Abstraction concept problem?

[OReubens]

If pointers are not recommended in most cases, how should I deal with the following situations?
1) when I need to pass another object at the constructor?
2) when I need to change the pointed object within another object?
3) when I want to avoid keeping a lot of instances of the same object by value?
In these cases, I do really need pointers
Thanks
Jack

1) use a (const) reference
2) use a non-const reference
3) use references, use a reference-counting reference wrapper or use a reference counted smart pointer (you seem to be unaware of actual ownership afterall), or you have a single strong pointer and lot of weak onces.
however, the real issue is probably more the "why do you need a lot of pointers/references to instances to the same object", the real 'magic' is probably about changing your design to avoid that particular 'necessity'.

[ahoodin]

But remember he did never discard pointers! They're live and well in both Java and C# only not in raw form but dressed up in a nice clothing.

A. Pointers don't wear clothes.

in other words, by banning pointers because they're unsafe you are opening the door for another equally severe or even worse safety issue - object slicing.

B. Nobody is talking about banning pointers or you didn't read. We are saying that they should only be used where necessary, not just because you can.

C. I can't think of anything else.. The guys got all the other points.

[2kaud]

Pointer historically means hardware address register. That's how pointers were viewed in C when it was introduced as a high-level assembly language in 1972, and that's how some C++ programmers still view pointers today, and that's a problem. Just listen to Stroustrup in The C++ Programming Language, fourth edition, page 19:

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

In other words: Don't be stuck in old thinking. Go for modern C++ 11.



Not at all. The number of C++ programmers who have never heard about the slicing problem are many, far too many.

But certainly, if you know about slicing then take proper steps to prevent it. In advice form: If an object should not be copyable then disable copying at the language level (deleting the copy constructor and copy assignment operator as you mention). If copies still are wanted supply a clone method. Especially to the OP who seems to be using Boost already: Consider boost::noncopyable for the polymorphic base classes.

This also raises an old issue that has been discussed in this forum previously - namely modern c++ teaching. IMO it still seems that in some (many?) cases c++ is taught as c plus classes with a bit of STL thrown in (cout/cin etc). Unfortunately, anyone can set themselves up as a c++ instructor and teach it how they want.

[OReubens]

IMO it still seems that in some (many?) cases c++ is taught as c plus classes with a bit of STL thrown in (cout/cin etc). Unfortunately, anyone can set themselves up as a c++ instructor and teach it how they want.

/agree

I'm in the process of teaching a number of very young kids (age 10 to 12) how to program in C++.

I'm having no problem at all getting them to create fun and interesting projects on a largely "by experiment" basis. And I'm doing this entirely without teaching them ANY of the 'old C' libraries or way of doing things and I haven't covered pointers. So it's very much possible to do so and get them to do fun and usefull projects (especially if you throw an easy to use graphics framework in there).

[tiliavirga]

I'm in the process of teaching a number of very young kids (age 10 to 12) how to program in C++.

C++ is a complex and powerful language and I'm not surprised you had to simplify it to teach it to kids (*). This may have worked for its intended purpose but it's the full C++ we are discussing here and not some detoxified subset suitable for child's play.

Your idea that pointers are evil and that the solution is to restrict C++ usage to value sematics is out of touch with modern C++. Reference sematics is live and kicking. See for example this excellent overview of modern C++,

https://msdn.microsoft.com/en-us/library/hh279654.aspx

The modern C++ approach best suited for the OP (assuming a polymorphic design with shared ownership objects) is to hold objects by shared_ptr (and to disable by-value copying of those objects). His urge to downcast is best countered by improved design skills.

and I haven't covered pointers

(*) If the pupose is to teach kids programming concepts (rather than language syntax) there must be better options than C++, musn't it?. Already Java and Python would be much easier to use and then there are special education languages available such as Logo. If the pupose on the other hand is to teach the kids how a computer works then I don't understand why you consider removal of the notion of an address to be such a bright idea? And also at the conceptual level the difference between value and identity is important and the sooner a kid gets it the better.

[lucky6969b]

Hello,
I also encounter one problem.
When I pass the variable by const &, I want to test if it is null.
But I can't be sure if the mesh is loaded successfully or not before the mesh is passed into the GameObject, so it can be null.
Is it still advisable to use const & in this case?
BTW:
when I did something like this, I get a double deletion of the shared pointers made by
make_shared...

m_WarehouseMesh.Load(m_pDevice, "data\\Warehouse.x");
boost::shared_ptr<CObject> warehouse(new CWarehouse());
g_Warehouse = boost::dynamic_pointer_cast<CWarehouse>(warehouse);
m_StaticObject.push_back(warehouse);
m_StaticObject[0]->Create(m_pDevice, boost::make_shared<CMesh>(m_WarehouseMesh), NULL);

Thanks
Jack

[laserlight]

When I pass the variable by const &, I want to test if it is null.

