strings in header files

I can't seem to figure out the correct syntax for using non-primitive data-types in header files. Can someone please help?

Here's an example of an attempt that won't compile:

Code:

---

#include <string>

struct golf
{
        string fullname;
        int handicap;
};

void setgolf(golf & g, const string name, int hc);
int setgolf(golf & g);
void handicap(golf & g, int hc);
void showgolf(const golf & g);

---

The #include directive may not belong there, but what triggers the error is just using the string variable in defining my structure. It just seems to me that there has to be a way to use non-primitive data-types in your header files, but I'm not getting it right, obviously.

Just as point of info, this goes with ch. 9, ex. 2 in Prata, C++ Primer Plus.

C++ has never had a string. It does have a std::string, however.

While it may be stating the obvious, I should perhaps add that this is the complete file golf.h, which is the prototype file for golf.cpp, where the functions are defined. And both then link to another file (called pe9-2.cpp just because of exercise sequence, but name doesn't matter).

I suppose I should also have created an include guard, but it shouldn't really matter with respect to the current issue.

Ah, interesting. So does that mean that my code should work if I do either of the following:

1) put in "using std::string" at the top and leaving out the #include <string> at the top.

2) leave out the #include <string> (which just looks wrong to me, although it doesn't seem to be causing any error--but I'm not convinced that it's doing anything good either) and just substitute "std::string" in each instance where I've used the word "string".

yep, throwing out the include and putting in "using std::string;" at the top made it compile.

Haven't tested it for doing what I want, but I think it probably will.

Thanks!

Quote:

---

Originally Posted by Aisthesis

yep, throwing out the include and putting in "using std::string;" at the top made it compile.

Haven't tested it for doing what I want, but I think it probably will.

Thanks!

---

Never, ever, ever, EVER put a using directive in a header file. NEVER.

well, that's a using declaration, right? So, in this specific case, it just means that in any file linked to that header file, "string" is interpreted as "std::string".

I'm not seeing exactly how that leads to such horrors in the long-run... ??

Prata does say to "avoid" using DIRECTIVES in header files, but even there, he doesn't make it sound quite as taboo as you are suggesting...

Quote:

---

Originally Posted by Aisthesis

well, that's a using declaration, right? So, in this specific case, it just means that in any file linked to that header file, "string" is interpreted as "std::string".

---

Which means that any file which wants to declare a type called "string" is completely inoperable with that header file. In the worst case, it still compiles, but the type is silently wrong.

1. If you're using std::string in your header, you need to #include <string> in your header. Otherwise your code won't compile if you change the order of your #include statements in your .cpp file.

2. Don't put using directives in header files for the reason brewbuck gave.

Quote:

---

Prata does say to "avoid" using DIRECTIVES in header files, but even there, he doesn't make it sound quite as taboo as you are suggesting...

---

In large code bases it is extremely taboo. Others who include your header bring in the entire namespace you brought into the header. In a cpp it's perfectly valid to use a using because your implementation file will not be included by anyone else - providing you have at least halfway intelligent programmers on your team. If someone does include your implementation file and it's not a template impl then you can smack them for being stupid.

So to sum up:

Code:

---

#include <string>

struct golf
{
        std::string fullname;
        int handicap;
};

...

---

Aisthesis, leave the include declaration as it was initially. That's not the source of your error and it is the right thing to do. You are including a standard library header file that declares the object you need to use. On this case, std::string.

The change you need to make for your initial code to work is to prefix std:: to string. Since the string class is declared inside the namespace std, you need to call it with the std qualifier.

Now, let's assume this bothers you because your golf struct declares a bunch of standard library types and you don't want (for some reason) to write std:: all over the place. That's just fine. You can use a typedef...

Code:

---

#include <string>

struct golf
{
    private:
        typedef std::string string;
    public:
        string fullname;
        int handicap;
};

---

It is declared private because this is merely an implementation shorthand. You don't want it to be accessed by users of your class.

Another (probably better) solution is to create your own namespace:

Code:

---

#include <string>

namespace mine {
        using std::string;

        struct golf
        {
                string fullname;
                int handicap;
        };
}

---

Probably better because the habit of creating and maintaining our own namespaces is a good thing since it is a powerful tool that allows us to curb name collision or better support the separation of interface and implementation.

In any case here, despite you use a using declaration inside a header file, it is declared inside a namespace you control, and is only local to that namespace.

This has been bugging me... I don't think I gave a good advise here...

Code:

---

#include <string>

namespace mine {
        using std::string;

        struct golf
        {
                string fullname;
                int handicap;
        };
}

---

You really don't want to do this. It's true you are lifting std::string inside a namespace you control. But there can be very real reasons for a user of your namespace to want to do:

Code:

---

using namespace mine;

---

