3 ms·
Most of the C stuff here is pretty good, but some of the C++ information is a little questionable. Even the "good programmer" exhibits a few common misconcepti
by Suncho 13y ago
Most of the C stuff here is pretty good, but some of the C++ information is a little questionable. Even the "good programmer" exhibits a few common misconceptions about inheritance and virtual destructors. Here's the text from slide 348:
"What is the point of having a virtual destructor on a class like this? There are no virtual functions so it does not make sense to inherit from it. I know that there are programmers who do inherit from non-virtual classes, but I suspect they have misunderstood a key concept of object orientation. I suggest you remove the virtual specifier from the destructor, it indicates that the class is designed to be used as a base class - while it obviously is not."
She's right that the class described on the slide probably shouldn't have a virtual destructor.
A base class should have a virtual destructor if and only if objects of its derived class are to be deleted through base class pointers.
The following four statements are wrong:
1. A class with other virtual functions should have a virtual destructor.
2. A class without other virtual functions should not have a virtual destructor.
3. A class designed to be a base class should have a virtual destructor.
4. You shouldn't inherit from classes that don't have virtual functions.
It's a narrow-minded to say that programmers who inherit from "non-virtual" classes have "misunderstood a key concept of object orientation." Which key concept is that, by the way? Object orientation isn't the be all and end all of C++. There are reasons to use inheritance that have nothing to do with run-time polymorphism. Maybe you just want to reduce redundancy and organize your data types in terms of each other.
Another gripe is that on slide 369, she says:
"When I see bald pointers in C++ it is usually a bad sign."
Naked pointers should usually be avoided for memory management. That's true. But they make great iterators, and they're useful, along with references, for passing objects to functions.
On the other hand, seeing the keywords "new" and "delete" in code is usually a bad sign. Resources (not just memory) should be managed by resource management classes. If you try to do it manually, especially in the presence of exceptions and concurrency, it's very easy to cause an inadvertent resource leak.
- NAFV_P 13y ago"On the other hand, seeing the keywords "new" and "delete" in code is usually a bad sign." I thought those two keywords were intended to replace the basic memory allocation functions found in stdlib.h. What are the alternatives?
- boryas 13y agomake_shared and make_unique http://herbsutter.com/gotw/_102/ http://herbsutter.com/gotw/_102/
- Suncho 13y agoAs other folks have mentioned, unique_ptr, make_unique, and all their happy friends are there if you need them. But your variables/objects should go on the stack unless you have a reason not to put them there. As the slide suggests, if you need a lot of stuff on the heap, a standard std::vector will often do. In C, it can be tricky to ensure that every malloc has a matching free and every fopen has a matching fclose etc. This style of resource management is error-prone, but it comes with the C territory. Java throws its hands up in the air in disgust and basically accepts that you will generate a lot of garbage. Then it slaps a mandatory garbage collector on top to clean everything up, which I guess is an okay way to deal with memory, but it sucks for other resources that aren't managed by the garbage collector. C++, on the other hand, makes it easy to write garbage-free code. But it's only easy if you avoid using new or similar functions that allocate resources such as file descriptors, locks, network sockets etc. If you see people using "new", there's a good chance they're misguided C or Java programmers. C programmers often think they should use new/delete as often as they used malloc/free in C. Java programmers sometimes try to use new every time they instantiate an object. Java did steal the new keyword from C++, and it's perfectly normal for Java code to be riddled with new's because there's no other way to do it in Java. But these styles lead to disaster in C++.
- hackinthebochs 13y agoWhat would a resource management class look like?
- reverius42 13y agoIt has a constructor (to initialize the resource), a destructor (to release the resource), copy/move constructors, and lets you get access to the underlying resource. See http://en.cppreference.com/w/cpp/memory/shared_ptr http://en.cppreference.com/w/cpp/memory/shared_ptr for an example.