multi. def. in headers....

This is a discussion on multi. def. in headers.... within the C++ Programming forums, part of the General Programming Boards category; Hello All, I have a problem with using header files: i've got a program in which i include the <vector> ...

  1. #1
    Registered User
    Join Date
    Nov 2007
    Posts
    11

    multi. def. in headers....

    Hello All,

    I have a problem with using header files: i've got a program in which i include the <vector> header and another header (let's say <header_x> ). Now the problem is that <header_x> has a definition for a vector which is nothing to do with the definition in the <vector> header, so when i come to compile i get an error message about the type vector<float> being ambiguous.

    i can go in to the <header_x> file and comment out the line which declares the other vector type(it's actually a function i think) and everything works fine but this seems like a bodge job and what if i need to use this vector in the future?

    Can anyone tell me how i get around this issue ?

    I hope i've been clear, if not ask me to elaborate.
    cheers

  2. #2
    Registered User
    Join Date
    Oct 2001
    Posts
    2,129
    don't use
    Code:
    using namespace std;
    and use
    Code:
    std::vector<something>
    instead.

  3. #3
    Registered User
    Join Date
    Nov 2007
    Posts
    11
    thanks robwhit.

    i think that'll work. i'm not in work at the moment so i'll try it tomorrow.
    I always wondered why people go the long way round by writing explicitly
    "std::"

    p.s. i just tried this without using the #include <string> statement:

    std::string s = "hh";

    My question now is: What lives inside the std namespace(or where can i find it) and is there any need for me to #include <string> is i just use the former method ?

  4. #4
    Registered User
    Join Date
    Jan 2005
    Posts
    7,317
    Sometimes headers include other headers as part of their implementation, so you might be able to use something without directly #including the header that declares it.

    Relying on this is a bad idea, though, since that could change at any time. Also, you might get only part of the declaration, and some code will work and other code will break (this actually happens with string on one particular platform).

    So if you use the string class, always #include <string> in the file that uses it.

  5. #5
    Registered User
    Join Date
    Nov 2007
    Posts
    11
    Thank Daved, that make sense now.

    Just going on from that is there a clause like #ifndef for #include's ? I was wondering if i had the folliwing situation:

    #include <a.h>
    #include <string>



    where file a.h it's self #includes <string> meaning that the <string> header has effectivly been
    included twice?


    cheers

  6. #6
    Cat without Hat CornedBee's Avatar
    Join Date
    Apr 2003
    Posts
    8,893
    No, the header is guarded against being included twice.

    Still, as a general rule you should include headers in the order

    system headers
    3rd party library headers
    project headers

    Just a personal style rule, but one I'm rather fond of.
    All the buzzt!
    CornedBee

    "There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
    - Flon's Law

  7. #7
    Captain Crash brewbuck's Avatar
    Join Date
    Mar 2007
    Location
    Portland, OR
    Posts
    7,236
    Quote Originally Posted by CornedBee View Post
    No, the header is guarded against being included twice.

    Still, as a general rule you should include headers in the order

    system headers
    3rd party library headers
    project headers

    Just a personal style rule, but one I'm rather fond of.
    This is the order I usually include headers, as well. It ensures that the most project-specific symbols are declared last, minimizing the chances of a bad interaction between headers that goes unnoticed. In some ways you can call this ordering "least-specific to most-specific."

    On the other hand, the Boost library uses the "most-specific to least-specific" ordering (at least, I read this in a Boost rationale document, but I can't remember where). The idea being that by including the most specific header files first, you ensure that their functionality is properly self-contained. If some project header forgot to #include <string> (because it uses std::strings) this error might be masked if it is included after <string> in some module somewhere. If on the other hand it is included first, the compiler will throw an error that std::string is not defined.

    I'm currently in limbo between these two rationales...

  8. #8
    Cat without Hat CornedBee's Avatar
    Join Date
    Apr 2003
    Posts
    8,893
    I use compile-only unit tests to ensure that my headers work standalone. I think that's a better method.
    All the buzzt!
    CornedBee

    "There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
    - Flon's Law

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. NAQ: Everything you never wanted to know about CPP
    By evildave in forum C Programming
    Replies: 21
    Last Post: 12-12-2005, 09:56 AM
  2. Not sure on hash table memory allocations
    By Thumper333 in forum C Programming
    Replies: 3
    Last Post: 09-27-2004, 09:00 PM
  3. include question
    By Wanted420 in forum C++ Programming
    Replies: 8
    Last Post: 10-17-2003, 03:49 AM
  4. Headers that use each other
    By nickname_changed in forum C++ Programming
    Replies: 7
    Last Post: 10-03-2003, 04:25 AM
  5. how do you handle all your headers?
    By mart_man00 in forum Linux Programming
    Replies: 0
    Last Post: 06-16-2003, 03:17 PM

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21