friendly operator overloading

friendly operator overloading

[Bernd Prager]

Hi,

I need some help with operator overloading.
Following test program compiles and runs fine with g++ (GCC) 4.1.2:

#include <iostream>
#include <string>

namespace xxx
{
class Container
{
friend std::ostream &operator<<(std::ostream&, const Container&);
private:
    int id;
    std::string s;
public:
    Container() : s("Hello World") {}
};


std::ostream &operator<<(std::ostream &stream, const Container &c)
{
    return std::cout << c.s << std::endl;
}
} // namespace

using namespace xxx;
int main()
{
    Container* c = new Container();

    std::cout << *c;

    return 0;
}

As long as I use it one (!) source file.

When I separate the Container class in separate Container.h and a
Container.cpp files the compiler complains about:
$ g++  -march=pentium4 -mfpmath=sse   tst.cpp container.cpp container.h  
-o tst
container.h: In function ‘std::ostream& operator<<(std::ostream&, const
xxx::Container&)’:
container.h:13: error: ‘std::string xxx::Container::s’ is private
container.cpp:8: error: within this context
make: *** [tst] Error 1

When I was trying to find out what is going on, I just put s into public.
Then I get the error message:

$ g++  -march=pentium4 -mfpmath=sse   tst.cpp container.cpp container.h  
-o tst
/tmp/ccCAgEWK.o: In function `main':
tst.cpp:(.text+0xb3): undefined reference to
`xxx::operator<<(std::basic_ostream<char, std::char_traits<char> >&,
xxx::Container const&)'
collect2: ld returned 1 exit status
make: *** [tst] Error 1

What makes me believe that there is some trouble with the namespace of the
operator<< definition, but only if I use separate files.

Anybody has any suggestion?

Thank you very much for any help,
-- Bernd

Re: friendly operator overloading

[Axel Freyn]

Hi Bernd,

for me (g++ 4.2.1) it runs in both situations.
On Mon, Feb 23, 2009 at 08:09:22AM -0700, Bernd Prager wrote:
> #include <iostream>
> #include <string>
> namespace xxx
> {
> class Container
> {
> friend std::ostream &operator<<(std::ostream&, const Container&);
> private:
>     int id;
>     std::string s;
> public:
>     Container() : s("Hello World") {}
> };
> std::ostream &operator<<(std::ostream &stream, const Container &c)
> {
>     return std::cout << c.s << std::endl;
> }
> } // namespace
> using namespace xxx;
> int main()
> {
>     Container* c = new Container();
>     std::cout << *c;
>     return 0;
> }
> 
> As long as I use it one (!) source file.
> 
> When I separate the Container class in separate Container.h and a
> Container.cpp files the compiler complains about:
> $ g++  -march=pentium4 -mfpmath=sse   tst.cpp container.cpp container.h  
> -o tst
> container.h: In function ‘std::ostream& operator<<(std::ostream&, const
> xxx::Container&)’:
> container.h:13: error: ‘std::string xxx::Container::s’ is private
> container.cpp:8: error: within this context
> make: *** [tst] Error 1
I suspect this is a problem how you defined operator <<. It works with
the following files ( operator << is defined OUTSIDE namespace xxx, and
before it is used in class Container):


container.h:

namespace xxx{
  class Container;
}
std::ostream &operator<<(std::ostream&, const xxx::Container&);
namespace xxx
{
class Container
{
friend std::ostream &::operator<<(std::ostream&, const xxx::Container&);
private:
    int id;
    std::string s;
public:
    Container();
};
}


container.cpp:

#include "container.h"
namespace xxx
{
Container::Container() : s("Hello World") {}
}
std::ostream &operator<<(std::ostream &stream, const xxx::Container &c)
{
    return std::cout << c.s << std::endl;
}


test.cpp:

#include "container.h"
using namespace xxx;
int main()
{
    Container* c = new Container();
    std::cout << *c;
    return 0;
}


Of course, it is also possible to define operator << inside the
namespace. 

HTH - if not, it would be useful if you could send the three seperated
files you used,

Axel

MinGW x86_64 ABI problem

[John Fine]

The Windows version of the x86_64 ABI specifies that registers 
xmm6-xmm15 be callee saved.

I'm building a .dll with MinGW used by an .exe from a different compiler.

