Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Shadowlord]

On the subject of integer sizes, in C++, they do vary by compiler and platform. It's actually standard (unless the standard has changed in the past ~10 years) in c and c++ for 'long' to mean 32-bit, not 64-bit, even if 'int' is also 32-bit. So for 64-bit integers, you end up with 'long long' or something else (if your compiler doesn't approve of "long long" and has its own thing instead).

Since 'int' can mean different things in c++ (and pointers can be different sizes, notable when making a 64-bit program, you have 64-bit pointers, but int is still 32-bit), it's convenient to use types that explicitly specify the size.

You can also use languages where the differently sized integers (8, 16, 32, or 64 bits, generally) are all standard types. Some of them (like C#) even say that 'int' will always be 32 bits everywhere, 'short' will always be 16 bits, 'long' will always be 64 bits, etc.

(Aside: java lacks unsigned integer types, which is a real nuisance, but otherwise lets you specify the size of your integers unambiguously)
(Also: Go has int8, int16, int32, int64, uint versions of those, and 'int', which is guaranteed to be at least 32 bits.)

[Putnam]

C++ has those too AFAIK. IIRC Dwarf Fortress even explicitly uses uint32 and similar in a lot of places.

[Antsan]

Common Lisp has the types (integer [min] [max]), which allows the programmer to specify the exact range. The most efficient representation is automatically chosen by the compiler.

[Reelya]

I wonder if something similar could be pulled off in C++ using templates?

[milo christiansen]

90% of the time when you really care about the size of an integer, you car about it's size in bytes not its range. This is because size mostly matters when you are doing IO or bit manipulation. Only rarely do you need to worry about range, and then mostly only if you have huge data sets or you fell the need to use tiny integers.

C and C++ integer type conventions are totally screwed, for that matter most of their type names are weird. "int64_t" as an *optional* extension? "long long int"? Why not do like Go does and have "int64", etc. No room for vendor specific weirdness there. C and C++ suffer from *way* too much backwards compatibility cruft, they really should be redesigned to some extent, particularly to get rid of weird type names and other "made sense back then"names and conventions.

Lets not get started on why "int" is 32 bits on 64 bit systems (in direct contravention of the C/C++ specifications!).

[Reelya]

Lets not get started on why "int" is 32 bits on 64 bit systems

You're seriously suggestion that "int" should mean 64 bits if you do a 64-bit compile? Weren't you just complaining that "long" was ambiguous based on platform? Why would you actually desire "int" to become ambiguous but in a worse way? Long is used rarely, int is used all the time.

And any benefit of having your ints aligned on 64-bit memory boundaries is negated by the fact that computers don't read single values from memory very often (if you've written your program in a sensibly optimized fashion), they read 64 byte cache lines. So, a main memory read right now can pull up 16 ints, but if you padded them all to 64 bits, you can only read 8 ints per cache line. Sure, there's a little overhead to put 32 bit values into 64 bit registers, but it's way less than the time needed to read values out of the main memory bus. So, magically turning all your ints into 64 bit values because "we're doing a 64 bit build" is basically going to fuck things up and cause incompatibilities. e.g. what happens when you serialize those values to disk or between programs. Now, you have an "oh shit!" moment since the data isn't going to be portable between different builds of the same software.

(in direct contravention of the C/C++ specifications!).

There's no such requirement that int should mean 64 bits. Not in C++, and certainly not in C. Only minimum sizes are specified, and everyone has basically agreed to stick to the minimum sizes for all the commonly named types. Which is just plain common sense. Why redefine what commonly-understood words mean, when there's no benefit to doing so.

[milo christiansen]

int should be the natural size suggested by the architecture

[Reelya]

Googling that, I find exactly one citation which is ISO/IEC 9899:1990 Standard ("ANSI C"). Which is way out-dated. C++ has no such restriction, nor do more recent versions of C.

Also, complaining about how they aren't going with the times by changing what "int" means is contradictory. Java isn't doing that, nor is C#. Int is 32 bits on modern C, C++, Java, and C#. Why would anyone want to change that? C and C++ only specify a minumum data length for each type. But by convention, people have just stuck them at predictable sizes and left them at that. The only caveat is "long" which got expanded to 64 bits by some vendors, but left at the size of int by other vendors. Having exactly one rarely-used type that's ambiguous is a minor issue.

btw with stdint.h, they have the _t suffixes on them so that the types won't pollute the namespace, and you can typedef them to be called whatever you like. e.g. you could typedef int8_t byte;, then use "byte" in your program for all 8-bit values. This would simplify porting it to C# and Java, which use 16-bit unicode chars.

[milo christiansen]

Int is 32 bits on modern C, C++, Java, and C#. Why would anyone want to change that?

Because 32 bit ints are slower (require extra instructions to process) on 64 bit processors in certain cases? It should be obvious to anyone who knows asembly...

There are some tricks compiler writers use, but they boil down to ugly hacks.

[Reelya]

Reading a cache line from main memory takes about 200 clock cycles. Conversion functions take a few clock cycles. If you're processing sequential data then the time to load your zero-padded 64 bit values outweighs any streamlining inside the CPU. Clearly, any sort of copying function isn't going to be helped by doubling of all the memory requirements.

With 64 byte cache lines, that's 25 clock cycles per 64 bit value vs 12.5 clock cycles per 32 bit value. You can do a lot in an extra 12 clock cycles.

[Antsan]

90% of the time when you really care about the size of an integer, you car about it's size in bytes not its range.

There are the type specifiers (signed-byte [bytes]) and (unsigned-byte [bytes]).
As a Common Lisper I seldom care about bit-fiddling and IO certainly is handled perfectly well with arbitrary data, but if bit fiddling should be necessary, it is available as needed. And still more expressive than C/C++, it seems.

[nogoodnames]

Bleurgh.

I don't suppose anyone here has experience with using background tasks on Windows 10 phones, do they?
Of course not, no one uses Windows phones.

[frostshotgg]

This is totally spitballing, but if Win10 phones use UWP this might be useful.

[nogoodnames]

Yeah, I've looked at that before.

I think I may know what my problem is. I've been getting errors while trying to run an indefinite background task with a DeviceUse trigger. It seems like the tasks I registered aren't getting disposed properly and carrying over to the next time I run the program, which causes problems.

I wish Microsoft would make their error descriptions a bit more useful. All I was getting for that was "A method was called at an unexpected time."

Edit: Well, I've tried everything I could think of and it still isn't working right. It will work once after I restart the phone, but no matter what I do I can't seem to get the background task to properly end without leaving anything behind.

[Bumber]

I wish Microsoft would make their error descriptions a bit more useful. All I was getting for that was "A method was called at an unexpected time."

"Something happened" -Windows 10 Setup