Thread: copy constructor for a class with a const reference member...

hello, i'm struggling to come up with the correct syntax.

Code:

class Foo
{
public:
  Foo(const Bar& bar);

private:
  const Bar& m_bar;
};


Foo::Foo(const Bar& bar)
  : m_bar(bar)
{ }

that works and compiles...until i put Foo into a vector, and it complains i don't have a assignment operator.

ok, so i define one...but now i have a problem where i don't want to change the m_bar reference because i can't assign it something else...

is there a way around this?

When you do

Code:

Foo a(whatever);
Foo b = a;

what reference do you want b to have? (If the answer is not "whatever", why not?) (If the answer is "I want a separate copy", then we shouldn't even have references in the first place.)

Couldn't you just use a pointer instead of a reference?

at my job my supervisor forbids me to use any pointers directly (must use a smart pointer if required), so a reference is the only acceptable compromise.

i can get it to work if i remove the constness, but i want to keep that.

@tabstop,
Foo a(whatever);
Foo b = a; // yes, b should contain the values of a, including the reference to whatever

I wonder why the guideline against pointers... Sometimes I have found one simple work around that doesn't even require any special programming knowledge is simply "Boss, I need this ctor to utilize a pointer, is that ok?"

You never know what (s)he just might agree to allow.

Originally Posted by bling

at my job my supervisor forbids me to use any pointers directly (must use a smart pointer if required), so a reference is the only acceptable compromise.

Well that's a stupid rule... I'm guessing your supervisor is a Java programmer who is affraid of the evil pointers in C/C++?

Well foo is not assignable by design. Let foo have a bar shared pointer, or just bar, if you can avoid the indirection.

Then your copy constructor should set m_bar of the new thing to m_bar of the old thing. Somehow I'm missing the problem? (Assignment operator for an existing left-hand side can't work with a reference object, since references can't be re-seated, so I'm hoping you don't mean assignment operator.)

Originally Posted by cpjust

Well that's a stupid rule... I'm guessing your supervisor is a Java programmer who is affraid of the evil pointers in C/C++?

Sometimes its actually not that at all. The primary reason pointers are even allowed in C++ is for compatibility with C. Even Stroustrup has been known to disagree with the way they can skirt some of the rules of encapsulation.

surprisingly he has no background in java/c# that i know of. his reasoning is to avoid memory leaks, but maybe he doesn't know that * doesn't necessarily mean it's on the heap. i'm still on probation so i can't do too much.

*scratches head* Well I had actually started making a mental list of good reasons to support this rule, just in case one of you guys started the typical chain of arguing... However, I would have never guessed that this is the reason behind the rule. Odd indeed.

Check this out:

Memory Leak:

Code:

myclass &getClass(int i)
{
     return *(new myclass(i));
}

...But whatever.

anyways, the problem is that my reference is const...so i can't reseat, so i can't make an assignment operator nor a copy constructor...

here's what i need:
- i do NOT want to be able to change the data in bar, hence const
- but i DO want to be able to redirect it to something else, which i'm guess the const and no-reseating for references is messing me up...

Have you tried the asking the boss for permission thing just yet? I was being completely serious when I suggested that.