www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - The "_t" name idiom in size_t, ptrdiff_t, etc.

reply Bruno Medeiros <daiphoenixNO SPAMlycos.com> writes:
This is a minor issue, but still:
I was browsing through some of those other threads where size_t and and 
ptrdiff_t was talked about, and then I thought, should we be using the 
C-legacy "_t" name idiom in these D types? Is it not ugly and 
unconsistent with the rest of the language (types)?
It seems to me so, at first glance, so maybe we should change the name 
then. To what exactly I'm not sure, maybe (memsize, ptrdiff), (msize, 
ptrdiff) or (umsize, msize), but these are just some initial suggestions.


-- 
Bruno Medeiros
Computer Science/Engineering student
Sep 27 2005
parent reply AJG <AJG_member pathlink.com> writes:
In article <dhb4jr$m2r$1 digitaldaemon.com>, Bruno Medeiros says...

This is a minor issue, but still:
I was browsing through some of those other threads where size_t and and 
ptrdiff_t was talked about, and then I thought, should we be using the 
C-legacy "_t" name idiom in these D types? Is it not ugly and 
unconsistent with the rest of the language (types)?
It seems to me so, at first glance, so maybe we should change the name 
then. To what exactly I'm not sure, maybe (memsize, ptrdiff), (msize, 
ptrdiff) or (umsize, msize), but these are just some initial suggestions.


I concur.
--AJG.
Sep 27 2005
parent reply Georg Wrede <georg.wrede nospam.org> writes:
AJG wrote:

 In article <dhb4jr$m2r$1 digitaldaemon.com>, Bruno Medeiros says...
 

This is a minor issue, but still:
I was browsing through some of those other threads where size_t and and 
ptrdiff_t was talked about, and then I thought, should we be using the 
C-legacy "_t" name idiom in these D types? Is it not ugly and 
unconsistent with the rest of the language (types)?
It seems to me so, at first glance, so maybe we should change the name 
then. To what exactly I'm not sure, maybe (memsize, ptrdiff), (msize, 
ptrdiff) or (umsize, msize), but these are just some initial suggestions.


 
 
 I concur.
 --AJG.


NO. There's nothing to be gained. And it would be a lot of work to again 
go through the libraries. And, those two names are Established in the 
Community. They have a very specific meaning to all professionals.

Their semantic meaning implicitly implies architecture dependence, which 
int or long don't.
Sep 27 2005
next sibling parent reply Don Clugston <dac nospam.com.au> writes:
Georg Wrede wrote:

 AJG wrote:
 

 In article <dhb4jr$m2r$1 digitaldaemon.com>, Bruno Medeiros says...


 This is a minor issue, but still:
 I was browsing through some of those other threads where size_t and 
 and ptrdiff_t was talked about, and then I thought, should we be 
 using the C-legacy "_t" name idiom in these D types? Is it not ugly 
 and unconsistent with the rest of the language (types)?
 It seems to me so, at first glance, so maybe we should change the 
 name then. To what exactly I'm not sure, maybe (memsize, ptrdiff), 
 (msize, ptrdiff) or (umsize, msize), but these are just some initial 
 suggestions.




 I concur.
 --AJG.


 
 
 NO. There's nothing to be gained. And it would be a lot of work to again 
 go through the libraries. And, those two names are Established in the 
 Community. They have a very specific meaning to all professionals.


The same is true of wchar_t, which C++ would love to change to wchar,
and which D has sucessfully changed. I think the Established Practice 
Argument is strong, but not overwhelming so. If there were a change, it 
would have to be to a clearly superior name. When you consider that the 
name should not conflict with a popular variable or function name, most 
of the good choices are already taken. I bet that if you do a search for 
'memsize' or 'ptrdiff' in C/C++/Java code, you'll get a lot of hits.
Personally, I doubt that satisfactory names exist, so ptrdiff_t and 
size_t are probably here to stay. But I'd be happy to be found wrong -- 
I agree that they are ugly.

