AspectC++

... and your code gets untangled

AspectC++ Frequently Asked Questions

  1. Can I use AspectC++ with my favourite IDE?
  2. Can others join in the development effort?
  3. Does AspectC++ generate code for platform X?
  4. Is ag++/ac++ for CygWin broken?
  5. Is it your plan to keep the AspectC++ compiler open-source?
  6. Is the AspectC++ compiler itself implemented using AspectC++?
  7. Is the AspectC++ compiler source code available?
  8. My pointcut expression matching a function looks perfect, but ac++ doesn't weave my advice code. Why?
  9. What about pure C code (no C++)?
  10. What about weaving in templates?
  11. Why don't you use size_t in the signature of generated operator new functions?
    Why does woven code not compile on a different platform?
  12. Why does 'set' and 'get' advice miss variable access via pointers or references?

Still questions?

If you have a question not answered here or you need additional explanations, feel free to send us a mail via info@aspectc.org.

Can I use AspectC++ with my favourite IDE?

Of course, you can use the sources generated by ac++ as input to any IDE. However, you would destroy your sources when you change aspects and re-run ac++.

If you are using Microsoft® Visual Studio.NET® check out the AspectC++ Add-In from pure systems. It provides seamless integration of AspectC++ into Visual Studio.NET. There is an evaluation version available for download.

Support for other IDEs is not provided, yet. A project to create an AspectC++ plugin for the Eclipse platform started recently.

However, calls to ac++ can be easiliy added to UNIX-like Makefiles. If your IDE supports a 'make-based' build process it will be fairly easy to integrate ac++.

Can others join in the development effort?

We strongly encourage users to submit bug reports with our Bugzilla-based bug tracking system. If possible, provide a very small code fragment that can be used to reproduce the problem.

Users who would like to offer even more help should contact info@aspectc.org. If you send us a patch, please also send us a statement, which says that you donate the patch (including all rights) to the AspectC++ development team. Please use the "unified" diff format, as produced by "diff -u" or "svn diff", and include the patch in your mail without any modifications.

Does AspectC++ generate code for platform X?

No. AspectC++ is a source-to-source translator. The output is C++, so you can use your preferred C++ compiler to generate code for any platform that is supported by that compiler.

We take care that the ac++ output is at least compatible with g++ compilers starting from version 2.95 and MS Visual C++.

Is ag++/ac++ for CygWin broken?

No, but you have to know what you are doing. ac++.exe and ag++.exe are compiled with mingw and *not* linked with the CygWin libraries. Therefore, they can't deal with Cygwin Links. In modern CygWin installations g++.exe is a link to /etc/alternatives/g++ and ag++ fails to execute it. However, with "ag++ --c_compiler g++-4.exe -c main.cc" it works fine.

Is it your plan to keep the AspectC++ compiler open-source?

Yes, the code developed by the AspectC++ development team will continue to be open source. However, there some specific extensions to support the development under Microsoft Windows® which are only available by pure-systems GmbH.

Is the AspectC++ compiler itself implemented using AspectC++?

Yes, most of it. The PUMA library is implemented using several aspects while the weaver itself is not written with aspects.

Is the AspectC++ compiler source code available?

Yes, the source code of the ac++ weaver and the underlying C++ code analyzer and transformer PUMA is available under the GPL from the AspectC++ homepage (www.aspectc.org).

My pointcut expression matching a function looks perfect, but ac++ doesn't weave my advice code. Why?

Make sure that the matched name is not a macro. AspectC++ can't match macros:

#define X x_is_real_function_name 

...

int X(int b) { ... } 
	 

will not be matched by "% X(int)".

What about pure C code (no C++)?

Currently, AspectC++ is able to parse and weave in C code. However, the AspectC++ parser is a C++ parser and there are a few incompatibilities. Another problem is that ac++ generates C++ code to weave the advice code into the component code. Therefore, even if your source code is pure C, the result can only be compiled with a C++ compiler.

Our goal is to make AspectC++ an AOP solution for C++ and C. Therefore, preliminary C support was announced for version 1.0pre3. However, the implementation was not yet in a useful state and therefore will be published later with the 1.0pre4 version in early summer 2006. Note that this version will support only a limited set of language features. It shall be improved step by step.

What about weaving in templates?

ac++ does not support weaving in templates yet. These potential join-points are silently ignored by the match mechanism.

The reason is that weaving in templates requires a full syntactic and semantic analysis of the template instances by the underlying C++ parser. However, this parser feature is still experimental and does not work for real-world code. Once the parser is able to perform this analysis reliably, we can implement the necessary code transformations within the aspect weaver.

Why don't you use size_t in the signature of generated operator new functions?
Why does woven code not compile on a different platform?

Weaving code that should be compiled on a different platform is a very special case. We don't generate 'size_t', because size_t is not a built-in type and generating #include (for instance) might cause trouble for users who don't use a fully standard-compliant C++ library. We prefer not to depend on external files in the generated code.

In order to solve the problem in the case of cross compilation (weaving + compilation with a cross compiler) we have integrated the options --size-type and --ptrdiff-type some time ago. This could also be used when woven code shall be compiled on a different platform.

With a g++ cross compiler one could also use ag++ with the option "--c_compiler <my-cross-compiler>". Then ag++ will determine the right types automatically and write the correct --size-type etc. options in the parser configuration file. If g++ is used on both platforms you might also use "--size-type=__SIZE_TYPE__". "__SIZE_TYPE__" is a built-in g++ macro which is automatically replaced by the correct type.

Why does 'set' and 'get' advice miss variable access via pointers or references?

Checking whether a specific variable is accessed via a dereferenced pointer or a reference would require a runtime system, complex static analyses, or a combination of both. Therefore, this feature is not supported, yet. 'set' and 'get' only work reliably if the variable is only access by its name. To make sure that no alias for a variable (pointer or reference) is created the 'ref' pointcut function can be combined with advice that contains a static assertion (C++ 11 feature). The static asserting needs to depend on the type 'JoinPoint' and the condition must evaluate to 'false'. In this case the compiler will instantiate the advice if a 'ref' join point was matched and the static assertion will make it print an error message.