Aspect Oriented Programming techniques

Discussion in 'C++' started by christopher diggins, Feb 9, 2004.

  1. I have written an article on how to do Aspect Oriented Programming in
    vanilla C++ (i.e. without language extensions or other tools such as
    AspectC++). The article is available at
    http://www.heron-language.com/aspect-cpp.html. I would appreciate some
    feedback on the article, and also I would like to know whether I am
    repeating some prior work.

    Thanks in advance!

    --
    Christopher Diggins
    yet another language designer
    http://www.heron-language.com


    [ See http://www.gotw.ca/resources/clcm.htm for info about ]
    [ comp.lang.c++.moderated. First time posters: Do this! ]
     
    christopher diggins, Feb 9, 2004
    #1
    1. Advertising

  2. christopher diggins

    Jack Klein Guest

    On 8 Feb 2004 19:48:44 -0500, "christopher diggins"
    <> wrote in comp.lang.c++:

    > I have written an article on how to do Aspect Oriented Programming in
    > vanilla C++ (i.e. without language extensions or other tools such as
    > AspectC++). The article is available at
    > http://www.heron-language.com/aspect-cpp.html. I would appreciate some
    > feedback on the article, and also I would like to know whether I am
    > repeating some prior work.
    >
    > Thanks in advance!


    I can't speak to the quality of the article itself, nor whether it
    repeats prior work, as I haven't researched Aspect Oriented
    Programming before, but I have an issue with the code sample.

    The sample program on the page is quite useless for most of the C++
    compilers in existence.

    > // This is a small application to illustrate aspect oriented programming techniques
    > // using only C++ (i.e. no language extensions or special pre-processors


    Ok, but how does that rationalize with:

    > #include "stdafx.h"


    .....and:

    > int _tmain(int argc, _TCHAR* argv[])


    .....neither of the lines above is standard C++, and neither will
    compile on most compilers out there. Or does "vanilla C++" mean
    something else?

    If you want to make the point that AOP is for standard C++, and is not
    just some new Microsoft/Windows specific extension, I would suggest
    you produce an example that actually is "vanilla C++" and not just
    Visual C++ specific.

    --
    Jack Klein
    Home: http://JK-Technology.Com
    FAQs for
    comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
    comp.lang.c++ http://www.parashift.com/c -faq-lite/
    alt.comp.lang.learn.c-c++
    http://www.contrib.andrew.cmu.edu/~ajo/docs/FAQ-acllc.html

    [ See http://www.gotw.ca/resources/clcm.htm for info about ]
    [ comp.lang.c++.moderated. First time posters: Do this! ]
     
    Jack Klein, Feb 9, 2004
    #2
    1. Advertising

  3. christopher diggins

    Phlip Guest

    christopher diggins wrote:

    > I have written an article on how to do Aspect Oriented Programming in
    > vanilla C++ (i.e. without language extensions or other tools such as
    > AspectC++). The article is available at
    > http://www.heron-language.com/aspect-cpp.html. I would appreciate some
    > feedback on the article, and also I would like to know whether I am
    > repeating some prior work.


    Before I read, I'l ask a question that commits me to work hard when reading:

    If we can implement Aspectism in vanilla C++, doesn't that suggest that
    Aspectism is a Pattern, not a Paradigm or an Orientation?

    --
    Phlip
    http://www.xpsd.org/cgi-bin/wiki?TestFirstUserInterfaces


    [ See http://www.gotw.ca/resources/clcm.htm for info about ]
    [ comp.lang.c++.moderated. First time posters: Do this! ]
     
    Phlip, Feb 9, 2004
    #3
  4. Hi,

    christopher diggins wrote:

    > I have written an article on how to do Aspect Oriented Programming in
    > vanilla C++ (i.e. without language extensions or other tools such as
    > AspectC++). The article is available at
    > http://www.heron-language.com/aspect-cpp.html. I would appreciate some
    > feedback on the article


    You state in this article that the technique uses only Standard C++.
    To fully support this claim, it would be good to resign from #include
    "stdafx.h", TCHAR and other Microsoft-related stuff. ;)

    Anyway - the article got me thinking a bit and ask myself the following
    question:

    If I call this technique a "compile-time Decorator pattern", would it be
    really wrong?
    If not (ie. if there is some merit in stating that this is *just* a
    Decorator pattern implemented staticly with the help of preprocessor),
    then: what is reason to name it Aspect-Oriented Programming?

    Note also that your technique uses more "wrapping" than "interleaving"
    (that's why I tend to call it Decorator, not AOP) when composing
    complete components.

    I may be wrong in this Decorator vs. AOP comparison.

    I think that AOP calls for some new approach to development, including
    completely new language features, or maybe a separate language in
    itself. Using macros to compose wrapped function calls is probably good
    for adding instrumentation to code (logging, etc.), but as for "true"
    AOP it is still insufficient.

    These are just my thoughts and I will be more than happy to learn
    others' opinions.

    Thank you for sharing this text with the community,

    --
    Maciej Sobczak : http://www.msobczak.com/
    Programming : http://www.msobczak.com/prog/


    [ See http://www.gotw.ca/resources/clcm.htm for info about ]
    [ comp.lang.c++.moderated. First time posters: Do this! ]
     
    Maciej Sobczak, Feb 10, 2004
    #4
  5. "Maciej Sobczak" <> wrote in message
    news:c07qst$kg2$...
    > Hi,
    >
    > christopher diggins wrote:
    >
    > > I have written an article on how to do Aspect Oriented Programming in
    > > vanilla C++ (i.e. without language extensions or other tools such as
    > > AspectC++). The article is available at
    > > http://www.heron-language.com/aspect-cpp.html. I would appreciate some
    > > feedback on the article

    >
    > You state in this article that the technique uses only Standard C++.
    > To fully support this claim, it would be good to resign from #include
    > "stdafx.h", TCHAR and other Microsoft-related stuff. ;)


    I apologize for having been so Microsoft-centric. There is now a new version
    that is more general.

    > Anyway - the article got me thinking a bit and ask myself the following
    > question:
    >
    > If I call this technique a "compile-time Decorator pattern", would it be
    > really wrong?


    I do not know what you mean by that. I am aware of a Decorator pattern but a
    compile-time Decorator pattern is a new one.

    > If not (ie. if there is some merit in stating that this is *just* a
    > Decorator pattern implemented staticly with the help of preprocessor),
    > then: what is reason to name it Aspect-Oriented Programming?


    Because it allows the separation and isolation of cross cutting concerns in
    a reusable manner.

    > Note also that your technique uses more "wrapping" than "interleaving"
    > (that's why I tend to call it Decorator, not AOP) when composing
    > complete components.


    AFAICT it interleaves with existing code just as well as AspectJ or
    AspectC++ does. Do you see examples which contradicts this?

    > I may be wrong in this Decorator vs. AOP comparison.


    There may be some truth to what you say, but the implementation does not
    discount the technique used. I could make a very similar argument about
    object oriented programming.

    > I think that AOP calls for some new approach to development, including
    > completely new language features, or maybe a separate language in
    > itself.


    What do you base that statement on?

    >Using macros to compose wrapped function calls is probably good
    > for adding instrumentation to code (logging, etc.), but as for "true"
    > AOP it is still insufficient.


    There are many examples of how the proposed crosscutting macro could be used
    : exception handling (not fully implemented as shown but trivial to add),
    call prevention, testing of class invariants, introduction of preconditions
    and postconditions, thread synchronization, real time constraints, resource
    allocation / deallocation, etc. See
    http://www.heron-language.com/aspect-programming.html for some more
    examples, Heron uses a similar technique to the one proposed for C++.

    I would like to see you back up the statement about insufficiency for AOP.

    > These are just my thoughts and I will be more than happy to learn
    > others' opinions.
    >
    > Thank you for sharing this text with the community,


    My pleasure.

    --
    Christopher Diggins
    yet another language designer
    http://www.heron-language.com


    [ See http://www.gotw.ca/resources/clcm.htm for info about ]
    [ comp.lang.c++.moderated. First time posters: Do this! ]
     
    christopher diggins, Feb 10, 2004
    #5
  6. "Phlip" <> wrote in message
    news:R4IVb.19973$...
    > christopher diggins wrote:
    >
    > > I have written an article on how to do Aspect Oriented Programming in
    > > vanilla C++ (i.e. without language extensions or other tools such as
    > > AspectC++). The article is available at
    > > http://www.heron-language.com/aspect-cpp.html. I would appreciate some
    > > feedback on the article, and also I would like to know whether I am
    > > repeating some prior work.

    >
    > Before I read, I'l ask a question that commits me to work hard when

    reading:
    >
    > If we can implement Aspectism in vanilla C++, doesn't that suggest that
    > Aspectism is a Pattern, not a Paradigm or an Orientation?


    IMHO no.

    --
    Christopher Diggins
    http://www.heron-language.com


    [ See http://www.gotw.ca/resources/clcm.htm for info about ]
    [ comp.lang.c++.moderated. First time posters: Do this! ]
     
    christopher diggins, Feb 10, 2004
    #6
  7. christopher diggins

    Dave Harris Guest

    (Phlip) wrote (abridged):
    > If we can implement Aspectism in vanilla C++, doesn't that suggest
    > that Aspectism is a Pattern, not a Paradigm or an Orientation?


    We can implement object orientation in plain C, by juggling pointers
    to functions by hand. Does that mean object orientation is a Pattern?

    -- Dave Harris, Nottingham, UK

    [ See http://www.gotw.ca/resources/clcm.htm for info about ]
    [ comp.lang.c++.moderated. First time posters: Do this! ]
     
    Dave Harris, Feb 10, 2004
    #7
  8. "Phlip" <> wrote in message news:<R4IVb.19973$>...
    [...]
    > Before I read, I'l ask a question that commits me to work hard when reading:
    >
    > If we can implement Aspectism in vanilla C++, doesn't that suggest that
    > Aspectism is a Pattern, not a Paradigm or an Orientation?


    Well, if you consider that it's orthogonal to Object Orientation... ;-)

    Cheers,
    Nicola Musatti

    P.S. Sorry, I couldn't resist :)

    [ See http://www.gotw.ca/resources/clcm.htm for info about ]
    [ comp.lang.c++.moderated. First time posters: Do this! ]
     
    Nicola Musatti, Feb 10, 2004
    #8
  9. christopher diggins

    Dave Boyle Guest

    Jack Klein <> wrote in message news:<>...

    <snip>

    > > #include "stdafx.h"

    >
    > ....and:
    >
    > > int _tmain(int argc, _TCHAR* argv[])

    >
    > ....neither of the lines above is standard C++, and neither will
    > compile on most compilers out there. Or does "vanilla C++" mean
    > something else?


    <snip>

    #include "stdafx.h" isn't standard C++? Why not?

    Cheers,

    Dave

    [ See http://www.gotw.ca/resources/clcm.htm for info about ]
    [ comp.lang.c++.moderated. First time posters: Do this! ]
     
    Dave Boyle, Feb 10, 2004
    #9
  10. christopher diggins

    John Kewley Guest

    > Before I read, I'l ask a question that commits me to work hard when
    reading:
    >
    > If we can implement Aspectism in vanilla C++, doesn't that suggest that
    > Aspectism is a Pattern, not a Paradigm or an Orientation?


    So if we can implement a functional program in vanilla C++, does that
    suggest FP is a Pattern or a paradigm?

    Why do you suggest that just because we can implement something in C++ that
    it must be a pattern rather than a paradigm?

    JK



    [ See http://www.gotw.ca/resources/clcm.htm for info about ]
    [ comp.lang.c++.moderated. First time posters: Do this! ]
     
    John Kewley, Feb 10, 2004
    #10
  11. christopher diggins

    Helium Guest

    > Before I read, I'l ask a question that commits me to work hard when reading:
    >
    > If we can implement Aspectism in vanilla C++, doesn't that suggest that
    > Aspectism is a Pattern, not a Paradigm or an Orientation?


    So object orientation isn't a paradigm, as we can do it in C++? What
    about the procedural "paradigm" (which isn't a paradigm as we can do
    itin C++). ...

    So there is only one paradigm, called C++?

    [ See http://www.gotw.ca/resources/clcm.htm for info about ]
    [ comp.lang.c++.moderated. First time posters: Do this! ]
     
    Helium, Feb 10, 2004
    #11
  12. christopher diggins

    Helium Guest

    Hm someonw mentioned that you used int _tmain ... (this strange MSVC7
    extension). Now you use void main, which is as bad. Could you please
    use int main, so it works on ISO-compatible compilers and not only on
    those which allow the void main extension?

    [ See http://www.gotw.ca/resources/clcm.htm for info about ]
    [ comp.lang.c++.moderated. First time posters: Do this! ]
     
    Helium, Feb 10, 2004
    #12
  13. "Dave Harris" <> wrote
    > We can implement object orientation in plain C, by juggling pointers
    > to functions by hand. Does that mean object orientation is a Pattern?


    Actually, it is. C programmers may not have called it that since neither "OOP"
    nor "patterns" had become a buzzword before C++, but when OOP techniques were
    used in C, it was basically just the application of an informal pattern (and
    they were used in C way before C++ existed). And a paradigm IS a pattern. Most
    people use the alternate definition: "a set of assumptions, concepts, values,
    and practices that constitutes a way of viewing reality for the community that
    shares them, especially in an intellectual discipline", but by that definition,
    a lot of things we view as patterns are also paradigms.

    Whether you see aspect-oriented programming as a pattern or as a paradigm
    (second definition), depends a lot on whether you're married to the ideal or
    just see the thing as yet another tool in your toolchest. Personally, I see it
    as just another tool, and not one that needs special language features, but hey!
    Every trend has its religious adherents ;-)

    Claudio Puviani



    [ See http://www.gotw.ca/resources/clcm.htm for info about ]
    [ comp.lang.c++.moderated. First time posters: Do this! ]
     
    Claudio Puviani, Feb 11, 2004
    #13
  14. christopher diggins

    Phlip Guest

    John Kewley wrote:

    > > Before I read, I'l ask a question that commits me to work hard when

    > reading:
    > >
    > > If we can implement Aspectism in vanilla C++, doesn't that suggest that
    > > Aspectism is a Pattern, not a Paradigm or an Orientation?

    >
    > So if we can implement a functional program in vanilla C++, does that
    > suggest FP is a Pattern or a paradigm?
    >
    > Why do you suggest that just because we can implement something in C++

    that
    > it must be a pattern rather than a paradigm?


    A poster to news:comp.object frequently promotes a paradigm called "table
    oriented programming". TOP might mean placing data in normalized tables and
    solving problem by traversing their links and executing code pointers in
    each table row. I don't see why this isn't just the "polymorphic array"
    pattern.

    Similarily, another poster gave the whimsical title "Pool oriented
    programming" to a model of a comic book store, where all sales items inherit
    a common Stock item, but each individual item has behaviors from "pools" of
    item types. So a Comic Book derivative item would have a GetPageCount method
    common to all objects in its pool, but a CD derivative would have a
    GetTotalPlayingTime() method.

    I suggested that given a Comic Book object, it can behave like a member of
    the pools "C", "Comic Books", "Books", "Periodicals", etc. But this does not
    mean the behavior must be >inside< the Comic Book object. That object could,
    for example, contain a pointer to an array of objects that obey the
    Flyweight Design Pattern. When asked to behave like a "Book" object, the
    Comic Book object would find the "Book" entry in this list, if any, and pass
    its state into that object's "doSomething()" method.

    If the root principle of OO is polymorphism, then do any programming
    orientations of "table", "pool", or "aspect" require a root principle that
    one cannot reconstruct using our built-in language support for polymorphism?

    --
    Phlip
    http://www.xpsd.org/cgi-bin/wiki?TestFirstUserInterfaces


    [ See http://www.gotw.ca/resources/clcm.htm for info about ]
    [ comp.lang.c++.moderated. First time posters: Do this! ]
     
    Phlip, Feb 11, 2004
    #14
  15. christopher diggins

    Phlip Guest

    christopher diggins wrote:

    > I have written an article on how to do Aspect Oriented Programming in
    > vanilla C++ (i.e. without language extensions or other tools such as
    > AspectC++). The article is available at
    > http://www.heron-language.com/aspect-cpp.html. I would appreciate some
    > feedback on the article, and also I would like to know whether I am
    > repeating some prior work.


    I looked at the source code, in terms of solving a problem found on
    news:comp.object , under the name "Pool oriented programming".

    The poster wanted to model a comic book store, where all sales items inherit
    a common Stock item, but each individual item has behaviors from "pools" of
    item types. So a Comic Book derivative item would have a GetPageCount method
    common to all objects in its pool, but a CD derivative would have a
    GetTotalPlayingTime() method.

    The OP uses "pool" to mean a venn diagram of abilities, with overlaps.

    Here's a basic object from your sample:

    class CPoint {
    public :
    CPoint() { SetXY(0, 0); };
    CPoint(const CPoint& pt) { SetXY(pt.GetX(), pt.GetY()); };
    CPoint(int x, int y) { SetXY(x, y); };
    virtual int GetX() const { return mX; };
    virtual int GetY() const { return mX; };
    virtual void SetX(int x) { mX = x; };
    virtual void SetY(int y) { mY = y; };
    virtual void SetXY(int x, int y) { SetX(x); SetY(y); };
    virtual void FuBar() { };
    private :
    int mX, mY;
    };

    I don't see how to solve either the pool oriented programmer's problem, or
    my potential solution, using this system. It appears I would need to add a
    method to a basic object for each of its aspects, whether an object
    containing only the intersection of all aspects can support that method or
    not.

    My thinking may lack some orthogonal dimension here.

    --
    Phlip
    http://www.xpsd.org/cgi-bin/wiki?TestFirstUserInterfaces


    [ See http://www.gotw.ca/resources/clcm.htm for info about ]
    [ comp.lang.c++.moderated. First time posters: Do this! ]
     
    Phlip, Feb 11, 2004
    #15
  16. Hi,

    christopher diggins wrote:

    > > If I call this technique a "compile-time Decorator pattern", would
    > > it be really wrong?

    >
    > I do not know what you mean by that. I am aware of a Decorator pattern
    > but a compile-time Decorator pattern is a new one.


    Well, I may be wrong with this comparison, but consider this:

    http://www.dofactory.com/patterns/PatternDecorator.aspx

    and in particular, the definition:

    "Attach additional responsibilities to an object dynamically."

    I understand that the merit of Decorator pattern is to provide non-invasive
    extension to some operation, where "atomicity" of the original operation is
    preserved. In other words, we "decorate" some operation with the means of
    providing some pre- and post-operations and not by introducing anything in
    the middle of the original operation, to which we may have no access. The
    dynamic part means that polymorphism is used as a composition tool, allowing
    us to change the decorations at runtime.
    I found your technique to be similar and at the same time different in that:
    - it composes operations with the means of providing pre- and
    post-operations (or in other words on-entry and on-exit blocks); the
    operations themselves are still black-box entities
    - it does it at compile-time, meaning that once the composition is specified
    and compiled, it cannot be later changed.

    This is why I called it a compile-time Decorator.

    > > If not (ie. if there is some merit in stating that this is *just* a
    > > Decorator pattern implemented staticly with the help of

    > preprocessor), > then: what is reason to name it Aspect-Oriented

    Programming?
    >
    > Because it allows the separation and isolation of cross cutting
    > concerns in a reusable manner.


    As do other techniques, where nobody bothered to put them into the now
    trendy AOP bandwagon.
    Consider the policy-based class design. I found it to be much more powerful
    and expressive, but never seen it directly called AOP.
    But see below.

    > > Note also that your technique uses more "wrapping" than "interleaving"
    > > (that's why I tend to call it Decorator, not AOP) when composing >

    > complete components.
    >
    > AFAICT it interleaves with existing code just as well as AspectJ or
    > AspectC++ does. Do you see examples which contradicts this?


    No, there is no need for contradiction.
    The wrapping means that the composition of different "aspects" looks like
    onion ("ogres are like onions" ;) ):

    logging(on-entry)
    synchro(on-entry)
    memory_mgmt(on-entry)
    ...
    operation
    ...
    memory_mgmt(on-exit)
    synchro(on-exit)
    loggin(on-exit)

    The "preventive" aspect still falls into this, as having only the on-entry
    part.

    This is wrapping. The interleaving, as I understand, it may look like this:

    logging(part1)
    synchro(part1)
    ...
    logging(part2)
    memory_mgmt(part1)
    synchro(part2)
    operation(part1)
    memory_mgmt(part2)
    operation(part1)
    synchro(part3)
    ...
    logging(part3)
    memory_mgmt(part3)
    loggin(part4)

    See? The composition of different aspects leads to some code transformations
    and building onion-like structures is only one, probably the simplest
    possible transformation. In general, the transformations required to compose
    different aspects can be arbitrary.

    It may be possible to decompose the code into pieces in a way that will lead
    to onion-like structures (where everything is based on on-entry and on-exit
    blocks), but such decomposition of the main program logic would be
    problematic in the sense that it would be needed *only* to bend to this
    particular composition technique and may spoil the initial design.

    Moreover, code can be transoformed even to the extent that cannot be
    expressed as moving around complete statements.

    Consider, for example, that your application prints some output and one of
    the *aspects* of your design is the case (lowercase/uppercase/mixed) of this
    output or whether the numbers are roman or arabic, or how strings should be
    compared, considering the character encoding and other localization-related
    stuff used.

    Another aspect may be the optimisation mode. The program can minimize DB
    accesses (with the use of local caching structures) or minimize the memory
    usage. This acpect may have influence on many points in the program,
    possibly scattered across the whole project. Moreover, this aspect may be
    bound at compile-time or at run-time and the binding time also influences
    the way it is implemented.

    Some aspects may not be even expressible in terms of classes or functions,
    for example the compile-time optimization. The program may be optimized for
    speed or for size and I may wish to bind this aspect differently for
    different parts of the project.

    All these exaples mean that wrapping calls with the means of on-entry and
    on-exit blocks is only a single tool, probably the simplest one. The problem
    is that other tools are not necessarily in the same box.

    > > I think that AOP calls for some new approach to development,

    > including > completely new language features, or maybe a separate
    > language in > itself.
    >
    > What do you base that statement on?

    [...]
    > I would like to see you back up the statement about insufficiency for

    AOP.

    I base it on the above examples.

    At the moment, I have to use different techniques for aspect specification
    and different techniques for composition. I can use compile-time wrapping,
    policy-based class design, design patterns, message filters and
    interceptors, compiler switches, makefiles, and everything else, but they
    are all very loosely coupled, if coupled at all. There is no clear relation
    between, for example, the makefile settings, the Strategy pattern in the
    middle of the project and the locale facet imbued in the single stream
    object, even if they all serve the same aspect.
    What I want is the possibility to specify and manage aspects in the
    consistent way, no matter what technique is later used to implement and
    compose aspects (or whether this is done automatically). Whether it is some
    meta-language, language extension or sophisticated GUI tool, it needs to be
    consistent.

    The loosely coupled bunch of techniques and approaches is only an indication
    that the community matures to further research, but there is still nothing
    that I would call a *paradigm*.

    > > These are just my thoughts and I will be more than happy to learn
    > > others' opinions.


    --
    Maciej Sobczak : http://www.msobczak.com/
    Programming : http://www.msobczak.com/prog/


    [ See http://www.gotw.ca/resources/clcm.htm for info about ]
    [ comp.lang.c++.moderated. First time posters: Do this! ]
     
    Maciej Sobczak, Feb 11, 2004
    #16
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Julia Donawald
    Replies:
    0
    Views:
    507
    Julia Donawald
    Dec 30, 2004
  2. Daniel Lohmann
    Replies:
    0
    Views:
    750
    Daniel Lohmann
    Feb 10, 2004
  3. John Gagon

    Aspect oriented programming.

    John Gagon, May 16, 2006, in forum: C++
    Replies:
    4
    Views:
    355
    Noah Roberts
    May 16, 2006
  4. Replies:
    1
    Views:
    332
    AMRowe
    Jan 17, 2008
  5. Bill Atkins

    Aspect-Oriented Programming

    Bill Atkins, Aug 6, 2004, in forum: Ruby
    Replies:
    3
    Views:
    183
    Martin DeMello
    Aug 6, 2004
Loading...

Share This Page