Integer conversions too pedantic in 64-bit
Jonathan M Davis
jmdavisProg at gmx.com
Tue Feb 15 14:28:19 PST 2011
On Tuesday, February 15, 2011 14:00:12 Nick Sabalausky wrote:
> "so" <so at so.so> wrote in message news:op.vqyk3emumpw3zg at so-pc...
>
> >> I disagree that the discussion is pointless.
> >> On the contrary, the OP pointed out some valid points:
> >>
> >> 1. that size_t is inconsistent with D's style guide. the "_t" suffix is
> >> a C++ convention and not a D one. While it makes sense for [former?] C++
> >> programmers it will confuse newcomers to D from other languages that
> >> would expect the language to follow its own style guide.
> >> 2. the proposed change is backwards compatible - the OP asked for an
> >> *additional* alias.
> >> 3. generic concepts should belong to the standard library and not user
> >> code which is also where size_t is already defined.
> >>
> >> IMO, we already have a byte type, it's plain common sense to extend this
> >> with a "native word" type.
> >
> > Funny thing is the most important argument against size_t got the least
> > attention.
> > I will leave it as an exercise for the reader.
>
> That variables of type "size_t" are frequently used to store indicies
> rather than the actual *size* of anything?
>
> That it does nothing to help with 32/64-bit portability until you actually
> compile your code both ways?
What _does_ have to do with 32/64-bit portability until you compile both ways?
Regardless of what the name is, it's still going to be the word size of the
machine and vary between 32-bit and 64-bit anyway.
- Jonathan M Davis
More information about the Digitalmars-d
mailing list