www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - SizeOf <what??>

reply S. Chancellor<dnewsgr mephit.kicks-ass.org> writes:
I want to voice my opinion on .sizeof, .mangleof and all the other `*of`
properties.   They don't make a whole lot of sense.  sizeof(<var>)
makes sense.  var.size makes sense.  var.sizeof, however, seems lacking as
nothing comes after the of.
Also, why isn't typeof() a property? I'm assuming it has something to do
with the fact that it's evaluated at compile-time instead of runtime. 
However, I still think that var.type would be a lot more consistent.
My 2 cents, thanks for listening.

-- 
Email works.
Jan 03 2006
next sibling parent F <F_member pathlink.com> writes:
I think Walter choose to rename .size (as initially was) to .sizeof in order to
avoid conflicts when porting C code, where "size" was a common variable name
while "sizeof" wasn't (since it was a function).
I have an ambiguous opinion im my head about that, but I admit that .size would
be more (human language) coherent.

F



In article <dpe6fj$edf$1 digitaldaemon.com>, S. Chancellor says...
I want to voice my opinion on .sizeof, .mangleof and all the other `*of`
properties.   They don't make a whole lot of sense.  sizeof(<var>)
makes sense.  var.size makes sense.  var.sizeof, however, seems lacking as
nothing comes after the of.
Also, why isn't typeof() a property? I'm assuming it has something to do
with the fact that it's evaluated at compile-time instead of runtime. 
However, I still think that var.type would be a lot more consistent.
My 2 cents, thanks for listening.

-- 
Email works.

Jan 03 2006
prev sibling parent reply Chris Sauls <ibisbasenji gmail.com> writes:
S. Chancellor wrote:
 I want to voice my opinion on .sizeof, .mangleof and all the other `*of`
 properties.   They don't make a whole lot of sense.  sizeof(<var>)
 makes sense.  var.size makes sense.  var.sizeof, however, seems lacking as
 nothing comes after the of.
 Also, why isn't typeof() a property? I'm assuming it has something to do
 with the fact that it's evaluated at compile-time instead of runtime. 
 However, I still think that var.type would be a lot more consistent.
 My 2 cents, thanks for listening.
 

While generally you make a point, the reason that 'tyepof()' isn't a property is because it can be used with expressions, and does *not* evaluate its expression for more than type information. So, for example: # typeof(foo(i) / bar(j)) var ; Here we declare 'var' according to the final type of the given expression, but *without* actually evaluating either 'foo(i)' or 'bar(i)' beyond function-matching and return-type exraction. -- Chris Sauls
Jan 03 2006
parent reply "Craig Black" <cblack ara.com> writes:
 While generally you make a point, the reason that 'tyepof()' isn't a 
 property is because it can be used with expressions, and does *not* 
 evaluate its expression for more than type information.  So, for example:

 # typeof(foo(i) / bar(j)) var ;

But couldn't the following be treated the same way? It is, perhaps, more difficult for the compiler to see that the expression should be evaluated at compile time? (foo(i) / bar(j)).typeof var; -Craig
Jan 03 2006
next sibling parent reply Sean Kelly <sean f4.ca> writes:
Craig Black wrote:
 While generally you make a point, the reason that 'tyepof()' isn't a 
 property is because it can be used with expressions, and does *not* 
 evaluate its expression for more than type information.  So, for example:

 # typeof(foo(i) / bar(j)) var ;

But couldn't the following be treated the same way? It is, perhaps, more difficult for the compiler to see that the expression should be evaluated at compile time?

Perhaps, but sizeof is evaluated at compile time as well. Sean
Jan 03 2006
parent reply "Craig Black" <cblack ara.com> writes:
 Perhaps, but sizeof is evaluated at compile time as well.

This does seem odd. If it doesn't overcomplicate the compiler, then typeof should be consistent with the rest of the "*of" family. -Craig
Jan 03 2006
parent reply "Matthew" <matthew hat.stlsoft.dot.org> writes:
"Craig Black" <cblack ara.com> wrote in message
news:dpek7p$tga$1 digitaldaemon.com...
 Perhaps, but sizeof is evaluated at compile time as well.

This does seem odd. If it doesn't overcomplicate the compiler, then

 should be consistent with the rest of the "*of" family.

My 2 cents: all should be non-member operators, a la typeof.
Jan 03 2006
next sibling parent reply S. Chancellor <S._member pathlink.com> writes:
In article <dpf5i1$1dp6$1 digitaldaemon.com>, Matthew says...
"Craig Black" <cblack ara.com> wrote in message
news:dpek7p$tga$1 digitaldaemon.com...
 Perhaps, but sizeof is evaluated at compile time as well.

This does seem odd. If it doesn't overcomplicate the compiler, then

 should be consistent with the rest of the "*of" family.

My 2 cents: all should be non-member operators, a la typeof.

Wouldn't that clutter up the namespace with all the properties from float and whatnot? -S.
Jan 03 2006
parent "Chris Miller" <chris dprogramming.com> writes:
On Tue, 03 Jan 2006 20:07:48 -0500, S. Chancellor <S._member pathlink.com>  
wrote:

 In article <dpf5i1$1dp6$1 digitaldaemon.com>, Matthew says...
 "Craig Black" <cblack ara.com> wrote in message
 news:dpek7p$tga$1 digitaldaemon.com...
 Perhaps, but sizeof is evaluated at compile time as well.

This does seem odd. If it doesn't overcomplicate the compiler, then

 should be consistent with the rest of the "*of" family.

My 2 cents: all should be non-member operators, a la typeof.

Wouldn't that clutter up the namespace with all the properties from float and whatnot? -S.

I think he means just the "*of" ones (mangleof,sizeof...) that apply to most everything, and I wouldn't be upset if this switch was made.
Jan 03 2006
prev sibling parent Chris Sauls <ibisbasenji gmail.com> writes:
Matthew wrote:
 "Craig Black" <cblack ara.com> wrote in message
 news:dpek7p$tga$1 digitaldaemon.com...
 
Perhaps, but sizeof is evaluated at compile time as well.

This does seem odd. If it doesn't overcomplicate the compiler, then

typeof
should be consistent with the rest of the "*of" family.

My 2 cents: all should be non-member operators, a la typeof.

Actually, that's not a bad idea at all, at least for the *of() ops. Mister Bright? -- Chris Sauls
Jan 04 2006
prev sibling parent reply "Walter Bright" <newshound digitalmars.com> writes:
"Craig Black" <cblack ara.com> wrote in message 
news:dpej71$s0i$1 digitaldaemon.com...
 While generally you make a point, the reason that 'tyepof()' isn't a 
 property is because it can be used with expressions, and does *not* 
 evaluate its expression for more than type information.  So, for example:

 # typeof(foo(i) / bar(j)) var ;

But couldn't the following be treated the same way? It is, perhaps, more difficult for the compiler to see that the expression should be evaluated at compile time? (foo(i) / bar(j)).typeof var;

That leads to parsing problems, unfortunately, as it becomes difficult to recognize a declaration vs an expression.
Jan 03 2006
parent Roberto Mariottini <Roberto_member pathlink.com> writes:
In article <dpet5r$16g0$3 digitaldaemon.com>, Walter Bright says...
"Craig Black" <cblack ara.com> wrote in message 
news:dpej71$s0i$1 digitaldaemon.com...

 (foo(i) / bar(j)).typeof var;

That leads to parsing problems, unfortunately, as it becomes difficult to recognize a declaration vs an expression.

Walter, what do you think about my idea of (optionally) disambiguating declarations from expressions? Ciao
Jan 04 2006