Abstraction concept problem?

[D_Drmmr]

Where did you get that from?

From the text I quoted.

I said that reference semantics is not outdated.

Didn't read that anywhere in your text.

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.

[tiliavirga]

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".

[superbonzo]

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 ?

[TheGreatCthulhu]

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.

[superbonzo]

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

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

[ahoodin]

Troll much?

[lucky6969b]

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.

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

[laserlight]

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.

[lucky6969b]

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

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

[superbonzo]

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 ).

[tiliavirga]

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.

[tiliavirga]

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.

[tiliavirga]

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

[D_Drmmr]

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.

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.

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.

[PredicateNormative]

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.