[Bug c++/84667] unreasonable refusal to use assignment operator method

redi at gcc dot gnu.org gcc-bugzilla@gcc.gnu.org
Mon Mar 5 11:22:00 GMT 2018


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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|REOPENED                    |RESOLVED
         Resolution|---                         |INVALID

--- Comment #12 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Elmar Stellnberger from comment #9)
> I still do not understand why this constructor gets called: inline xstrbuf(
> base_str s ). If I use .as_const() the result should be an xstr_const :
> public xstr_abstract<const xchar,xchar> and not an xstr_mutable: public
> xstr_abstract<xchar,xchar>. Even if it ascended to xstr_abstract it would
> have to discard the const qualifyer.

Read my answer again more carefully.

> This is copy-initialization:
>
>  estrbuf copybuf1 = varbuf4.as_const();
>
> That means it's equivalent to this:
>
>  estrbuf copybuf1 = estrbuf(varbuf4.as_const());

The result of as_const() is an xstr_const, but then a temporary xstrbuf is
created from that, and then because your copy constructor was not viable for
copying a temporary (it only accepts non-const lvalues) the temporary is
converted to its base class (xstr_mutable) and then the xstrbuf(base_str)
constructor is used.

If you write complicated, unreadblae code then don't be surprised if you can't
understand what it does!


(In reply to Elmar Stellnberger from comment #11)
>   Why does my gcc not report uninitialized variables. Is the version too old
> (6.3.0 20170516)? 

Yes, I see warnings with GCC 7.1 and later.

>   Still I do not know how g++ can convert an xstr_const into an
> xstr_mutable. That should be impossible as stated in the comment above. Thus
> the fact that correcting an error reported by clang has made the program
> behave correctly under g++ is simply astonishing. However I have no idea why
> g++ behaves like this.

Because that's what the C++ standard says should happen.

I don't get any error compiling yuor code with clang, I see exactly the same
behaviour as GCC.


More information about the Gcc-bugs mailing list