On Tuesday, February 15, 2011 15:13:33 spir wrote:
> On 02/15/2011 11:24 PM, Jonathan M Davis wrote:
> > Is there some low level reason why size_t should be signed or something I'm completely missing?
> 
> My personal issue with unsigned ints in general as implemented in C-like
> languages is that the range of non-negative signed integers is half of the
> range of corresponding unsigned integers (for same size).
> * practically: known issues, and bugs if not checked by the language
> * conceptually: contradicts the "obvious" idea that unsigned (aka naturals)
> is a subset of signed (aka integers)

It's inevitable in any systems language. What are you going to do, throw away a bit for unsigned integers? That's not acceptable for a systems language. On some level, you must live with the fact that you're running code on a specific machine with a specific set of constraints. Trying to do otherwise will pretty much always harm efficiency. True, there are common bugs that might be better prevented, but part of it ultimately comes down to the programmer having some clue as to what they're doing. On some level, we want to prevent common bugs, but the programmer can't have their hand held all the time either.

- Jonathan M Davis

On 2011-02-15 22:41:32 -0500, "Nick Sabalausky" <a@a.a> said:

> I like "nint".

But is it unsigned or signed? Do we need 'unint' too?

I think 'word' & 'uword' would be a better choice. I can't say I'm too displeased with 'size_t', but it's true that the 'size_t' feels out of place in D code because of its name.


-- 
Michel Fortin
michel.fortin@michelf.com
http://michelf.com/

"Michel Fortin" <michel.fortin@michelf.com> wrote in message news:ijfhkt$1fte$1@digitalmars.com...
> On 2011-02-15 22:41:32 -0500, "Nick Sabalausky" <a@a.a> said:
>
>> I like "nint".
>
> But is it unsigned or signed? Do we need 'unint' too?
>

*shrug* Beats me. I can't even remember if size_t is signed or not.

> I think 'word' & 'uword' would be a better choice.

The only problem I have with that is that "word" seems like something you might want to use as a variable name in certain cases. However, I'd still prefer "word" over "size_t"

> I can't say I'm too displeased with 'size_t', but it's true that the 'size_t' feels out of place in D code because of its name.
>

Disagree quite strongly -- use the correct type. Yes, lengths are ulongs on AMD64, yes this means a lot of uints turn into size_t, but that's how it's supposed to be IMO.

On 2/15/11 11:33 PM, Nick Sabalausky wrote:
> "Michel Fortin"<michel.fortin@michelf.com>  wrote in message
> news:ijfhkt$1fte$1@digitalmars.com...
>> On 2011-02-15 22:41:32 -0500, "Nick Sabalausky"<a@a.a>  said:
>>
>>> I like "nint".
>>
>> But is it unsigned or signed? Do we need 'unint' too?
>>
>
> *shrug* Beats me. I can't even remember if size_t is signed or not.
>

size_t is unsigned in C/C++, whereas ssize_t is signed.

I like word/uword as well, but word is too common as a variable name.

What about archint/uarchint ?

Am 15.02.2011 22:49, schrieb Michel Fortin:
> On 2011-02-15 16:33:33 -0500, Walter Bright <newshound2@digitalmars.com>
> said:
>
>> Nick Sabalausky wrote:
>>> "Walter Bright" <newshound2@digitalmars.com> wrote in message
>>> news:ijeil4$2aso$3@digitalmars.com...
>>>> 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.
>>>
>>> And there's a vast body who don't.
>>>
>>> And there's a vast body who are used to C++, so let's just abandon D
>>> and make it an implementation of C++ instead.
>>
>> I would agree that D is a complete waste of time if all it consisted
>> of was renaming things.
>
> I'm just wondering whether 'size_t', because it is named after its C
> counterpart, doesn't feel too alien in D, causing people to prefer
> 'uint' or 'ulong' instead even when they should not. We're seeing a lot
> of code failing on 64-bit because authors used the fixed-size types
> which are more D-like in naming. Wouldn't more D-like names that don't
> look like relics from C -- something like 'word' and 'uword' -- have
> helped prevent those bugs by making the word-sized type look worth
> consideration?
>
I am also for renaming it. It should begin with u to ensure everybody knows it's unsigned even if there's no signed counterpart.

But what we definitely should avoid is to have two names for the same thing. It's the same mistake C++ did with inheriting everything from C and _adding_ it's own way.

Mafi

