Re: being copy constructible
terry wrote:
Perhaps I can be allowed to ask it again. Do those with
experience think the code below is a breach of the standards.
Does the non-const nature of the copy constructor stop it
being copy constructible in the sense of the standard?
#include <vector>
class S
{
public:
S(){}
S(S& a){} //non-const copy constructor
bool operator==(const S & rhs){return true;};
};
int main(int argc, char* argv[])
{
std::vector<S> u(1);
return 0;
}
It depends. The non-const-ness doesn't stop the constructor
from being a copy constructor, from the point of view of the
compiler; the compiler will not generate a default copy
constructor for this class, because it considers that the class
already has a copy constructor.
In order to meet the CopyConstructible constraint in the
library, it must be possible to copy const objects, however, and
this constructor doesn't allow that. There is also a
requirement that the result of the copy be "equivalent" to the
original. There is, however, intentionally no definition of
"equivalent", since in many cases, this would depend on the
application---there is no requirement, for example, that the ==
operator be defined, or even, if it is defined, that it
implements the same definition of equivalence; although one
would hope that this is generally the case, it's easy to imagine
cases where the equivalence requirements on copying were
stronger than those for ==. (The case actually arrises
frequently with input iterators, at least in my code.)
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient?e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S?mard, 78210 St.-Cyr-l'?cole, France, +33 (0)1 30 23 00 34
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]