Re: uint64_t error and architecture targets
Re: uint64_t error and architecture targets
- Subject: Re: uint64_t error and architecture targets
- From: Andreas Grosam <email@hidden>
- Date: Fri, 11 Feb 2011 15:52:30 +0100
On Feb 11, 2011, at 10:43 AM, Quincey Morris wrote:
> On Feb 11, 2011, at 00:55, Andreas Grosam wrote:
>
>> In C++ I would prefer to write
>>
>> #include <limits>
>> #include <stdint.h>
>>
>> uint64_t y = std::numeric_limits<uint64_t>::max();
>
> Sorry, I have to admit I LOL'ed.
>
> C++ takes:
>
> 2 #includes
> 2 operators
> 1 namespace
> 1 template instantiation
> 1 function
>
> to do what C does with "-1", but it does it so much *better* than C. It's a perfect example of what's wrong with C++. :)
I just wanted to suggest a more proper way to do this kind of stuff.
Well, at least here, what's apparently wrong with C++ makes the code robust, maintainable and easily understandable. And don't think the compiler expands this to a whole bunch of machine statements - it's as small as it can be. On the other hand, using the assignment with a constant -1 can lead quickly to broken code. Just consider this:
Within some class:
typedef unsigned int index_type;
...
const index_type MAX_INDEX = -1;
Now, just imagine, a co-worker changes - for some good reason - the type for index_type:
typedef signed long long index_type;
Notice *signed* !
After changing this, the rest of the code will most likely not work as before. If you were a thrill-seeker, you might even wrote:
some_unsigned_integer_type MAX_INDEX = -1;
Because, mixing singed and unsigned integers in calculations might yield surprising results - if you don't understand the underlaying model how C performs such arithmetic. Your code would be broken now.
Instead, if you were using
const index_type MAX_INDEX = std::numeric_limits<index_type>::max();
the code would (most likely) run as before.
So, while it may be appealing to use a parsimonious C style which makes your fingers happy for a few seconds, it may make the maintainers go nuts later for a long time.
Furthermore, I don't think the cost for writing a few more characters is as cumbersome as it appears ;)
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden