[aspectc-user] Compiler Error - Related Error being fixed in(Version 1.0pre1: 10/2005)?

Olaf Spinczyk Olaf.Spinczyk at informatik.uni-erlangen.de
Fri Oct 28 17:38:48 CEST 2005 

Hi Dimple,

it is correct that there is no puma.config in the binary package. This 
is generated by make with ag++ --gen_config. However, in your case your 
system seems to be unable to run the ag++ binary. I've just downloaded 
the linux packages and it works perfectly. Are you sure that you have 
downloaded the right binary package? As the ac++ and ag++ binaries are 
statically linked they should run almost everywhere. On which kind of 
system are you working? Can you run ag++ --help?

- Olaf

Dimple wrote:
> Hi Olaf,
> I was trying to build example makefile of 1.0pre1 version by running make
> command in my installation path. It is giving me following error
> "<my_installation_path> /ag++ --gen_config -o
> <my_installation_path>/ac-1.0pre1/puma.config
> <my_installation_path>/ac-1.0pre1/ag++:
> <my_installation_path>/ac-1.0pre1/ag++: cannot execute binary file
> make: *** [<my_installation_path>/ac-1.0pre1/puma.config] Error 126"
> 
> It seem there is no puma.config file in the directory. In your last release
> you had puma.config file in main directory of installation.
> Thanks,
> Dimple
> 
> -----Original Message-----
> From: aspectc-user-bounces at aspectc.org
> [mailto:aspectc-user-bounces at aspectc.org] On Behalf Of Olaf Spinczyk
> Sent: Friday, October 28, 2005 2:00 AM
> To: John C. Weicher
> Cc: aspectc-user at aspectc.org
> Subject: Re: [aspectc-user] Compiler Error - Related Error being fixed
> in(Version 1.0pre1: 10/2005)?
> 
> Hi John,
> 
> version 1.0pre1 contains a fix for your problem. I tested it with a 
> SystemC application that has had a similar problem.
> 
> Of course, I'm interested in your top secret project ;-). Please keep us 
> posted!
> 
> -Olaf
> 
> 
> John C. Weicher wrote:
>>Olaf-
>>  Ha ha ha, please don't think me ungrateful, but I'd rather not say.
>>There's some competition on the task, and I'd like to keep our doings to
>>ourselves until we're ready to release.  It's always nice to be the first,
>>you know?  As for AspectC++, it's been absolutely great.  Up until
> recently
>>our approach was direct modification of existing functions, hacking up the
>>original application's source files, etc.  Okay for experimentation, but
>>totally unacceptable in the end as a means of producing an external,
>>optional patch-like modification, you know?  Then we discovered aspects,
> and
>>it's been great.  So definitely thank you for all your work.  I'll keep
> you
>>posted if you're interested!
>>
>>-John
>> 
>>
>>>-----Original Message-----
>>>From: Olaf Spinczyk [mailto:Olaf.Spinczyk at informatik.uni-erlangen.de]
>>>Sent: Thursday, October 20, 2005 11:27 AM
>>>To: John C. Weicher
>>>Subject: Re: [aspectc-user] Compiler Error - Related Error being fixed in
>>>(Version 1.0pre1: 10/2005)?
>>>
>>>John,
>>>
>>>on which open source project are you working? How much trouble did you
>>>have with AspectC++ so far? ;-)
>>>
>>>Olaf
>>>
>>>
>>>Olaf Spinczyk wrote:
>>>>Hi,
>>>>
>>>>for SystemC there is no solution, yet. We hope simply that no user needs
>>>>execution advice for the sc_main function ;-), which is similar to
>>>>main() in normaly C++ code.
>>>>
>>>>The best solution would be a last minute fix that is integrated into
>>>>version 1.0pre1. I'll do what I can.
>>>>
>>>>Olaf
>>>>
>>>>John C. Weicher wrote:
>>>>>Olaf-
>>>>>  Dead on!  That is exactly the situation.  And I discovered that
>>>>>late last
>>>>>night.  If I manually go in and add the declaration before the
>>>>>definition,
>>>>>it compiles perfectly (the extern header file issue never occurred to
>>>me
>>>>>though).  Do you have any suggestions on a way to get around this
>>>without
>>>>>the manual intervention? Because everything being open source, it
>>>>>would be
>>>>>nice to not make potential users who wanted to rebuild the app I'm
>>>>>modifying
>>>>>on their own, have to go in and do the same.  Right now the beauty is
>>>>>that
>>>>>everything is done by a single additional script that I would
>>>distribute
>>>>>with my modification/patch.  They'd just have to drop in the
>>>>>distribution,
>>>>>the scripts calls the aspect compiler to make the changes, calls the
>>>apps
>>>>>original make routines they would have had to call anyway, and bingo,
>>>>>they've modified their app.  I'd love to be able to keep it that way.
>>>>>
>>>>>If this is not doable, I'll just have to come up with another
>>>>>strategy.  I'm
>>>>>sorry I've taken so much of your time on this issue already, as I know
>>>>>now
>>>>>it's kind of in my court.  But you mentioned another similar encounter,
>>>>>SystemC?  What was the solution in that case?
>>>>>
>>>>>I really appreciate the help already given.
>>>>>
>>>>>
>>>>>
>>>>>>-----Original Message-----
>>>>>>From: Olaf Spinczyk [mailto:Olaf.Spinczyk at informatik.uni-erlangen.de]
>>>>>>Sent: Thursday, October 20, 2005 11:00 AM
>>>>>>To: John C. Weicher
>>>>>>Cc: aspectc-user at aspectc.org
>>>>>>Subject: Re: [aspectc-user] Compiler Error - Related Error being
>>>>>>fixed in
>>>>>>(Version 1.0pre1: 10/2005)?
>>>>>>
>>>>>>Hi,
>>>>>>
>>>>>>I'm slowly beginning to understand (at least I hope so) ...
>>>>>>
>>>>>>* you are using ac++ in the WPT mode and not via ag++
>>>>>>* your command line options are "-p module/dev -d module"
>>>>>>* the "include" directory tree does not belong to the project
>>>>>> (from ac++'s point of view)
>>>>>>* the function for which you define execution advice is
>>>>>> *declared* somewhere in "include", but defined in your
>>>>>> part, i.e. module
>>>>>>
>>>>>>Is that right? It explains the behavior completely:
>>>>>>
>>>>>>* call advice works properly, as the location of the call is part
>>>>>> of the ac++ project
>>>>>>
>>>>>>* execution advice does not work completely, because there is a
>>>function
>>>>>> declaration that does not belong to the ac++ project
>>>>>>
>>>>>>We have a similar problem with the SystemC library. In this case the
>>>>>>function sc_main is declared in a library header file, but the
>>>>>>implementation has to be provided in the application code.
>>>>>>
>>>>>>o check if we are right, you can insert a declaration of the function
>>>in
>>>>>>front of the definition. Then the execution advice should work as
>>>>>>expected.
>>>>>>
>>>>>>Does that help?
>>>>>>
>>>>>>Olaf
>>>>>>
>>>>>>
>>>>>>John C. Weicher wrote:
>>>>>>>Olaf-
>>>>>>> As a matter of fact, yes, the prototype for the function that I am
>>>>>>>attempting to call around is included in a header file that is
>>>outside
>>>>>>of my
>>>>>>>project directory.  I am using aspects to increase the functionality
>>>of
>>>>>>one
>>>>>>>module in a much larger open source application.  So like many such
>>>>>>>applications, the source code that I am extending is in a separate
>>>part
>>>>>>of
>>>>>>>the directory tree than the application's main include directory,
>>>>>>containing
>>>>>>>the headers for those sources:
>>>>>>>
>>>>>>>AppRoot
>>>>>>>|
>>>>>>>-- include  <- prototype for function I'm wrapping in header file
>>>here
>>>>>>>|              (It's an existing application function that I'm
>>>>>>>wrapping,
>>>>>>>|               not one of my own that I can easily relocate)
>>>>>>>|
>>>>>>>-- module   <- where I am placing weaved code to be placed so it can
>>>>>>still
>>>>>>>  |          be found by application's existing make routines, etc.
>>>>>>>  |
>>>>>>>  -- dev  <- new directory I've created where I've copied and keep
>>>>>>>             original versions of source and aspects
>>>>>>>
>>>>>>>The problem is that this is a large application, to which I am
>>>>>>>trying to
>>>>>>>develop a useful extension to that I could offer to people.  I'm only
>>>>>>>mentioning all this because the point is I want to keep my
>>>>>>>modifications
>>>>>>>through aspects as modularized from the rest of code as possible (so
>>>it
>>>>>>can
>>>>>>>be easily applied by interested parties).  I want to avoid having to
>>>>>>make
>>>>>>>changes to files outside of that one 'module' directory (and more
>>>>>>>specifically the 'dev') directory.  If possible, I want to avoid
>>>having
>>>>>>to
>>>>>>>make changes to outside files, for example those in the apps main
>>>>>>include
>>>>>>>directory.  For this same reason, I don't want to rename any function
>>>>>>names
>>>>>>>as the function I am wrapping is actually called from a whole
>>>different
>>>>>>>module, which means I'd have to edit IT'S code as well, etc.
>>>>>>>
>>>>>>>I assume this is causing my problem, because there is then an
>>>existing
>>>>>>>prototype for the function that I am wrapping, which is a point you
>>>>>>asked
>>>>>>>about at the end of your last post.
>>>>>>>
>>>>>>>Is it possible to force ac++ to add any necessary new prototypes
>>>right
>>>>>>into
>>>>>>>the file that contains the source for functions it is
>>>>>>>weaving/modifying?
>>>>>>>
>>>>>>>Thanks again for your help.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>-----Original Message-----
>>>>>>>>From: Olaf Spinczyk [mailto:Olaf.Spinczyk at informatik.uni-
>>>erlangen.de]
>>>>>>>>Sent: Thursday, October 20, 2005 3:16 AM
>>>>>>>>To: John C. Weicher
>>>>>>>>Cc: aspectc-user at aspectc.org
>>>>>>>>Subject: Re: [aspectc-user] Compiler Error - Related Error being
>>>fixed
>>>>>>in
>>>>>>>>(Version 1.0pre1: 10/2005)?
>>>>>>>>
>>>>>>>>Hi,
>>>>>>>>
>>>>>>>>there should be no problem, even if the called function (F1 in your
>>>>>>>>example) is part of a separate library. The call advice only
>>>>>>>>affects the
>>>>>>>>function that calls (F2). You can test it with this example:
>>>>>>>>
>>>>>>>>void f2 () {
>>>>>>>>puts ("hello");
>>>>>>>>}
>>>>>>>>
>>>>>>>>int main () {
>>>>>>>>f2 ();
>>>>>>>>}
>>>>>>>>
>>>>>>>>aspect Foo {
>>>>>>>>advice execution("% f2(...)") : before() {
>>>>>>>>  printf ("before\n");
>>>>>>>>}
>>>>>>>>advice call("% puts(...)") && within("% f2(...)") : around() {
>>>>>>>>  tjp->proceed ();
>>>>>>>>  printf ("after\n");
>>>>>>>>}
>>>>>>>>};
>>>>>>>>
>>>>>>>>The libc function puts is definitely part of a separate library.
>>>>>>>>
>>>>>>>>AspectC++ does not generate the function prototype that is missing
>>>in
>>>>>>>>your case, if
>>>>>>>>
>>>>>>>>(A) somewhere is a prototype declaration of the wrapped function
>>>(f2).
>>>>>>>>  (in this case the wrapper function prototype will be generated in
>>>>>>>>  front of this declaration and doesn't have to be generated in
>>>front
>>>>>>>>  of the definition)
>>>>>>>>
>>>>>>>>(B) the wrapped function is a member function of a class
>>>>>>>>  (in this case the function is either defined in a class body and,
>>>>>>>>  thus, declarations are not necessary, or the function is defined
>>>>>>>>  outside the class body. In this case there will be a declaration
>>>>>>>>  within the class body and the declaration of the wrapper function
>>>>>>>>  will be generated there)
>>>>>>>>
>>>>>>>>Is it possible that there is a declaration of the function f2 (the
>>>one
>>>>>>>>for which you defined execution advice) in some header file that is
>>>>>>>>*not* part of your project (-p option!)? Maybe it is the prototype
>>>>>>>>of a
>>>>>>>>different function that unintentionally has the same name. You
>>>>>>>>could try
>>>>>>>>to rename your function to rule out this possibility.
>>>>>>>>
>>>>>>>>- Olaf
>>>>>>>>
>>>>>>>>
>>>>>>>>John C. Weicher wrote:
>>>>>>>>>I apologize for not CC-ing my first response to the listserv as
>>>well,
>>>>>>so
>>>>>>>>>thank you for doing so with your last reply, so that message can at
>>>>>>>>least
>>>>>>>>>now be included.
>>>>>>>>>
>>>>>>>>>With that said, unfortunately, I am not sure how to give you a
>>>>>>>>>minimal
>>>>>>>>step
>>>>>>>>>by step, as when I do testing similar to yours, it works for me
>>>too!
>>>>>>>>But in
>>>>>>>>>doing so, I have found what I think is the source of the problem.
>>>>>>There
>>>>>>>>is
>>>>>>>>>in fact a prototype that is being omitted from the weaved code.
>>>>>>>>>
>>>>>>>>>Using the following example, all but identical to yours:
>>>>>>>>>
>>>>>>>>>void F1(){
>>>>>>>>>}
>>>>>>>>>
>>>>>>>>>void F2(){
>>>>>>>>>F1();
>>>>>>>>>}
>>>>>>>>>
>>>>>>>>>int main(int argc, char **argv){
>>>>>>>>>F2();
>>>>>>>>>return 0;
>>>>>>>>>}
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>aspect intercept{
>>>>>>>>>
>>>>>>>>>advice call("% F1(...)") && within("% F2(...)") : around() {
>>>>>>>>> printf("About to enter F1()\n");
>>>>>>>>> tjp->proceed();
>>>>>>>>>}
>>>>>>>>>
>>>>>>>>>advice execution("% F2(...)") : before() {
>>>>>>>>> printf("About to enter F2\n");
>>>>>>>>>}
>>>>>>>>>};
>>>>>>>>>--
>>>>>>>>>
>>>>>>>>>Everything here works just fine.  But when I go back and look at my
>>>>>>>>actual
>>>>>>>>>code, I notice a difference between it and the code generated for
>>>the
>>>>>>>>above
>>>>>>>>>test.  In the above test, the modifications for the
>>>execution/before
>>>>>>>>advice
>>>>>>>>>are as follows:
>>>>>>>>>
>>>>>>>>><snip>
>>>>>>>>>#line 7 "./main.c"
>>>>>>>>>
>>>>>>>>>#line 1 ""
>>>>>>>>>
>>>>>>>>>inline void __exec_old_F2();
>>>>>>>>>
>>>>>>>>>#line 7 "./main.c"
>>>>>>>>>void F2()
>>>>>>>>>#line 1 ""
>>>>>>>>>{
>>>>>>>>>AC::invoke_intercept_intercept_a1_before ();
>>>>>>>>>__exec_old_F2();
>>>>>>>>>
>>>>>>>>>}
>>>>>>>>>inline void __exec_old_F2()
>>>>>>>>>#line 7 "./main.c"
>>>>>>>>>{
>>>>>>>>>__call__ZN2F2Ev_0_0 ();
>>>>>>>>>}
>>>>>>>>><snip>
>>>>>>>>>
>>>>>>>>>This makes perfect sense.  We have the prototype for the inline
>>>>>>>>>altered
>>>>>>>>>original function, the replacement of the original function which
>>>>>>>>>calls
>>>>>>>>the
>>>>>>>>>inline alternate, and then the definition of the inline alternate
>>>>>>(which
>>>>>>>>>itself has internal modifications due to the other call/around
>>>advice
>>>>>>>>for
>>>>>>>>>the F1).
>>>>>>>>>
>>>>>>>>>The kicker is that in my real code, the general layout is the
>>>>>>>>>same, but
>>>>>>>>NO
>>>>>>>>>prototype is ever inserted above the replacement of the original
>>>>>>>>function.
>>>>>>>>>There is just the replacement of the original function which calls
>>>>>>>>>the
>>>>>>>>>inline alternate, and then the definition of the inline alternate.
>>>>>>>>Without
>>>>>>>>>the prototype above all this, the undeclared error is going to
>>>occur.
>>>>>>>>>As I said, other than the above program you gave me, I don't know
>>>how
>>>>>>to
>>>>>>>>>give you another minimal step by step.  The layout of my real
>>>project
>>>>>>is
>>>>>>>>>identical.  Can you think of any other reason why a prototype
>>>>>>>>>would be
>>>>>>>>>omitted?
>>>>>>>>>
>>>>>>>>>Actually I just realized that I have made a mistake.  There is one
>>>>>>>>>difference.  The function with the call/around advice (the nested
>>>>>>>>function)
>>>>>>>>>is NOT in the same file as the function causing problems with the
>>>>>>>>missing
>>>>>>>>>prototype.  It's part of another library.  I apologize I missed
>>>this.
>>>>>>>>>However, being call/around, the compiler never needs access to it's
>>>>>>>>actual
>>>>>>>>>code, correct?, and in fact I wasn't having any problems with it's
>>>>>>>>>call/around advice anyway, until I added the execute/before advice
>>>to
>>>>>>>>the
>>>>>>>>>function that calls IT.
>>>>>>>>>
>>>>>>>>>Phew!  Sorry for the long post.  Maybe this will change the
>>>>>>>>>situation?
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>-----Original Message-----
>>>>>>>>>>From: John C. Weicher [mailto:jweicher at piocon.com]
>>>>>>>>>>Sent: Wednesday, October 19, 2005 9:13 AM
>>>>>>>>>>To: 'Olaf Spinczyk'
>>>>>>>>>>Subject: RE: [aspectc-user] Compiler Error - Related Error being
>>>>>>>>>>fixed
>>>>>>>>in
>>>>>>>>>>(Version 1.0pre1: 10/2005)?
>>>>>>>>>>
>>>>>>>>>>Thanks for your help so far.  There is really only one difference
>>>>>>>>between
>>>>>>>>>>my code and your test program.  It's not really a situation of
>>>>>>>>around/call
>>>>>>>>>>and before/execution of the same function.  Using your example,
>>>the
>>>>>>>>>>function having advice inserted before its execution is F2(), not
>>>>>>F1().
>>>>>>>>I
>>>>>>>>>>of course have no idea if this should make any difference?
>>>>>>>>>>
>>>>>>>>>>In other words, in your program you have a function F1 that is
>>>both
>>>>>>>>being
>>>>>>>>>>called around, as well as having code inserted before its
>>>execution
>>>>>>>>>>contents.
>>>>>>>>>>
>>>>>>>>>>In my code I have a function F1 that is being called around, and a
>>>>>>>>>>_different_ function (from which the first is called), that is
>>>>>>>>>>having
>>>>>>>>the
>>>>>>>>>>code inserted before it.
>>>>>>>>>>
>>>>>>>>>>I admit even to me this seems like a trivial difference, but you'd
>>>>>>know
>>>>>>>>>>far better.  Could there be a problem with applying before advice
>>>>>>>>>>to a
>>>>>>>>>>function and then applying around advice to another function call
>>>>>>within
>>>>>>>>>>it? Perhaps simply in how it decides in which order to append
>>>weaved
>>>>>>>>code
>>>>>>>>>>to the source file?  I am totally grasping at straws here.
>>>>>>>>>>Obviously
>>>>>>>>the
>>>>>>>>>>operations of the weaver are way over my head.  It's just that
>>>>>>>>>>the odd
>>>>>>>>>>thing is, if I go look at the source file, all the code for all
>>>>>>advices
>>>>>>>>is
>>>>>>>>>>properly generated.  It's just that the code for the alternate
>>>>>>>>>>call to
>>>>>>>>the
>>>>>>>>>>function to handle the before insertion is placed after it's
>>>>>>invocation,
>>>>>>>>>>giving the not defined error when parsed for compling.
>>>>>>>>>>Otherwise, all
>>>>>>>>the
>>>>>>>>>>code is generated perfectly!
>>>>>>>>>>
>>>>>>>>>>Other that this though, nothing else mentioned comes to mind.
>>>>>>Regarding
>>>>>>>>>>your other questions, no, all applicable functions are in the same
>>>>>>>>source
>>>>>>>>>>file, and no recursion is involved.
>>>>>>>>>>
>>>>>>>>>>Thanks for your help.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>-----Original Message-----
>>>>>>>>>>>From: Olaf Spinczyk
>>>>>>>>>>>[mailto:Olaf.Spinczyk at informatik.uni-erlangen.de]
>>>>>>>>>>>Sent: Wednesday, October 19, 2005 2:25 AM
>>>>>>>>>>>To: John C. Weicher
>>>>>>>>>>>Cc: aspectc-user at aspectc.org
>>>>>>>>>>>Subject: Re: [aspectc-user] Compiler Error - Related Error being
>>>>>>fixed
>>>>>>>>>>in
>>>>>>>>>>>(Version 1.0pre1: 10/2005)?
>>>>>>>>>>>
>>>>>>>>>>>Hi John,
>>>>>>>>>>>
>>>>>>>>>>>there is no general problem with around/call and before/execution
>>>>>>>>advice
>>>>>>>>>>>for the same function. I tried the following example without any
>>>>>>>>>>>problems (version 0.9.3):
>>>>>>>>>>>
>>>>>>>>>>>--
>>>>>>>>>>>void f1 () {
>>>>>>>>>>>}
>>>>>>>>>>>
>>>>>>>>>>>void f2 () {
>>>>>>>>>>>f1 ();
>>>>>>>>>>>}
>>>>>>>>>>>
>>>>>>>>>>>int main () {
>>>>>>>>>>>f2 ();
>>>>>>>>>>>}
>>>>>>>>>>>
>>>>>>>>>>>aspect Foo {
>>>>>>>>>>>advice call("% f1(...)") && within("% f2(...)") : around() {
>>>>>>>>>>> tjp->proceed ();
>>>>>>>>>>> printf ("after\n");
>>>>>>>>>>>}
>>>>>>>>>>>advice execution("% f1(...)") : before() {
>>>>>>>>>>> printf ("before\n");
>>>>>>>>>>>}
>>>>>>>>>>>};
>>>>>>>>>>>--
>>>>>>>>>>>
>>>>>>>>>>>What is the difference between your code and this test program?
>>>Are
>>>>>>any
>>>>>>>>>>>recursive functions involved? Is f2() declared in a separate
>>>header
>>>>>>>>file
>>>>>>>>>>>that does not belong to your project?
>>>>>>>>>>>
>>>>>>>>>>>The (HUGE) problem with version 0.9.3 is a different one. It is
>>>>>>related
>>>>>>>>>>>to introductions.
>>>>>>>>>>>
>>>>>>>>>>>Best regards,
>>>>>>>>>>>
>>>>>>>>>>>Olaf
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>John C. Weicher wrote:
>>>>>>>>>>>>I am running into an odd error during compilation that only
>>>>>>>>>>>>crops up
>>>>>>>>>>>>when I provide two separate advice calls which affect the same
>>>>>>>>>>function.
>>>>>>>>>>>>Simplified scenario exists where there is
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>someFunctionA(){
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>//blah blah
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>someFunctionB();
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>//blah blah
>>>>>>>>>>>>
>>>>>>>>>>>>}
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>I have already defined an aspect with advice as follows:
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>advice call("% %someFunctionB(...)") && within("%
>>>>>>>>>>%someFunctionA(...)")
>>>>>>>>>>>>: around() {  //blah blah }
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>Obviously I am trying to call around function B when called from
>>>>>>>>>>within
>>>>>>>>>>>>A (I do some other stuff, and then let it proceed).  This
>>>weaves,
>>>>>>>>>>>>parses, compiles and runs beautifully.  I've been using this in
>>>a
>>>>>>>>>>>>working application for some time now.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>A new situation has arisen for me now where in addition to the
>>>>>>>>>>>>above
>>>>>>>>>>>>(situation is the same, and the previous advice block is also
>>>>>>>>>>>>still
>>>>>>>>>>>>needed and in place), I ALSO want to define an additional advice
>>>>>>block
>>>>>>>>>>>>to perform some operations before the execution of function A,
>>>>>>>>>>>>done
>>>>>>as
>>>>>>>>>>>>follows:
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>advice execution("% %someFunctionA(...)") : before() {  // blah
>>>>>>>>>>>>blah
>>>>>>}
>>>>>>>>>>>>This is causing problems.  Weaving still occurs without error,
>>>but
>>>>>>>>>>when
>>>>>>>>>>>>I then try to compile weaved code, I receive the following error
>>>>>>>>>>>>(changed the function names to match my fake example above, so
>>>it
>>>>>>>>>>makes
>>>>>>>>>>>>sense):
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>: In function `int someFunctionA(args args args.)':
>>>>>>>>>>>>
>>>>>>>>>>>>:4: `__exec_old_someFunctionA' undeclared (first use this
>>>>>>>>>>>>function)
>>>>>>>>>>>>
>>>>>>>>>>>>:4: (Each undeclared identifier is reported only once for each
>>>>>>>>>>function
>>>>>>>>>>>it
>>>>>>>>>>>>appears in.)
>>>>>>>>>>>>
>>>>>>>>>>>>./thefile.c: In function `int __exec_old_someFunctionA(args arg
>>>>>>>>>>args)':
>>>>>>>>>>>>./thefile.c:280: `int __exec_old_someFunctionA(args args args)
>>>>>>>>>>>>
>>>>>>>>>>>>' used prior to declaration
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>And sure enough, when I go into the file the inline definition
>>>for
>>>>>>>>>>>>__exec_old_someFunctionA is coming after the modified call to
>>>it.
>>>>>>But
>>>>>>>>>>I
>>>>>>>>>>>>didn't think this mattered with inline functions.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>I apologize for the lengthy post, but I am definitely
>>>>>>>>>>>>confused.  If
>>>>>>I
>>>>>>>>>>>>take the new additional advice block back out, everything
>>>compiles
>>>>>>>>>>fine
>>>>>>>>>>>>again.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>I also noticed that although that it specifically mentions only
>>>>>>>>>>classes,
>>>>>>>>>>>>this sounds very similar to the issue that is supposed to be
>>>fixed
>>>>>>in
>>>>>>>>>>>>the new release mentioned on the Roadmap page: "fix for the HUGE
>>>>>>>>>>problem
>>>>>>>>>>>>of ac++ 0.9.3 that causes parse errors, when an aspect defines
>>>>>>>>>>>>code
>>>>>>>>>>>>advice for a class into which it also introduces new
>>>>>>>>>>functions/members".
>>>>>>>>>>>>Is this the case, and if so is there a workaround in the
>>>meantime?
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>----------------------------------------------------------------
>>>----
>>>>>>--
>>>>>>>>>>--
>>>>>>>>>>>>_______________________________________________
>>>>>>>>>>>>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
>>>>>_______________________________________________
>>>>>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
> 
> _______________________________________________
> 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