On Tue, 15 Feb 2011 09:26:21 -0500, spir <denis.spir@gmail.com> wrote:

> On 02/15/2011 02:36 PM, Steven Schveighoffer wrote:

>>
>> Hey, bikeshedders, I found this cool easter-egg feature in D! It's called
>> alias! Don't like the name of something? Well you can change it!
>>
>> alias size_t wordsize;
>>
>> Now, you can use wordsize instead of size_t in your code, and the compiler
>> doesn't care! (in fact, that's all size_t is anyways *hint hint*)
>
> Sure, but it's not the point of this one bikeshedding thread. If you do that, then you're the only one who knows what "wordsize" means. Good, maybe, for app-specific semantic notions (alias Employee[] Staff;); certainly not for types at the highest degree of general purpose like size_t. We need a standard alias.

The standard alias is size_t.  If you don't like it, alias it to something else.  Why should I have to use something that's unfamiliar to me because you don't like size_t?

I guarantee whatever you came up with would not be liked by some people, so they would have to alias it, you can't please everyone.  size_t works, it has a precedent, it's already *there*, just use it, or alias it if you don't like it.

No offense, but this discussion is among the most pointless I've seen.

-Steve

spir wrote:
> On 02/15/2011 02:01 PM, Daniel Gibson wrote:
> >Am 15.02.2011 12:50, schrieb spir:
> >>On 02/15/2011 03:44 AM, Piotr Szturmaj wrote:
> >>>spir wrote:
> >>>>Rename size-t, or rather introduce a meaningful standard alias? (would
> >>>>vote for Natural)
> >>>
> >>>Maybe ptrint and ptruint?
> >>
> >>If ptr means pointer, then it's wrong: size-t is used for more than that, I guess. Strangely enough, while "size" may suggest it, .length does not return a size_t but an uint.
> >>
> >>Denis
> >
> >.length of what? An array?
> >I'm pretty sure it returns size_t.
> 
> unittest {
>     int[] ints; auto l = ints.length;
>     writeln(typeof(l).stringof);
> }
> press play ;-)

I do not get it.
The above returns uint which is fine because my dmd v2.051 is 32-bit
only. I.e. size_t is an alias to uint (see src/druntime/src/object_.d
lin 52).
But somehow I think you are implying it does not return size_t.
This is right in the sense that it does not return the alias name size_t
but it returns the aliased type name, namely uint. What's the problem?
This
writeln(size_t.stringof);
also returns uint.
I read that the compiler is free to return whatever name of an alias,
i.e. either the name of the alias or the name of the thing it was
aliased to (which can be again an alias). I do not understand the rule
for stringof (reading
http://www.digitalmars.com/d/2.0/property.html#stringof) but I never had
a problem.

Jens

== Quote from dsimcha (dsimcha@yahoo.com)'s article
> Now that DMD has a 64-bit beta available, I'm working on getting a whole bunch of code to compile in 64 mode.  Frankly, the compiler is way too freakin' pedantic when it comes to implicit conversions (or lack thereof) of array.length.  99.999% of the time it's safe to assume an array is not going to be over 4 billion elements long.  I'd rather have a bug the 0.001% of the time than deal with the pedantic errors the rest of the time, because I think it would be less total time and effort invested.  To force me to either put casts in my code everywhere or change my entire codebase to use wider integers (with ripple effects just about everywhere) strikes me as purity winning out over practicality.

I have a similar grudge about short's being implicitly converted to int's, resulting in hundreds of unwanted casts thrown in everywhere cluttering up code.

ie:
   short a,b,c,;
   a = b + c;

Hidden implicit casts should die.

Daniel Gibson:

> void main() {
>    size_t x;
>    writefln(typeof(x).stringof);
> }
> try this, too ;-)
> 
> Because it's an alias the information about size_t gone at runtime and the "real" type is shown. uint in your case. (Here - gdc on amd64 - it's ulong).

I think both typeof() and stringof are compile-time things.

And regarding lost alias information I suggest to do as Clang does: http://d.puremagic.com/issues/show_bug.cgi?id=5004

Bye,
bearophile

spir wrote:
> Having to constantly explain that "_t" means type, that "size" does not mean size, what this type is supposed to mean instead, what it is used for in core and stdlib functionality, and what programmers are supposed to use it for... isn't this a waste of our time? This, only because the name is mindless?

No, because there is a vast body of work that uses size_t and a vast body of programmers who know what it is and are totally used to it.

I think David has raised a good point here that seems to have been lost in the discussion about naming.