With a bit of imagination, there may be other possibilities, though.

You can already do
typeof(x.size) a = x.size;

So you could imagine a property .sizetype as syntactic sugar for 
typeof(x.size), and similarly .difftype  for typeof(&x - &x). This type 
would be defined for all types.

Then you could have
typedef idouble any; // doesn't matter what type you use
alias any.sizetype size_t;
alias any.difftype ptrdiff_t;

for backwards compatibility with C.

I'm not proposing this, I don't really think it's a good idea.


 Their semantic meaning implicitly implies architecture dependence, which 
 int or long don't.


Agreed. But something like 'ptrdifftype' might.
Sep 27 2005
next sibling parent reply James Dunne <james.jdunne gmail.com> writes:
Don Clugston wrote:

 Georg Wrede wrote:
 

 AJG wrote:


 In article <dhb4jr$m2r$1 digitaldaemon.com>, Bruno Medeiros says...


 This is a minor issue, but still:
 I was browsing through some of those other threads where size_t and 
 and ptrdiff_t was talked about, and then I thought, should we be 
 using the C-legacy "_t" name idiom in these D types? Is it not ugly 
 and unconsistent with the rest of the language (types)?
 It seems to me so, at first glance, so maybe we should change the 
 name then. To what exactly I'm not sure, maybe (memsize, ptrdiff), 
 (msize, ptrdiff) or (umsize, msize), but these are just some initial 
 suggestions.





 I concur.
 --AJG.




 NO. There's nothing to be gained. And it would be a lot of work to 
 again go through the libraries. And, those two names are Established 
 in the Community. They have a very specific meaning to all professionals.


 
 
 The same is true of wchar_t, which C++ would love to change to wchar,
 and which D has sucessfully changed. I think the Established Practice 
 Argument is strong, but not overwhelming so. If there were a change, it 
 would have to be to a clearly superior name. When you consider that the 
 name should not conflict with a popular variable or function name, most 
 of the good choices are already taken. I bet that if you do a search for 
 'memsize' or 'ptrdiff' in C/C++/Java code, you'll get a lot of hits.
 Personally, I doubt that satisfactory names exist, so ptrdiff_t and 
 size_t are probably here to stay. But I'd be happy to be found wrong -- 
 I agree that they are ugly.
 
 With a bit of imagination, there may be other possibilities, though.
 
 You can already do
 typeof(x.size) a = x.size;
 


That has no meaning!  x.size is an integer property that returns the 
number of bytes that element x takes in memory.  Taking the typeof() 
that is completely worthless.  Without a test to back me up here, I 
would say it would always be of type int - a result from the internals 
of the compiler's implementation (and I've looked into the DMD front end 
code on more than one occasion).  If this is allowed by the reference 
compiler, then it is surely a side-effect.


 So you could imagine a property .sizetype as syntactic sugar for 
 typeof(x.size), and similarly .difftype  for typeof(&x - &x). This type 
 would be defined for all types.
 
 Then you could have
 typedef idouble any; // doesn't matter what type you use
 alias any.sizetype size_t;
 alias any.difftype ptrdiff_t;
 
 for backwards compatibility with C.
 
 I'm not proposing this, I don't really think it's a good idea.
 

 Their semantic meaning implicitly implies architecture dependence, 
 which int or long don't.


 
 
 Agreed. But something like 'ptrdifftype' might.
