Using same source for different apps

Discussion in 'C++' started by jeremy.todter@gmail.com, Nov 8, 2006.

  1. Guest

    I have a question...obviously

    I am developing an application, or two applications using c++ and
    openGL. They involve a basic structure where approximately 70 percent
    of the framework applies to both projects, and each different project
    has its own special funtionality. They are both very similar and exist
    together, where the irrelevent menu items for example are greyed in one
    and not the other. Each needs a different icon and title depending on
    the application.

    My problem is that there exists only one source. When I build the
    release versions, I would like to be able to make these subtle changes
    in both, whereby keeping the original source structure and not have to
    edit parts for one and then go back and change them for the other.

    I am sure, or hoping that there is some sort of build version system,
    similar to CVS or something that will allow me to do this. I have
    looked around but havent really found anything.

    If anyone knows of anything or has any ideas that will help me out, can
    you please let me know...

    Thanks for your help, appreciate it.

    J
    , Nov 8, 2006
    #1
    1. Advertising

  2. wrote:

    > I have a question...obviously
    >
    > I am developing an application, or two applications using c++ and
    > openGL. They involve a basic structure where approximately 70 percent
    > of the framework applies to both projects, and each different project
    > has its own special funtionality. They are both very similar and exist
    > together, where the irrelevent menu items for example are greyed in one
    > and not the other. Each needs a different icon and title depending on
    > the application.
    >
    > My problem is that there exists only one source. When I build the
    > release versions, I would like to be able to make these subtle changes
    > in both, whereby keeping the original source structure and not have to
    > edit parts for one and then go back and change them for the other.


    I rather do hope that you have created some inheritance hierarchy with a
    lot of base classes that can be used by both projects. Furthermore, each
    of these base classes should have its own header and implementation
    file, so that you can make changes in these base classes without
    changing any details that are specific to project-specific derived
    classes. If your code isn't organized this way, you'll have the most
    wonderful time re-organizing it. In the end your source tree should look
    like this:

    src
    |_ common
    | |_ BaseClass1
    | |_ BaseClass2
    | |...
    |_ Project1
    | |_ DerivedClass1_1 (with details that are specific to
    | | project 1)
    | |_ DerivedClass1_2
    | |...
    |_ Project2
    | |_ DerivedClass2_1
    | |...

    Regards,
    Stuart
    Stuart Redmann, Nov 8, 2006
    #2
    1. Advertising

  3. Puppet_Sock Guest

    wrote:
    [snips]
    > I am sure, or hoping that there is some sort of build version system,
    > similar to CVS or something that will allow me to do this. I have
    > looked around but havent really found anything.
    >
    > If anyone knows of anything or has any ideas that will help me out, can
    > you please let me know...


    Sure there are build utils. But they are off topic in this news group.
    You need to go to a platform specific news group for those. You
    could start with a news group that talks about development in
    your particular OS, or to do with your particular compiler. Google
    up the news group or groups that have relevant stuff.

    As far as organizing your code, there are plenty hints and tips
    available if you are interested. The most simple of notions is
    to use macro compile flags of some kind. When you compile
    for one project, you have some extra include file, or your build
    util sets flags for you, or some such. And this sets all the stuff
    so that the first project gets what it needs. Then for the other
    project you have a second include file, or a second make file,
    or whatever your build util needs.

    Another thing to look at is making a library for the common
    features. Again, the details of how to make a library are
    off topic here. For two projects, a library may, or may not,
    be appropriate. There are plenty books on writing libraries.
    The basic rule is: a feature probably belongs in the library if
    nearly every client of the library will use it, at least now
    and then. If only one client wants it, then it is unlikely to
    belong in the library.
    Socks
    Puppet_Sock, Nov 8, 2006
    #3
  4. noone Guest

    On Wed, 08 Nov 2006 07:03:58 -0800, jeremy.todter wrote:

    > I have a question...obviously
    >
    > I am developing an application, or two applications using c++ and openGL.
    > They involve a basic structure where approximately 70 percent of the
    > framework applies to both projects, and each different project has its own
    > special funtionality. They are both very similar and exist together,
    > where the irrelevent menu items for example are greyed in one and not the
    > other. Each needs a different icon and title depending on the application.
    >
    > My problem is that there exists only one source. When I build the release
    > versions, I would like to be able to make these subtle changes in both,
    > whereby keeping the original source structure and not have to edit parts
    > for one and then go back and change them for the other.


    I can't tell you how similar they need to be for this strategy to work in
    you apps, but you could consider conditional compilation. Maybe consider
    something like


    c++ -DAPP1 source.cc


    in the source.cc file

    #ifdef APP1
    cout << "app 1\n";
    #else
    cout << "other app\n";
    #endif

    When compiling with the APP1 symbol defined, the first clause will be
    compiled, otherwise the second will. This is the best way for me to
    include hardware level functions that work on one platform but are
    different on the other.

    But in keeping with the OO paradigm it is best to encapsulate the
    application specific stuff in different classes and then only use
    conditional compilation to instantiate the correct class. The optimizing
    compiler shouldn't then include machine code for other than its intended
    target.

    class x8086_port_access; // x86 port access class
    class arm_port_access; // arm port access class
    #ifdef ARM
    arm_port_access ports;
    #else
    x8086_port_access ports;
    #endif
    ports.set(ports::IRQ_CLEAR_REGISTER, ports::IRQ_ACK);

    Assuming that the API for the classes are the same then the program will
    only use the one for its target platform.

    The above is only a hypothetical example so we need not discuss the
    issues of class overhead when dealing with direct hardware access in
    latency sensitive applications.
    noone, Nov 9, 2006
    #4
    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. davout
    Replies:
    5
    Views:
    599
    Juha Laiho
    May 16, 2005
  2. Replies:
    5
    Views:
    799
  3. Christopher Brewster
    Replies:
    5
    Views:
    339
    John Machin
    Nov 14, 2008
  4. bluebaron
    Replies:
    3
    Views:
    736
    Jonathan N. Little
    Nov 4, 2009
  5. Guest
    Replies:
    2
    Views:
    177
    Foo Man Chew
    Dec 29, 2003
Loading...

Share This Page