• davidl (30/30) Nov 11 2007 Dynamic cast is some thing should be templatized.
• Jarrett Billingsley (5/6) Nov 11 2007 At the call site, yes, it will become slightly smaller. But you've
• DavidL (7/17) Nov 11 2007 If you grep your source thoroughly, you will find you only cast to very ...

davidl <davidl 126.com> writes:

Dynamic cast is some thing should be templatized.

A typical call to dynamic cast, we need to push classinfo, object.

A templatized dynamic cast, we only need to push object itself.

It would make the code size smaller with a very neglectable runtime cost.

Moreover, class oriented stuff would be best if it's customized.

For porting DMDFE, a very interesting use case of class hierarchy, directly
using D's classinfo would result codebloat & bad run time efficiency.

For extreme case, we sometimes don't need a full consistent classinfo.
Sometimes we want a little bit sacrifice at runtime but cut a lot  
generated code
size. Like ForeachStatement in DMDFE, it represents ForeachStatement,
ForeachReverseStatement, if I create two class, it costs too much to only
get a different classinfo for this two classes. and mixin template would  
make
the binary bloat. So for this special case, a different dynamic cast is  
used
in DMDFE, there's a specific field to trait what kind of class this is.

I think a lot factors contribute to make dparser binary bigger than DMDFE,  
this
RTTI is one of the issue.

With traits power, and the compile-time power we now have, it's really  
possible
to leave the classinfo to user to design on their own. so RTTI would be  
flexible
and less user sensitive information would be exposed. Consider a  
commercial ware,
classinfo.name would expose their internal design of their classes in  
their binary.


-- 
使用 Opera 革命性的电子邮件客户程序: http://www.opera.com/mail/

"Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:

"davidl" <davidl 126.com> wrote in message news:op.t1nqmwn5eb62bo lzg...

 It would make the code size smaller with a very neglectable runtime cost.

At the call site, yes, it will become slightly smaller.  But you've 
forgotten that you then need to have a separate copy of the dynamic cast 
function for every class that you do a dynamic cast to.  With the current 
way of doing things, there's only one function. 

DavidL <davidl 126.com> writes:

Jarrett Billingsley Wrote:

 "davidl" <davidl 126.com> wrote in message news:op.t1nqmwn5eb62bo lzg...
 
 It would make the code size smaller with a very neglectable runtime cost.

 
 At the call site, yes, it will become slightly smaller.  But you've 
 forgotten that you then need to have a separate copy of the dynamic cast 
 function for every class that you do a dynamic cast to.  With the current 
 way of doing things, there's only one function. 
 
 

If you grep your source thoroughly, you will find you only cast to very limited
set of classes. while each cast(Certain_type) might have been called dozens of
times.

That depends on a balance point which can be controlled by compiler, how much
function would be benefit from making it a template.

e.g. cast(Type1) has been referenced over 50 times,  in this case, it would be
better to make it template. (better runtime efficiency, and better in size)
cast(Type2) has been only referenced 10 times, then making it as it's now by
using a generic dynamic cast.

The times of templatizing a function depends on how much code does a dynamic
cast function take, if the binary size of a dynamic cast function takes 50
bytes, and each non-template caller takes 5bytes more than template caller, 
then if the cast is referenced over 50/5 = 10 times , then this specific type
cast should be templatized.

And if users prefers speed over the size of the binary size, then all this kind
of stuffs should be templates.