Sep 27 2005
parent reply Don Clugston <dac nospam.com.au> writes:
James Dunne wrote:

 Don Clugston wrote:
 

 Georg Wrede wrote:


 AJG wrote:


 In article <dhb4jr$m2r$1 digitaldaemon.com>, Bruno Medeiros says...


 This is a minor issue, but still:
 I was browsing through some of those other threads where size_t and 
 and ptrdiff_t was talked about, and then I thought, should we be 
 using the C-legacy "_t" name idiom in these D types? Is it not ugly 
 and unconsistent with the rest of the language (types)?
 It seems to me so, at first glance, so maybe we should change the 
 name then. To what exactly I'm not sure, maybe (memsize, ptrdiff), 
 (msize, ptrdiff) or (umsize, msize), but these are just some 
 initial suggestions.






 I concur.
 --AJG.





 NO. There's nothing to be gained. And it would be a lot of work to 
 again go through the libraries. And, those two names are Established 
 in the Community. They have a very specific meaning to all 
 professionals.




 The same is true of wchar_t, which C++ would love to change to wchar,
 and which D has sucessfully changed. I think the Established Practice 
 Argument is strong, but not overwhelming so. If there were a change, 
 it would have to be to a clearly superior name. When you consider that 
 the name should not conflict with a popular variable or function name, 
 most of the good choices are already taken. I bet that if you do a 
 search for 'memsize' or 'ptrdiff' in C/C++/Java code, you'll get a lot 
 of hits.
 Personally, I doubt that satisfactory names exist, so ptrdiff_t and 
 size_t are probably here to stay. But I'd be happy to be found wrong 
 -- I agree that they are ugly.

 With a bit of imagination, there may be other possibilities, though.

 You can already do
 typeof(x.size) a = x.size;


 
 That has no meaning!  x.size is an integer property that returns the 
 number of bytes that element x takes in memory.  Taking the typeof() 
 that is completely worthless.  Without a test to back me up here, I 
 would say it would always be of type int - a result from the internals 
 of the compiler's implementation (and I've looked into the DMD front end 
 code on more than one occasion).  If this is allowed by the reference 
 compiler, then it is surely a side-effect.


Sorry, should have been sizeof. The code below works correctly in DMD 0.133.
----------------------
import std.stdio;

int main()
{
    typeof(int.sizeof) a = double.sizeof;
    writefln(a);
    return 0;
}
------------------
x.sizeof has to be a size_t rather than an integer property. Even if 
there's an implicit conversion from size_t to int.
Remember that on a 64-bit system, the number of bytes x takes in memory 
might be greater that 2^32 and hence the result of .sizeof might not fit 
into an int. (It's possible that the existing front end might not yet 
deal with this correctly).


 So you could imagine a property .sizetype as syntactic sugar for 
 typeof(x.size), and similarly .difftype  for typeof(&x - &x). This 
 type would be defined for all types.

 Then you could have
 typedef idouble any; // doesn't matter what type you use
 alias any.sizetype size_t;
 alias any.difftype ptrdiff_t;

 for backwards compatibility with C.

 I'm not proposing this, I don't really think it's a good idea.


 Their semantic meaning implicitly implies architecture dependence, 
 which int or long don't.


 Agreed. But something like 'ptrdifftype' might.
