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