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.

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