Sep 27 2005
parent reply James Dunne <james.jdunne gmail.com> writes:
Don Clugston wrote:

 James Dunne wrote:
 

 Don Clugston wrote:


 Georg Wrede wrote:


 AJG wrote:


 In article <dhb4jr$m2r$1 digitaldaemon.com>, Bruno Medeiros says...


 This is a minor issue, but still:
 I was browsing through some of those other threads where size_t 
 and and ptrdiff_t was talked about, and then I thought, should we 
 be using the C-legacy "_t" name idiom in these D types? Is it not 
 ugly and unconsistent with the rest of the language (types)?
 It seems to me so, at first glance, so maybe we should change the 
 name then. To what exactly I'm not sure, maybe (memsize, ptrdiff), 
 (msize, ptrdiff) or (umsize, msize), but these are just some 
 initial suggestions.







 I concur.
 --AJG.






 NO. There's nothing to be gained. And it would be a lot of work to 
 again go through the libraries. And, those two names are Established 
 in the Community. They have a very specific meaning to all 
 professionals.





 The same is true of wchar_t, which C++ would love to change to wchar,
 and which D has sucessfully changed. I think the Established Practice 
 Argument is strong, but not overwhelming so. If there were a change, 
 it would have to be to a clearly superior name. When you consider 
 that the name should not conflict with a popular variable or function 
 name, most of the good choices are already taken. I bet that if you 
 do a search for 'memsize' or 'ptrdiff' in C/C++/Java code, you'll get 
 a lot of hits.
 Personally, I doubt that satisfactory names exist, so ptrdiff_t and 
 size_t are probably here to stay. But I'd be happy to be found wrong 
 -- I agree that they are ugly.

 With a bit of imagination, there may be other possibilities, though.

 You can already do
 typeof(x.size) a = x.size;


 That has no meaning!  x.size is an integer property that returns the 
 number of bytes that element x takes in memory.  Taking the typeof() 
 that is completely worthless.  Without a test to back me up here, I 
 would say it would always be of type int - a result from the internals 
 of the compiler's implementation (and I've looked into the DMD front 
 end code on more than one occasion).  If this is allowed by the 
 reference compiler, then it is surely a side-effect.


 
 
 Sorry, should have been sizeof. The code below works correctly in DMD 
 0.133.
 ----------------------
 import std.stdio;
 
 int main()
 {
    typeof(int.sizeof) a = double.sizeof;
    writefln(a);
    return 0;
 }
 ------------------
 x.sizeof has to be a size_t rather than an integer property. Even if 
 there's an implicit conversion from size_t to int.
 Remember that on a 64-bit system, the number of bytes x takes in memory 
 might be greater that 2^32 and hence the result of .sizeof might not fit 
 into an int. (It's possible that the existing front end might not yet 
 deal with this correctly).
 

 So you could imagine a property .sizetype as syntactic sugar for 
 typeof(x.size), and similarly .difftype  for typeof(&x - &x). This 
 type would be defined for all types.

 Then you could have
 typedef idouble any; // doesn't matter what type you use
 alias any.sizetype size_t;
 alias any.difftype ptrdiff_t;

 for backwards compatibility with C.

 I'm not proposing this, I don't really think it's a good idea.


 Their semantic meaning implicitly implies architecture dependence, 
 which int or long don't.



 Agreed. But something like 'ptrdifftype' might.






I think you are confusing int.max with int.sizeof.  int.sizeof returns 
the number of bytes that the integer type takes up in memory, similar 
for long.sizeof.

int is _always_ 32 bits as specified by the D language spec.  int.sizeof 
will _always_ return 4.  long is _always_ 64 bits, again as in the spec. 
  long.sizeof will _always_ return 8.  The typeof() that number returned 
by int.sizeof and long.sizeof is compiler-implementation-specific and 
essentially has no meaning.