I debugged a failure to the point of determining that the code produced 
by MinGW clobbers xmm9 in violation of the ABI.

I tried a bunch of Google searches, expecting this problem would be 
discussed somewhere, but couldn't find it.

I'm using a downloaded binary copy of MinGW for x86_64.  I expect I will 
need to download source code and figure out how to build it, in order to 
deal with this problem.

But I don't know where to look in the gcc source code included in MinGW 
for the registers that should be callee saved.

1) Can you tell me where callee saved registers are specified in the gcc 
source code.

2) I tried adding "-f-call-saved-xmm9" to the g++ command to see if that 
would fix the problem for one register.  That compile aborted with
internal compiler error: in copyprop_hardreg_forward_1, at regrename.c:1590
Is that switch so incorrect?  I understand it would generate .obj code 
incompatible with anything generated without that switch.  But why 
should it crash gcc?

Re: MinGW x86_64 ABI problem

[NightStrike]

On Mon, Feb 23, 2009 at 5:33 PM, John Fine <johnsfine@verizon.net> wrote:
>
> The Windows version of the x86_64 ABI specifies that registers xmm6-xmm15 be callee saved.
>
> I'm building a .dll with MinGW used by an .exe from a different compiler.
>
> I debugged a failure to the point of determining that the code produced by MinGW clobbers xmm9 in violation of the ABI.
>
> I tried a bunch of Google searches, expecting this problem would be discussed somewhere, but couldn't find it.
>
> I'm using a downloaded binary copy of MinGW for x86_64.  I expect I will need to download source code and figure out how to build it, in order to deal with this problem.
>
> But I don't know where to look in the gcc source code included in MinGW for the registers that should be callee saved.
>
> 1) Can you tell me where callee saved registers are specified in the gcc source code.
>
> 2) I tried adding "-f-call-saved-xmm9" to the g++ command to see if that would fix the problem for one register.  That compile aborted with
> internal compiler error: in copyprop_hardreg_forward_1, at regrename.c:1590
> Is that switch so incorrect?  I understand it would generate .obj code incompatible with anything generated without that switch.  But why should it crash gcc?
>


First, I added both the mingw-w64 mailing list to the chain as well as
Kai Tietz.

Second, what version of the toolchain are you using?  Is it from our
site?  Is it after Jan 19th of 2009?

Re: MinGW x86_64 ABI problem

[John Fine]

Thankyou.  Problem solved.  Apologies for my misunderstanding of version 
status.

I didn't realize there were newer versions than what I had.  I was just 
looking at the "4.4.0".  I couldn't find any mention of the bug on the 
website, so I didn't think it was likely that it had been fixed 
recently.  Reinstalling a newer build was one of the items on my todo 
list for chasing this problem, but since I saw no mention of the bug 
fix, it wasn't high enough on that list.

I thought I was using a newer build of 4.4.0 than I actually was (not 
sure what I did wrong when getting that) but I just now double checked 
and it was
4.4.0 20080528 (experimental)

I just reinstalled from with "4.4.0 20090221" and confirmed that the bug 
was fixed.

NightStrike wrote:
>
> First, I added both the mingw-w64 mailing list to the chain as well as
> Kai Tietz.
>
> Second, what version of the toolchain are you using?  Is it from our
> site?  Is it after Jan 19th of 2009?
>
>   

Re: MinGW x86_64 ABI problem

[NightStrike]

On Tue, Feb 24, 2009 at 12:35 PM, John Fine <johnsfine@verizon.net> wrote:
> Thankyou.  Problem solved.  Apologies for my misunderstanding of version
> status.
>
> I didn't realize there were newer versions than what I had.  I was just
> looking at the "4.4.0".  I couldn't find any mention of the bug on the
> website, so I didn't think it was likely that it had been fixed recently.
>  Reinstalling a newer build was one of the items on my todo list for chasing
> this problem, but since I saw no mention of the bug fix, it wasn't high
> enough on that list.
>
> I thought I was using a newer build of 4.4.0 than I actually was (not sure
> what I did wrong when getting that) but I just now double checked and it was
> 4.4.0 20080528 (experimental)
>
> I just reinstalled from with "4.4.0 20090221" and confirmed that the bug was
> fixed.

Good news!