[cfe-dev] AST Representation of Conversions

steve naroff snaroff at apple.com
Tue Jul 28 12:48:59 PDT 2009

On Jul 28, 2009, at 3:03 PM, Sebastian Redl wrote:
> Essentially, I think, we will have to enhance or wrap
> ImplicitConversionSequence from SemaOverload.h to also be able to
> represent conversions that are only explicitly possible. Then we put  
> it
> into the AST library and give CastExpr one of those.
> The problem with this approach is that it is heavy.
> ImplicitConversionSequence is a heavy object (40 bytes on 32-bit  
> without
> considering alignment, 80 bytes on 64-bit if alignment works the way I
> think it does), and every single ImplicitCastExpr (think of all the
> "usual integral conversions" in C) would bear this weight, as would
> casts that don't need this information, like const_cast (noop to
> codegen), dynamic_cast (always runtime calls) and reinterpret_cast
> (always bitcast).
> An option would be to rearrange the hierarchy, but this makes it  
> reflect
> the implementation instead of the logical grouping. Currently the
> hierarchy makes sense to programmers:
> http://clang.llvm.org/doxygen/classclang_1_1CastExpr.html
> If we were to rearrange it to fit the needs of data storage, CastExpr
> would be the direct base of CXXConstCastExpr, CXXDynamicCastExpr,
> CXXReinterpretCastExpr and ComplexCastExpr. ComplexCastExpr would hold
> the conversion sequence and be the base of CXXStaticCastExpr,
> CXXFunctionalCastExpr, CStyleCastExpr and ImplicitCastExpr. Not  
> pretty.
> Does anyone else have suggestions on how to solve this problem?

Hi Sebastian,

 From my perspective, ExplicitCastExpr models the language and  
ImplicitCastExpr models aspects of the underlying implementation (AST  
nodes inserted by Sema to simplify the code generator). IIRC, CastExpr  
is abstract. I think this division is nice/clean.

Would it make sense to add "heavier" sub-classes of ImplicitCastExpr  
to model the C++-specific conversions? Would this avoid the space  
overhead you are talking about?

I'm just starting to get my feet wet with clang's C++ support, so I  
don't have any C++-specific insights.


> Sebastian
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev

More information about the cfe-dev mailing list