By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
459,292 Members | 1,718 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 459,292 IT Pros & Developers. It's quick & easy.

namespace? include errors??

P: n/a
Can any of you help with this? Pretty much all the errors I have belong to 2
different categories:
1) error C2872: ambiguous symbols
2) error C2662: cannot convert 'this' pointer from 'const class Vertex' to
'class Vertex &'

Let's see them:

f:\my school\cse528\showdxf\vertex.h(9) : error C2872: 'ostream' : ambiguous
symbol
f:\my school\cse528\showdxf\vertex.h(9) : error C2872: 'ostream' : ambiguous
symbol
f:\my school\cse528\showdxf\triangle.h(9) : error C2872: 'ostream' :
ambiguous symbol
f:\my school\cse528\showdxf\triangle.h(9) : error C2872: 'ostream' :
ambiguous symbol
f:\my school\cse528\showdxf\edge.h(12) : error C2872: 'ostream' : ambiguous
symbol
f:\my school\cse528\showdxf\edge.h(12) : error C2872: 'ostream' : ambiguous
symbol
f:\my school\cse528\showdxf\dxfparser.h(34) : error C2872: 'ifstream' :
ambiguous symbol
f:\my school\cse528\showdxf\dxfparser.h(35) : error C2872: 'ifstream' :
ambiguous symbol
f:\my school\cse528\showdxf\dxfparser.h(36) : error C2872: 'ifstream' :
ambiguous symbol
f:\my school\cse528\showdxf\dxfparser.h(37) : error C2872: 'ifstream' :
ambiguous symbol
f:\my school\cse528\showdxf\dxfparser.h(39) : error C2872: 'ifstream' :
ambiguous symbol
f:\my school\cse528\showdxf\drawdxf.cpp(505) : error C2872: 'cout' :
ambiguous symbol
f:\my school\cse528\showdxf\drawdxf.cpp(525) : error C2872: 'cout' :
ambiguous symbol

where for example:

#ifndef FG_VERTEX
#define FG_VERTEX
#include <iostream>
using namespace std;
class Vertex {
friend ostream &operator<<(ostream&, const Vertex&); <<<<<<<<< line 9
public:
Vertex(float vx, float vy, float vz);
~Vertex() { }; // default destructor
float getX(void) {return x;}; // returns vertex X coordinate
float getY(void) {return y;}; // returns vertex Y coordinate
float getZ(void) {return z;}; // returns vertex Z coordinate
void set(float newX, float newY, float newZ);
bool operator<(const Vertex& v) const;
bool operator==(const Vertex& v) const;
private:
float x,y,z;
};
#endif

and again:

#ifndef FG_DXF_PARSER
#define FG_DXF_PARSER
#include <fstream.h>
#include "model.h"
class DXFParser {
public:
void read_and_build(char *filename, Model *model);
private:
DXFSection getSection(ifstream is);
void readFace(ifstream is, Model *model);
void readPolyline(ifstream is, Model *model);
float getFloat(ifstream is);
void showError(void);
bool skipToHeader(ifstream is, char *header);
void trim(char *str, char *trimmed);
};
#endif

and let's see an example of the error C2662:
f:\my school\cse528\showdxf\vertex.cpp(17) : error C2662: 'getX' : cannot
convert 'this' pointer from 'const class Vertex' to 'class Vertex &'
Conversion loses qualifiers
f:\my school\cse528\showdxf\vertex.cpp(17) : error C2662: 'getY' : cannot
convert 'this' pointer from 'const class Vertex' to 'class Vertex &'
Conversion loses qualifiers
f:\my school\cse528\showdxf\vertex.cpp(17) : error C2662: 'getZ' : cannot
convert 'this' pointer from 'const class Vertex' to 'class Vertex &'
Conversion loses qualifiers
here is the vertex.cpp code:

#include <iostream>
#include "vertex.h"
Vertex::Vertex(float vx, float vy, float vz) {
x = vx; y = vy; z = vz;
}; // default constructor
void Vertex::set(float newX, float newY, float newZ) {
x = newX; y = newY; z = newZ;
};
ostream &operator<<(ostream& out, const Vertex& vertex) {
out << "(" << vertex.getX() << "," << vertex.getY() << "," <<
vertex.getZ() << ")";
return out;
}; // for printing
bool Vertex::operator <(const Vertex& v) const {
if(x<v.x) return true;
else if(x==v.x && y<v.y) return true;
else if(x==v.x && y==v.y && z<v.z) return true;
return false;
};
bool Vertex::operator ==(const Vertex& v) const {
return (x==v.x && y==v.y && z==v.z);
};

