Why typedef's shouldn't have been removed :(

Matt Peterson ricochet1k at gmail.com
Sat May 5 20:15:00 PDT 2012


I understand you're frustrated, but you don't need to be so
hostile. I agree with most of what you've said on this thread.
And just because I made a short comment doesn't mean I don't know
about std.stdint, sizediff_t, etc. My point was to say that
size_t is supposed to be the size of the architecture's word. I
said nothing about it being the "fastest" type or even whether it
was useful . I would be very interested if you have a better
solution for the integer typing/naming problem.

There definitely needs to be way to define a type that can't
implicitly cast to its base type. The problem is that the
original typedef did do implicit casting away, and that has
potential to cause confusion when porting from C or D1. I don't
see that as much of a problem, but others might.




On Sunday, 6 May 2012 at 02:25:54 UTC, Mehrdad wrote:
>> The point of size_t is to be the native word-sized integer for 
>> the platform
>
> "Native word-sized integer" is such a blurry term, but of course
> you
> wouldn't know this without understanding why C has a gazillion
> "native" integer types... (hint: if you're trying to justify
> these with today's x86 processors, you're already on the wrong
> track)
>
> The point of size_t is for it to be able to represent the size 
> of
> something. That's all.
>
> The point of sizediff_t is for it to be able to represent the
> difference between two size_t's. That's all.
>
> The point of ptrdiff_t is for it to be able to represent the
> difference between two pointers. That's all.
>
> Those three need NOT be the same size on the same machine, and
> they need NOT be the same as the "fastest" integers on any
> platform.
> That's the whole point of std.stdint, in case you hadn't heard 
> of
> it.
>
>
>
>> That doesn't compile on x86_64.
>
> I can't tell if you're missing my point or what...
> In case that was unclear:
> ***** I'm saying that shouldn't compile on *ANY* platform. ****
>
> What you're saying is like saying "dchar[] function()" should be
> interchangeable with "uint[] function()" just because they're 
> the same data on the same
> platform.
>
> Or like saying class Bar { } and class Foo { } should be
> interchangeable because there's no actual difference between 
> them.
>
> Or like saying "HWND function()" and "HANDLE function()" and
> "void* function()" should be
> interchangeable because they're all the same anyway.
>
> Kind of silly IMO.


More information about the Digitalmars-d mailing list