At function scope for instance, or when merging your namespace with their own. On the other hand the using declaration is being made at too much of a higher scope. Right at mine::. This isn't correct. You will be exposing std::string too much. Perhaps even to areas of the namespace mine where it isn't necessary or desirable.

Consider the typedef approach the more correct.

Anyone care to comment?

Quote:

---

Originally Posted by Mario F.

Anyone care to comment?

---

In C++ Coding Standards, Sutter and Alexandrescu recommend against using directives and using declaration in namespace scope in a header file, and that recommendation includes avoiding what you suggested about a using declaration within a namespace.

As a demonstration, they provide this code snippet, with the critical question in a comment:

Code:

---

// snippet 1
namespace A {
    int f(double);
}

// snippet 2
namesapce B {
    using A::f;
    void g();
}

// snippet 3
namespace A {
    int f(int);
}

// snippet 4
void B::g() {
    f(1); // which overload is called?
}

---

They proceed to comment that:

Quote:

---

The dangerous thing happening here is that the using declaration takes a snapshot of whatever entities named f in namespace A have been seen by the time the using declaration is encountered. So, from within B, which overloads are visible depends on where these code snippets exist and in what order they are combined. (At this point, your internal "but order dependencies are evil!" klaxon should be blaring.) The second overload, f(int), would be a better match for the call f(1), but f(int) will be invisible to B::g if its declaration comes after the using declaration.

---

Yeah. That was my thought too. I couldn't be right.
Thanks for the confirmation.

Incidentally...

Quote:

---

Originally Posted by brewbuck

Never, ever, ever, EVER put a using directive in a header file. NEVER.

---

Though never is too strong a word here, since a using directive in an inline function in a header file is acceptable since its effects would be restricted to the scope of the function. On a related note, a using declaration in class scope in a header file may be the correct thing to do if one needs to bring in a name from a base class that is otherwise hidden.

