Template and Copy constructor

[Guest]

Just a little sample :

class A
{
public:
A( )
{
}
template<typename T> A( const typename T& a)
{
}
};

int APIENTRY WinMain(HINSTANCE hInstance,
HINSTANCE hPrevInstance,
LPSTR lpCmdLine,
int nCmdShow)
{
// TODO: Place code here.

A a; // This called the default constructor
A b( a ); // This called the default Copy constructor and not mine !!!
A c( 3 ); // This called my template constructor
A d( 3.0f ); // This called my template constructor
return 0;
}

Why the default copy constructor is called instead of mine when I'm using template constructor ? This compile fine but the default constructor is not the good one used when creating A b( a ); Is there something wrong there ?
Thanks for help !

 

[Carl Daniel [VC++ MVP]]

Just a little sample :

class A
{
public:
A( )
{
}
template<typename T> A( const typename T& a)
{
}
};

int APIENTRY WinMain(HINSTANCE hInstance,
HINSTANCE hPrevInstance,
LPSTR lpCmdLine,
int nCmdShow)
{
// TODO: Place code here.

A a; // This called the default constructor
A b( a ); // This called the default Copy constructor and not
mine !!! A c( 3 ); // This called my template constructor
A d( 3.0f ); // This called my template constructor
return 0;
}

Why the default copy constructor is called instead of mine when I'm
using template constructor ? This compile fine but the default
constructor is not the good one used when creating A b( a ); Is there
something wrong there ? Thanks for help !

There is nothing wrong, rather this is in accordance with the C++ Standard.
A templated constructor will never be considered a copy constructor even if
it's a perfect match on argument types. You need to supply your own copy
constructor if the compiled-supplied one is inadequate for your class.

-cd

 

[Guest]

But there is no warning... It's not really the behaviour we are expecting and I think nobody knows it... Ok, thanks for your help !

 

[Carl Daniel [VC++ MVP]]

But there is no warning... It's not really the behaviour we are
expecting and I think nobody knows it... Ok, thanks for your help !

It's a pretty common trap - comes up on the newsgroups all the time.

An analogous case applies to the copy-assignment operator as well.

FYI: C++ Standard, section 12.8, footnote 106 says

"Because a template constructor is never a copy constructor, the presence of
such a template does not suppress the implicit declaration of a copy
constructor. Template constructors participate in overload resolution with
other constructors, including copy constructors, and a template constructor
may be used to copy an object if it provides a better match than other
constructors."

-cd

 

[Hendrik Schober]

Just a little sample :

class A
{
public:
A( )
{
}
template<typename T> A( const typename T& a)
{
}
};

I see that Carl has already answered your
question. But I want to point out that
the second 'typename' is not necessary. In
fact, I believe the compiler shouldn't even
accept it. However, VC is very lax with
bogus (or missing) 'typenames'.

[...]

Schobi

--
(e-mail address removed) is never read
I'm Schobi at suespammers dot org

"Sometimes compilers are so much more reasonable than people."
Scott Meyers

 

[Brandon Bray [MSFT]]

I see that Carl has already answered your
question. But I want to point out that
the second 'typename' is not necessary. In
fact, I believe the compiler shouldn't even
accept it. However, VC is very lax with
bogus (or missing) 'typenames'.

We might just be ahead of the curve.

In 7.1, we shouldn't be lax about mixxing typenames. The standards committee
is investigating expansion of where typename can go, which actually solves
some common real world problems -- so we may end up implementing it sooner.

 

[Hendrik Schober]

We might just be ahead of the curve.

In 7.1, we shouldn't be lax about mixxing typenames. The standards committee
is investigating expansion of where typename can go, which actually solves
some common real world problems -- so we may end up implementing it sooner.

>
However, AFAIK, this won't be C++ before
2008. Until then, your compiler remains
broken in this regard.
And, VC7.1 is lax about missing 'typename's,
too, although not as bad as the other way.

Schobi

--
(e-mail address removed) is never read
I'm Schobi at suespammers dot org

