5 Problems & Workarounds
5.1 Common Pitfalls
5.1.1 Include Cycles
In versions prior to 1.0pre1 include cycles could occur in many situations and workarounds could not always be found. In version 1.0pre1 include cycles can only occur in the case of aspect code with introductions. Advice for code join points cannot produce cycles.
The reason for the remaining possible cycles is that ac++ generates #include <aspect-header> in every file that contains the definition of a target class of an introduction. Without this generation pattern definitions from the aspect header would not be accessible by introduced code. However, if the aspect header directly or indirectly includes the target file, there is a cycle, which might cause parse errors.
Figure 1 illustrates the include cycle problem by giving an example. Here an aspect Problem uses the type Target and therefore includes Target.h. At the same time the aspect introduces a slice into the class Target. As the slice might depend on definitions or #includes in Problem.ah, the weaver generates the #include "Problem.ah" in Target.h. This causes the include cycle. Include guards (which should always be used!) avoid duplicate definitions, but do not solve the problem. It might still be the case that the parser complains about undefined types.
To avoid these cycles introductions can always be separated from the aspect by means of slices. Slice declarations and slice member definitions can be located in arbitrary aspect header files. The aspect weaver will only include these aspect headers in the target classes’ header/implementation files and thereby avoid the cycle. For a slice reference within an advice declaration even a forward declaration of the slice is sufficient.
Figure 2 shows how the include cycle from the example in Figure 1 can be avoided. Here the function dump is implemented in a separate slice class Dump that is stored in an aspect header file Dump.ah. The implementation of Dump could rely on defintions and #includes in Dump.ah (stdio.h in this example), but not on defintions in Problem.ah. Therefore, the aspect weaver generates #include "Dump.ah" and not #include "Problem.ah" in Target.h.
Note that in the case of non-inline introductions the #include directive is generated in the file that contains the “link-once element” of the target class, which is never a header file. You can, for example, exploit this feature to produce cyclic class relationships. The included file will be the aspect header file that contains the definition of the non-inline slice member.
5.1.2 Duplicate Forced Includes in STU Mode
In the Single Translation Unit (STU) mode ac++ handles forced includes (see -include option in section 3.4.26) in the following way:
- internal includes:
- If the included file is part of your project, the file content will be expanded in the compiled translation unit.
- external includes:
- If the included file is not part of the project, ac++ generates an #include directive with the absolute path name of the file.
In both cases the back-end compiler should not be forced to include the same file again. For example, g++ users should not use the -include option with ac++ and with g++, because otherwise symbols might be defined twice.
5.1.3 Compiling libraries
There are certain restrictions on the code structure if ac++ should generate transformed header files for an aspect-oriented C++ library. For instance, all header files need "include guards" and should not depend on the context by which they are included. Furthermore all headers must have the extension .h.
Furthermore, users have to be careful not to generate transformed headers into the project directory tree (-p option). Otherwise, the next compilation of the library is likely to fail, because ac++ would search aspect header files in the generated directory tree.
5.1.4 Project structure
The AspectC++ weaver ac++ expects that "projects" do not overlap, have no cyclic dependencies, and can be described by a list of directory names (-p option). AspectC++ needs the notion of a "project" in order to restrict the set files that are affected by the aspects. Sometimes big applications are organized in multiple projects within the same workspace and have arbitrary dependencies (include relations) to each other. For these applications selecting the -p option is sometimes difficult. Often treating the whole workspace as one AspectC++ project is the best solution.
5.1.5 The --aspect_header option
This option can be used to avoid that ac++ automatically searches all aspect header files in the project directory tree. It is to be made sure by the user that each aspect header file is included only once. If no aspect headers should be taken into account, the option “-a 0” has to be used.
5.2 Unimplemented Features
5.2.1 Multi-Threading Support
C++ has no integrated thread model like Java. Therefore, the woven AspectC++ code cannot rely on any available thread synchronization mechanism. As a result the implementation of the cflow pointcut functions is currently not thread-safe.
We are urgently investigating how thread synchronization and thread local storage can be integrated into AspectC++.
5.2.2 C++ 11/14/...
ac++ does not fully support the latest language features introduced with the C++ 11 standard. These features, such as lambda functions or move constructors, are accepted by the underlying parser (the Clang framework, which is used in ac++ 2.x), but the weaver can’t deal with these features, yet. Therefore, it is safe to use C++ 11 code as long as the code affected by advice conforms to C++ 2003.
5.2.3 Parse Errors
If ac++ stops processing because of parse errors this might be due to an incompatibility or missing feature in the underlying C++ parser.
In the case that the error is found in your own code, i.e. code you are able to modify, you could use the following workaround:
#ifdef __acweaving
// ... simplified version of the code for ac++
#else
// ... original code
#endif
Even if your own AspectC++ code contains only harmless C++ code you might experience parsing problems due to header files from libraries which your application code includes, especially in the case of template libraries. In this situation it might help to copy the file with the parse error into a different directory. Then you have to change the code in this file to avoid the error message by simplifying it. The final step is to extend the puma.config file by a “-I <path>” entry for the directory where you placed the copy. As the result ac++ will now parse the simplified version while the original file is untouched and used while the C++ compiler runs.
5.2.4 Templates
Currently ac++ is able to parse a lot of the (really highly complicated) C++ templates, but weaving is restricted to non-templated code only. That means you can not weave in templates or even affect calls to template functions or members of template classes. However, template instances can be matched by match expressions in the pointcut language and calls to members of class templates or template functions can be affected by advice.
5.2.5 Macros
In versions prior to 1.0 the weaver was not able at all to transform code that was generated by macro expansion. It simply printed a warning and continued without transforming the code. To turn this warning off the command line option --no_warn_macro could be used (see Table 3).
The current solution is to expand a macro whenever it is affected by aspects and do the weaving afterwards. While this works fine for most cases, problems may occur if the macro definition used by the (cross-)compiler differs from the one used by ac++. Future releases will thus distinguish between macros definitions that belong to the project and can safely be expanded and macros that were defined outside the project.
5.2.6 Unimplemented Language Elements
- cflow
- does not yet support exposure of context information.
- base
- only works as expected if all classes that should be matched by the pointcut function’s argument are known in the translation unit. Therefore, the aspect header file has to contain the right set of include directives.
5.2.7 Support for Plain C Code
Currently ac++ generates C++ code, which cannot be compiled by a C compiler. As for many hardware platforms in the embedded domain no C++ compiler is available we are actively looking for a solution.
5.2.8 Support for C++ language extensions
The parser fully supports the language features of C++ 11 and more recent standards (see 5.2.2), but the AspectC++ language and the code transformation patterns have not been extended, yet. Make sure that match expressions don’t match functions with signatures that contain elements that did not exist in C++ 03. Since version 2.3 constexpr functions are not matched automatically.
5.2.9 Constructor/Destructor Generation
If advice for construction/destruction joinpoints is given and no constructor/destructor is defined explicitly, ac++ will generate it. However, currently ac++ assumes that the copy constructor has one argument of type “const <Classname>&”. This leads to problems if the implicitly declared copy constructor has an argument of type “<Classname>&”. Therefore, you should not define construction/destruction advice for classes with this copy constructor signature.
Further problems appear when an a class instance is aggregate initialized. The automatic constructor generation can break this ability.
5.2.10 Functions with variable argument lists
There is no support for execution advice on functions with variable argument lists. A warning will be issued. There is no portable way to generate a wrapper function for this class of functions.
5.2.11 Restrictions on calling tjp->proceed()
Due to a problem with result object construction/destruction of intercepted functions, the tjp->proceed() function may only be called once during around advice.
5.2.12 Advice on advice
Join points within advice code are not matched by pointcut expressions.
5.2.13 JoinPoint-API for slices
There is a joinpoint-API for slices introduced into a target class. It provides static type information about the target’s baseclasses and members as well as dynamic information, such as a pointer to each member. However, the baseclass part of the slice may not access the JoinPoint-API. This is partly natural, as, for instance, member types might depend on the introduced baseclass. Yet, not even the target’s classname is available. Future versions might make this possible.
The identifier ’JoinPoint’ is only to be used to access the joinpoint-API. Even though it would conceptually make sense to allow, for instance, a local variable to be called ’JoinPoint’, it is not supported, yet.