www.digitalmars.com         C & C++   DMDScript  

D - .size => .sizeof

reply "Walter" <walter digitalmars.com> writes:
It occurs to me that .sizeof is a much better name for the size of a type
than .size, because:

1) since sizeof is a C/C++ keyword, it cannot conflict with any struct or
class names.
2) it's immediately recognizable for what it does
Nov 16 2003
next sibling parent "Charles Sanders" <sanders-consulting comcast.net> writes:
Hmm, i think of sizeof as a function that takes a parameter, and .size as a
property.  I like .size for what its worth.

C

"Walter" <walter digitalmars.com> wrote in message
news:bp7jd9$914$1 digitaldaemon.com...
 It occurs to me that .sizeof is a much better name for the size of a type
 than .size, because:

 1) since sizeof is a C/C++ keyword, it cannot conflict with any struct or
 class names.
 2) it's immediately recognizable for what it does
Nov 16 2003
prev sibling next sibling parent reply "Matthew Wilson" <matthew-hat -stlsoft-dot.-org> writes:
Do it! Do it!

"Walter" <walter digitalmars.com> wrote in message
news:bp7jd9$914$1 digitaldaemon.com...
 It occurs to me that .sizeof is a much better name for the size of a type
 than .size, because:

 1) since sizeof is a C/C++ keyword, it cannot conflict with any struct or
 class names.
 2) it's immediately recognizable for what it does
Nov 16 2003
parent "Luna Kid" <lunakid neuropolis.org> writes:
Yes, please!

If you really mean the same thing as the C compile-time
sizeof constant, please make the change!

Thanks,
Sz.

"Matthew Wilson" <matthew-hat -stlsoft-dot.-org> wrote in message
news:bp8mb1$1p2m$2 digitaldaemon.com...
 Do it! Do it!

 "Walter" <walter digitalmars.com> wrote in message
 news:bp7jd9$914$1 digitaldaemon.com...
 It occurs to me that .sizeof is a much better name for the size of a type
 than .size, because:

 1) since sizeof is a C/C++ keyword, it cannot conflict with any struct or
 class names.
 2) it's immediately recognizable for what it does
Nov 18 2003
prev sibling next sibling parent reply J C Calvarese <jcc7 cox.net> writes:
Walter wrote:

 It occurs to me that .sizeof is a much better name for the size of a type
 than .size, because:
 
 1) since sizeof is a C/C++ keyword, it cannot conflict with any struct or
 class names.
 2) it's immediately recognizable for what it does
I like .size. It's meaning is as obvious to me as .sizeof. I don't see the more verbose .sizeof as an improvement. I'd prefer .bytes to .sizeof. And besides, it's not good grammar to end a sentence with a preposition (though I've ended sentences with prepositions from time to time). I think we should break from the C/C++ crowd with sizeof. Justin
Nov 16 2003
parent "Matthew Wilson" <matthew-hat -stlsoft-dot.-org> writes:
 I like .size.  It's meaning is as obvious to me as .sizeof.  I don't see
 the more verbose .sizeof as an improvement.  I'd prefer .bytes to .sizeof.
The reason to dislike size is that .size could well be a property of a user-defined type. That leads to some nasty surprises; mixing compile-time and runtime quantities leads to some sticky messes in generic programming.
 And besides, it's not good grammar to end a sentence with a preposition
 (though I've ended sentences with prepositions from time to time).
This is true, but that's less important
 I think we should break from the C/C++ crowd with sizeof.
I think we should do whatever will create a better language. And not using .size will indeed break from the C/C++ crowd by reducing the potential ambiguities between compile-time and run-time constant mixing
Nov 16 2003
prev sibling next sibling parent reply "Andrew Edwards" <edwardsac spamfreeusa.com> writes:
"Walter" <walter digitalmars.com> wrote in message
news:bp7jd9$914$1 digitaldaemon.com...
 It occurs to me that .sizeof is a much better name for the size of a type
 than .size, because:

 1) since sizeof is a C/C++ keyword, it cannot conflict with any struct or
 class names.
 2) it's immediately recognizable for what it does
.size is also immediately recognizable for what it does. Making size a keyword in D eliminates potintial conflicts with UDT's. Programmers can always use sizeof or mysize withing UDT's. Andrew
Nov 16 2003
next sibling parent reply "Matthew Wilson" <matthew-hat -stlsoft-dot.-org> writes:
"Andrew Edwards" <edwardsac spamfreeusa.com> wrote in message
news:bp8sr9$223f$1 digitaldaemon.com...
 "Walter" <walter digitalmars.com> wrote in message
 news:bp7jd9$914$1 digitaldaemon.com...
 It occurs to me that .sizeof is a much better name for the size of a
