string class won't compile

[Richard Cavell]

#include <string>
using std::string;
#include <stdio.h>
#include <stdlib.h>
#include <gmp.h>

void My Function(string ParameterOne, string ParameterTwo)
{
int i, j;
string MyString = "hello";
}


This chokes on the last line and says "error: 'string' undeclared (first
use in this function). What am I doing wrong?

 

[JKop]

Made 3 changes:

1) Got rid of #include <gmp.h>

2) Fixed typo in function definition

3) Put in "main".


The following should and does compile:


#include <string>

using std::string;

#include <stdio.h>
#include <stdlib.h>

//#include <gmp.h>

void MyFunction(string ParameterOne, string ParameterTwo)
{
int i, j;
string MyString = "hello";
}

int main()
{

}


-JKop

 

[Andre Kostur]

Made 3 changes:

1) Got rid of #include <gmp.h>

2) Fixed typo in function definition

3) Put in "main".


The following should and does compile:


#include <string>

using std::string;

#include <stdio.h>
#include <stdlib.h>

//#include <gmp.h>

Stylistic point to consider....

I'd move all of your using declarations after _all_ includes. If you
don't, you may inadvertantly bring in a bad symbol lookup (or
ambiguity)....

 

[Miro Jurisic]

Stylistic point to consider....

I'd move all of your using declarations after _all_ includes. If you
don't, you may inadvertantly bring in a bad symbol lookup (or
ambiguity)....

I disagree. I find that

#include <string>
using std::string

#include <vector>
using std::vector

#include <...>
using ...

much much more legible than what you propose, and the risk of ambiguity is low
(so low, in fact, that I have never run into this problem, and I use STL and
boost heavily).

meeroh

 

[Mark]

[...]

Stylistic point to consider....

I'd move all of your using declarations after _all_ includes. If you
don't, you may inadvertantly bring in a bad symbol lookup (or
ambiguity)....

Bad symbol lookup or ambiguity. Sure? Interesting!!!

Mark

 

[David Hilsee]

I disagree. I find that

#include <string>
using std::string

#include <vector>
using std::vector

#include <...>
using ...

much much more legible than what you propose, and the risk of ambiguity is low
(so low, in fact, that I have never run into this problem, and I use STL and
boost heavily).

Beauty is in the eye of the beholder. I prefer this order: application
headers, standard headers, using declarations/directives. The elimination
of potential ambiguities/hidden dependencies is an added bonus.

 

[Andre Kostur]

[...]

Stylistic point to consider....

I'd move all of your using declarations after _all_ includes. If you
don't, you may inadvertantly bring in a bad symbol lookup (or
ambiguity)....

Bad symbol lookup or ambiguity. Sure? Interesting!!!

If you have an unqualified identifier in a subsequent header file, which
namespace does it come from? Let's assume:

/// a.h

extern void fn(string str);

/// a.cpp

#include <string>
using std::string;

#include "a.h"

void fn(string str)
{
}

/// b.cpp

#include <customstring>
using customstring::string;

#include "a.h"

void bfn()
{
fn("");
}



What happens in b.cpp?

 

[Mark]

[...]

If you have an unqualified identifier in a subsequent header file, which
namespace does it come from? Let's assume:

/// a.h

extern void fn(string str);

/// a.cpp

#include <string>
using std::string;

#include "a.h"

void fn(string str)
{
}

/// b.cpp

#include <customstring>
using customstring::string;

#include "a.h"

void bfn()
{
fn("");
}



What happens in b.cpp?

Point taken. As I understand the example, it boils down to which
namespace, hence the ambiguity.

Mark