"Sometimes compilers are so much more reasonable than people."
Scott Meyers

 

[Hendrik Schober]

We might just be ahead of the curve.

In 7.1, we shouldn't be lax about mixxing typenames. The standards committee
is investigating expansion of where typename can go, which actually solves
some common real world problems -- so we may end up implementing it sooner.

>
However, AFAIK, this won't be C++ before
2008. Until then, your compiler remains
broken in this regard.
And, VC7.1 is lax about missing 'typename's,
too, although not as bad as the other way.

Schobi

--
(e-mail address removed) is never read
I'm Schobi at suespammers dot org

"Sometimes compilers are so much more reasonable than people."
Scott Meyers

 

[Brandon Bray [MSFT]]

However, AFAIK, this won't be C++ before
2008. Until then, your compiler remains
broken in this regard.

Broken isn't quite the right word. This is an extension, and perfectly
allowed in a compiler that has extensions.

And, VC7.1 is lax about missing 'typename's,
too, although not as bad as the other way.

Can you provide examples? Looking through the bug database, there isn't
anything like this. (Well, there is one thing -- typename cannot be used in
a default argument to a function, but that's so uncommon that it has never
been reported by a customer or seen in any real world code.)

 

[Hendrik Schober]

Broken isn't quite the right word. This is an extension, and perfectly
allowed in a compiler that has extensions.

Uh, how can I turn this extension off?

Can you provide examples? Looking through the bug database, there isn't
anything like this. (Well, there is one thing -- typename cannot be used in
a default argument to a function, but that's so uncommon that it has never
been reported by a customer or seen in any real world code.)

I don't have a repro. I know that while
porting to Linux (GCC) and Mac (CW)
superflous 'typename's turn up rather
regularly. Sometimes missing ones, too.
But usually nobody takes the time to
boil down the code to a repro.
If I happen to come across something
and find the time to make one I will
post it here.

Schobi

--
(e-mail address removed) is never read
I'm Schobi at suespammers dot org

"Sometimes compilers are so much more reasonable than people."
Scott Meyers

 

[Brandon Bray [MSFT]]

Uh, how can I turn this extension off?

That's not a requirement for compiling non-extension code, so there isn't a
way. Since you seem to be highly concerned about portability, simply
sticking to standards conformance doesn't get you that. Highly portable
programs can make use of very little of what is in the standard.

We do spend a lot of time working towards compiling standards conforming
programs. Working towards limitting programs to standards conformance
doesn't really benefit our customers. First, there is really no test suite
to judge this, which means if we were to expend energy on it, you would be
required to trust our implementation. Secondly, it's actually a poor
barometer of what you actually want -- portability.

All that said, we do have plans on making sure programmers know when they're
using highly visible extensions. In this case, this is a pesky issue that
spending any time on our part wouldn't really help you out. The compilers
you use on other platforms may not be correct either. To get the result you
want, you must use the intersection of the features. That, in practice, has
nothing to do with the standard (other than we know generally the
intersection is supporting more of the standard, but still it is desperately
small).

 

[Hendrik Schober]

That's not a requirement for compiling non-extension code, so there isn't a
way. Since you seem to be highly concerned about portability, simply
sticking to standards conformance doesn't get you that. Highly portable
programs can make use of very little of what is in the standard.