type
 than .size, because:

 1) since sizeof is a C/C++ keyword, it cannot conflict with any struct
or
 class names.
 2) it's immediately recognizable for what it does
.size is also immediately recognizable for what it does. Making size a keyword in D eliminates potintial conflicts with UDT's. Programmers can always use sizeof or mysize withing UDT's.
If .size is a reserved word, and only applies to compile-time, then I'm happy for it to stay as is. I never liked the size() method of the STL; length() fits better in most cases.
Nov 16 2003
next sibling parent reply Hauke Duden <H.NS.Duden gmx.net> writes:
Matthew Wilson wrote:
 If .size is a reserved word, and only applies to compile-time, then I'm
 happy for it to stay as is. I never liked the size() method of the STL;
 length() fits better in most cases.
If size is a reserved word then I DO want it to change. size is one of those identifiers that you would want to use from time to time. But I don't think the name of the size property has to be reserved (and I don't think it is, but I haven't checked). It is just a property of a type, so why should it be reserved for all other uses? Where's the difference to other properties? Also, I think a better name would be instanceSize or instancesize. After all, it is not the size of the type (which doesn't really HAVE a size), but the size of a type instance. It would also make it easier to understand what the value refers to. Hauke
Nov 16 2003
parent reply "Matthew Wilson" <matthew-hat -stlsoft-dot.-org> writes:
 Matthew Wilson wrote:
 If .size is a reserved word, and only applies to compile-time, then I'm
 happy for it to stay as is. I never liked the size() method of the STL;
 length() fits better in most cases.
If size is a reserved word then I DO want it to change. size is one of those identifiers that you would want to use from time to time.
Fair enough.
 But I don't think the name of the size property has to be reserved (and
 I don't think it is, but I haven't checked). It is just a property of a
 type, so why should it be reserved for all other uses? Where's the
 difference to other properties?
The classic case in C/C++ is a dimensionof macro #define dimensionof(x) ((sizeof(x) / sizeof(x[0])) int ar[10]; for(int i = 0; i < dimensionof(ar); ++i) { ar[i]; // do something with the ith element } It breaks when applied to ptrs. int *p; for(int i = 0; i < dimensionof(p); ++i) // Loops once, on most architectures { p[i]; // do something with the ith element } and can be even worse, to udts std::vector<int> v; for(int i = 0; i < dimensionof(v); ++i) // Number of loops is dependent on the size of the vector implementation, not v.size() { v[i]; // do something with the ith element } If we can have a static .size attribute and a dynamic .size property there'll be different, but analogous, evil nonsense.
 Also, I think a better name would be instanceSize or instancesize. After
 all, it is not the size of the type (which doesn't really HAVE a size),
 but the size of a type instance. It would also make it easier to
 understand what the value refers to.
If it can't be size, sizeof is the obvious choice. I doubt you'll persuade many to have an instancesize. What would that return on an array? The size of the array instance or the size of an instance of the array's type?
Nov 16 2003
parent Hauke Duden <H.NS.Duden gmx.net> writes:
Matthew Wilson wrote:
 I doubt you'll persuade many to have an instancesize. What would that return
 on an array? The size of the array instance or the size of an instance of
 the array's type?
Hmmm. I think there might be a misunderstanding here. What are we talking about? A compile-time property of a type or a runtime property of an object? If the size of a type instance isn't known at compile time (as is the case with dynamic arrays), then the type cannot have an instancesize property. The semantics here are a little tricky, since D uses references implicitly. Would instancesize of an array refer to the array itself or the size of the reference? What does .size currently do? I think, I'm confused ;). Need to drink that tea first... Hauke
Nov 17 2003
prev sibling parent reply J C Calvarese <jcc7 cox.net> writes:
Matthew Wilson wrote:
...

 
 If .size is a reserved word, and only applies to compile-time, then I'm
 happy for it to stay as is. I never liked the size() method of the STL;
 length() fits better in most cases.
 
"size" is *not* a keyword in D. A person can create a variable named size or override the default .size with a custom version in a struct. struct myStruct { int whatever; int mySize(){ return 6; } int size(){ return 8; } } void main() { int i; printf("size: %d\n", i.size); int size; printf("size: %d\n", size.size); myStruct test; test.whatever = 0; printf("mySize: %d\n", test.mySize); printf("size: %d\n", test.size); } Justin
Nov 16 2003
parent "Matthew Wilson" <matthew-hat -stlsoft-dot.-org> writes:
In that case, that brings us back to sizeof.