Please note that the C name of the machine word integer was usually called "int". The C standard only specifies a minimum bit-size for the different types (see for example http://www.ericgiguere.com/articles/ansi-c-summary.html). Most of current C++ implementations have identical "int" sizes, but now "long" is different. This approach has failed and has caused many headaches when porting software from one platform to another. D has recognized this and has explicitely defined the bit-size of the various integer types. That's good!

Now, with size_t the distinction between platforms creeps back into the language. It is everywhere across phobos, be it as length of ranges or size of containers. This can get viral, as everything that gets in touch with these values might have to stick to size_t. Is this really desired?

Consider saving an array to disk, trying to read it on another platform. How many bits should be written for the size of that array?

Consider a range that maps the contents of a file. The file can be larger than 4GB, though a lot of the ranges that wrap the file mapping range will truncate the length to 32 bit on 32-bit platforms.

I don't have a perfect solution, but maybe builtin arrays could be limited to 2^^32-1 elements (or maybe 2^^31-1 to get rid of endless signed/unsigned conversions), so the normal type to be used is still "int". Ranges should adopt the type sizes of the underlying objects.

Agreed, a type for the machine word integer must exist, and I don't care how it is called, but I would like to see its usage restricted to rare cases.

Rainer


dsimcha wrote:
> Now that DMD has a 64-bit beta available, I'm working on getting a whole bunch
> of code to compile in 64 mode.  Frankly, the compiler is way too freakin'
> pedantic when it comes to implicit conversions (or lack thereof) of
> array.length.  99.999% of the time it's safe to assume an array is not going
> to be over 4 billion elements long.  I'd rather have a bug the 0.001% of the
> time than deal with the pedantic errors the rest of the time, because I think
> it would be less total time and effort invested.  To force me to either put
> casts in my code everywhere or change my entire codebase to use wider integers
> (with ripple effects just about everywhere) strikes me as purity winning out
> over practicality.

On Tue, 15 Feb 2011 14:15:06 -0500, Rainer Schuetze <r.sagitario@gmx.de> wrote:

>
> I think David has raised a good point here that seems to have been lost in the discussion about naming.
>
> Please note that the C name of the machine word integer was usually called "int". The C standard only specifies a minimum bit-size for the different types (see for example http://www.ericgiguere.com/articles/ansi-c-summary.html). Most of current C++ implementations have identical "int" sizes, but now "long" is different. This approach has failed and has caused many headaches when porting software from one platform to another. D has recognized this and has explicitely defined the bit-size of the various integer types. That's good!
>
> Now, with size_t the distinction between platforms creeps back into the language. It is everywhere across phobos, be it as length of ranges or size of containers. This can get viral, as everything that gets in touch with these values might have to stick to size_t. Is this really desired?

Do you really want portable code?  The thing is, size_t is specifically defined to be *the word size* whereas C defines int as a fuzzy size "should be at least 16 bits, and recommended to be equivalent to the natural size of the machine".  size_t is *guaranteed* to be the same size on the same platform, even among different compilers.

In addition size_t isn't actually defined by the compiler.  So the library controls the size of size_t, not the compiler.  This should make it extremely portable.

> Consider saving an array to disk, trying to read it on another platform. How many bits should be written for the size of that array?

It depends on the protocol or file format definition.  It should be irrelevant what platform/architecture you are on.  Any format or protocol worth its salt will define what size integers you should store.

Then you need a protocol implementation that converts between the native size and the stored size.

This is just like network endianness vs. host endianness.  You always use htonl and ntohl even if your platform has the same endianness as the network, because you want your code to be portable.  Not using them is a no-no even if it works fine on your big-endian system.

> I don't have a perfect solution, but maybe builtin arrays could be limited to 2^^32-1 elements (or maybe 2^^31-1 to get rid of endless signed/unsigned conversions), so the normal type to be used is still "int". Ranges should adopt the type sizes of the underlying objects.

No, this is too limiting.  If I have 64GB of memory (not out of the question), and I want to have a 5GB array, I think I should be allowed to.  This is one of the main reasons to go to 64-bit in the first place.

-Steve

On 02/15/2011 03:25 PM, Daniel Gibson wrote:
> Am 15.02.2011 15:18, schrieb spir:
>> On 02/15/2011 02:01 PM, Daniel Gibson wrote:
>>> Am 15.02.2011 12:50, schrieb spir:
>>>> On 02/15/2011 03:44 AM, Piotr Szturmaj wrote:
>>>>> spir wrote:
>>>>>> Rename size-t, or rather introduce a meaningful standard alias? (would
>>>>>> vote for Natural)
>>>>>
>>>>> Maybe ptrint and ptruint?
>>>>
>>>> If ptr means pointer, then it's wrong: size-t is used for more than
>>>> that, I guess. Strangely enough, while "size" may suggest it, .length
>>>> does not return a size_t but an uint.
>>>>
>>>> Denis
>>>
>>> .length of what? An array?
>>> I'm pretty sure it returns size_t.
>>
>> unittest {
>> int[] ints; auto l = ints.length;
>> writeln(typeof(l).stringof);
>> }
>> press play ;-)
>>
>> denis
>
> void main() {
> size_t x;
> writefln(typeof(x).stringof);
> }
> try this, too ;-)
>
> Because it's an alias the information about size_t gone at runtime and the
> "real" type is shown. uint in your case. (Here - gdc on amd64 - it's ulong).

Oops, you're right! had not realised yet names are de-aliased on output.

denis
-- 
_________________
vita es estrany
spir.wikidot.com

"bearophile" <bearophileHUGS@lycos.com> wrote in message news:ijefj9$25sm$1@digitalmars.com...
> Daniel Gibson:
>
>> void main() {
>>    size_t x;
>>    writefln(typeof(x).stringof);
>> }
>> try this, too ;-)
>>
>> Because it's an alias the information about size_t gone at runtime and the "real" type is shown. uint in your case. (Here - gdc on amd64 - it's ulong).
>
> I think both typeof() and stringof are compile-time things.
>
> And regarding lost alias information I suggest to do as Clang does: http://d.puremagic.com/issues/show_bug.cgi?id=5004
>

That would *really* be nice. In my Goldie parsing lib, I make heavy use of templated aliases to provide maximally-reader-friendly types for strongly-typed tokens (ie, if the programmer desires, each symbol and each production rule has its own type, to ensure maximum compile-time safety). These aliases wrap much less readable internal types. Expecting the user to understand the internal type for any error message is not nice.

"Jens Mueller" <jens.k.mueller@gmx.de> wrote in message news:mailman.1694.1297781518.4748.digitalmars-d@puremagic.com...
>
> I read that the compiler is free to return whatever name of an alias, i.e. either the name of the alias or the name of the thing it was aliased to (which can be again an alias). I do not understand the rule for stringof (reading http://www.digitalmars.com/d/2.0/property.html#stringof) but I never had a problem.
>

DMD itself has never really understood stringof.