Implementation, Disclose or not?

Discussion in 'C++' started by thomas, Aug 17, 2010.

  1. thomas

    thomas Guest

    Hi,

    I have a header file like this:
    -------------------MyStruct.h---------
    struct MyStruct{
    void method1();
    };
    ------------------MyStruct.cpp----------
    void MyStruct::method1(){}

    Now I will use MyStruct in several projects.
    Definitely I will include "MyStruct.h" in each project.
    But I don't know how to handle "MyStruct.cpp".

    I think there are several options:
    1. compile MyStruct.cpp in a library, link it when building other
    projects.
    But there is only one "cpp", it seems over-kill.
    2. compile MyStruct.cpp in one of the project, link the project when
    building other projects.
    But it seems ugly. There's no obvious dependence between the projects.
    3. put one copy of MyStruct.cpp in each project.
    It's obviously ugly as to maintenance difficulty.

    Now I want to hear your suggestions, thanks.
    thomas, Aug 17, 2010
    #1
    1. Advertising

  2. thomas

    DDD Guest

    thomas wrote:
    > Hi,
    >
    > I have a header file like this:
    > -------------------MyStruct.h---------
    > struct MyStruct{
    > void method1();
    > };
    > ------------------MyStruct.cpp----------
    > void MyStruct::method1(){}
    >
    > Now I will use MyStruct in several projects.
    > Definitely I will include "MyStruct.h" in each project.
    > But I don't know how to handle "MyStruct.cpp".
    >
    > I think there are several options:
    > 1. compile MyStruct.cpp in a library, link it when building other
    > projects.
    > But there is only one "cpp", it seems over-kill.
    > 2. compile MyStruct.cpp in one of the project, link the project when
    > building other projects.
    > But it seems ugly. There's no obvious dependence between the projects.
    > 3. put one copy of MyStruct.cpp in each project.
    > It's obviously ugly as to maintenance difficulty.
    >
    > Now I want to hear your suggestions, thanks.


    If you think the 1st option seems over-kill, why not putting the
    MyStruct.cpp in another more big library.
    DDD, Aug 17, 2010
    #2
    1. Advertising

  3. thomas

    Öö Tiib Guest

    On 17 aug, 14:51, thomas <> wrote:
    > Hi,
    >
    > I have a header file like this:
    > -------------------MyStruct.h---------
    > struct MyStruct{
    >     void method1();};
    >
    > ------------------MyStruct.cpp----------
    > void MyStruct::method1(){}
    >
    > Now I will use MyStruct in several projects.
    > Definitely I will include "MyStruct.h" in each project.
    > But I don't know how to handle "MyStruct.cpp".
    >
    > I think there are several options:
    > 1. compile MyStruct.cpp in a library, link it when building other
    > projects.
    > But there is only one "cpp", it seems over-kill.
    > 2. compile MyStruct.cpp in one of the project, link the project when
    > building other projects.
    > But it seems ugly. There's no obvious dependence between the projects.
    > 3. put one copy of MyStruct.cpp in each project.
    > It's obviously ugly as to maintenance difficulty.
    >
    > Now I want to hear your suggestions, thanks.


    Number of .h and .cpp files should not matter at all when considering
    if to make it library or not.

    For example SQLite. It is one of the most widely used SQL database
    engines and it is made available as single ANSI C source file. It is
    not developed as one source file but it is merged to one to speed up
    its compiling time.

    How to make modules/libraries/packages involves bit more than just
    throwing some cpp files together.
    Öö Tiib, Aug 17, 2010
    #3
  4. thomas

    Jorgen Grahn Guest

    On Tue, 2010-08-17, DDD wrote:
    >
    >
    > thomas wrote:
    >> Hi,
    >>
    >> I have a header file like this:
    >> -------------------MyStruct.h---------
    >> struct MyStruct{
    >> void method1();
    >> };
    >> ------------------MyStruct.cpp----------
    >> void MyStruct::method1(){}
    >>
    >> Now I will use MyStruct in several projects.
    >> Definitely I will include "MyStruct.h" in each project.


    Do you mean #include, or include as in copy, as in "point out", or what?
    I see no reason not to treat it just like MyStruct.cpp

    >> But I don't know how to handle "MyStruct.cpp".
    >>
    >> I think there are several options:
    >> 1. compile MyStruct.cpp in a library, link it when building other
    >> projects.
    >> But there is only one "cpp", it seems over-kill.
    >> 2. compile MyStruct.cpp in one of the project, link the project when
    >> building other projects.
    >> But it seems ugly. There's no obvious dependence between the projects.
    >> 3. put one copy of MyStruct.cpp in each project.
    >> It's obviously ugly as to maintenance difficulty.
    >>
    >> Now I want to hear your suggestions, thanks.

    >
    > If you think the 1st option seems over-kill, why not putting the
    > MyStruct.cpp in another more big library.


    Keeping an ever-growing "utilities" library isn't much fun either --
    I suspect it will become unwieldy and of varying quality.

    I'd go for (3). Make a copy in each project which uses it. With
    version control you can tell where the code originated, and notice if
    one of them got bug-fixes which others will want too. Or, you can
    tear it apart and rework it within project A if needed, without
    affecting project B.

    /Jorgen

    --
    // Jorgen Grahn <grahn@ Oo o. . .
    \X/ snipabacken.se> O o .
    Jorgen Grahn, Aug 17, 2010
    #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. Phil Sandler
    Replies:
    4
    Views:
    10,124
    Alex Richardson
    Jan 28, 2010
  2. Mike P
    Replies:
    0
    Views:
    2,289
    Mike P
    Mar 12, 2005
  3. Michael Tsang
    Replies:
    32
    Views:
    1,082
    Richard Bos
    Mar 1, 2010
  4. Michael Tsang
    Replies:
    54
    Views:
    1,165
    Phil Carmody
    Mar 30, 2010
  5. sanket
    Replies:
    7
    Views:
    981
    Tsung
    Nov 3, 2011
Loading...

Share This Page