There is no such thing as a null reference in C++, so this cannot be done. However, there are a few options, e.g.,

• Pass a (smart) pointer instead.
• Define a "null state" for the object, then allow this state to be queried via the public interface.
• If it can be null because it is optional rather than because it is an error, then Boost.Optional might be appropriate.

[lucky6969b]

When I pass in a smart pointer to another function (created by boost::make_shared<CMesh>(m_WarehouseMesh)),
I get a double deletion, I think m_WarehouseMesh hasn't gone out of scope in CMyApp but inside
the gameobject class, I have shared the ownership of the pointer of m_WarehouseMesh with CMyApp
When the mesh pointer in GameObject gone out of scope, and probably where the main m_WarehouseMesh in the CMyApp class
gone out of scope, it has been deleted twice.
Thanks
Jack

[laserlight]

Why are you using make_shared in this case?

[lucky6969b]

Because I want to test inside the GameObject if the mesh has been loaded successfully or not

bool CObject::Create(LPDIRECT3DDEVICE9 pDevice, boost::shared_ptr<CMesh> pMesh, boost::shared_ptr<ObjMap> pObjMap, float fAnimSpeed)
{
	if(pMesh == NULL)
		return false;

[lucky6969b]

Okay, I think I should test the loading in the CMesh class and return a flag and test it outside

if (m_WarehouseMesh.Load(...)) {
    m_StaticObject->Create(...);
}

[laserlight]

Because I want to test inside the GameObject if the mesh has been loaded successfully or not

Well yeah, but consider: it seems from implied context that you already have a CMesh object named m_WarehouseMesh. Therefore, you do not need to make a shared_ptr to point to a copy of it, so make_shared is pointless.

Rather, your concern is that "can't be sure if the mesh is loaded successfully or not before the mesh is passed into the GameObject". This implies that in your CMesh Load member function, there must be some way to determine if the load was successful. If you do not throw an exception to indicate load failure, or return a boolean value or error code (which is what you did in the end as per post #26), then this should be part of the state of the CMesh, e.g., a boolean member variable indicating if the mesh has been loaded successfully.

Consequently, if you want to go with the "pass and check from within the function" route, a const reference parameter makes sense: you should then call a (member) function to check if the mesh has been loaded successfully.

[OReubens]

C++ is a complex and powerful language and I'm not surprised you had to simplify it to teach it to kids (*). This may have worked for its intended purpose but it's the full C++ we are discussing here and not some detoxified subset suitable for child's play.

I didn't simplify it. They're using pretty much everything the language has to offer, including stuff like templates, the standard library, lambda's etc. I simply removed the 'C' stuff because they don't need it.
So far they haven't had a use for pointers which is why I haven't covered it yet as I pointed out it's largely a 'learn by experiment' approach so I'm only covering material they're actually needing to solve a particular problem they encountered on their own. I'm just pointing out you can create real programs in C++ without using pointers directly (though there's pointers being used "behind the scenes" in the containers etc).

Your idea that pointers are evil and that the solution is to restrict C++ usage to value sematics is out of touch with modern C++. Reference sematics is live and kicking. See for example this excellent overview of modern C++,

https://msdn.microsoft.com/en-us/library/hh279654.aspx

This only agrees with my view, the "old style" C++ program with pointers gets changed to a modern design without.

And evil doesn't mean you can't use them. it's just typically better without.

If the pupose is to teach kids programming concepts (rather than language syntax) there must be better options than C++, musn't it?

maybe, what makes python or java better ? I'm obviously managing to achieve what I set out to do, so why would that make C++ a bad choice?
Logo is entirely pointless for anything realistic. I did try this approach and found the kids lost interest in it as soon as they figured out the language was restricted to just drawing some lines and basically didn't allow any form of interaction.
The graphics framework they can use now, can do 'logo lines' too, but it also caters to ellipses, arcs, text, bitmaps, (though they haven't used all of it yet) etc.. and allows interaction.

[D_Drmmr]

Your idea that pointers are evil and that the solution is to restrict C++ usage to value semantics is out of touch with modern C++. Reference semantics is live and kicking.

I find your suggestion that value semantics are outdated and reference semantics are modern out of touch with modern programming. Reference semantics are much harder to reason about than value semantics, especially in a multi-threaded context. Value semantics allow you to reason about your program locally, because the number of places in your code where a certain value that you use can be changed is limited. With reference semantics, it is much harder to prevent local changes from having effects on large parts of your program.

C++11 has introduced move semantics, which has lowered the price you pay for passing by value considerably (if done right). Mostly, you don't even need to do anything special to harness this power, except not pessimize prematurely.

[tiliavirga]

I find your suggestion that value semantics are outdated and reference semantics are modern out of touch with modern programming.

Where did you get that from?

I said that reference semantics is not outdated. People should stop crying "pointers are evil" and start learning modern C++.