Any idea? I am getting really confused here! The only thing that makes me
happy here is that maybe somebody out there knows the solution to this
frustrating situation....

NOTE: the errors C2662 go away of I remove the const from the operator<<
definition, but i don't even know if this is correct overloading now
(Deitel's book shows "const" in it)
Jul 19 '05 #1
Share this Question
Share on Google+
10 Replies


P: n/a
WW
Francesco Gallarotti wrote:
class Vertex {
friend ostream &operator<<(ostream&, const Vertex&); <<<<<<<<<
You need to qualify with std:: here.
friend std::ostream &operator<<(std::ostream&, const Vertex&);
line 9 public:
Vertex(float vx, float vy, float vz);
~Vertex() { }; // default destructor
float getX(void) {return x;}; // returns vertex X coordinate
float getY(void) {return y;}; // returns vertex Y coordinate
float getZ(void) {return z;}; // returns vertex Z coordinate


float getX(void) const {return x;};
float getY(void) const {return y;};
float getZ(void) const {return z;};

Make them const. They don't change the object.
--
WW aka Attila
Jul 19 '05 #2

P: n/a
On Mon, 06 Oct 2003 13:57:34 GMT, "Francesco Gallarotti"
<ga********@hotmail.com> wrote:
Can any of you help with this? Pretty much all the errors I have belong to 2
different categories:
1) error C2872: ambiguous symbols
2) error C2662: cannot convert 'this' pointer from 'const class Vertex' to
'class Vertex &'

where for example:

#ifndef FG_VERTEX
#define FG_VERTEX
#include <iostream>
using namespace std;
Delete the above line! Never put "using namespace std" in a header,
since it produces exactly the problems you are seeing.
class Vertex {
friend ostream &operator<<(ostream&, const Vertex&); <<<<<<<<< line 9
friend std::ostream &operator<<(std::ostream&, const Vertex&);

public:
Vertex(float vx, float vy, float vz);
~Vertex() { }; // default destructor
float getX(void) {return x;}; // returns vertex X coordinate
float getY(void) {return y;}; // returns vertex Y coordinate
float getZ(void) {return z;}; // returns vertex Z coordinate
void set(float newX, float newY, float newZ);
float getX(void) const {return x;}; // returns vertex X coordinate
float getY(void) const {return y;}; // returns vertex Y coordinate
float getZ(void) const {return z;}; // returns vertex Z coordinate

bool operator<(const Vertex& v) const;
bool operator==(const Vertex& v) const;
private:
float x,y,z;
};
#endif

and again:

#ifndef FG_DXF_PARSER
#define FG_DXF_PARSER
#include <fstream.h>


Why the legacy header?

Tom
Jul 19 '05 #3

P: n/a
"WW" <wo***@freemail.hu> writes:
Francesco Gallarotti wrote:
class Vertex {
friend ostream &operator<<(ostream&, const Vertex&); <<<<<<<<<


You need to qualify with std:: here.
friend std::ostream &operator<<(std::ostream&, const Vertex&);


No, he doesn't - he has a

using namespace std;

just before the declaration of class Vertex.
To the OP: NEVER put using directives or declarations in header
files.

kind regards
frank

--
Frank Schmitt
4SC AG phone: +49 89 700763-0
e-mail: frankNO DOT SPAMschmitt AT 4sc DOT com
Jul 19 '05 #4

P: n/a
Frank Schmitt wrote:
"WW" <wo***@freemail.hu> writes:
Francesco Gallarotti wrote:
class Vertex {
friend ostream &operator<<(ostream&, const Vertex&); <<<<<<<<<


You need to qualify with std:: here.
friend std::ostream &operator<<(std::ostream&, const Vertex&);


No, he doesn't - he has a

using namespace std;

just before the declaration of class Vertex.
To the OP: NEVER put using directives or declarations in header
files.


IIRC a friend declaration does not pick up names from a using directive. I
might be wrong. If you have chapter and verse I can be easily convinced.
:-)

--
Attila aka WW
Jul 19 '05 #5

P: n/a
"Attila Feher" <at**********@lmf.ericsson.se> writes:
Frank Schmitt wrote:
"WW" <wo***@freemail.hu> writes:
Francesco Gallarotti wrote:
class Vertex {
friend ostream &operator<<(ostream&, const Vertex&); <<<<<<<<<

You need to qualify with std:: here.
friend std::ostream &operator<<(std::ostream&, const Vertex&);


No, he doesn't - he has a

using namespace std;

just before the declaration of class Vertex.
To the OP: NEVER put using directives or declarations in header
files.


IIRC a friend declaration does not pick up names from a using directive. I
might be wrong. If you have chapter and verse I can be easily convinced.
:-)


Aehm. You got me here - I honestly don't know whether a friend declaration
is different from a "normal" declaration regarding this ;-)
(damn, I *really* have to get a copy of the standard)