Now, with other types, aside from basic types, sizeof does not have to 
be represented as a size_t because there are no types that are going to 
exceed a 32-bit representable size, aside from an extremely large static 
array.  But that is what we have the length property for.  And if you'll 
agree, length must be a size_t.  Besides, last I recall, the size of 
static arrays is limited to something on the order of 16MB, so this case 
is effectively stamped out by that limit.
Sep 28 2005
parent Don Clugston <dac nospam.com.au> writes:
James Dunne wrote:

 Don Clugston wrote:
 

 James Dunne wrote:


 Don Clugston wrote:


 Georg Wrede wrote:


 AJG wrote:


 In article <dhb4jr$m2r$1 digitaldaemon.com>, Bruno Medeiros says...


 This is a minor issue, but still:
 I was browsing through some of those other threads where size_t 
 and and ptrdiff_t was talked about, and then I thought, should we 
 be using the C-legacy "_t" name idiom in these D types? Is it not 
 ugly and unconsistent with the rest of the language (types)?
 It seems to me so, at first glance, so maybe we should change the 
 name then. To what exactly I'm not sure, maybe (memsize, 
 ptrdiff), (msize, ptrdiff) or (umsize, msize), but these are just 
 some initial suggestions.








 I concur.
 --AJG.







 NO. There's nothing to be gained. And it would be a lot of work to 
 again go through the libraries. And, those two names are 
 Established in the Community. They have a very specific meaning to 
 all professionals.






 The same is true of wchar_t, which C++ would love to change to wchar,
 and which D has sucessfully changed. I think the Established 
 Practice Argument is strong, but not overwhelming so. If there were 
 a change, it would have to be to a clearly superior name. When you 
 consider that the name should not conflict with a popular variable 
 or function name, most of the good choices are already taken. I bet 
 that if you do a search for 'memsize' or 'ptrdiff' in C/C++/Java 
 code, you'll get a lot of hits.
 Personally, I doubt that satisfactory names exist, so ptrdiff_t and 
 size_t are probably here to stay. But I'd be happy to be found wrong 
 -- I agree that they are ugly.

 With a bit of imagination, there may be other possibilities, though.

 You can already do
 typeof(x.size) a = x.size;


 That has no meaning!  x.size is an integer property that returns the 
 number of bytes that element x takes in memory.  Taking the typeof() 
 that is completely worthless.  Without a test to back me up here, I 
 would say it would always be of type int - a result from the 
 internals of the compiler's implementation (and I've looked into the 
 DMD front end code on more than one occasion).  If this is allowed by 
 the reference compiler, then it is surely a side-effect.




 Sorry, should have been sizeof. The code below works correctly in DMD 
 0.133.
 ----------------------
 import std.stdio;

 int main()
 {
    typeof(int.sizeof) a = double.sizeof;
    writefln(a);
    return 0;
 }
 ------------------
 x.sizeof has to be a size_t rather than an integer property. Even if 
 there's an implicit conversion from size_t to int.
 Remember that on a 64-bit system, the number of bytes x takes in 
 memory might be greater that 2^32 and hence the result of .sizeof 
 might not fit into an int. (It's possible that the existing front end 
 might not yet deal with this correctly).


 So you could imagine a property .sizetype as syntactic sugar for 
 typeof(x.size), and similarly .difftype  for typeof(&x - &x). This 
 type would be defined for all types.

 Then you could have
 typedef idouble any; // doesn't matter what type you use
 alias any.sizetype size_t;
 alias any.difftype ptrdiff_t;

 for backwards compatibility with C.

 I'm not proposing this, I don't really think it's a good idea.


 Their semantic meaning implicitly implies architecture dependence, 
 which int or long don't.




 Agreed. But something like 'ptrdifftype' might.






 
 
 I think you are confusing int.max with int.sizeof.  int.sizeof returns 
 the number of bytes that the integer type takes up in memory, similar 
 for long.sizeof.


Yes, I'm well aware of the difference.


 int is _always_ 32 bits as specified by the D language spec.  int.sizeof 
 will _always_ return 4.  long is _always_ 64 bits, again as in the spec. 
  long.sizeof will _always_ return 8.


Yes.

   The typeof() that number returned

 by int.sizeof and long.sizeof is compiler-implementation-specific and 
 essentially has no meaning.


Not so. It's in the spec. To quote portability.html:
* The .length, .size, .sizeof, and .alignof properties will be of type 
size_t.


 Now, with other types, aside from basic types, sizeof does not have to 
 be represented as a size_t because there are no types that are going to 
 exceed a 32-bit representable size, aside from an extremely large static 
 array.  But that is what we have the length property for.  And if you'll
 agree, length must be a size_t.  Besides, last I recall, the size of 
 static arrays is limited to something on the order of 16MB, so this case 
 is effectively stamped out by that limit.
