problem with size_t and an easy solution

ketmar via Digitalmars-d digitalmars-d at puremagic.com
Mon Dec 8 06:28:55 PST 2014


On Mon, 08 Dec 2014 14:00:25 +0000
Jonathan Marler via Digitalmars-d <digitalmars-d at puremagic.com> wrote:

> On Monday, 8 December 2014 at 11:49:47 UTC, ketmar via 
> Digitalmars-d wrote:
> > On Mon, 08 Dec 2014 11:37:00 +0000
> > Dominikus Dittes Scherkl via Digitalmars-d
> > <digitalmars-d at puremagic.com> wrote:
> >
> >> On Monday, 8 December 2014 at 08:46:49 UTC, bearophile wrote:
> >> > Freddy:
> >> >
> >> >> Why not keep size_t implictly convertable but disallow it 
> >> >> for
> >> >> usize.
> >> >
> >> > This is an interesting idea. (But the name "uword" seems 
> >> > better).
> >> YES.
> >> And I want a signed variant of this (instead of the ugly 
> >> ptrdiff_t):
> >> I want to wield my sword!
> > "uword" is meaningless, and "usize" is meaningfull. but i like
> > "sword"... yet i used to 16-bit words.
> 
> This is just my opinion and I could be persuaded otherwise but 
> word/uword seem nicer.  It seems more descriptive, the size of a 
> word on the system. Also I see less potential for name conflicts. 
>   The type "size" will probably conflict with alot of symbol names 
> (function names/variables/etc).  I would be willing to bet this 
> is why C/C++ initially used "size_t" instead of "size" in the 
> first place.
ah, there can't be "size" type, only "usize". we can't have list or
array with -3 items. ;-) and even if we want signed size, this will be
"ssize". we already have "byte" instead of "sbyte", it's PITA.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: not available
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20141208/8e235ef8/attachment.sig>


More information about the Digitalmars-d mailing list