[aspectc-user] cout insertion -- AOP-able?

[Olaf Spinczyk]

Hello Craig,

Craig E. Tull wrote:
> 
> We are trying to intercept and override the illegal use of cout in a 
> large, high energy physics framework. We would like to use this as an 
> illustration of the power of AOP.
> 
> We believe that aspectc's inability to handle templates is the reason 
> that the following does not work. Are we doing something wrong? If not...

Both, there is a problem with the inability to handle templates and you 
also did something wrong (the pointcut expression, see below). The class 
ostream has been a template instance since g++ 3.x. AspectC++ does not 
'see' any joinpoints related to functions that depend on templates. 
Therefore, your example wouldn't work, even with a correct pointcut 
expression.

> ...Are there any workarounds? What are the prospects of this trivial 
> example working in a future release?
> 
> - Craig

Yes, there is a workaround. If you use an older g++ compiler like 2.95.4 
the following example code ...

--
#include <iostream>

aspect COutTracing {
   advice call ("ostream & ostream::operator <<(const char *)") &&
          !within ("COutTracing") : after () {
     cout << " world" << endl;
   }
};

int main () {
   cout << "hello" << endl;
}
--

can be compiled and works as expected (it prints "hello world"). If you 
don't want to compile your application with such an old compiler you 
could try to use the 2.95 header files only for weaving and not for the 
compilation.

[By the way, the example doesn't work if you write std::cout instead of 
cout. There is a 2.95 compatibility hack needed in ac++ to support this, 
which is enabled by --gnu-2.95 in your config file. However, this hack 
has been broken. It will be fixed in the next release. Contact me 
directly if you need this feature.]

Concerning full template support (parsing + weaving) in future ac++ 
versions, I can't give you an exact date. A lot of code needed for the 
full analysis has already been implemented and several examples work. 
However, there is a big difference between simple test cases and the 
code of the GNU STL. We are optimistic that at least call advice for 
templates (no weaving inside templates, which is the next step) will 
work by september.

> /////////////////////////////////////////////// main.cc
> #include <iostream>
> int main();
> int main()
> {
>     std::cout <<  "Hello world" << std::endl;
>     std::cout.operator<<(33);
>     std::cout.operator<<(std::endl);
>     return 0;
> }
> 
> /////////////////////////////////////////////// Cnot.ah
> #ifndef __Cnot_h__
> #define __Cnot_h__
> #include <iostream>
> aspect Cnot
> {
>     pointcut inserter() = "% std::cout::operator<<(...)";
> public:
>     advice execution(inserter ()) : void around ()
>     {
>         std::cerr << "Sorry, no output allowed!!!" << std::endl;
>     }
> };
> #endif // __Cnot_h__
> 

The pointcut expression "% std::cout::operator<<(...)" is incorrect, 
because std::cout is not a class. Currently AspectC++ does not support 
any kind of advice on object instances. Therefore, you would have to 
define advice for operator << on the class in which it is defined 
(ostream in the g++2.95 headers). The pointcut can expose the object 
instance on which the function is called as a context variable: '.. && 
target (the_object) : around (ostream *the_object) { ... }'. This object 
could be compared with cout in the advice (at run-time).

Furthermore, ac++ does not weave in header files, which are not part of 
your project (like system headers). Therefore, you can only define call 
advice for functions defined in system headers.

And last but not least, you have to be very careful with blanks in match 
expressions in ac++ <= 0.8.1 (compare your match expression with the one 
in my example). If you are unsure, use a very generic match expression 
and look at the output you get when you run ac++ with '-v9'.

[The next release of ac++ will have a match-expression parser and a 
match expression semantics described in the language reference manual. 
This will solve the problems with blanks and many others. The next 
release will also be much faster than 0.8.1.]

Best regards,

Olaf