kind regards
frank

--
Frank Schmitt
4SC AG phone: +49 89 700763-0
e-mail: frankNO DOT SPAMschmitt AT 4sc DOT com
Jul 19 '05 #6

P: n/a
Frank Schmitt wrote:
[SNIP]
Aehm. You got me here - I honestly don't know whether a friend
declaration is different from a "normal" declaration regarding this
;-) (damn, I *really* have to get a copy of the standard)


Ahh. I was hoping you will do the job. :-) I do not remember this exactly
either. I recall someone telling it does not pick up names from other
namespaces. Actually friend declarations are veeery interesting beasts.
Herb Sutter has some pretty damn good presentation(s) about it.

--
Attila aka WW
Jul 19 '05 #7

P: n/a
Attila Feher wrote:
Frank Schmitt wrote:
[SNIP]
Aehm. You got me here - I honestly don't know whether a friend
declaration is different from a "normal" declaration regarding this
;-) (damn, I *really* have to get a copy of the standard)


Ahh. I was hoping you will do the job. :-) I do not remember this
exactly either. I recall someone telling it does not pick up names
from other namespaces.


I mean from using directives. Using declarations were (IIRC) told to be
different.

--
Attila aka WW
Jul 19 '05 #8

P: n/a
"Attila Feher" <at**********@lmf.ericsson.se> writes:
Attila Feher wrote:
Frank Schmitt wrote:
[SNIP]
Aehm. You got me here - I honestly don't know whether a friend
declaration is different from a "normal" declaration regarding this
;-) (damn, I *really* have to get a copy of the standard)


Ahh. I was hoping you will do the job. :-) I do not remember this
exactly either. I recall someone telling it does not pick up names
from other namespaces.


I mean from using directives. Using declarations were (IIRC) told to be
different.


Hm. further research turned up that it's considered a defect in the
standard, and there seemed to be some confusion how it should be handled:

http://anubis.dkuug.dk/jtc1/sc22/wg2...ctive.html#138

According to the website, an informal consensus has been reached -
although they don't mention which one???

kind regards
frank

--
Frank Schmitt
4SC AG phone: +49 89 700763-0
e-mail: frankNO DOT SPAMschmitt AT 4sc DOT com
Jul 19 '05 #9

P: n/a
Frank Schmitt wrote:
"Attila Feher" <at**********@lmf.ericsson.se> writes:
Attila Feher wrote:
Frank Schmitt wrote:
[SNIP]
Aehm. You got me here - I honestly don't know whether a friend
declaration is different from a "normal" declaration regarding this
;-) (damn, I *really* have to get a copy of the standard)

Ahh. I was hoping you will do the job. :-) I do not remember this
exactly either. I recall someone telling it does not pick up names
from other namespaces.


I mean from using directives. Using declarations were (IIRC) told
to be different.


Hm. further research turned up that it's considered a defect in the
standard, and there seemed to be some confusion how it should be
handled:

http://anubis.dkuug.dk/jtc1/sc22/wg2...ctive.html#138

According to the website, an informal consensus has been reached -
although they don't mention which one???


I could not see any consensus either. :-(

--
Attila aka WW
Jul 19 '05 #10

P: n/a
Frank Schmitt <in*****@seesignature.info> wrote in message news:<4c************@scxw21.4sc>...
"Attila Feher" <at**********@lmf.ericsson.se> writes:
Attila Feher wrote:
Frank Schmitt wrote:
[SNIP]
> Aehm. You got me here - I honestly don't know whether a friend
> declaration is different from a "normal" declaration regarding this
> ;-) (damn, I *really* have to get a copy of the standard)

Ahh. I was hoping you will do the job. :-) I do not remember this
exactly either. I recall someone telling it does not pick up names
from other namespaces.


I mean from using directives. Using declarations were (IIRC) told to be
different.


Hm. further research turned up that it's considered a defect in the
standard, and there seemed to be some confusion how it should be handled:

http://anubis.dkuug.dk/jtc1/sc22/wg2...ctive.html#138

According to the website, an informal consensus has been reached -
although they don't mention which one???


Perhaps they have yet to agree which consensus has been reached :)

GJD
Jul 19 '05 #11

This discussion thread is closed

Replies have been disabled for this discussion.