CodeGuru Home VC++ / MFC / C++ .NET / C# Visual Basic VB Forums Developer.com
Page 3 of 5 FirstFirst 12345 LastLast
Results 31 to 45 of 64

Thread: Abstraction concept problem?

  1. #31
    Join Date
    Jul 2005
    Location
    Netherlands
    Posts
    2,042

    Re: Abstraction concept problem?

    Quote Originally Posted by tiliavirga View Post
    Where did you get that from?
    From the text I quoted.
    Quote Originally Posted by tiliavirga View Post
    I said that reference semantics is not outdated.
    Didn't read that anywhere in your text.
    Quote Originally Posted by tiliavirga View Post
    People should stop crying "pointers are evil" and start learning modern C++.
    I agree that the focus on the use of pointers is misleading. It is not pointers that are evil, but they can be a sign of many other issues. Better to focus on those actual issues.
    Cheers, D Drmmr

    Please put [code][/code] tags around your code to preserve indentation and make it more readable.

    As long as man ascribes to himself what is merely a posibility, he will not work for the attainment of it. - P. D. Ouspensky

  2. #32
    Join Date
    Jun 2015
    Posts
    208

    Re: Abstraction concept problem?

    Quote Originally Posted by D_Drmmr View Post
    From the text I quoted.
    If you read that quote more carefully you'll certainly notice that I didn't say that value semantics is outdated. I said that the "idea that pointers are evil and that the solution is to restrict C++ usage to value semantics" is outdated.

    Didn't read that anywhere in your text.
    Strange because that's been my point and theme of almost all my posts in this thread:

    The deep-rooted notion that pointers are evil has become outdated in modern C++.

    I agree that the focus on the use of pointers is misleading. It is not pointers that are evil, but they can be a sign of many other issues. Better to focus on those actual issues.
    Even better than dwelling on issues of the past is it to focus on the solutions modern C++ offers. And that is to prefer pointer abstractions over raw pointers. It is to use smart pointers, iterators and implicit iteration constructs.

    Value and reference semantics are complementary in modern C++. None is more evil than the other. None should be avoided more than the other. If you're not convinced I suggest you have a hard look at yourself because maybe it's you who Stroustrup is alluding to here,

    "Often, what an experienced C++ programmer has failed to notice over the years is not the introduction of new features as such, but rather the changes in relationship between features that make fundamental new programming techniques feasible".
    Last edited by tiliavirga; July 9th, 2015 at 09:42 AM.

  3. #33
    Join Date
    Oct 2008
    Posts
    1,456

    Re: Abstraction concept problem?

    Quote Originally Posted by tiliavirga View Post
    Value and reference semantics are complementary in modern C++. None is more evil than the other. None should be avoided more than the other.
    Congratulations!!! You've just won the Dogmatic Statement of the Month competition. ( July edition )

    >> None is more evil than the other

    this is hardly believable; references carry more responsabilities than the value they refer to ( you don't know who the reference refers to ), and pointers carry more responsabilities than references ( (smart) pointers have ownership; a pointer can point to nothing, even in a legal program; ... ).

    This adds a complexity cost and nothing can change this fact. Of course, this cost can be fair or even a great deal whenever those added responsabilities you paid for are used for something good.

    The evilness of pointers stands still though, because inexperienced programmers tend to pay this cost in exchange for nothing, as this very thread shows, resulting in bulimic base classes, downcasts, untestable spaghetti, ...

    for example, suppose we asked the OP to write classes modeling trains, made of locomotives and wagons; I could bet he'd think "hey, wagons can be linked to other wagons and a pair of locomotives, let's use (smart)pointers to model the links and add em' to the train instance ..." whoa, can you see where this will end ?

  4. #34
    Join Date
    Jan 2010
    Posts
    1,133

    Re: Abstraction concept problem?

    Seems like you guys are talking about two different things here, while calling it the same name.

    Value vs reference semantics is one thing - a concept that is related to the character, and the notion of identity, of objects. The C++ specific language constructs of values, references, pointers, and others that are built from those, are a separate thing - although there is, admittedly, a relationship between the two when it comes to representing/implementing the aforementioned concept in code (but that need not be the case).

    On a higher, conceptual level, in the context of OOP - there's nothing wrong with saying that "value and reference semantics are complementary [... and that ...] none should be avoided more than the other." From the design perspective, there are certainly use cases for both.

    When it comes to a concrete implementation in C++, however, your points about added dangers and complexities stand, and that may in turn result in a certain bias design-wise, but only in the sense that, because of these details of the implementation language, the design should be more judiciously constructed.

    So, while C++ pointers may be "evil", that's not necessarily true for the notion of reference semantics.
    Last edited by TheGreatCthulhu; July 9th, 2015 at 02:20 PM.

  5. #35
    Join Date
    Oct 2008
    Posts
    1,456

    Re: Abstraction concept problem?

    Quote Originally Posted by TheGreatCthulhu View Post
    Seems like you guys are talking about two different things here, while calling it the same name.
    yep, the original discussion ( and my reply ) was about pointers rather than reference semantics, it looks like tilavirga uses the two interchangeably ...

    anyway

    Quote Originally Posted by TheGreatCthulhu View Post
    When it comes to a concrete implementation in C++, however, your points about added dangers and complexities stand, and that may in turn result in a certain bias design-wise, but only in the sense that, because of these details of the implementation language, the design should be more judiciously constructed.

    So, while C++ pointers may be "evil", that's not necessarily true for the notion of reference semantics.
    I disagree, for two reasons

    first, even at a higher level reference semantics carry more responsability on a variable name than value semantics, for the aformentioned reasons: tell me, who would you trust more, some person you talk eye to eye ( a value ) or a name on an address book ( a reference ) ?
    of course, I stress again, this adds complexity locally to where the object is "used", it's a local cost that may pay off globally, resulting in a lower global complexity ( eg, it's simpler to sort an address book rather than physically collecting and sorting real persons, isn't it ? )

    second, the design bias you mentioned is not just an artifact of reference implementations; reference semantics naturally lands itself to represent "weak relations" ( like the "wagon links" in my "train" example above ) and people do all sorts of sins in order to enforce such relations in terms of their preferred "references" implementation ( be it (smart)pointers or something else ), again, take a look at the OP

    that said, I'd never claim that reference semantics is evil ( but it may be when implemented in terms of things as dumb pointers, or improperly used smart pointers ), but yes, I do believe reference semantics requires more care even at a conceptual design level
    Last edited by superbonzo; July 10th, 2015 at 02:38 AM. Reason: typos

  6. #36
    Join Date
    Mar 2001
    Posts
    2,527

    Re: Abstraction concept problem?

    Troll much?
    ahoodin
    To keep the plot moving, that's why.

  7. #37
    Join Date
    Dec 2010
    Posts
    907

    Re: Abstraction concept problem?

    In regard to the pointer stuff,
    I wonder when I pass the reference as an argument to the constructor of another class and retain a copy.
    It would take up a huge number of space in memory if B was big.

    Code:
    class A {
    public:
        A(const B& _b) : b(_b) { }
      
    private:
       B b;
    };

  8. #38
    Join Date
    Jan 2006
    Location
    Singapore
    Posts
    6,768

    Re: Abstraction concept problem?

    Quote Originally Posted by lucky6969b
    I wonder when I pass the reference as an argument to the constructor of another class and retain a copy.
    It would take up a huge number of space in memory if B was big.
    You retain a copy, so of course there is a price to be paid for making and storing a copy.
    C + C++ Compiler: MinGW port of GCC
    Build + Version Control System: SCons + Bazaar

    Look up a C/C++ Reference and learn How To Ask Questions The Smart Way
    Kindly rate my posts if you found them useful

  9. #39
    Join Date
    Dec 2010
    Posts
    907

    Re: Abstraction concept problem?

    But I just can't simply store a reference handle in the class like this

    Code:
    class A {
    public:
        A(const B& _b) : b(_b) { }
      
    private:
       B& b;
    };

  10. #40
    Join Date
    Oct 2008
    Posts
    1,456

    Re: Abstraction concept problem?

    Quote Originally Posted by lucky6969b View Post
    But I just can't simply store a reference handle in the class like this
    sure you can ( of course, your example won't compile because you can not bind a const reference to a non-const reference ) with the caveat that either A or A's users must ensure that any access to 'b' does not exceed '_b' lifetime.

    That said, you should not think in terms of what you can/cannot technically do, but the other way around. First, you ask yourself what an interface is supposed to mean, then you choose the most complete, efficient(*) technical solution with the smallest responsibility (*, but, excluding trivial cases, don't assume something is in/efficient, measure it ).
    Last edited by superbonzo; July 12th, 2015 at 10:18 AM. Reason: typos

  11. #41
    Join Date
    Jun 2015
    Posts
    208

    Re: Abstraction concept problem?

    Quote Originally Posted by lucky6969b View Post
    I wonder when I pass the reference as an argument to the constructor of another class and retain a copy.
    It would take up a huge number of space in memory if B was big.
    And not only that, the B object may be sliced in the copying process resulting in a bug (if the passed-in B object is in fact a derived child of B).

    Now for the umpteenth and last time. Do the right thing and handle your shared-ownership polymorphic objects by shared_ptr. And as a security measure, disable copying of the objects.

  12. #42
    Join Date
    Jun 2015
    Posts
    208

    Re: Abstraction concept problem?

    Quote Originally Posted by TheGreatCthulhu View Post
    So, while C++ pointers may be "evil", that's not necessarily true for the notion of reference semantics.
    That's right, but there is also the notion of a pointer. There is always a pointer, implicit or explicit, involved in reference semantics. Pointers and reference semantics are inseparable.

    In most languages, including Java and Python, objects have reference semantics by language design and the pointer is implicit. In C++ on the other hand reference semantics for objects must be simulated using an explicit pointer.

    So what's evil in the above situation? Well, according to the inventors of Java some 20 years ago the culprit is the C++ pointer. It is too easy to corrupt and doesn't automatically manage object memory. And that still is true for raw pointers but modern C++ 11 offers a better pointer, namely the smart pointer.

    In my view the introduction of smart pointers in C++ is a game changer. It's a benign pointer in the best tradition of the RAII idiom. And interestingly the new Apple language Swift has taken the same approach.
    Last edited by tiliavirga; July 13th, 2015 at 12:42 AM.

  13. #43
    Join Date
    Jun 2015
    Posts
    208

    Re: Abstraction concept problem?

    Quote Originally Posted by superbonzo View Post
    The evilness of pointers stands still though, because inexperienced programmers tend to pay this cost in exchange for nothing, as this very thread shows, resulting in bulimic base classes, downcasts, untestable spaghetti, ...
    You can hardly blame pointers for the lack of design & programming skills among C++ programmers.

    And even if you do the best medicine is not to dwelve on old C++ but to embrace modern C++ 11. It offers lots of safe and secure features suitable for less experienced programmers. Or use another language if you don't trust people to be able to learn and use modern C++.

    The "pointers are evil" dogma is an extreme position not shared by the best and brightest among language designers. They didn't abandon pointers when they had the chance. D even reinvented the raw C pointer. But most languages followed Java and domesticated the pointer and that's what C++ now finally has done too with version 11. Instead of raw pointers prefer pointer abstractions (such as smart pointers, iterators and implicit iteration constructs).

    Among languages C++ is something of an oddball because it has value types only and reference types must be simulated. But that doesn't mean reference types are evil and should be avoided. At least that's not the moderate mainstream position,

    https://msdn.microsoft.com/en-us/library/hh279654.aspx
    Last edited by tiliavirga; July 13th, 2015 at 01:18 AM.

  14. #44
    Join Date
    Jul 2005
    Location
    Netherlands
    Posts
    2,042

    Re: Abstraction concept problem?

    Quote Originally Posted by tiliavirga View Post
    And not only that, the B object may be sliced in the copying process resulting in a bug (if the passed-in B object is in fact a derived child of B).

    Now for the umpteenth and last time. Do the right thing and handle your shared-ownership polymorphic objects by shared_ptr. And as a security measure, disable copying of the objects.
    Slicing is only a problem is B is designed as a polymorphic base class. If that's the case, you should take either a (const) reference or (smart-)pointer to an abstract base class. You cannot store an instance of an abstract class, so you don't have the option to pass by value (and there is no need to disable copying in derived classes).

    If you have the choice to store either a copy or a (const) reference to an instance of B, that should imply that B is not designed as a polymorphic base class (i.e. it has no virtual functions) and slicing is not an issue. The choice is then whether you want to keep a copy that you can do anything you want with, or whether you want to keep a const reference and (manually) assure the passed-in object outlives the object that keeps the reference.

    Avoiding the issue of managing the lifetime of objects by storing a shared_ptr rather than a copy or const reference is a bad idea, because it does not address the design issue. The fact that a shared_ptr helps you prevent having a dangling reference does not imply that introducing shared_ptrs makes your code behave as it should. That's not to say that storing a shared_ptr should always be avoided; it can be the best design choice. But it shouldn't be your default choice, not even for runtime-polymorphic objects.
    Quote Originally Posted by tiliavirga View Post
    That's right, but there is also the notion of a pointer. There is always a pointer, implicit or explicit, involved in reference semantics. Pointers and reference semantics are inseparable.
    I find that this confuses the discussion. There are issues with using reference semantics that are unrelated to the way it's implemented. These are design issues. And there are issues with doing manual memory management, using pointers to the first element in an array and using pointers where references suffice that can be addressed in C++ without changing the design of you program in any way.
    Quote Originally Posted by tiliavirga View Post
    In my view the introduction of smart pointers in C++ is a game changer. It's a benign pointer in the best tradition of the RAII idiom. And interestingly the new Apple language Swift has taken the same approach.
    I don't understand how the introduction of smart pointers can be a game changer, because it's a pure library construct meaning you could do this already in C++98 (except unique_ptr being move-only, but even that can be emulated in C++98). OTOH the introduction of move-semantics in C++11 has made it possible to use value-semantics without paying the costs of unnecessary copies of objects. That's the game changer if you ask me.
    Cheers, D Drmmr

    Please put [code][/code] tags around your code to preserve indentation and make it more readable.

    As long as man ascribes to himself what is merely a posibility, he will not work for the attainment of it. - P. D. Ouspensky

  15. #45
    Join Date
    May 2007
    Location
    Scotland
    Posts
    1,164

    Re: Abstraction concept problem?

    I’ve been really enjoying this thread and if it was going faster, I might even have got some popcorn for the show.

    All joking aside, tiliavirga you seem to be using a different set of definitions than are most commonly held and consequently there is a lot more arguing in this thread than is really necessary.

    In general on this C++ forum (and any other that I’ve been on for that matter), when talking about values we have value semantics in mind, when talking about references we have reference semantics in mind and when talking about pointers we have in mind a special object type that is copied by value but partially simulates reference semantics.

    You tend to be talking about the above with respect to your under-the-hood understanding of the implementation of C++. But this perspective is not portable and is only going to cause you the communication issues that you are already experiencing in this thread.

    You might find it more helpful to use the same definitions that others on this forum are using; i.e. the language independent definitions derived from “pass by value” and “pass by reference” semantics - with the understanding that pointers fall under the category of pass by value. If you follow this definition then you will not incorrectly lump pointers and references together under the umbrella of the term "pointers" – pointers and references semantically different. Really, when it comes down to it, semantically, a reference should not be thought of as an object, but as an alias regardless of how a particular language implements it (a pointer on the other hand should be thought of as an object in its own right).

    At the end of the day, you are correct that C++ under the hood implements references in terms of pointers, but you shouldn’t think of references this way – that is a language implementation detail. What you should be doing is thinking of references in terms of reference semantics and should not lump them together with pointers. C++ does a pretty good job of implementing reference semantics in that any operation that can be performed directly on a reference actually happens to the referenced object.

    Finally, when people say “pointers are evil”, you have to remember that these statements originated before the creation of the recent smart pointers in the C++ language (auto_ptr excluded – they really are evil). Thus statements like “pointers are evil” refer to raw pointers (e.g. int* ptr) as inherited from C, not smart pointers, and certainly not references. As others have stated, that does not mean that raw pointers shouldn’t be used, but raw pointers should only be used when necessary – references or smart pointers should be preferred.

    Now, if you re-read the previous posts that others have written with the view point that I’ve outlined in this post, then you’ll realise that the views of others and your own views are not as far separated as you thought.
    Last edited by PredicateNormative; July 13th, 2015 at 12:11 PM.

Page 3 of 5 FirstFirst 12345 LastLast

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  


Windows Mobile Development Center


Click Here to Expand Forum to Full Width




On-Demand Webinars (sponsored)