Compile time container, run-time execution.

Discussion in 'C++' started by shar3ub@googlemail.com, Feb 4, 2009.

  1. Guest

    Hi,

    I was wondering if anyone could give me some directions.

    I want to be able to build a compile time container of some all
    objects of type 'X' that exist in the code, and then at run time,
    iterate through the container and invoke a specific function on all
    items in this container. Could template-metaprogramming help me here?
    Is there something easier as I really don't have the time to spend on
    learning all about template metaprogramming.

    It sounds pretty impossible for me to do, but if anyone has any
    suggestions, I would highly appreciate them.
    , Feb 4, 2009
    #1
    1. Advertising

  2. writes:
    > I was wondering if anyone could give me some directions.
    >
    > I want to be able to build a compile time container of some all
    > objects of type 'X' that exist in the code, and then at run time,
    > iterate through the container and invoke a specific function on all
    > items in this container. Could template-metaprogramming help me here?
    > Is there something easier as I really don't have the time to spend on
    > learning all about template metaprogramming.
    >
    > It sounds pretty impossible for me to do, but if anyone has any
    > suggestions, I would highly appreciate them.


    There is no communication between phases, but thru the .o/executable.
    So it is indeed quite impossible.

    But you can set up things to build this container at runtime: the
    constructor of these some objets could add the created object to the
    container. Once they're all created, you can use the container to
    find them out.

    --
    __Pascal Bourguignon__
    Pascal J. Bourguignon, Feb 4, 2009
    #2
    1. Advertising

  3. Guest


    > After re-reading the original post here, I now see a different
    > requirement.  Yes, if "all objects X somewhere in the code" need to be
    > placed in some kind of container to later be used somehow, then it's the
    > function of each object X to "register" itself with the container (and
    > take itself out during destruction).  Without changing the class X to
    > allow for this functionality to exist, there is no way.
    >
    > Please disregard my other reply.


    Thanks for the replies guys. No, I am not looking for someone to do it
    for me. I just wanted to know if it is worth the time looking into
    'meta-programming'. I thought about registering them with a container
    and then calling them later, but the problem is, all code paths where
    these objects are created will have to be executed. And that is what I
    am trying to avoid.

    There are virtually hundreds of objects, some need quite an elaborate
    testing scneario from our QA engineers to execute, and all I am trying
    to do is somehow round them up in a container and invoke them later
    all at once.
    , Feb 4, 2009
    #3
  4. wrote:
    > Hi,
    >
    > I was wondering if anyone could give me some directions.
    >
    > I want to be able to build a compile time container of some all
    > objects of type 'X' that exist in the code, and then at run time,
    > iterate through the container and invoke a specific function on all
    > items in this container. Could template-metaprogramming help me here?


    A compile time container for objects that may exists in the future, it
    is not possible.

    > Is there something easier as I really don't have the time to spend on
    > learning all about template metaprogramming.
    >
    > It sounds pretty impossible for me to do, but if anyone has any
    > suggestions, I would highly appreciate them.



    If I understand correctly, you would like all object of a given type to
    register themselves in a container. This is possible with CRTP.

    template<class Derived>
    struct auto_register
    {
    //singleton that hold existing Derived
    static list<Derived*>& container()
    {static list<Derived*> obj_list;return obj_list;}

    auto_register()
    {
    container().push_back(static_cast<Derived*>(this));
    }
    ~auto_register()
    {
    container().erase(static_cast<Derived*>(this));
    }
    };

    And then:

    class Foo:auto_register<Foo>
    {

    };

    //each instance of Foo will be registered in auto_register<Foo>::container()

    Making it thread safe is left to the reader.

    --
    Michael
    Michael DOUBEZ, Feb 4, 2009
    #4
  5. writes:

    >> After re-reading the original post here, I now see a different
    >> requirement.  Yes, if "all objects X somewhere in the code" need to be
    >> placed in some kind of container to later be used somehow, then it's the
    >> function of each object X to "register" itself with the container (and
    >> take itself out during destruction).  Without changing the class X to
    >> allow for this functionality to exist, there is no way.
    >>
    >> Please disregard my other reply.

    >
    > Thanks for the replies guys. No, I am not looking for someone to do it
    > for me. I just wanted to know if it is worth the time looking into
    > 'meta-programming'. I thought about registering them with a container
    > and then calling them later, but the problem is, all code paths where
    > these objects are created will have to be executed. And that is what I
    > am trying to avoid.
    >
    > There are virtually hundreds of objects, some need quite an elaborate
    > testing scneario from our QA engineers to execute, and all I am trying
    > to do is somehow round them up in a container and invoke them later
    > all at once.


    You should try to think more about it.

    How can you create the objects that are at the end of a given code
    path, while avoiding executing this code path? How would you create
    this objects if you don't have the parameters computed by this avoided
    code path?


    --
    __Pascal Bourguignon__
    Pascal J. Bourguignon, Feb 4, 2009
    #5
  6. Guest


    > you considering for those? It's like asking dead people to dance you
    > the jig or asking unborn children to smile. Not gonna happen, right?


    > you considering for those?  It's like asking dead people to dance you
    > the jig or asking unborn children to smile.  Not gonna happen, right?


    That is what I thought all along. I just wanted to confirm that with
    the experts. Thanks guys for your responses and help.

    If I knew the input to creating each object, I guess it wouldn't be
    too outrageous to parse the files in question, using boost::regex or
    something similar, and reconstruct the code itself, adding the objects
    to a container and then invoking a certain method on them.
    , Feb 4, 2009
    #6
  7. > template<class Derived>
    > struct auto_register
    > {
    >     //singleton that hold existing Derived
    >     static list<Derived*>& container()
    >     {static list<Derived*> obj_list;return obj_list;}
    >
    >    auto_register()
    >    {
    >         container().push_back(static_cast<Derived*>(this));
    >    }
    >    ~auto_register()
    >    {
    >         container().erase(static_cast<Derived*>(this));
    >    }
    >
    > };
    >
    > And then:
    >
    > class Foo:auto_register<Foo>
    > {
    >
    > };
    >



    I think that will work. The other thing OP will have to implement is
    a destructo that will remove/unregister objects.
    puzzlecracker, Feb 4, 2009
    #7
  8. On Feb 4, 1:12 pm, Victor Bazarov <> wrote:
    > puzzlecracker wrote:
    > >> template<class Derived>
    > >> struct auto_register
    > >> {
    > >>     //singleton that hold existing Derived
    > >>     static list<Derived*>& container()
    > >>     {static list<Derived*> obj_list;return obj_list;}

    >
    > >>    auto_register()
    > >>    {
    > >>         container().push_back(static_cast<Derived*>(this));
    > >>    }
    > >>    ~auto_register()
    > >>    {
    > >>         container().erase(static_cast<Derived*>(this));
    > >>    }

    >
    > >> };

    >
    > >> And then:

    >
    > >> class Foo:auto_register<Foo>
    > >> {

    >
    > >> };

    >
    > > I think that will work.  The other thing OP will have to implement is
    > > a destructo that will remove/unregister objects.

    >
    > You mean like the one in 'auto_register' (called ~auto_register)?
    >
    > V
    > --
    > Please remove capital 'A's when replying by e-mail
    > I do not respond to top-posted replies, please don't ask


    yeah just like that... but my question is whether the solution is
    workable as I see it.
    puzzlecracker, Feb 4, 2009
    #8
  9. On Feb 4, 2:25 pm, Victor Bazarov <> wrote:
    > puzzlecracker wrote:
    > > On Feb 4, 1:12 pm, Victor Bazarov <> wrote:
    > >> puzzlecracker wrote:
    > >>>> template<class Derived>
    > >>>> struct auto_register
    > >>>> {
    > >>>>     //singleton that hold existing Derived
    > >>>>     static list<Derived*>& container()
    > >>>>     {static list<Derived*> obj_list;return obj_list;}
    > >>>>    auto_register()
    > >>>>    {
    > >>>>         container().push_back(static_cast<Derived*>(this));
    > >>>>    }
    > >>>>    ~auto_register()
    > >>>>    {
    > >>>>         container().erase(static_cast<Derived*>(this));
    > >>>>    }
    > >>>> };
    > >>>> And then:
    > >>>> class Foo:auto_register<Foo>
    > >>>> {
    > >>>> };
    > >>> I think that will work.  The other thing OP will have to implement is
    > >>> a destructo that will remove/unregister objects.
    > >> You mean like the one in 'auto_register' (called ~auto_register)?

    >
    > >> V
    > >> --
    > >> Please remove capital 'A's when replying by e-mail
    > >> I do not respond to top-posted replies, please don't ask

    >
    > > yeah just like that... but my question is whether the solution is
    > > workable as I see it.

    >
    > As you "see it"?  How do *you* see it?
    >
    > V
    > --
    > Please remove capital 'A's when replying by e-mail
    > I do not respond to top-posted replies, please don't ask


    stop being a dick!
    puzzlecracker, Feb 4, 2009
    #9
  10. wrote:
    >> you considering for those? It's like asking dead people to dance you
    >> the jig or asking unborn children to smile. Not gonna happen, right?

    >
    >> you considering for those? It's like asking dead people to dance you
    >> the jig or asking unborn children to smile. Not gonna happen, right?

    >
    > That is what I thought all along. I just wanted to confirm that with
    > the experts. Thanks guys for your responses and help.
    >
    > If I knew the input to creating each object, I guess it wouldn't be
    > too outrageous to parse the files in question, using boost::regex or
    > something similar, and reconstruct the code itself, adding the objects
    > to a container and then invoking a certain method on them.


    If you can have the list of the objects in external units, you can
    indeed build a container of const pointer to those objects:

    //node in list
    template <Object* OBJ,class NEXT>
    class object_list
    {
    typedef NEXT next;
    };
    //end of list
    class object_end{};

    //objects with external linkage
    extern Object obj1;
    extern Object obj2;
    extern Object obj3;

    typedef object_list<&obj1,
    object_list<&obj2,
    object_list<&obj3,
    object_end
    >
    >
    >

    list_of_objects;

    I have not tried it but in theory, it works. It should be possible to
    have a better readability with boost or some macros.

    To iterate on the elements, you can use the usual typelist visitation.

    --
    Michael
    Michael DOUBEZ, Feb 5, 2009
    #10
    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. newbiecpp

    run-time vs compile-time

    newbiecpp, Sep 8, 2004, in forum: C++
    Replies:
    17
    Views:
    6,611
    Chris \( Val \)
    Sep 11, 2004
  2. Daniel T.
    Replies:
    2
    Views:
    322
    Daniel T.
    Oct 19, 2004
  3. Markus Dehmann

    compile time vs. run time?

    Markus Dehmann, Jan 22, 2005, in forum: C++
    Replies:
    11
    Views:
    611
    Joseph Turian
    Jan 24, 2005
  4. Nagaraj
    Replies:
    1
    Views:
    842
    Lionel B
    Mar 1, 2007
  5. Carter
    Replies:
    2
    Views:
    490
    Carter
    Mar 4, 2009
Loading...

Share This Page