confused about .h and .cpp definition vs implementation

Discussion in 'C++' started by michael.goossens@gmail.com, Jan 26, 2008.

  1. Guest

    Hello everyone,
    maybe some usefull information first: I'm a student, I can program and
    most of my experience is in java but I always had the feeling java is
    "the easy way out" so now I'm interested in some c++. I'm longing to
    make a speedy raytracer and that is why I need c++ and need to learn
    alot about how it works internally to see what choices are the best
    way for an optimal speed result.

    I have some troubles understanding the concepts of a header and all
    around it. It seems that a header has the purpose to define classes
    and functions. But its also possible to actually implement the classes
    and functions in there. But why would someone do that? Is it better?

    I see three options of implementation at the moment:

    1) defining a header with the definitions and implement them in a .cpp
    file
    2) defining a header with the definitions and the implementations
    3) using a cpp file and implement it all in there.

    So what are the pro's and contras here? Currently I'm using using
    option 1 since I learned it that way in a basic OO-language course.

    Also, it is possible to define a range of multiple classes in the same
    header file, why would I want that over the 1 header - 1 class
    structure that I'm using now(probably a java influence here).
     
    , Jan 26, 2008
    #1
    1. Advertising

  2. * :
    > Hello everyone,
    > maybe some usefull information first: I'm a student, I can program and
    > most of my experience is in java but I always had the feeling java is
    > "the easy way out" so now I'm interested in some c++. I'm longing to
    > make a speedy raytracer and that is why I need c++ and need to learn
    > alot about how it works internally to see what choices are the best
    > way for an optimal speed result.
    >
    > I have some troubles understanding the concepts of a header and all
    > around it. It seems that a header has the purpose to define classes
    > and functions. But its also possible to actually implement the classes
    > and functions in there. But why would someone do that? Is it better?
    >
    > I see three options of implementation at the moment:
    >
    > 1) defining a header with the definitions and implement them in a .cpp
    > file
    > 2) defining a header with the definitions and the implementations
    > 3) using a cpp file and implement it all in there.
    >
    > So what are the pro's and contras here? Currently I'm using using
    > option 1 since I learned it that way in a basic OO-language course.
    >
    > Also, it is possible to define a range of multiple classes in the same
    > header file, why would I want that over the 1 header - 1 class
    > structure that I'm using now(probably a java influence here).


    Headers and implementation files are a way to emulate logical separately
    compiled modules in a language that has a pre-processor but no direct
    support for separately compiled modules.

    Separately compiled modules are a way to physically split and package a
    large system so as to reduce complexity and build times, and allow
    concurrent development of different parts.

    Method (1) achieves these goals for pure OO code, but with current
    compilers (except Comeau) fails to provide information hiding for
    template code, because current compilers don't support "export" so that
    the template implementations must be provided in the header file.

    Method (2) supports template code, and can avoid some extra work, at the
    cost of possibly longer build times and not providing information
    hiding. In particular, it does not support the common PIMPL idiom.

    Method (3) means essentially that the program is so small that there's
    no need for physical packaging.


    Cheers, & hth.,

    - Alf

    --
    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 26, 2008
    #2
    1. Advertising

  3. Guest

    So what is the best choice for a rendering program? Takes alot of
    memmory and computation. Obviously its not method 3. And is there any
    gain by putting classes together in a header?
     
    , Jan 26, 2008
    #3
  4. * :
    > So what is the best choice for a rendering program? Takes alot of
    > memmory and computation. Obviously its not method 3. And is there any
    > gain by putting classes together in a header?


    Rendering program = irrelevant, what's relevant is the size and
    complexity of the source code.

    Lot of memory and computation = irrelevant, as above.

    Gain by putting classes together in one header, yes, e.g. if they're a
    set of strongly related classes used for one purpose. Unrelated classes
    are generally best distributed in different headers. It also depends on
    whether the classes are meant to be reused, where client code programmer
    may want to use just one or a few classes without dragging in a lot of
    unrelated stuff that may clash with other things, and it depends on what
    size and complexity the resulting headers are (judgement call that too).

    Possibly you will do as engineers have traditionally done when designing
    bridges.

    First, make bridge too weak, collapse. Respond by making bridge to
    strong, high cost. Make weaker and weaker bridges until new collapse.
    Say oops, now make really really strong but costly bridge. So on.


    Cheers, & hth.,

    - Alf

    --
    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 26, 2008
    #4
  5. Guest

    So classes like Vector - Point and Normal, which are heavely used and
    strongly related should better be put together and a class like
    Texture should be on its own. Should the implementation be in the same
    file? My guess would be yes because otherwise the compiler won't know
    where the implementation is?

    Thanks for answering my questions :), will have more in the future.
     
    , Jan 26, 2008
    #5
  6. Guest

    O yeah, I don't think engineers can afford to see their bridge
    collapse :). Just as I want to make a good program with solid
    foundations. Even though the odds are against me, implementing
    something difficult in a language I have no expertise of :).
     
    , Jan 26, 2008
    #6
  7. Pavel Guest

    wrote:
    > So what is the best choice for a rendering program? Takes alot of
    > memmory and computation. Obviously its not method 3. And is there any
    > gain by putting classes together in a header?
    >

    I would suggest you to keep using method (1). The Alf's reference to the
    small program, BTW, referred to the amount of source code, not the
    amount memory and computation so if you hoped to fit all your ray tracer
    code in less than about 500 lines of code, you (3) would not be
    theoretically too bad.

    But the main question then is the purpose of your ray tracer. If it is
    going to be a library (like a Java jar file with packages to use in
    different program), it has to have an interface that the client program
    will need to use at compile time.

    In C++, the only way to "import" such interface is to textually include
    it (into the file, using #include <header> preprocessor directive). So,
    if you are building a library the general rules will be:

    1. Use method (1).

    2. Put only as little as you can code into the header to avoid making
    the client code dependent on unnecessary implementation details (which
    you might want to change often) and save compilation time.

    3. Make sure you break down your API to headers in a way that you won't
    forget what's where if you have to leave your code and return to it
    after 3 months. Many strategies can work for you in this regard and it
    is sometimes a matter of a personal taste and maybe of the size of the
    API code (only API is counted here, no implementation so for a basic
    raytracer it can be quite compact). For example:

    3.1. 1 single header file with API.
    3.2. 1 header per publicly exposed class and/or a related group of the
    freestanding functions.
    3.3. A combination of both: have your library delivered to the clients
    with a single header file as per 3.1. (clients will appreciate that,
    they will have enough headache with their own multiple header files to
    remember about them all) and work with multiple files yourself if you
    feel so (which will also spare you some compilation time). A single
    header file you deliver to your client then will mostly consist of
    #include statements including your smaller header files.

    On the other hand, if it is just a test ray tracer utility you are
    writing it is sometimes pays off to start with method (3), especially in
    the beginning where you do not yet know the final breakdown yourself or
    just want to play with some algorithms.

    Hope this will help.

    -Pavel
     
    Pavel, Jan 26, 2008
    #7
  8. Guest

    The goal is a physically based raytracer, global illumination etc.
    Should be a pretty huge thing.
     
    , Jan 26, 2008
    #8
  9. Guest

    Can someone explain:

    explicit Normal(const Vector &v) : x(v.x), y(v.y), z(v.z) { }

    if I implement that in the header it works. If I just define it in the
    header and try to implement it in the c++ file I get: illegal storage
    class as error notification. Is it that explicit can only be defined
    in the class definition itself rather than a Class:: reference thingy?
     
    , Jan 26, 2008
    #9
  10. Pavel Guest

    wrote:
    > Can someone explain:
    >
    > explicit Normal(const Vector &v) : x(v.x), y(v.y), z(v.z) { }
    >
    > if I implement that in the header it works. If I just define it in the
    > header and try to implement it in the c++ file I get: illegal storage
    > class as error notification. Is it that explicit can only be defined
    > in the class definition itself rather than a Class:: reference thingy?

    Yes, `explicit' is a part of the declaration (interface), do not use it
    in the constructor *definition* outside of the class:

    class C {
    explicit C(); // declaration
    };

    C::C() {} // definition

    -Pavel
     
    Pavel, Jan 26, 2008
    #10
  11. Guest

    > Yes, `explicit' is a part of the declaration (interface), do not use it
    > in the constructor *definition* outside of the class:
    >
    > class C {
    > explicit C(); // declaration
    >
    > };
    >
    > C::C() {} // definition
    >
    > -Pavel


    Why can't they just put that information on the pages with tutorials,
    api's and such :(. All those examples are always just implementation
    in the c++ file but nothing with header thingies :(.

    But good thing I got you guys :p
     
    , Jan 26, 2008
    #11
  12. wrote:
    > It seems that a header has the purpose to define classes
    > and functions.


    No. The purpose of a header file is to declare the *public interface*
    of a module. In other words, to declare what other modules should see
    from this module.
     
    Juha Nieminen, Jan 28, 2008
    #12
    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. DrUg13
    Replies:
    1
    Views:
    486
    DrUg13
    Feb 10, 2004
  2. Alex Vinokur
    Replies:
    7
    Views:
    416
    Greg Comeau
    Nov 15, 2004
  3. Vinu
    Replies:
    9
    Views:
    642
  4. www.hitechskill.com
    Replies:
    0
    Views:
    1,368
    www.hitechskill.com
    Apr 9, 2006
  5. Belebele
    Replies:
    4
    Views:
    592
    Gavin Deane
    Oct 17, 2006
Loading...

Share This Page