Sep 28 2005
prev sibling parent Bruno Medeiros <daiphoenixNO SPAMlycos.com> writes:
Don Clugston wrote:

 Georg Wrede wrote:
 

 AJG wrote:


 In article <dhb4jr$m2r$1 digitaldaemon.com>, Bruno Medeiros says...


 This is a minor issue, but still:
 I was browsing through some of those other threads where size_t and 
 and ptrdiff_t was talked about, and then I thought, should we be 
 using the C-legacy "_t" name idiom in these D types? Is it not ugly 
 and unconsistent with the rest of the language (types)?
 It seems to me so, at first glance, so maybe we should change the 
 name then. To what exactly I'm not sure, maybe (memsize, ptrdiff), 
 (msize, ptrdiff) or (umsize, msize), but these are just some initial 
 suggestions.





 I concur.
 --AJG.




 NO. There's nothing to be gained. And it would be a lot of work to 
 again go through the libraries. And, those two names are Established 
 in the Community. They have a very specific meaning to all professionals.


 
 
 The same is true of wchar_t, which C++ would love to change to wchar,
 and which D has sucessfully changed. I think the Established Practice 
 Argument is strong, but not overwhelming so. If there were a change, it 
 would have to be to a clearly superior name. When you consider that the 
 name should not conflict with a popular variable or function name, most 
 of the good choices are already taken. I bet that if you do a search for 
 'memsize' or 'ptrdiff' in C/C++/Java code, you'll get a lot of hits.
 Personally, I doubt that satisfactory names exist, so ptrdiff_t and 
 size_t are probably here to stay. But I'd be happy to be found wrong -- 
 I agree that they are ugly.
 


Yes, despite the current situation not being ideal, finding a good 
alternative may not be easy. I recognize the problem that a type name 
without "_t" might conflict with a common var name (either with existing 
or future made code). That is why I hereby make the call here for people 
to start working their technical creativity to see if we can come up 
with a good name :) . It may take a while, but if we take this issue in 
regard and keep it in mind we'll get there.

"msize" is probably not good, it is too common, the "m" could be a lot 
of things.
"memsize" is better, but still may not be the ideal.
"sizetype" or "ptrdifftype" I don't like them either, the "type" 
redundancy is still there.

I'm trying to get my inspiration from the type's description, since it 
is it's semantic meaning that matters:

	alias size_t
	An unsigned integral type large enough to span the memory space. Use 
for array indices and pointer offsets for maximal portability to 
architectures that have different memory address ranges. This is 
analogous to C's size_t.

	alias ptrdiff_t
	A signed integral type large enough to span the memory space. Use for 
pointer differences and for size_t differences for maximal portability 
to architectures that have different memory address ranges. This is 
analogous to C's ptrdiff_t.

So here's some more ideias:

"memspan"
"ptrsize"
"ptrspan" -> hum... this last one may be quite good, and it fits well 
with it's complement "ptrdiff" .

-- 
Bruno Medeiros - CS/E student
"Certain aspects of D are a pathway to many abilities some consider to 
be... unnatural."
Sep 30 2005
prev sibling parent AJG <AJG_member pathlink.com> writes:
In article <43393881.3080108 nospam.org>, Georg Wrede says...

AJG wrote:

 In article <dhb4jr$m2r$1 digitaldaemon.com>, Bruno Medeiros says...
 

This is a minor issue, but still:
I was browsing through some of those other threads where size_t and and 
ptrdiff_t was talked about, and then I thought, should we be using the 
C-legacy "_t" name idiom in these D types? Is it not ugly and 
unconsistent with the rest of the language (types)?
It seems to me so, at first glance, so maybe we should change the name 
then. To what exactly I'm not sure, maybe (memsize, ptrdiff), (msize, 
ptrdiff) or (umsize, msize), but these are just some initial suggestions.


 
 
 I concur.
 --AJG.


NO. There's nothing to be gained.


Yes, there is something to be gained. Cleaner, shorter, simpler names.


 And it would be a lot of work to again 
go through the libraries.


They could simply be deprecated, just like functions are every once in a while.


And, those two names are Established in the 
Community. They have a very specific meaning to all professionals.


Perhaps in the C community. But this is D, so we can be a little progressive.


Their semantic meaning implicitly implies architecture dependence, which 
int or long don't.


Really? That's funny. Ever heard of endianness?

Cheers,
--AJG.
Sep 28 2005