"J C Calvarese" <jcc7 cox.net> wrote in message
news:bp9394$2d2l$1 digitaldaemon.com...
 Matthew Wilson wrote:
 ...

 If .size is a reserved word, and only applies to compile-time, then I'm
 happy for it to stay as is. I never liked the size() method of the STL;
 length() fits better in most cases.
"size" is *not* a keyword in D. A person can create a variable named size or override the default .size with a custom version in a struct. struct myStruct { int whatever; int mySize(){ return 6; } int size(){ return 8; } } void main() { int i; printf("size: %d\n", i.size); int size; printf("size: %d\n", size.size); myStruct test; test.whatever = 0; printf("mySize: %d\n", test.mySize); printf("size: %d\n", test.size); } Justin
Nov 16 2003
prev sibling parent reply Ilya Minkov <Ilya_member pathlink.com> writes:
In article <bp8sr9$223f$1 digitaldaemon.com>, Andrew Edwards says...

.size is also immediately recognizable for what it does. Making size a
keyword in D eliminates potintial conflicts with UDT's. Programmers can
always use sizeof or mysize withing UDT's.
I agree wholeheartedly. Don't change to sizeof.
Nov 18 2003
parent reply "Charles Sanders" <sanders-consulting comcast.net> writes:
I agree also, I _like_ .size , keep it!

C

"Ilya Minkov" <Ilya_member pathlink.com> wrote in message
news:bpcp5t$1k5o$1 digitaldaemon.com...
 In article <bp8sr9$223f$1 digitaldaemon.com>, Andrew Edwards says...

.size is also immediately recognizable for what it does. Making size a
keyword in D eliminates potintial conflicts with UDT's. Programmers can
always use sizeof or mysize withing UDT's.
I agree wholeheartedly. Don't change to sizeof.
Nov 18 2003
parent "Carlos Santander B." <carlos8294 msn.com> writes:
Same here.

—————————————————————————
Carlos Santander
"Charles Sanders" <sanders-consulting comcast.net> wrote in message
news:bpdjmv$2pk7$1 digitaldaemon.com...
| I agree also, I _like_ .size , keep it!
|
| C
|
| "Ilya Minkov" <Ilya_member pathlink.com> wrote in message
| news:bpcp5t$1k5o$1 digitaldaemon.com...
| > In article <bp8sr9$223f$1 digitaldaemon.com>, Andrew Edwards says...
| >
| > >.size is also immediately recognizable for what it does. Making size a
| > >keyword in D eliminates potintial conflicts with UDT's. Programmers can
| > >always use sizeof or mysize withing UDT's.
| >
| > I agree wholeheartedly.
| >
| > Don't change to sizeof.
| >
| >
|
|


---

Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.541 / Virus Database: 335 - Release Date: 2003-11-14
Nov 18 2003
prev sibling next sibling parent reply Russ Lewis <spamhole-2001-07-16 deming-os.org> writes:
IMHO, .sizeof is better because of the familiarity with C/C++.  If we 
started from scratch, then .size would have been better...but that's not 
how things happened.

Russ

Walter wrote:
 It occurs to me that .sizeof is a much better name for the size of a type
 than .size, because:
 
 1) since sizeof is a C/C++ keyword, it cannot conflict with any struct or
 class names.
 2) it's immediately recognizable for what it does
Nov 17 2003
parent reply davepermen <davepermen_member pathlink.com> writes:
actually, that is exactly WHY we have D. take c++ as a base, but start from
scratch.. sizeof sounds bad.

and to the one with the

struct A { uint size() { return 0xFFFFFFFF; } };
A a;
printf("%i" \n,a.size);

this is simply syntactically not what you want it to.. you want to know the size
of the type A, so use A.size.

i think a typeof or similar would be very useful..

printf("%i" \n,typeof(a).size); would be unambiguous. (and i prefer here the
function syntax over the property syntax.. looks more understandable, and this
could get a keyword.. useful for metaprogramming one day, possibly, too)


THAT is a proper solution.


or we could use .bigness :D or .amountofusedram .... size should be a type-only
property. because you can't rely on instances to use that amount of memory in
the end anyways.. gc allocates in chunks i think.. at least its not needed for
the user to query the runtime size of an object.. only the compile time type
size.. all the rest can be .length..


