Hello
In case I have:
Where should I derive from boost::noncopyable?Code:class someclass : public derived { public: };
Should I do this:
Thanks for helpCode:class someclass : public derived, private boost::noncopyable { public: };
Hello
In case I have:
Where should I derive from boost::noncopyable?Code:class someclass : public derived { public: };
Should I do this:
Thanks for helpCode:class someclass : public derived, private boost::noncopyable { public: };
/me shakes his head in disbelief.
No you shouldn't do that.
Whats the right way then?
Why don't you make the base class itself noncopyable?
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.
I'm using exactly the version from his first post in my software
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.
Originally Posted by brewbuck:
Reimplementing a large system in another language to get a 25% performance boost is nonsense. It would be cheaper to just get a computer which is 25% faster.
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.
All the buzzt!
CornedBee
"There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
- Flon's Law
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.
The aim is to write good code.Besides it avoids inheritance... I hear it is always the aim when possible.
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.
Originally Posted by brewbuck:
Reimplementing a large system in another language to get a 25% performance boost is nonsense. It would be cheaper to just get a computer which is 25% faster.
Uh, why are you better off that way? You've just duplicated functionality.
All the buzzt!
CornedBee
"There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
- Flon's Law
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...
Originally Posted by brewbuck:
Reimplementing a large system in another language to get a 25% performance boost is nonsense. It would be cheaper to just get a computer which is 25% faster.
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:
(assuming importing of noncopyable, of course) is far cleaner, clearer and more concise than this:Code:class foo : noncopyable { ... };
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.Code:class foo { foo(const foo &); // Don't implement. foo &operator =(const foo &); // Don't implement. };
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.
All the buzzt!
CornedBee
"There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
- Flon's Law