• 10
• 13
• 18
• 27
• 9

# Error when using an 'constructor initializer list'...

This topic is 2816 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

Hi there,

I've got a Problem,

whenever I'm using a constructor initializer list in any of my classes, like that

//in Camera.hCCamera(CSceneGame& Scene);//in Camera.cppCCamera::CCamera(CSceneGame& Scene) : m_Scene(Scene){}

everything works great since I initialize the class like that

CCamera Camera(Scene);

but when I want to handle the pointer of that object to an object of another class, for example

//in a function of the CControl-Classvoid CControl::Setup(CCamera &Camera){	m_Camera = Camera;}

I get the error C2582: 'operator =' function is unavailable in 'CCamera class'.
Surely that has something to do that this class now don't have any normal constructor anymore, but if I add one normal constructor, I get the error I would get without using constructor initializer list.

How can I solve that? I still want to be able to handle pointers over without having to re-construct for example my CControl-Class-Object, that works so far...

##### Share on other sites
The solution is to make your m_Scene member into a pointer. A reference is not reseatable, so it breaks copy construction. However, you can still present the CCamera interface with references:
class Camera{public:    Camera(SceneGame& scene) : scene(&scene)    {    }private:    Scene *scene;};

This is a common idiom.

##### Share on other sites
I don't believe that's what's happening here. Granted the OP hasn't posted enough to tell for sure, but I believe m_Scene is an object, not a reference.

this page demonstrates what causes the C2582 error and how to fix it.
It would appear that you need to define the assignment operator for CCamera.

Those reference arguments should probably be const too.

##### Share on other sites
Quote:
 Original post by iMalcbut I believe m_Scene is an object, not a reference.

It does not matter if it's an object or a reference in this case. Assignment will always assign to the object, never to the reference itself.
int a = 1;int b = 2;int& r = a;r = b;

The last line assigns 2 to a. It does NOT rebind the reference to b, because rebinding references is impossible in C++.

##### Share on other sites
Thanks, rip-off was right, it is working now after I used his solution.

Since then my m_Scene-object was defined as

CSceneGame& m_Scene

seems that this is really un-copyable. But now it works, thanks again.

##### Share on other sites
Quote:
Original post by DevFred
Quote:
 Original post by iMalcbut I believe m_Scene is an object, not a reference.

It does not matter if it's an object or a reference in this case. Assignment will always assign to the object, never to the reference itself.
int a = 1;int b = 2;int& r = a;r = b;

The last line assigns 2 to a. It does NOT rebind the reference to b, because rebinding references is impossible in C++.
Yes I knew that. My reasons for stating it was probably an object had nothing to do with that. It's occam's razor in that it did not seem necessary to cause the error given here. rip-off did turn out to be correct, which was probably the luck of the draw.

##### Share on other sites
There aren't that many things that would inhibit the automatic generation of the assignment operator. You could have a reference member variable, a const member variable and a object member variable of a class type that itself doesn't have an accessible assignment operator. I don't see how Occam's razor really would say that the member variable would be an object, as the simplest explanation that fits the fact would be the one with the least amount of code behind it. In this case the reference member variable which would only add a single & to a properly function class to make it generate a class that didn't have a default generated assignment operator.

##### Share on other sites
It was more than luck I hope.

There are only a few cases where default copy construction is suppressed, and this seemed the obvious situation. I would think if the OP was savvy enough to make their objects intentionally noncopyable then they would be quick to diagnose this error.

##### Share on other sites
Quote:
 Original post by rip-offIt was more than luck I hope.There are only a few cases where default copy construction is suppressed, and this seemed the obvious situation. I would think if the OP was savvy enough to make their objects intentionally noncopyable then they would be quick to diagnose this error.

Hm, actually I'm not as I'm new to software development. Well, not that new, I can do some nice things with c++ and directx but everything is really plain and miss some really important information.

But now I'm interested in that topic, is there any tutorial or so on how to create custom classes in a neat way without making some supid mistakes like that? I read some books about c++, but so far their content was limited to some basic things or how to create a working code, but not to make it safe or so...

##### Share on other sites
Since I was the one who suggested a member reference in the first place I feel somewhat responsible for this confusion, even though I didn't say it was the right way to design classes, just a way to find out if pass by value was the cause of your initial problem. Good thing we cleared that up though, I have been programming C++ for many years and never had that issue myself.
Anyway, I wouldn't call it a stupid mistake, rather another one of many C++ corner cases or compromises that requires a work-around that eventually ends up as another more or less feasible idiom.

As for books, the only books I know that help you design better classes is the books written by Scott Meyers. I'm sure there is more of them but that is the only ones I remember worth mentioning.

Another thing you might want to consider is to read the C++ ISO standards. You should be able to find those online somewhere