In article <bpbm23$297$1 digitaldaemon.com>, Russ Lewis says...
IMHO, .sizeof is better because of the familiarity with C/C++.  If we 
started from scratch, then .size would have been better...but that's not 
how things happened.

Russ
Nov 18 2003
parent Antti =?iso-8859-1?Q?Syk=E4ri?= <jsykari gamma.hut.fi> writes:
In article <bpckvt$1eoe$1 digitaldaemon.com>, davepermen wrote:
 actually, that is exactly WHY we have D. take c++ as a base, but start from
 scratch.. sizeof sounds bad.
In C++, I very rarely use sizeof. It's a relic from C, where you have to say malloc(sizeof(foo)) all the time. In D, I'd expect to use it even less. In my opinion, the concept of sizeof is not so useful and all-encompassing that it would warrant using a common name like "size". "size", on the other hand, is a common property for STL containers. It tells how many elements a container has, which is immensely more useful information than how many bytes the representation of the container class itself requires in the activation record. Therefore it must have a simple and straightforward name: size. Besides, all C++ programmers sophisticated enough to know STL know what size() means. Using .length in meaning "number of elements" sounds clumsy to me. I wouldn't like to talk about length of a hash table, or length of a binary tree, or even length of a list. (Then again, others might.) Strings, buffers and perhaps files do possess the property of length. -Antti
Nov 18 2003
prev sibling next sibling parent reply Patrick Down <Patrick_member pathlink.com> writes:
In article <bp7jd9$914$1 digitaldaemon.com>, Walter says...
It occurs to me that .sizeof is a much better name for the size of a type
than .size, because:

1) since sizeof is a C/C++ keyword, it cannot conflict with any struct or
class names.
2) it's immediately recognizable for what it does
My problem with .size is that I get it confused with size from the STL. So I often use .size when I should use .length. Makeing it .sizeof would fix this, so I am in favor or it. However if I might give a counter proposal, why not make it .bytesize?
Nov 18 2003
parent reply J C Calvarese <jcc7 cox.net> writes:
Patrick Down wrote:
 In article <bp7jd9$914$1 digitaldaemon.com>, Walter says...
 
It occurs to me that .sizeof is a much better name for the size of a type
than .size, because:

1) since sizeof is a C/C++ keyword, it cannot conflict with any struct or
class names.
2) it's immediately recognizable for what it does
My problem with .size is that I get it confused with size from the STL. So I often use .size when I should use .length. Makeing it .sizeof would fix this, so I am in favor or it. However if I might give a counter proposal, why not make it .bytesize?
Perhaps my lack of C++ experience is why I like D's .size so much. If .size won't work anymore, I also prefer your suggestion of .bytesize to .sizeof. Another idea I had is *.typesize* since it returns the SIZE of the TYPE. While "of" just doesn't add any meaning, "type" adds a lot of meaning. In a ranked list (favorite first)... 1) .size 2) .typesize 3) .bytesize 4) .bytes 5) .sizeof My 2 cents... Justin
Nov 18 2003
parent reply "Andrew Edwards" <edwardsac spamfreeusa.com> writes:
"J C Calvarese" <jcc7 cox.net> wrote...

 Perhaps my lack of C++ experience is why I like D's .size so much.  If
 .size won't work anymore, I also prefer your suggestion of .bytesize to
 .sizeof.
I agree. I have had the pleasure of being tainted moreso by D than by any other programming language. .size was easily understandable when I first used it and remains that way even now. Personally, I'd rather you not try to make D into C/C++. IMHO the developers are holding on to too much of the latter because of fear of loosing the audience of that community. I believe that if it is better than C/C++, easily understood, not bloated, boast a robust library, and reduces development time, D will have a large community. Java does (I'm sure alot of Java programmers were once C/C++ programmers)! So, why not D?
 Another idea I had is *.typesize* since it returns the SIZE of the TYPE.
   While "of" just doesn't add any meaning, "type" adds a lot of meaning.
Agreed! Of all the suggested alternatives to .size, .typesize is the only valid choice. It eliminates all ambiguities, does not conflict with C/C++ and can be retained as a keyword. If it must be changed, typesize gets my vote. Andrew
Nov 18 2003
parent reply Felix <Felix_member pathlink.com> writes:
Me too, I agree with "typesize". In fact, this is the true meaning of .size,
isn't?




In article <bpf1es$21n4$1 digitaldaemon.com>, Andrew Edwards says...
"J C Calvarese" <jcc7 cox.net> wrote...

 Perhaps my lack of C++ experience is why I like D's .size so much.  If
 .size won't work anymore, I also prefer your suggestion of .bytesize to
 .sizeof.