Ok, on the main issue, I'm going to conclude that at least until I get sufficiently advanced that I know exactly why I'm doing it (e.g., Laserlight's cases), I just won't use usings in a header.

To me, anyway, it also seems a little pointless for an inline function declaration, since, at least at my level, those are 1-liners that cost less effort to writing std:: once or twice than to write using, etc. But those exceptions are things I shouldn't need to worry about for a good while.

I still do have 1 question remaining, emerging mainly from Mario's comment that he likes keeping the #include <iostream>

At least both the books I've been using have up to now NOT put this in in header files. I'm pretty sure they've avoided #include's altogether in headers. There, I could indeed see an exception if you wanted to declare an inline function using cin, cout, or anything else requiring a header.

But if you only have prototypes, struct, class declarations, etc. in there, I'm not seeing why to keep it. The reason I started with it in the first place was the hope that it might get the compiler to accept my string, but the #include didn't really have anything to do with that.

Quote:

---

Originally Posted by Aisthesis

But if you only have prototypes, struct, class declarations, etc. in there, I'm not seeing why to keep it. The reason I started with it in the first place was the hope that it might get the compiler to accept my string, but the #include didn't really have anything to do with that.

---

Well, it sort of does -- if you don't #include <string>, you don't get to have a std::string either. Same for all the containers -- if you even mention that you want to have a std::vector, you have to #include <vector> in that file.

Quote:

---

Originally Posted by Aisthesis

I still do have 1 question remaining, emerging mainly from Mario's comment that he likes keeping the #include <iostream>

At least both the books I've been using have up to now NOT put this in in header files. I'm pretty sure they've avoided #include's altogether in headers. There, I could indeed see an exception if you wanted to declare an inline function using cin, cout, or anything else requiring a header.

But if you only have prototypes, struct, class declarations, etc. in there, I'm not seeing why to keep it. The reason I started with it in the first place was the hope that it might get the compiler to accept my string, but the #include didn't really have anything to do with that.

---

Books usually do that since they assume the reader will include the necessary headers.

You have to undestand that even during declaration the types you use must be known to the compiler. this is only possible through the #include directive.

Now you may be mislead into believe it works without the include. I'll give you an example of an apparent lack of #include that compiles just fine:

Code:

---

Header file (test.hpp):
struct golf
{
        std::string fullname; //oops?
        int handicap;
};


Source File:
#include <iostream>
#include "test.hpp"

int main() {

 //do nothing

}

---

This compiles. Despite the lack of #include <string> in the header file, the compiler has no problems finding the std::string type. Why?

Because in reality your source file only includes test.hpp after including <iostream>. Since <iostream> itself includes <string> at some point, it works.

But what happens if you want to use test.hpp somewhere else? You will have to guarantee <string> is included also before "test.hpp". Now, imagine you are grabbing your code in 3 months, or that someone else wants to include "test.hpp". Do you think you will remember then you will need to include <string> on your source file before including "test.hpp"? And what about that other person? Do you think they will even know they need to include <string>?

>> Since <iostream> itself includes <string> at some point, it works.
I think Mario knows this but I do want to clarify. <iostream> does not officially include <string>, but with some libraries it appears to work because they share common includes.

The bottom line is to always use a #include when you use something from that header, even if your code is also in a header. In cases where you use the name of something but don't need the full definition, then a forward declaration works, but that is rare with standard library objects. It is not good practice to use something in your header file without #includ'ing the proper header for it.

hey, if you guys wouldn't mind, take a look at the header file I'm getting ready to post from my html translator problem. It compiles and runs without the #include (and using std::string).

I'm going to leave it the way it is for today anyway. But I'm gathering from the comments here that it's better to throw at least one #include in.

I'll elaborate on the question in the new thread.

>> It compiles and runs without the #include (and using std::string).

That doesn't matter. If you use std::string in that header, you should add the #include <string>.

Otherwise you'll be wondering why your code mysteriously stops compiling or working later on.

Quote:

---

Originally Posted by Daved

I think Mario knows this but I do want to clarify. <iostream> does not officially include <string>, but with some libraries it appears to work because they share common includes.

---

Yes, I should have worded it better.

With MSVC 9.0 this is the include path to the actual declaration of std::string, from the original iostream, to xstring where it is finally declared.

iostream
istream
ostream
ios
xlocnum
streambuf
xiosbase
xlocale
stdexcept
xstring

Quote:

---

Originally Posted by Aisthesis

hey, if you guys wouldn't mind, take a look at the header file I'm getting ready to post from my html translator problem. It compiles and runs without the #include (and using std::string).

---

I don't think you are listening. It works because of an almost random event. The std::string name is being introduced by some other header. This is pure coincidence. Try to insert your header file somewhere else where std::string is not being declared by some header file and your code will not work.

"Books usually do that since they assume the reader will include the necessary headers."

Not in these cases because these are chapters introducing the way to code multi-file programs. It may be coincidence that the examples they used in these chapters didn't NEED the includes, but they're not omitting them here because it's self-evident. They purport to be providing complete code that works.

"It works because of an almost random event."

Having the std::string name introduced elsewhere is no coincidence when your header file only includes a prototype that uses it. Thye prototype obviously MUST be elaborated on with a full-scale function definition.

"The std::string name is being introduced by some other header."

It can't be. That's the only header file in the program.

Quote:

---

Originally Posted by Aisthesis

"Books usually do that since they assume the reader will include the necessary headers."

Not in these cases because these are chapters introducing the way to code multi-file programs. It may be coincidence that the examples they used in these chapters didn't NEED the includes, but they're not omitting them here because it's self-evident. They purport to be providing complete code that works.

---

Please share us the titles, so we start a new sticky thread on books no one should read.

Quote:

---

Originally Posted by Aisthesis

"It works because of an almost random event."

Having the std::string name introduced elsewhere is no coincidence when your header file only includes a prototype that uses it. Thye prototype obviously MUST be elaborated on with a full-scale function definition.

---

Let's get something straight here. You are NOT declaring a prototype. The only prototypes I know are function prototypes. You are defining a class (or struct, which is a class too). The only thing remotely close to a function prototype that is applied to classes is a class forward declaration. And that is definitely not what you are doing:

Code:

---

class B; // class forward declaration

class A { // class definition
  /* ... */
};

---

So with that off your mind, let's proceed...

In any case you could be declaring a function and you could be declaring the prototype of a function and you would still be forced to #include the necessary headers for those function arguments or return type:

Code:

---

void myfunc (std::string str); // function declaration, or prototype if you must

---

The above function declaration will NOT compile if the std::string identifier is not being declared somewhere in your includes path. Create a new project and try this:

Code:

---

void myfunc (std::string str);

int main() {
    // do nothing
}

void myfunc (std::string str) {
    // do nothing
}

---

It will fail to compile.

Quote:

---

Originally Posted by Aisthesis

"The std::string name is being introduced by some other header."

It can't be. That's the only header file in the program.

---

Please show us your code. Mention also which compiler you are using.

Try this... In your .cpp file, you must be doing something like this:

Code:

---

#include <string>
#include "Your_Header.h"
...

---

So try switching the #include statements around so that you include your header file before any of the standard header files. Compile it and watch the errors you get.
Now add #include <string> back into your header file and see if those errors disappear.

cpjust's restatement is the way I understood it.

Books: Prata, C++ Primer Plus; Gaddis, Starting out with C++

I've been showing the code since the beginning.

And, sorry, I did mistakenly say that it was only prototypes when a huge feature of the header file was a struct declaration. Other than those points, I really feel like this thread has run its course and the issue is about as clear as its going to get.

sorry, one omission still: compiler is MS Visual C++ 2008 Express