work related dig regarding separation of definitions and implementations

Discussion in 'C++' started by noone, Jan 23, 2007.

  1. noone

    noone Guest

    Hi.

    I've got a fella working for me who is trying to convince me to change our
    coding standards to using separate .h and .cc files for definitions and
    implementations. I know this is a perfectly valid way of doing things but
    in my mind it is kind of quirky. Here's why.

    The first reason I'd resist deals with the simplicity of makefiles. When
    including most code from headers where classes are protected by #ifdef
    blocks the makefile doesn't have to have a separate build rule for each
    class.

    Next, TTBOMK you need to do your classes in header files if you are going
    to make them into generic templates...well, putting them into headers
    isn't strictly a requirement but the other restrictions for (templatizable
    code) would encourage only using headers.

    I understand that there a a couple of reasons why you might want separate
    definitions and implementation, such as when a class has a static data
    member, or if you intend to create a shared object library of class code,
    but it seems to me that putting the code into the header files is a bit
    more elegant and the other way would be more of a holdover from the old
    days before templates.

    I'm wondering what comments the upper echelon lurkers might have. Do they
    agree with my reasoning, or can they give me reasons why I should
    reevaluate my assertions.
    noone, Jan 23, 2007
    #1
    1. Advertising

  2. noone wrote:
    > I've got a fella working for me who is trying to convince me to
    > change our coding standards to using separate .h and .cc files for
    > definitions and implementations. I know this is a perfectly valid
    > way of doing things but in my mind it is kind of quirky. Here's why.
    >
    > The first reason I'd resist deals with the simplicity of makefiles.
    > When including most code from headers where classes are protected by
    > #ifdef blocks the makefile doesn't have to have a separate build rule
    > for each class.
    >
    > Next, TTBOMK you need to do your classes in header files if you are
    > going to make them into generic templates...well, putting them into
    > headers isn't strictly a requirement but the other restrictions for
    > (templatizable code) would encourage only using headers.
    >
    > I understand that there a a couple of reasons why you might want
    > separate definitions and implementation, such as when a class has a
    > static data member, or if you intend to create a shared object
    > library of class code, but it seems to me that putting the code into
    > the header files is a bit more elegant and the other way would be
    > more of a holdover from the old days before templates.
    >
    > I'm wondering what comments the upper echelon lurkers might have. Do
    > they agree with my reasoning, or can they give me reasons why I should
    > reevaluate my assertions.


    I know of no "upper echelon lurkers", so forgive my barging in, but
    I have only one issue to mention: speed of compilation. As soon as
    you cross a hundred file barrier (and have a team of more that three
    people), you'll probably want to separate your implementation in
    a different translation unit for each class so that it could be
    independently compiled and not cause recompilation of all other
    translation units that include it.

    C++ was designed with large scale systems in mind. That's not the
    only paradigm it supports, but it's the most important, if you ask me.
    If your system is small, no big deal. Keep your headers full of code
    and don't bother. We used to do that in Pascal, didn't we? Then
    along came units, and suddenly we could split the development into
    several relatively independent pieces... You can do it nowadays in
    C++ with many modern compilers that support precompiled headers, of
    course. But then again, once code changes you need to recompile
    most of them again... Kind of PITA.

    V
    --
    Please remove capital 'A's when replying by e-mail
    I do not respond to top-posted replies, please don't ask
    Victor Bazarov, Jan 23, 2007
    #2
    1. Advertising

  3. * noone:
    >
    > I've got a fella working for me who is trying to convince me to change our
    > coding standards to using separate .h and .cc files for definitions and
    > implementations. I know this is a perfectly valid way of doing things but
    > in my mind it is kind of quirky. Here's why.


    Rather, having all code in header files is the unusual way.


    > The first reason I'd resist deals with the simplicity of makefiles. When
    > including most code from headers where classes are protected by #ifdef
    > blocks the makefile doesn't have to have a separate build rule for each
    > class.


    Builds nowadays are mostly automated. Anyway, even with hand-crafted
    make files you can lay down some general rules.


    > Next, TTBOMK you need to do your classes in header files if you are going
    > to make them into generic templates...well, putting them into headers
    > isn't strictly a requirement but the other restrictions for (templatizable
    > code) would encourage only using headers.


    Even template code can benefit from a separation into header and
    implementation. For most template classes that means including the
    implementation file in the header file. The main advantage is that the
    header file can give a very concise overview and defines the logical
    interface, whereas with just one big file it's not that clear what's
    interface and what's implementation detail. A possible but very
    improbable advantage is that with compiler support for 'export' (only
    Comeau right now, as far as I know) this can also reduce build times.


    > I understand that there a a couple of reasons why you might want separate
    > definitions and implementation, such as when a class has a static data
    > member


    Can be done in header file via template trick.


    >, or if you intend to create a shared object library of class code,


    AFAICS that is irrelevant except for the headers the client code needs.


    > but it seems to me that putting the code into the header files is a bit
    > more elegant and the other way would be more of a holdover from the old
    > days before templates.
    >
    > I'm wondering what comments the upper echelon lurkers might have. Do they
    > agree with my reasoning, or can they give me reasons why I should
    > reevaluate my assertions.


    One reason to separate the two is that with all the code in headers, any
    build of the system involves all of the code, which is slow (precompiled
    headers have their own problems). And with all code in header files,
    you force a remake of dependent modules when only the implementation is
    changed, compounding that problem. A third reason to separate is to be
    free to use any implementation techniques that suit the problem, instead
    of doing very "clever" things and going amok with namespacing.

    --
    A: Because it messes up the order in which people normally read text.
    Q: Why is it such a bad thing?
    A: Top-posting.
    Q: What is the most annoying thing on usenet and in e-mail?
    Alf P. Steinbach, Jan 23, 2007
    #3
  4. noone

    noone Guest

    On Mon, 22 Jan 2007 23:09:57 -0500, Victor Bazarov wrote:

    > C++ was designed with large scale systems in mind. That's not the only
    > paradigm it supports, but it's the most important, if you ask me. If your
    > system is small, no big deal. Keep your headers full of code and don't
    > bother. We used to do that in Pascal, didn't we? Then along came units,
    > and suddenly we could split the development into several relatively
    > independent pieces... You can do it nowadays in C++ with many modern
    > compilers that support precompiled headers, of course. But then again,
    > once code changes you need to recompile most of them again... Kind of
    > PITA.


    Thanks for your comments. I do understand your point. Our systems
    definitely fall into the category of many small embedded programs with a
    well defined message passing API to communicate between the processes.

    Thanks for the followup.
    noone, Jan 23, 2007
    #4
  5. noone

    noone Guest

    On Tue, 23 Jan 2007 05:29:55 +0100, Alf P. Steinbach wrote:

    Hi.

    I should probably clarify what I mean by "all the code"

    I'm talking about utility classes. The individual program logic is of
    course still in .cc files. I try to encourage class coding where the
    methods are suitable for implicit inline compilation.

    And as I mentioned to Victor, the projects are numerous small embedded
    software component programs of less than 1000 lines including comments.

    The utility classes are things like C++ wrappers around socket networking,
    a joystick driver (which does use a separate .cc file only because it uses
    signals and requires a static data member to point to the class instance
    that is needed to register in the polling timer), message passing
    wrappers. interfaces to kernel drivers, etc.

    Your points are well taken. I think based on scale it is a tradeoff right
    now. The whole unmanned system operating environment compiles in less
    than two minutes on a single CPU Xeon machine.
    noone, Jan 23, 2007
    #5
    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. Razvan

    XML related definitions

    Razvan, Jan 25, 2005, in forum: XML
    Replies:
    3
    Views:
    369
    Razvan
    Jan 28, 2005
  2. Brendan
    Replies:
    10
    Views:
    465
    Terry Reedy
    Apr 4, 2005
  3. clintonG
    Replies:
    0
    Views:
    321
    clintonG
    Feb 9, 2007
  4. Replies:
    16
    Views:
    616
  5. PaulNaude

    How can I dig deeper into the ERROR?

    PaulNaude, Oct 28, 2005, in forum: ASP .Net Datagrid Control
    Replies:
    0
    Views:
    106
    PaulNaude
    Oct 28, 2005
Loading...

Share This Page