On 02/16/2011 04:49 AM, Michel Fortin wrote:
> On 2011-02-15 22:41:32 -0500, "Nick Sabalausky" <a@a.a> said:
>
>> I like "nint".
>
> But is it unsigned or signed? Do we need 'unint' too?
>
> I think 'word' & 'uword' would be a better choice. I can't say I'm too
> displeased with 'size_t', but it's true that the 'size_t' feels out of place in
> D code because of its name.

yop! Vote for word / uword.
unint looks like meaning (x € R / not (x € Z)) lol!

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

On 02/16/2011 03:07 AM, Jonathan M Davis wrote:
> On Tuesday, February 15, 2011 15:13:33 spir wrote:
>> On 02/15/2011 11:24 PM, Jonathan M Davis wrote:
>>> Is there some low level reason why size_t should be signed or something
>>> I'm completely missing?
>>
>> My personal issue with unsigned ints in general as implemented in C-like
>> languages is that the range of non-negative signed integers is half of the
>> range of corresponding unsigned integers (for same size).
>> * practically: known issues, and bugs if not checked by the language
>> * conceptually: contradicts the "obvious" idea that unsigned (aka naturals)
>> is a subset of signed (aka integers)
>
> It's inevitable in any systems language. What are you going to do, throw away a
> bit for unsigned integers? That's not acceptable for a systems language. On some
> level, you must live with the fact that you're running code on a specific machine
> with a specific set of constraints. Trying to do otherwise will pretty much
> always harm efficiency. True, there are common bugs that might be better
> prevented, but part of it ultimately comes down to the programmer having some
> clue as to what they're doing. On some level, we want to prevent common bugs,
> but the programmer can't have their hand held all the time either.

I cannot prove it, but I really think you're wrong on that.

First, the question of 1 bit. Think at this -- speaking of 64 bit size:
* 99.999% of all uses of unsigned fit under 2^63
* To benefit from the last bit, you must have the need to store a value 2^63 <= v < 2^64
* Not only this, you must step on a case where /any/ possible value for v (depending on execution data) could be >= 2^63, but /all/ possible values for v are guaranteed < 2^64
This can only be a very small fraction of cases where your value does not fit in 63 bits, don't you think. Has it ever happened to you (even in 32 bits)? Something like: "what a luck! this value would not (always) fit in 31 bits, but (due to this constraint), I can be sure it will fit in 32 bits (always, whatever input data it depends on).
In fact, n bits do the job because (1) nearly all unsigned values are very small (2) the size used at a time covers the memory range at the same time.

Upon efficiency, if unsigned is not a subset of signed, then at a low level you may be forced to add checks in numerous utility routines, the kind constantly used, everywhere one type may play with the other. I'm not sure where the gain is.
Upon correctness, intuitively I guess (just a wild guess indeed) if unigned values form a subset of signed ones programmers will more easily reason correctly about them.

Now, I perfectly understand the "sacrifice" of one bit sounds like a sacrilege ;-)
(*)

Denis

(*) But you know, when as a young guy you have coded for 8 & 16-bit machines, having 63 or 64...
-- 
_________________
vita es estrany
spir.wikidot.com

Jonathan M Davis wrote:
> It's inevitable in any systems language. What are you going to do, throw away a bit for unsigned integers? That's not acceptable for a systems language. On some level, you must live with the fact that you're running code on a specific machine with a specific set of constraints. Trying to do otherwise will pretty much always harm efficiency. True, there are common bugs that might be better prevented, but part of it ultimately comes down to the programmer having some clue as to what they're doing. On some level, we want to prevent common bugs, but the programmer can't have their hand held all the time either.

Yup. A systems language is going to map closely onto the target machine, and that means its characteristics will show up in the language. Trying to pretend that arithmetic on integers is something other than what the CPU natively does just will not work.

== Quote from spir (denis.spir@gmail.com)'s article
> On 02/16/2011 04:49 AM, Michel Fortin wrote:
> > On 2011-02-15 22:41:32 -0500, "Nick Sabalausky" <a@a.a> said:
> >
> >> I like "nint".

It's the machine integer, so I think the word 'mint' would better match your naming logic. Also, reminds me of this small advert: http://www.youtube.com/watch?v=zuy6o8YXzDo ;)

> >
> > But is it unsigned or signed? Do we need 'unint' too?
> >
> > I think 'word' & 'uword' would be a better choice. I can't say I'm too displeased with 'size_t', but it's true that the 'size_t' feels out of place in D code because of its name.
> yop! Vote for word / uword.
> unint looks like meaning (x € R / not (x € Z)) lol!
> Denis

word/uword sits well with my understanding.