[aspectc-user] concrete aspects: can or can not be inherited from?

Olaf Spinczyk Olaf.Spinczyk at informatik.uni-erlangen.de
Wed Mar 28 14:01:05 CEST 2007


Hello Panu,

sorry for the late reply. In my opinion it does not make sense to support
classes that inherit from (abstract or concrete) aspects. As your example shows,
this could lead to conflicts with the aspect instantiation scheme. Therefore, I
consider this behavior as a weaver bug.

- Olaf

Panu Bloigu wrote:
> Hello.
> 
> A correction to my last post. It doesn't seem matter which platform the
> code is compiled on. Instead, please consider the following file:
> 
> =============================================================================
> 
> 1:    int main()
> 2:    {
> 3:        return 0;
> 4:    }
> =============================================================================
> 
> 
> This is the contents of the file 'main.cpp' which gets instrumented by
> the aspects shown in my previous posts. The compiler generates ill C++
> code with this file. However, if there is anything in this file before
> the main function, compilation goes fine and the aspects are applied as
> I told in my first post. And by anything I mean that even a single empty
> line before the main function lets the compilation to succeed. So, for
> example, the following 'main.cpp' would compile fine with previously
> shown aspects and a class.
> 
> =============================================================================
> 
> 1:    // Anything here. Even an empty line will do.
> 2:    int main()
> 3:    {
> 4:        return 0;
> 5:    }
> =============================================================================
> 
> 
> What is going on here? This is strange enough as it is, let alone that I
> don't even know whether the code shown in my earlier posts *should* (as
> per AspectC++ language definition) compile.
> 
> Panu.
> 
> 
> Panu Bloigu wrote:
>> Hello.
>>
>> Yet more information on the subject. The code I presented compiles and
>> runs when compiled in Windows environment with cygwin as a backend.
>> However, on a Debian box following errors are printed by the compiler:
>>
>> =============================================================================
>>
>> **** Build of configuration Debug for project Inheritance ****
>>
>> make -k all
>> Building puma.config
>> "/opt/eclipse-3.2.2/plugins/org.aspectc.compiler.linux_0.9.93/AC/ag++"
>> --gen_config -o "puma.config"
>>
>> Building file: ../main.cpp
>> Invoking: GCC C++ Compiler
>> "/opt/eclipse-3.2.2/plugins/org.aspectc.compiler.linux_0.9.93/AC/ag++"
>> -r repo.acp -p .. -I.. --c_compiler g++ -O0 -g3 -Wall
>> -fmessage-length=0 -o"main.o" -c "../main.cpp" --Xweaver --keywords && \
>> echo -n main.d ./ > main.d && \
>> g++ -MM -MG -P -w -include../Aspectc.ah -O0 -g3 -Wall -c
>> -fmessage-length=0 "../main.cpp" >> main.d
>> main.acc: In member function ‘void TJP__ZN4mainEv_1::proceed()’:
>> main.acc:79: error: ‘invoke_Inherited_Inherited_a0_around’ is not a
>> member of ‘AC’
>> main.acc:79: error: expected primary-expression before ‘>’ token
>> error: Execution failed: "g++" -I".." -O0 -g3 -Wall -fmessage-length=0
>> -c -xc++ "main.acc" -xnone -I"../" -o "main.o"
>> make: *** [main.o] Error 1
>> make: Target `all' not remade because of errors.
>> Build complete for project Inheritance
>> =============================================================================
>>
>>
>> On both machines Eclipse 3.2.2 was used with ACDT 3.1.0. The g++
>> version on the Debian box is '4.1.2 20061115 (prerelease) (Debian
>> 4.1.1-21)' and the g++ on cygwin is '3.4.4 (cygming special, gdc 0.12,
>> using dmd 0.125)'. However, I don't thing that the backend compiler
>> matters here. Instead, ac++ seems to generate different code on these
>> machines. Which one is correct, that I do not know.
>>
>> Panu.
>>
>>
>> Panu Bloigu wrote:
>>> Hello.
>>>
>>> Until recently I've been under the impression that only abstract
>>> aspects can be inherited from. Now I'm not so sure anymore. I'll
>>> present some code that I find rather confusing as it seems that
>>> concrete aspects indeed *can* be inherited from.
>>>
>>> =============================================================================
>>>
>>> #include <iostream>
>>> aspect Base
>>> {
>>> pointcut pc() = "int main()";
>>> advice execution(pc()) : around()
>>> {
>>> std::cout<<"Before from base!\n";
>>> tjp->proceed();
>>> }
>>> };
>>>
>>> class Class : public Base
>>> {
>>> public:
>>> Class(){}
>>> virtual ~Class(){} };
>>>
>>>
>>> aspect Inherited : public Class
>>> {
>>>
>>> advice execution(pc()) : around()
>>> {
>>> std::cout<<"Before from Inherited!\n";
>>> tjp->proceed();
>>> } };
>>> =============================================================================
>>>
>>>
>>> This compiles fine and prints out:
>>>
>>> Before from base!
>>> Before from Inherited!
>>>
>>> Would someone care to comment what's going on here? To me this seems
>>> like non-abstract aspects can be inherited from if a regular class is
>>> as a mediator. Is this an intentional feature or is it something
>>> else? I'm confused.
>>>
>>> Thanks,
>>>
>>> Panu.
>>>
>>> _______________________________________________
>>> aspectc-user mailing list
>>> aspectc-user at aspectc.org
>>> http://www.aspectc.org/mailman/listinfo/aspectc-user
>>>
>>
>>
>> _______________________________________________
>> aspectc-user mailing list
>> aspectc-user at aspectc.org
>> http://www.aspectc.org/mailman/listinfo/aspectc-user
>>
> 
> 
> _______________________________________________
> aspectc-user mailing list
> aspectc-user at aspectc.org
> http://www.aspectc.org/mailman/listinfo/aspectc-user




More information about the aspectc-user mailing list