[Bug c++/64611] Using a << operator inside an overloaded << operator gives compile error

[Bug c++/64611] Using a << operator inside an overloaded << operator gives compile error

[jvoosten at bankai dot nl]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64611

--- Comment #1 from J. van Oosten <jvoosten at bankai dot nl> ---
Output of gcc -v:

Reading specs from /usr/lib64/gcc/x86_64-slackware-linux/4.8.2/specs
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-slackware-linux/4.8.2/lto-wrapper
Target: x86_64-slackware-linux
Configured with: ../gcc-4.8.2/configure --prefix=/usr --libdir=/usr/lib64
--mandir=/usr/man --infodir=/usr/info --enable-shared --enable-bootstrap
--enable-languages=ada,c,c++,fortran,go,java,lto,objc --enable-threads=posix
--enable-checking=release --enable-objc-gc --with-system-zlib
--with-python-dir=/lib64/python2.7/site-packages --disable-libunwind-exceptions
--enable-__cxa_atexit --enable-libssp --enable-lto --with-gnu-ld --verbose
--enable-java-home --with-java-home=/usr/lib64/jvm/jre
--with-jvm-root-dir=/usr/lib64/jvm
--with-jvm-jar-dir=/usr/lib64/jvm/jvm-exports --with-arch-directory=amd64
--with-antlr-jar=/tmp/gcc/antlr-runtime-3.4.jar --enable-java-awt=gtk
--disable-gtktest --disable-multilib --target=x86_64-slackware-linux
--build=x86_64-slackware-linux --host=x86_64-slackware-linux
Thread model: posix
gcc version 4.8.2 (GCC)

[Bug c++/64611] Using a << operator inside an overloaded << operator gives compile error

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64611

--- Comment #2 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to J. van Oosten from comment #0)
> Basically, it's applying the friend operator << function on the internal
> std::ostringstream object, while I would expect the compiler to pick
> 'std::ostringstream::operator <<()'. Furthermore, casting, using ::
> resolution operators, using the 'using' word all does not work.

This works fine:

    template <typename F> friend F &operator << (F &in, float f) 
    {
        in.type ("f");
        using std::operator<<;
        in.m_buf << f;          // This causes a 'recursive' compile call
        return in;
    }


Reduced test that clang and EDG compile OK:

namespace std
{
  struct ostream { };
  struct ostringstream : ostream { };

  ostream& operator<<(ostream&, float);
}

struct SmartStream
{
    template <typename F> friend F &operator << (F &in, float f) 
    {
        in.m_buf << f;          // This causes a 'recursive' compile call
        return in;
    }

    std::ostringstream m_buf;
};

int main()
{
    SmartStream ss;
    ss << 123.456;
}

[Bug c++/64611] Using a << operator inside an overloaded << operator gives compile error

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64611

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|---                         |DUPLICATE

--- Comment #4 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to J. van Oosten from comment #3)
> Yes, that works. Surprising simple solution, but I'm still wondering if this
> is a bug or a feature....
> 
> Thanks for the reply.

This is a bug and a dup of bug 11814.

*** This bug has been marked as a duplicate of bug 11814 ***

[Bug c++/64611] Using a << operator inside an overloaded << operator gives compile error

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64611

Jonathan Wakely <redi at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |NEW
   Last reconfirmed|                            |2015-01-16
         Resolution|DUPLICATE                   |---
     Ever confirmed|0                           |1

--- Comment #5 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Andrew Pinski from comment #4)
> This is a bug and a dup of bug 11814.
> 
> *** This bug has been marked as a duplicate of bug 11814 ***

I don't think so