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.
