boost::noncopyable

This is a discussion on boost::noncopyable within the C++ Programming forums, part of the General Programming Boards category; Hello In case I have: Code: class someclass : public derived { public: }; Where should I derive from boost::noncopyable? ...

  1. #1
    l2u
    l2u is offline
    Registered User
    Join Date
    May 2006
    Posts
    630

    boost::noncopyable

    Hello

    In case I have:

    Code:
    class someclass : public derived {
    public:
    };
    Where should I derive from boost::noncopyable?

    Should I do this:

    Code:
    class someclass : public derived, private boost::noncopyable {
    public:
    };
    Thanks for help

  2. #2
    Deathray Engineer MacGyver's Avatar
    Join Date
    Mar 2007
    Posts
    3,211
    /me shakes his head in disbelief.

    No you shouldn't do that.

  3. #3
    l2u
    l2u is offline
    Registered User
    Join Date
    May 2006
    Posts
    630
    Whats the right way then?

  4. #4
    and the hat of sweating
    Join Date
    Aug 2007
    Location
    Toronto, ON
    Posts
    3,545
    Why don't you make the base class itself noncopyable?

  5. #5
    Captain Crash brewbuck's Avatar
    Join Date
    Mar 2007
    Location
    Portland, OR
    Posts
    7,274
    Quote Originally Posted by cpjust View Post
    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.

  6. #6
    Deathray Engineer MacGyver's Avatar
    Join Date
    Mar 2007
    Posts
    3,211
    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.

  7. #7
    Registered User
    Join Date
    Nov 2006
    Posts
    519
    I'm using exactly the version from his first post in my software

  8. #8
    (?<!re)tired Mario F.'s Avatar
    Join Date
    May 2006
    Location
    Portugal
    Posts
    7,581
    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.
    The programmer’s wife tells him: “Run to the store and pick up a loaf of bread. If they have eggs, get a dozen.”
    The programmer comes home with 12 loaves of bread.


    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.

  9. #9
    Cat without Hat CornedBee's Avatar
    Join Date
    Apr 2003
    Posts
    8,893
    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

  10. #10
    Captain Crash brewbuck's Avatar
    Join Date
    Mar 2007
    Location
    Portland, OR
    Posts
    7,274
    Quote Originally Posted by Mario F. View Post
    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.

  11. #11
    (?<!re)tired Mario F.'s Avatar
    Join Date
    May 2006
    Location
    Portugal
    Posts
    7,581
    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.
    The programmer’s wife tells him: “Run to the store and pick up a loaf of bread. If they have eggs, get a dozen.”
    The programmer comes home with 12 loaves of bread.


    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.

  12. #12
    Cat without Hat CornedBee's Avatar
    Join Date
    Apr 2003
    Posts
    8,893
    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

  13. #13
    (?<!re)tired Mario F.'s Avatar
    Join Date
    May 2006
    Location
    Portugal
    Posts
    7,581
    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...
    The programmer’s wife tells him: “Run to the store and pick up a loaf of bread. If they have eggs, get a dozen.”
    The programmer comes home with 12 loaves of bread.


    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.

  14. #14
    Cat without Hat CornedBee's Avatar
    Join Date
    Apr 2003
    Posts
    8,893
    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:
    Code:
    class foo : noncopyable { ... };
    (assuming importing of noncopyable, of course) is far cleaner, clearer and more concise than this:
    Code:
    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.
    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

  15. #15
    Captain Crash brewbuck's Avatar
    Join Date
    Mar 2007
    Location
    Portland, OR
    Posts
    7,274
    Quote Originally Posted by Mario F. View Post
    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.

Popular pages Recent additions subscribe to a feed

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21