I agree. I have had the pleasure of being tainted moreso by D than by any other programming language. .size was easily understandable when I first used it and remains that way even now. Personally, I'd rather you not try to make D into C/C++. IMHO the developers are holding on to too much of the latter because of fear of loosing the audience of that community. I believe that if it is better than C/C++, easily understood, not bloated, boast a robust library, and reduces development time, D will have a large community. Java does (I'm sure alot of Java programmers were once C/C++ programmers)! So, why not D?
 Another idea I had is *.typesize* since it returns the SIZE of the TYPE.
   While "of" just doesn't add any meaning, "type" adds a lot of meaning.
Agreed! Of all the suggested alternatives to .size, .typesize is the only valid choice. It eliminates all ambiguities, does not conflict with C/C++ and can be retained as a keyword. If it must be changed, typesize gets my vote. Andrew
Nov 18 2003
parent reply davepermen <davepermen_member pathlink.com> writes:
why can't you just call the type's size then?
struct A {}
A a;
A.size instead of a.size

how difficult is that? yes in templates, it can be. then again, there we need a
typeof() or similar anyways (and i think that should look like a function)

In article <bpf77q$2920$1 digitaldaemon.com>, Felix says...
Me too, I agree with "typesize". In fact, this is the true meaning of .size,
isn't?




In article <bpf1es$21n4$1 digitaldaemon.com>, Andrew Edwards says...
"J C Calvarese" <jcc7 cox.net> wrote...

 Perhaps my lack of C++ experience is why I like D's .size so much.  If
 .size won't work anymore, I also prefer your suggestion of .bytesize to
 .sizeof.
I agree. I have had the pleasure of being tainted moreso by D than by any other programming language. .size was easily understandable when I first used it and remains that way even now. Personally, I'd rather you not try to make D into C/C++. IMHO the developers are holding on to too much of the latter because of fear of loosing the audience of that community. I believe that if it is better than C/C++, easily understood, not bloated, boast a robust library, and reduces development time, D will have a large community. Java does (I'm sure alot of Java programmers were once C/C++ programmers)! So, why not D?
 Another idea I had is *.typesize* since it returns the SIZE of the TYPE.
   While "of" just doesn't add any meaning, "type" adds a lot of meaning.
Agreed! Of all the suggested alternatives to .size, .typesize is the only valid choice. It eliminates all ambiguities, does not conflict with C/C++ and can be retained as a keyword. If it must be changed, typesize gets my vote. Andrew
Nov 19 2003
parent reply "Matthew Wilson" <matthew-hat -stlsoft-dot.-org> writes:
I've been stewing on all these things, and I think that the best option is
to have .size as a legal property for things, and to use typeof(x).size to
get the size of x.

We are *so* going to need typeof in the language anyway - and there'll be a
quantum leap over C++ - so it's an idiom we could get used to very quickly.

For any types whose sizes are determinable at compile time, the value can be
evaluated as a compile-time constant.



"davepermen" <davepermen_member pathlink.com> wrote in message
news:bpf941$2cun$1 digitaldaemon.com...
 why can't you just call the type's size then?
 struct A {}
 A a;
 A.size instead of a.size

 how difficult is that? yes in templates, it can be. then again, there we
need a
 typeof() or similar anyways (and i think that should look like a function)

 In article <bpf77q$2920$1 digitaldaemon.com>, Felix says...
Me too, I agree with "typesize". In fact, this is the true meaning of
.size,
isn't?




In article <bpf1es$21n4$1 digitaldaemon.com>, Andrew Edwards says...
"J C Calvarese" <jcc7 cox.net> wrote...

 Perhaps my lack of C++ experience is why I like D's .size so much.  If
 .size won't work anymore, I also prefer your suggestion of .bytesize
to
 .sizeof.
I agree. I have had the pleasure of being tainted moreso by D than by
any
other programming language. .size was easily understandable when I first
used it and remains that way even now.

Personally, I'd rather you not try to make D into C/C++. IMHO the
developers
are holding on to too much of the latter because of fear of loosing the
audience of that community. I believe that if it is better than C/C++,
easily understood, not bloated, boast a robust library, and reduces
development time, D will have a large community. Java does (I'm sure
alot of
Java programmers were once C/C++ programmers)! So, why not D?

 Another idea I had is *.typesize* since it returns the SIZE of the
TYPE.
   While "of" just doesn't add any meaning, "type" adds a lot of
