>But it would be nice to have an official alias for the system native register sized type.

I agree this would probably be sufficient, we need both signed and unsigned aliases.

I would like to see standard aliases that would map into:

C language typical compiler for CPU (the one you will link with)
int
unsigned int

Anyone have a good name?  I'm not a big fan of the fast integer name. How about something with native?

Should it go here? http://www.digitalmars.com/d/phobos/std_stdint.html

I vote "size_t" and "ptrdiff_t".

-[Unknown]


>>But it would be nice to have an official alias for the system native register sized type.
> 
> 
> I agree this would probably be sufficient, we need both signed and unsigned
> aliases. 
> 
> I would like to see standard aliases that would map into:
> 
> C language typical compiler for CPU (the one you will link with)
> int unsigned int
> 
> Anyone have a good name?  I'm not a big fan of the fast integer name. How about something with native?
> 
> Should it go here?
> http://www.digitalmars.com/d/phobos/std_stdint.html
> 
> 
> 

"Unknown W. Brackets" <unknown@simplemachines.org> wrote in message news:dm59m5$1777$1@digitaldaemon.com...
>I vote "size_t" and "ptrdiff_t".
>> Should it go here? http://www.digitalmars.com/d/phobos/std_stdint.html

Blergh X-(
All those _t's are so ugly!

How about calling the native ones int/uint? Wouldn't break any existing code ;-)

L.

Yes, it would.  My ints are 32 bits, and I love that D guarantees that.  They round when they round, and cause no strange bugs.  If I cast to an int array, I break something into the right size chunks.

You may dislike this style of programming.  You may use int32_t or something whenever depending on the size of an int.  But not everyone does, when the language promises otherwise (and some even when it doesn't!)

It would break existing code.  So, what you want, is to take a situation where you can do everything you want, but have to put an alias in because you hate size_t's name.... and change it to one that breaks code and is exactly the situation D was moving away from by changing int to be fixed size!

That's not progress.  I'll keep the horse off my car, thank you very much, even if it would save me paying gas to do otherwise.

-[Unknown]


> "Unknown W. Brackets" <unknown@simplemachines.org> wrote in message news:dm59m5$1777$1@digitaldaemon.com...
> 
>>I vote "size_t" and "ptrdiff_t".
>>
>>>Should it go here?
>>>http://www.digitalmars.com/d/phobos/std_stdint.html
> 
> 
> Blergh X-(
> All those _t's are so ugly!
> 
> How about calling the native ones int/uint? Wouldn't break any existing code ;-)
> 
> L. 
> 
> 

"Unknown W. Brackets" <unknown@simplemachines.org> wrote in message news:dmi2gj$1qtj$1@digitaldaemon.com...
>> How about calling the native ones int/uint? Wouldn't break any existing code
> It would break existing code.

Please explain how 'making int/uint machine register size' would break any _existing_ code?

L.

Lionello Lunesu wrote:
> "Unknown W. Brackets" <unknown@simplemachines.org> wrote in message news:dmi2gj$1qtj$1@digitaldaemon.com...
> 
>>>How about calling the native ones int/uint? Wouldn't break any existing code
>>
>>It would break existing code.
> 
> 
> Please explain how 'making int/uint machine register size' would break any _existing_ code?

Old behavior:

int a = 2147483647;
a++;
writefln(a);	// -2147483648;

New behavior (64-bit architecture):

int a = 2147483647;
a++;
writefln(a);	// 2147483648;


I'm not saying this is a proper use of int's. I've used this approach with fixed point angles. It might break if you do some complex bit operations.

Mark T wrote:

>>But it would be nice to have an official alias for the system native register sized type.
> 
> 
> I agree this would probably be sufficient, we need both signed and unsigned
> aliases. 
> 
> I would like to see standard aliases that would map into:
> 
> C language typical compiler for CPU (the one you will link with)
> int unsigned int
> 
> Anyone have a good name?  I'm not a big fan of the fast integer name. How about something with native?
> 
> Should it go here?
> http://www.digitalmars.com/d/phobos/std_stdint.html
> 
> 
> 

alias int register;
(Of course you have a 80x87 FPU which has registers also)

Optimizing programs which have yet to be written on hardware which has yet to be built.  I have to say this is the most premature optimization ever!

Software engineers are the only people who wring their hands over whether something is the maximum possible speed/efficiency/etc.  For every problem there is a min/max criteria needed for each component.

Its like a construction foreman repouring cement 20 times even though any of the batches are within acceptible strength limits for the task.

Absit injuria verbis
-DavidM

To add to Jari-Matti Mäkelä's comment, some people also have code that relies on the size of an int.  For example, shifting and bit operations.

Moreover, code that links with other code, and uses "int" where C uses a "long".  In other words, all of Phobos would have to be changed if the size of an int were changed.

Don't think of it like a max.  That's not what it is.  Think of it as a number of bytes.  If you make all the cars on the road twice as wide, things are going to get crazy.  It's not just a matter of the car having more space inside.

-[Unknown]


> "Unknown W. Brackets" <unknown@simplemachines.org> wrote in message news:dmi2gj$1qtj$1@digitaldaemon.com...
> 
>>>How about calling the native ones int/uint? Wouldn't break any existing code
>>
>>It would break existing code.
> 
> 
> Please explain how 'making int/uint machine register size' would break any _existing_ code?
> 
> L. 
> 
>