"Axter" <go****@axter.comwrote in message
news:11**********************@i42g2000cwa.googlegr oups.com...
Gavin Deane wrote:
>scroopy wrote:
On 17 Jul 2006 02:11:46 -0700, "Gavin Deane" <de*********@hotmail.com>
wrote:
scroopy wrote:
<snip>
>I want to do something like this
class MyClass
{
const int m_iValue;
public:
MyClass(int iVal):m_iValue(iVal){}
MyClass operator=(const MyClass& mc)
{
m_iValue = mc.m_iValue; //not allowed
Not allowed for obvious reasons I hope.
return *this;
}
Your design seems confused. The obvious solution is not to declare
m_iValue const in the first place if its value is going to change. But
presumably you had a reason for declaring it const in the first place.
You can declare it const or you can change its value in the assignment
operator but you can't do both. Which choice fits your design?
II want the value to be assigned upon object creation but remain const
throughout the lifetime.
You seem to be confusing assignment and creation. The assignment
operator never has anything to do with object creation. That's the job
of constructors. Construction of a brand new object and assignment of a
new value to an exisiting object are completely different things. Using
your code above
MyClass object1(3);
will create an object called object1 using the constructor that takes
an int.
MyClass object2(object1);
or
MyClass object2 = object1;
are two ways of constructing an object called object2 as a copy of
object1 but you would have to write a copy constructor for MyClass.
The second way is actually a call to the assignment operator, and not
the copy constructor.
Many compilers, like VC++, will optimize away the assignment operator
call, so all you get is the copy constructor call.
But not all compilers will do that, and it's not required by the
standard.
As far as I can tell, you're a tad confused. The relevant bit from the
standard (well, the draft version of it, anyway, which is all I have to
hand - something like this will likely be very similar in the real thing)
reads:
***
(extract from 8.5)
If the initialization is direct-initialization, or if it is
copy-initialization where the cv-unqualified version of the source type is
the same class as, or a derived class of, the class of the destination,
constructors are considered. The applicable constructors are enumerated
(13.3.1.3), and the best one is chosen through overload resolution (13.3).
The constructor so selected is called to initialize the object, with the
initializer expression(s) as its argument(s). If no constructor applies, or
the overload resolution is ambiguous, the initialization is ill-formed.
Otherwise (i.e., for the remaining copy-initialization cases), a temporary
is created. User-defined conversion sequences that can convert from the
source type to the destination type or a derived class thereof are
enumerated (13.3.1.4), and the best one is chosen through overload
resolution (13.3). The user-defined conversion so selected is called to
convert the initializer expression into a temporary, whose type is the type
returned by the call of the user-defined conversion function, with the
cv-qualifiers of the destination type. If the conversion cannot be done or
is ambiguous, the initialization is ill-formed. The object being initialized
is then direct-initialized from the temporary according to the rules
above.87) In certain cases, an implementation is permitted to eliminate the
temporary by initializing the object directly; see 12.2.
***
In other words (i.e. less precisely but hopefully more lucidly):
MyClass object2 = object1;
is an example of copy-initialization where the cv-unqualified version of the
source type (i.e. MyClass) is the same class as the class of the
destination. In this case, as the first paragraph above makes clear,
constructors are considered. In other words, the copy constructor will get
invoked in this instance, *not* the assignment operator.
The second paragraph seems to be the source of your confusion, but note that
even there it talks about the object being *initialized*, not assigned to.
Hope this helps,
Stu