Removing =

you can declare the operator= a private function, that way it cant be called

Removing the ability to do assignments in general would be a very bad thing, it sounds like you do just want to do it for a specific class type I think (sorry if I misunderstood). Simply implement an operator= member function for the class you dont want to have the ability and make it private.

Aside from adding private: foo & operator=(const foo&); to class foo, you cannot remove the operator. Mind you, making constructors or operators private so they cannot be used is a common idiom in many OO languages.

The other cool thing is if you dont define it (after declaring it private), you'll get a linker error if you try to use =

boost::noncopyable?

So the basic answer is the hack. I figured there would be a better way around that, but I guess I'll take what I can get.

Quote:

Original post by BigBadBob Removing the ability to do assignments in general would be a very bad thing

Removing the ability to do assignments in general would result in no functional code at all. But I don't plan to write copy functionality for objects that never need to be copied. And there are many, many types of objects in my project that do not need to be copied. Allowing use of the = operator on complex types, without writing copy functionality, means all of those objects just brake down and die violent fish out of the water deaths if the operator is mistakenly used.

Thanks for the help!

What the previous posters stated about making it private, and also not defining it, is very good advice.

Infact it is in one of the best C++ books to date.



Another thing you can do, to catch the error before the linker stage, and at compile time,

Just create a base class for the = and/or copy constructor, and make them private there, and then inherit from that class.

That will move the error up to compile time, instead of link time, which is allways good.

It's not really a hack. Declaring it private means you get a nice compiler error if outside code tries to use it; not implementing it means you get a linker error (not as nice, but the best you can really do) if inside code tries to use it. It's standard idiom, and if it really galls you, you can make use of boost::noncopyable, which wraps the process.

Quote:

Original post by Kest Removing the ability to do assignments in general would result in no functional code at all.

Ironically, no assignments would result in functional code (as opposed to imperative one).

Quote:

Original post by Kest So the basic answer is the hack. I figured there would be a better way around that, but I guess I'll take what I can get. Quote: Original post by BigBadBob Removing the ability to do assignments in general would be a very bad thing Removing the ability to do assignments in general would result in no functional code at all. But I don't plan to write copy functionality for objects that never need to be copied. And there are many, many types of objects in my project that do not need to be copied. Allowing use of the = operator on complex types, without writing copy functionality, means all of those objects just brake down and die violent fish out of the water deaths if the operator is mistakenly used. Thanks for the help!

You seem to have the wrong idea of things, but really, please do hear me out.
The whole point of operator = is that you can define it to correctly do a complete copy of your class objects data. This includes allocating new buffers for things and copying their contents across rather than doing what the default implementation does which is simply copy the pointer value.
It sounds to me very much like this is exactly what you want to do, i.e. define a proper assignment operator for those classes where the default assignment operator screws things up for you.

Here is an example of someone making this exact mistake. They do not define an operator = to actually copy the data, so things end up getting deleted multiple times.

It would be a good idea to read up on The rule ot three.

Also, here is an example of how to write a correct assignment operator.

Basicaly what it comes down to is that you can go ahead and write your copy functions, and then rename them as assignment operators instead and you're all done, and using proper C++ techniques![cool]

C++'s stream objects can't be assigned or copied. My thread objects can't be assigned or copied. Preventing said objects from being copied makes sense.

Quote:

Original post by Zahlman It's not really a hack. Declaring it private means you get a nice compiler error if outside code tries to use it; not implementing it means you get a linker error (not as nice, but the best you can really do) if inside code tries to use it. It's standard idiom, and if it really galls you, you can make use of boost::noncopyable, which wraps the process.

:)

I have nothing against hacks when no other options are available. But necessary hacks are still hacks. We need a bridge to fill a gap.

Quote:

Original post by iMalc You seem to have the wrong idea of things, but really, please do hear me out. The whole point of operator = is that you can define it to correctly do a complete copy of your class objects data. This includes allocating new buffers for things and copying their contents across rather than doing what the default implementation does which is simply copy the pointer value. It sounds to me very much like this is exactly what you want to do, i.e. define a proper assignment operator for those classes where the default assignment operator screws things up for you.

I know I could overload the = operator for every one of my classes in my project. I just don't want to. I have no need to do this. It would be a lot of work, and the functionality would never be used. There are very few classes that I can think of that need copy operations, and nearly all of those that do are generic behind-the-scene classes that I've already written the operators for. That means I need to define a heck of a lot of private operators for my hundreds of advanced objects. Not because I want extra functionality, but because I don't want to blow the world up by accidently using functionality that I never asked for? I'm not sure if I should even bother protecting myself in this situation.

You may be right. I may have an unusual state of mind regarding the function vs operator argument. I see operator = as an assignment operator, or a math operator. Not a 'duplicate this seriously complicated system' operator. So if an object is simple, such as a string or array, I would use an operator. But when I'm writing map based game objects, skinmeshes, or particle systems, I would rather write a function to copy it. Same functionality, more typing. It makes me happy and I don't see a down-side.

"We need a bridge to fill a gap."

Someone else mentioned it, but thats what boost::noncopyable is about. Just inherit from it and it adds clarity, and you don't have to go defining a load of functions you'll never use. I'm not sure if noncopyable is one of them, but plenty of parts of boost are to be added to c++, so that would be almost a "standard way" of doing it, and not a hack.