View mode: basic / threaded / horizontal-split · Log in · Help
January 03, 2006
Re: SizeOf <what??>
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.
>
January 03, 2006
Re: SizeOf <what??>
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
January 03, 2006
Re: SizeOf <what??>
> 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
January 03, 2006
Re: SizeOf <what??>
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
January 03, 2006
Re: SizeOf <what??>
> 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
January 03, 2006
Re: SizeOf <what??>
"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.
January 04, 2006
Re: SizeOf <what??>
"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.
January 04, 2006
Re: SizeOf <what??>
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
>typeof
>> 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.
January 04, 2006
Re: SizeOf <what??>
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
>> typeof
>>> 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.
« First   ‹ Prev
1 2
Top | Discussion index | About this forum | D home