meaning.
Agreed! Of all the suggested alternatives to .size, .typesize is the
only
valid choice. It eliminates all ambiguities, does not conflict with
C/C++
and can be retained as a keyword.

If it must be changed, typesize gets my vote.

Andrew
Nov 19 2003
parent reply Berin Loritsch <bloritsch d-haven.org> writes:
Matthew Wilson wrote:

 I've been stewing on all these things, and I think that the best option is
 to have .size as a legal property for things, and to use typeof(x).size to
 get the size of x.
 
 We are *so* going to need typeof in the language anyway - and there'll be a
 quantum leap over C++ - so it's an idiom we could get used to very quickly.
 
 For any types whose sizes are determinable at compile time, the value can be
 evaluated as a compile-time constant.
Perhaps I am spoiled by Java's type system, but here are a few observations. 1) In a Java program I have never had to determine an object's size. Not only are the type sizes well defined, there is no low level pointer arithmetic which would make that necessary. 2) If D is to allow or encourage low level pointer arithmetic (which I think is a mistake), a sizeof operator or a .size on the type would be sufficient. 3) In templates (AKA generics), all marker types are aliases for another type. For instance: class Rectangle<Coord> { Coord left; Coord top; Coord right; Coord bottom; public void someMethod() { long sizeOfCoord = Coord.size; } } Coord would translate into something like this: alias Coord float; if the type passed in was a float... new Rectangle<float>(); THe only time I can see where the .size on a type would vary based on the particular variable would be strings and arrays, but I would use a .length for those.
Nov 19 2003
parent reply "Jeroen van Bemmel" <someone somewhere.com> writes:
 Perhaps I am spoiled by Java's type system, but here are a few
observations.
 1) In a Java program I have never had to determine an object's size.  Not
only
     are the type sizes well defined, there is no low level pointer
arithmetic
     which would make that necessary.
Very good point! If D is aiming to discourage low level pointer aritthmetic and provides garbage collection, that reduces the two major use cases for .size or sizeof to nothing. On the other hand, Java's type system encourages people to use lots of objects since the memory cost is transparent, which causes Java programs to require ridiculus amounts of memory. Probably the most likely usecase is interfacing with other languages such as C/C++, and perhaps (lowlevel) serialization. Some random thoughts: - is size a static compile time property, or also dynamic (polymorphic)? For the former, I would vote for something that clearly distinguishes it from other language concepts (on a syntactic level), especially since it is compiler specific (different compilers could give different values depending on eg optimization flags). Much like type casts are particularly verbose and noticable in C++ (new standard). What about __sizeof__( x ) or even
Nov 19 2003
parent reply "Walter" <walter digitalmars.com> writes:
"Jeroen van Bemmel" <someone somewhere.com> wrote in message
news:bpgtk2$1pf5$1 digitaldaemon.com...
 Very good point! If D is aiming to discourage low level pointer
aritthmetic
 and provides garbage collection, that reduces the two major use cases for
 .size or sizeof to nothing. On the other hand, Java's type system
encourages
 people to use lots of objects since the memory cost is transparent, which
 causes Java programs to require ridiculus amounts of memory.
Yet what prevents Java from doing system apps is an inability to do pointer arithmetic. You cannot implement certain kinds of things without knowing the sizes. One thing that won't work is varargs <g>. Another is implementing the garbage collector.
 Probably the most likely usecase is interfacing with other languages such
as
 C/C++, and perhaps (lowlevel) serialization.

 Some random thoughts:
 - is size a static compile time property, or also dynamic (polymorphic)?
For
 the former, I would vote for something that clearly distinguishes it from
 other language concepts (on a syntactic level), especially since it is
 compiler specific (different compilers could give different values
depending
 on eg optimization flags). Much like type casts are particularly verbose
and
 noticable in C++ (new standard). What about __sizeof__( x ) or even

It's a static property.
Nov 19 2003
parent reply Berin Loritsch <bloritsch d-haven.org> writes:
Walter wrote:

 "Jeroen van Bemmel" <someone somewhere.com> wrote in message
 news:bpgtk2$1pf5$1 digitaldaemon.com...
 
