[aspectc-user] Should AOP need a separate compiler ?

Olaf Spinczyk olaf at ivs.cs.uni-magdeburg.de
Tue Jan 29 13:24:32 CET 2002


On Tuesday, 29. January 2002 11:57, you wrote:
> Hi,
> At the implementation level for AOP, AspectC++ provides a separate language
> specification and a compiler for defining and compiling aspects. I have an
> ambiguity in why do we need a separate language specification for
> describing aspects and compile it separately. Are there any issues that can
> pop up if we use the same C++ compiler by defining aspects in C++ ?

I don't see any fundamental reason why there shouldn't be a single compiler 
that produces machine code directly from AspectC++. There are only two 

1. There are some language features, we would like to provide in the future,
   which require compiling all translation units at once. For instance, 
   pointcuts defined with "reachable" require a static control flow analysis,
   which makes no sense if it is restricted to a single translation unit.

2. You might want to use the transformed source code afterwards. For example,
   you implement a library with AspectC++, but your clients who want to use
   your include files use ordinary C++ compilers.
   Another example is that you might want to apply some other code
   transformation after AspectC++. AspectC++ is not able to implement
   all kinds of aspects that I could imagine. Different weavers with
   different aspect languages could be chained. This requires at least
   a compiler with aspect weaver plugins and an appropriate intermediate code

The practical reason for us to use a code transformation system to implement 
the language was, of course, that the AspectC++ transformer/compiler is not 
machine dependant now. The back-end is your favorite C++ compiler.

Does this answer cover all aspects of your question?



More information about the aspectc-user mailing list