Usable highly portable programs can be written
so that at least 80% of the code is C++ only
without any extensions.
And on the platforms we need, VC, CW, GCC, and
Comeau _are_ close enough to the standard so
that we can use just about everything that is
in the standard except 'export'. What remains
are those many little annoyances: This compiler
choking on one little template, that compiler
ICEing on another one, the third one missing
support for two-phase lookup or accepting code
that all the others won't accept because it
is non-standard.
(BTW, usually, VC7.1 is a mix of the second and

We do spend a lot of time working towards compiling standards conforming
programs. Working towards limitting programs to standards conformance
doesn't really benefit our customers.

I can understand that most of your customers
won't appreciate you working on disallowing
non-conforming code. However, "most" is not
"all".

First, there is really no test suite
to judge this, which means if we were to expend energy on it, you would be
required to trust our implementation.

The reason for wanting std conforming code
to compile only is that we need to port. And
when you port among a variety of compilers,
code that is non-std usually is found very
quick.
(And you have to admint that como in fact
is pretty close to beeing a good test bed.
So far, I have heard of one bug in it [a GC
bug]. I have yet to find one.)

Secondly, it's actually a poor
barometer of what you actually want -- portability.

That is plain wrong. If you have good, std
conforming compilers (that don't let you
get away with non-std code), sticking to
strictly std conforming code in the plat-
form-indepened 80% of the code takes you a
long way. Since we do have such compilers
on all the needed platforms and since we
follow this route, porting has become a
lot easier.

All that said, we do have plans on making sure programmers know when they're
using highly visible extensions. In this case, this is a pesky issue that
spending any time on our part wouldn't really help you out.

I don't know what you draw this conclusion
from. I think it is wrong.
I think it can be safley assumed that most
of the compiler/library vendors aim for std
conformance. So the more compilers conform,
the more portable is my code. In fact, there
is even more than that: Since the C++ std is
the only general agreement on what C++ really
is, it is the the safest bet I can make when
I need my code to be compilable by more than
one compiler.

The compilers
you use on other platforms may not be correct either.

To get the result you
want, you must use the intersection of the features. That, in practice, has
nothing to do with the standard (other than we know generally the
intersection is supporting more of the standard, but still it is desperately
small).

This is wrong. It might be desperately small
when you need some platforms where you depend
on one compiler supplier. However, on the
platforms we target (mainly Win, MacOS, Linux),
it is good. (In fact, for many many years,
your compiler was the cause of most of our
woes. I am really glad that 7.1 has stopped
this.)

Schobi

--
(e-mail address removed) is never read
I'm Schobi at suespammers dot org

"Sometimes compilers are so much more reasonable than people."
Scott Meyers

 

[Brandon Bray [MSFT]]

When it comes down to every case that you disagree with me, it is a matter
of how many platforms you consider important. Not everyone has exactly the
same matrix of targets that you do. I do have data to back up my claims,
which unfortunately I am not at liberty to disclose it here.

I do completely understand your position. While it is an important customer
scenario, given the totality of the customers using Visual C++, it is by far
not a common scenario. It would be a disservice to our customers at large if
we were to focus on scenarios that bear no benefits to a larger audience.

That said, as you've already pointed out, compiling the same code with
several compilers is already a good way to diagnose portability issues.
Anything we do (or done in other compilers) would be no match to simply
trying to compile the code with several toolsets.

 

[Hendrik Schober]

When it comes down to every case that you disagree with me, it is a matter
of how many platforms you consider important. Not everyone has exactly the
same matrix of targets that you do. I do have data to back up my claims,
which unfortunately I am not at liberty to disclose it here.

I do not doubt that there are many shops
out there doing different things than what
we do on many different platforms.

I do completely understand your position. While it is an important customer
scenario, given the totality of the customers using Visual C++, it is by far
not a common scenario. It would be a disservice to our customers at large if
we were to focus on scenarios that bear no benefits to a larger audience.

I think I said that I understand that.
Nevertheless, just I have to make sure
that what is important for me ends up
in your data, even though that doesn't
make it as important to you. >

That said, as you've already pointed out, compiling the same code with
several compilers is already a good way to diagnose portability issues.
Anything we do (or done in other compilers) would be no match to simply
trying to compile the code with several toolsets.

Of course. However, when you actually do
port to different platforms, you start to
realize what is wrong with the platform
you started with. In other words: While
it is nice that this catches bugs which
the compiler the code was developed on
doesn't catch, it is also very annoying
to have to remove (and sometimes add) all
these 'typename's again and again just
because the compiler the code originally
was developed on doesn't do it "right".

Schobi

--
(e-mail address removed) is never read
I'm Schobi at suespammers dot org

"Sometimes compilers are so much more reasonable than people."
Scott Meyers