Very good point! If D is aiming to discourage low level pointer
aritthmetic
and provides garbage collection, that reduces the two major use cases for
.size or sizeof to nothing. On the other hand, Java's type system
encourages
people to use lots of objects since the memory cost is transparent, which
causes Java programs to require ridiculus amounts of memory.
:) I can't vouch for other people's misuse of memory. However I agree with your assessment of far too many applications. The Java Garbage Collector is truly an amazing thing, but it won't waste time collecting garbage if there is plenty of memory available. That's part of the reason that the JVM has min and max memory parameters to tune the JVM for an application. I also think that Java developers have discovered something that is also just as disturbing. Garbage collection can lull you into a false sense of security. IOW, if the system is taking care of deleting my old objects then I won't have to care about memory consumption. That is a patent lie. We have to be just as careful with garbage collection as we do with explicit new and delete operators. The thing is that garbage collection allows us to do some things a lot easier than with explicit new and delete operators. Case and point is the Java compiler. It is pretty well known that it has a memory leak. You can't embed the Java compiler (itself a Java program) inside a server based app, or you will grind your server to a halt over time. It has to be run externally because it does not dereference all the variables it uses. A chief culprit is storing state information in static variables. The state info references other objects, which in turn reference more objects, even though those objects are no longer needed. End result is very hard to trace memory leaks. What some folks have done is to "instrument" their environments to track the memory consumption and how it is behaving. Is this something we can expect from the D memory system? I think it would be *very* important to tracking down certain types of memory leaks in an application resulting in some objects never being cleared.
 
 
 Yet what prevents Java from doing system apps is an inability to do pointer
 arithmetic. You cannot implement certain kinds of things without knowing the
 sizes. One thing that won't work is varargs <g>. Another is implementing the
 garbage collector.
 
Essentially the .size is then used for system apps. Is this a pattern we would want to encourage? I.e. .size only be available in an "unprotected" domain, explicit memory management and pointer arithmetic--not that it is an unprotected memory space. About the varargs argument, I'm not really that convinced. If every argument is an implicit pointer to the object itself (as it is in Java), then all argument sizes are the size of a pointer. You can have several objects passed in, but as far as iterating over the arguments, they would all be 32 bits wide on an x86 JVM. Of course to contradict myself (and to be fair to your argument) the only time that there is a difference is for primitives. A long is 64 bits, an int is 32 bits, a short is 16 bits and a byte is 8 bits.
Nov 20 2003
parent reply "Walter" <walter digitalmars.com> writes:
"Berin Loritsch" <bloritsch d-haven.org> wrote in message
news:3FBCBC60.80005 d-haven.org...
 I also think that Java developers have discovered something that is also
just
 as disturbing.  Garbage collection can lull you into a false sense of
security.
 IOW, if the system is taking care of deleting my old objects then I won't
have
 to care about memory consumption.  That is a patent lie.  We have to be
just as
 careful with garbage collection as we do with explicit new and delete
operators.
 The thing is that garbage collection allows us to do some things a lot
easier
 than with explicit new and delete operators.
You're right.
 What some folks have done is to "instrument" their environments to track
the
 memory consumption and how it is behaving.  Is this something we can
expect
 from the D memory system?  I think it would be *very* important to
tracking
 down certain types of memory leaks in an application resulting in some
objects
 never being cleared.
In the D implementation of gc, you can turn on various options to track all the allocations. This capability is not an official part of D, just a nice thing about the current implementation of the D garbage collector.
 Essentially the .size is then used for system apps.  Is this a pattern we
would
 want to encourage?  I.e. .size only be available in an "unprotected"
domain,

have
 explicit memory management and pointer arithmetic--not that it is an
unprotected
 memory space.
I don't think that the idea of various domains is appropriate for D (there's no way to sandbox it anyway without a VM). D makes no attempt to prevent using pointers to arbitrarilly access memory, it just tries to make it *unnecessary* for routine programming tasks.
 About the varargs argument, I'm not really that convinced.  If every
argument is
 an implicit pointer to the object itself (as it is in Java), then all
argument
 sizes are the size of a pointer.  You can have several objects passed in,
but as
 far as iterating over the arguments, they would all be 32 bits wide on an
x86
 JVM.  Of course to contradict myself (and to be fair to your argument) the
only
 time that there is a difference is for primitives.  A long is 64 bits, an
int is
 32 bits, a short is 16 bits and a byte is 8 bits.
But every argument is not an object reference. Arguments can be basic types, or structs which are passed by value.
Nov 20 2003
parent reply "Jeroen van Bemmel" <someone somewhere.com> writes:
 JVM.  Of course to contradict myself (and to be fair to your argument) the
 only
 time that there is a difference is for primitives.  A long is 64 bits,
an
 int is
 32 bits, a short is 16 bits and a byte is 8 bits.
