boost::noncopyable

[l2u]

Hello

In case I have:

class someclass : public derived {
public:
};

Where should I derive from boost::noncopyable?

Should I do this:

class someclass : public derived, private boost::noncopyable {
public:
};

Thanks for help

[MacGyver]

/me shakes his head in disbelief.

No you shouldn't do that.

[l2u]

Whats the right way then?

[cpjust]

Why don't you make the base class itself noncopyable?

[brewbuck]

Why don't you make the base class itself noncopyable?

What if he doesn't want to? He's got a class B, which derives from A. He wants B to be non-copyable. What's wrong with that?

As far as I can tell, what he originally wrote is just fine.

[MacGyver]

Wait....

/me reads original post again.

Bleh, ok I change my verdict. That can work. I just can't read today. Apologies. I'm going to go sit in the corner and beat myself with the keyboard.

[pheres]

I'm using exactly the version from his first post in my software

[Mario F.]

You can also simply declare a private copy constructor and assignment operator and not define them (in case you later want to derive from your class).

As much as I like boost, I never really saw the point of noncopyable. It is clearer to the class user sure. But really... the previous method is not ugly either (and all but the laziest programmer should read any class documentation anyways). Besides it avoids inheritance... I hear it is always the aim when possible.

[CornedBee]

noncopyable is clearer and shorter than doing the hiding yourself, without any disadvantages I can see. Avoiding inheritance from an empty class is a non-goal, as it shouldn't add any sort of overhead in any way.

[brewbuck]

As much as I like boost, I never really saw the point of noncopyable. It is clearer to the class user sure. But really... the previous method is not ugly either

You mean "identical." This exactly what noncopyable does. If you have already decided to use Boost, there's no excuse to NOT use features like this when you need them.

Besides it avoids inheritance... I hear it is always the aim when possible.

The aim is to write good code.

[Mario F.]

I guess you guys are probably right. However...

> If you have already decided to use Boost, there's no excuse to NOT use features like this when you need them.

If I need to ask how to use boost::noncopyable, I probably didn't fully understand yet about the copy constructor and assignment operators as well as inheritance and whatever more. In that context I'm probably better not using libraries that speed up my code but first get used to the rules of the game.

In a similar note, noncopyable describes, I think, an idiom. I'm better off not using boost::noncopyable and instead create my own noncopyable class if I want to share my code with other users.

[CornedBee]

Uh, why are you better off that way? You've just duplicated functionality.

[Mario F.]

If I'm using other boost functionality, yes. Otherwise, why should I create a library dependency? Granted, I can always copy the headers to the project file.

I don't know CornedBee, I'm failing to make my point across. Probably because I don't have a good point anyways. I just think that (and this because I did this very mistake) most of us learning the language look at boost as a quicker way to achieve results. This is a mistake, I reckon. That is how you and many other seasoned programmers should look at it. For the rest of us, other than those parts of boost that implement new functionality not easily made available by the language, things like noncopyable are better of forgotten for now untill we grasp the language concepts. Or better yet, studied...

There's nothing in the original post that tells me he wasn't doing that though...

[CornedBee]

I disagree, particularly in the case of noncopyable.

The way to make an object noncopyable is to declare its copy constructor and assignment operator private and not implement them. Why? This is, actually, rather non-intuitive. It's nearly a hack, because the language doesn't have a simple, clear feature that says: don't copy this. It's an implementation trick.
I see absolutely nothing wrong with hiding implementation tricks in libraries, even if you don't understand how the trick works.

I also think that the most important teaching goal must be to teach writing clear, concise code. Language features are a minor point, programming concepts are important, but not that hard to learn. But clear code is something that must be made a habit, and it must be made a habit before other habits can form.
In the tutorial I'm writing, I'm teaching functions before even if-statements. Why? Because the structuring of code is, in my opinion, a habit a newbie should get into before being able to write spaghetti programs.

My point is, having a class definition that looks like:

class foo : noncopyable { ... };

(assuming importing of noncopyable, of course) is far cleaner, clearer and more concise than this:

class foo
{
  foo(const foo &); // Don't implement.
  foo &operator =(const foo &); // Don't implement.
};

And because of what I've said above, cleaner, clearer and more concise are worthy goals even if you don't understand the mechanism behind it, even if you're a newbie.

There's another lesson here: focus on the lesson at hand. If you want to learn a specific feature of the language and write a program to learn it, I think it's a bad idea if you let yourself be sidetracked by other things. If your learning program requires something to be noncopyable, use boost::noncopyable. If you want, you can come back later and learn how the trick works. For now, focus on what you set out to learn in the first place.

[brewbuck]

If I'm using other boost functionality, yes. Otherwise, why should I create a library dependency?

I don't think anybody is suggesting that you introduce a dependency on Boost just to use boost::noncopyable and nothing else. If you've got Boost, you'll be using many other features besides just that one.