Visual C++ 6.0 bug?
Leen Ammeraal
must return something (just insert "return" before
"os << ..."). -mod}
The Visual C++ 6.0 compiler does not accept the
following program, complaining 'cannot access
private member variables x and y' and
operator<< is ambiguous. Can anyone explain this
and tell me whether or not this program is correct?
(The program works fine if I completely define
the operator<< function inside the class vec.)
#include <iostream>
using namespace std;
class vec {
public:
vec(float x1=0, float y1=0) {x = x1; y = y1;}
friend ostream &operator<<(ostream &os, const vec &v);
private:
float x, y;
};
ostream &operator<<(ostream &os, const vec &v)
{ os << v.x << " " << v.y << endl;
}
int main()
{ vec u;
cout << u << endl;
return 0;
}
Leen Ammeraal
[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
[ about comp.lang.c++.moderated. First time posters: do this! ]
hlh_N...@excite.com
>#include <iostream>
>using namespace std;
>
>class vec {
>public:
> vec(float x1=0, float y1=0) {x = x1; y = y1;}
> friend ostream &operator<<(ostream &os, const vec &v);
>private:
> float x, y;
>};
>
>ostream &operator<<(ostream &os, const vec &v)
>{ os << v.x << " " << v.y << endl;
>}
>
>int main()
>{ vec u;
> cout << u << endl;
> return 0;
>}
Other than the missing return value from ostream &operator<<(), I see
nothing wrong with this. If VC 6 can't handle friend, I would
consider that a serious problem. However, you might want to make sure
the compiler isn't just giving you a misleading error message (you did
compile that exact snippet above by itself, didn't you?).
--
The true scientist revises his beliefs to fit the evidence.
The true believer revises the evidence to fit his beliefs.
--
hlh_N...@excite.com is a valid address. It is NOT munged.
However, it is not read, either. Please reply via this newsgroup.
Tom Platts-Mills
Ammeraal) wrote:
> {The code looks fine, except that of course operator<<
> must return something (just insert "return" before
> "os << ..."). -mod}
>
>The Visual C++ 6.0 compiler does not accept the
>following program, complaining 'cannot access
>private member variables x and y' and
>operator<< is ambiguous. Can anyone explain this
>and tell me whether or not this program is correct?
>(The program works fine if I completely define
>the operator<< function inside the class vec.)
>
>#include <iostream>
>using namespace std;
>
>class vec {
>public:
> vec(float x1=0, float y1=0) {x = x1; y = y1;}
> friend ostream &operator<<(ostream &os, const vec &v);
>private:
> float x, y;
>};
>
>ostream &operator<<(ostream &os, const vec &v)
>{ os << v.x << " " << v.y << endl;
>}
>
>int main()
>{ vec u;
> cout << u << endl;
> return 0;
>}
The code is OK - apart from the return problem pointed out by the
moderator ( e.g. egcs compiles it with no complaints). This looks
like VC namespace flakiness - I find it's always best to keep
namespace scoping as tight as possible when using VC. In particular
never use global using directives.
To make it work in VC6 you have to remove the 'using namespace std;'
directive and either use the fully namespace qualified names
(std::ostream etc.), or replace the directive with individual
declarations; (using std::ostream; etc.).
Tom Platts-Mills
Larry Brasfield
> {The code looks fine, except that of course operator<<
> must return something (just insert "return" before
> "os << ..."). -mod}
>
>The Visual C++ 6.0 compiler does not accept the
>following program, complaining 'cannot access
>private member variables x and y' and
>operator<< is ambiguous. Can anyone explain this
>and tell me whether or not this program is correct?
This is such a commonly posted VC6 bug that it
almost belongs in the FAQ.
>(The program works fine if I completely define
>the operator<< function inside the class vec.)
>
>#include <iostream>
>using namespace std;
// Workaround:
ostream &operator<<(ostream &os, const vec &v);
>class vec
>public:
> vec(float x1=0, float y1=0) {x = x1; y = y1;}
> friend ostream &operator<<(ostream &os, const vec &v);
>private:
> float x, y;
>};
[Cut definitions and use. The damage is done.]
For some strange reason (viewed from outside
the mind(s) of the bug creator(s)), VC6 does
not allow the first declaration of a properly
privileged friend to be done in the class that
grants friendship, possibly depending on the
presence of a prior "using namespace std;". I
understand a version of the compiler front-end
..exe that fixes this is available from Microsoft
customer support.
See Microsoft's knowledge-base article at
http://support.microsoft.com/support/kb/articles/q192/5/39.asp
--Larry Brasfield
Above opinions may be mine alone.
(Humans may reply at unundered larry_br@sea_net.com )
.
Leen Ammeraal
the VC6 bug with regard to friend functions
and using namespace std. The hint to use
the workaround in the form of using std::cout etc. was
a great help.
It seems that
VC6 does not like the combination of
using namespace std;
and the use of friend functions.
Here is another example, which causes even
an INTERNAL COMPILER ERROR message.
This message does not appear after the removal of
the using namespace std line:
#include <iostream>
using namespace std;
class vec {
public:
vec(float x=0, float y=0)
{ this->x = x; this->y = y;
}
friend vec operator+(const vec &u, const vec &v)
{ return vec(u.x + v.x, u.y + v.y);
}
private:
float x, y;
};
int main()
{ vec a(2, 1), b(3, 2), s = a + b;
return 0;
}
Leen Ammeraal
http://home.wxs.nl/~ammeraal/
Jerry Coffin
NOSPAM.l...@consunet.nl says...
> {The code looks fine, except that of course operator<<
> must return something (just insert "return" before
> "os << ..."). -mod}
>
> The Visual C++ 6.0 compiler does not accept the
> following program, complaining 'cannot access
> private member variables x and y' and
> operator<< is ambiguous. Can anyone explain this
> and tell me whether or not this program is correct?
That depends on whether your definition of "correct" is "well-written"
or "in accordance with the standard". Your code is legal, but (IMO)
poorly written.
> #include <iostream>
> using namespace std;
As soon as I got rid of this "using..." and properly qualified names
instead, your code compiled without errors or warnings with VC++ 6.0.
<IMO and don't take it too seriously>
It's sad that this statement was named "use" or "using" or anything
like it. There should have two statements -- one to use an individual
name from within a namespace, with the same general syntax as above.
The second would the form you have above, where you use ALL names in
the namespace. This form would properly have been named "abuse". The
syntax would be something like:
abusing namespaces_in_general, drag_in_everything_from_namespace std;
In the D&E, Bjarne comments to the effect that the long, ugly syntax
of the new casts might discourage their use, and if so, this is
probably a good thing. I'd say the same about this, except I'd make
it more explicit -- it's long and ugly on purpose, specifically so
nobody will ever use it.
Personally, I'm quite happy that VC++ refuses to accept code that
makes use of this crufty hack and hope it continues to do so.
</IMO and don't take it too seriously>
Larry Brasfield
> must return something (just insert "return" before
> "os << ..."). -mod}
>
>The Visual C++ 6.0 compiler does not accept the
>following program, complaining 'cannot access
>private member variables x and y' and
>operator<< is ambiguous. Can anyone explain this
>and tell me whether or not this program is correct?
This is such a commonly posted VC6 bug that it
almost belongs in the FAQ.
>(The program works fine if I completely define
>the operator<< function inside the class vec.)
>
>#include <iostream>
>using namespace std;
// Workaround:
ostream &operator<<(ostream &os, const vec &v);
>class vec
>public:
> vec(float x1=0, float y1=0) {x = x1; y = y1;}
> friend ostream &operator<<(ostream &os, const vec &v);
>private:
> float x, y;
>};
[Cut definitions and use. The damage is done.]
For some strange reason (viewed from outside
the mind(s) of the bug creator(s)), VC6 does
not allow the first declaration of a properly
privileged friend to be done in the class that
grants friendship, possibly depending on the
presence of a prior "using namespace std;". I
understand a version of the compiler front-end
..exe that fixes this is available from Microsoft
customer support.
See Microsoft's knowledge-base article at
http://support.microsoft.com/support/kb/articles/q192/5/39.asp
--Larry Brasfield
Above opinions may be mine alone.
(Humans may reply at unundered larry_br@sea_net.com )
.
[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]