But every argument is not an object reference. Arguments can be basic
types,
 or structs which are passed by value.
..but that could be fixed: Force structs to varargs methods to always be passed by reference (by creating a temporary on the stack if needed), and force simple data types to be passed by value as 32bits (and then don't allow 64bit parameters, or force all to 64 bit). Aligning parameters to be 32bits is a good idea anyway, especially on x86
Nov 20 2003
parent reply "Walter" <walter digitalmars.com> writes:
"Jeroen van Bemmel" <someone somewhere.com> wrote in message
news:bpjk2l$2o9r$1 digitaldaemon.com...
 JVM.  Of course to contradict myself (and to be fair to your argument)
the
 only
 time that there is a difference is for primitives.  A long is 64 bits,
an
 int is
 32 bits, a short is 16 bits and a byte is 8 bits.
But every argument is not an object reference. Arguments can be basic
types,
 or structs which are passed by value.
..but that could be fixed: Force structs to varargs methods to always be passed by reference (by creating a temporary on the stack if needed), and force simple data types to be passed by value as 32bits (and then don't allow 64bit parameters, or force all to 64 bit).
That can work, but there's a runtime cost for that can be a problem.
 Aligning parameters to be 32bits is a good idea anyway, especially on x86
It already does that, using the C rules for varargs <g>.
Nov 20 2003
parent "Jeroen van Bemmel" <someone somewhere.com> writes:
 That can work, but there's a runtime cost for that can be a problem.
I'll bet that an analysis of uses of varargs methods would reveal that most of the time, primitive types (ints and char*) are passed as parameters. Varargs methods are generic by nature, thus it makes sense that also their parameters are (structs require specific knowledge of their internals)
Nov 21 2003
prev sibling parent reply "Jeroen van Bemmel" <someone somewhere.com> writes:
If I had to choose I would prefer ".size" since 'sizeof' is an operator /
function (and not a property), which would intuitively be used as
sizeof(obj) and not obj.sizeof


obj.size if you like)

As for conflicts with C/C++ keywords, that would only be an issue when you
translate (preprocess) D to C/C++ code. That preprocessor would simply have
to make sure to make the right translation

"Walter" <walter digitalmars.com> wrote in message
news:bp7jd9$914$1 digitaldaemon.com...
 It occurs to me that .sizeof is a much better name for the size of a type
 than .size, because:

 1) since sizeof is a C/C++ keyword, it cannot conflict with any struct or
 class names.
 2) it's immediately recognizable for what it does
Nov 18 2003
parent reply "Walter" <walter digitalmars.com> writes:
"Jeroen van Bemmel" <someone somewhere.com> wrote in message
news:bpdrn6$4g9$1 digitaldaemon.com...
 If I had to choose I would prefer ".size" since 'sizeof' is an operator /
 function (and not a property), which would intuitively be used as
 sizeof(obj) and not obj.sizeof
What would happen is sizeof(obj) in C would be semantically the same as obj.sizeof in D.

 obj.size if you like)
 As for conflicts with C/C++ keywords, that would only be an issue when you
 translate (preprocess) D to C/C++ code. That preprocessor would simply
have
 to make sure to make the right translation
The conflict comes from size being a common field name in C/C++, and this would not translate directly to D. Using sizeof means that it could not conflict with field names coming from C/C++.
Nov 18 2003
next sibling parent "Jeroen van Bemmel" <someone somewhere.com> writes:

 obj.size if you like)
Hey, me too! And also ' (tick), although it may be a bit small to notice...
Nov 18 2003
prev sibling parent "Jeroen van Bemmel" <someone somewhere.com> writes:
 The conflict comes from size being a common field name in C/C++, and this
 would not translate directly to D. Using sizeof means that it could not
 conflict with field names coming from C/C++.
I was working on a language (more like a preprocessor) that translated to C/C++. As a rule I simply generate some prefix (I like '$' but that may not be portable) to variable names, to make sure they do not conflict with C keywords. You could do the same for a translator from C/C++ to D, although it would make the code slightly more akward to use if you intend to extend it in D after translation.(viz "obj.$size = 3;" or perhaps "_size" if you like ) Alternatively, such a translator would simply look for conflicting identifiers (i.e. hashtable of D keywords) and only prepend / replace something in these cases. It just seems a bit strange to me, the argument to use 'sizeof' because it happens to be a C keyword which gives immunity to conflicts. Surely D has more keywords that could interfere ("class" being one of them for plain C code), would that mean that these also get replaced with C keywords?
Nov 18 2003