[Bug c++/24847] Instantiates un-called copy constructor

[Bug c++/24847] Instantiates un-called copy constructor

[pinskia at gcc dot gnu.org]

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

--- Comment #4 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
these compiler reject this code:
GCC
MSVC
ICC

Only clang accepts the code.

All of the ones which reject it, all say the constructor is a copy constructor.

[Bug c++/24847] Instantiates un-called copy constructor

[redi at gcc dot gnu.org]

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

--- Comment #5 from Jonathan Wakely <redi at gcc dot gnu.org> ---
Overload resolution considers both constructors, to decide which one v(i)
should use. Performing overload resolution on foo<int, 5, b>::foo(foo<int, 0,
b>) will cause the instantiation of struct foo<int, 0, b> to see if there is a
valid conversion sequence from int to foo<int, 0, b>. Instantiating that type
causes the instantiation of foo<int, 0, b>::foo(foo<int, 0, b>) which is indeed
an invalid copy constructor.

So the problem is not that it thinks the second constructor is a copy
constructor of foo<int, 5, b>, obviously it's not. But it is an invalid copy
constructor for foo<int, 0, b> which gets implicitly instantiated.

I don't know how Clang accepts this.

[Bug c++/24847] Instantiates un-called copy constructor

[redi at gcc dot gnu.org]

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

--- Comment #6 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Ivan Godard from comment #0)
> The second constructor is intended to catch the case: "foo<T, 5, A>(foo<T,
> 0, A>", i.e. to convert an instance of foo with second argument zero to a
> foo with any other second argument.

You can define that as:

explicit    foo(const foo<T, 0, x>&);

Or:

template<int N, typename = std::enable_if_t<N == 0 && i != 0>
explicit    foo(foo<T, N, x>);

Or in C++20:

explicit    foo(foo<T, 0, x>) requires (i != 0);

[Bug c++/24847] Instantiates un-called copy constructor

[bangerth at dealii dot org]

------- Comment #3 from bangerth at dealii dot org  2005-11-23 05:21 -------
The second constructor is definitely bogus, but its mere existence 
does no harm. We should only perform the check for sensibility when
we actually instantiate the second constructor.

W.


-- 

bangerth at dealii dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|0                           |1
   Last reconfirmed|0000-00-00 00:00:00         |2005-11-23 05:21:00
               date|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24847

[Bug c++/24847] Instantiates un-called copy constructor

[igodard at pacbell dot net]

------- Comment #2 from igodard at pacbell dot net  2005-11-15 00:30 -------
The original was much more sensible - and much bigger :-)

Ivan


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24847

[Bug c++/24847] Instantiates un-called copy constructor

[pinskia at gcc dot gnu dot org]

------- Comment #1 from pinskia at gcc dot gnu dot org  2005-11-14 19:32 -------
Comeau also rejects this.  I don't understand why we are trying to instantiate
foo<int, 5, b>::foo(foo<int, 0, b>) except to try to match the constructor, so
maybe this is invalid after all.  Some one else really needs to look at this.

A weird testcase at best.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24847