Re: Silly C++ OOP question

On 2 Mrz., 14:19, Spaceman Spiff <sardonicstuffedti...@gmail.com>
wrote:


Lots of problems:
- CPP files don't need "include guards" because...
- CPP files are not included (!)
- I hope you realize that this example doesn't represent
   an appropriate use of polymorphic classes.
- Your polymorphic base class lacks a virtual destructor and yet you
   try to delete a derived object through a base pointer. This is
   illegal.
- Your polymorphic class should be abstract (see also "pure virtual
   functions").
- You should check out how to properly initialize the object's
   members. There's a special syntax for it which you should prefer.
   Sometimes, you don't even have a choice (when a member can't be
   default-constructed).
- Your toString interface/function is a bad choice/buggy. You're
   returning a dangling pointer, a pointer that is invalid. Let me
   quote it:


This should be

      virtual std::string toString() const {
         std::stringstream ss;
         ss << this->getHour() << ":" << this->getMinute()
            << ":" << this->getSecond();
         return ss.str();
      }

The problem with your version is that ss.str() results in *short-
lived* std::string object that is destructed again after the complete
evaluation of the expression has finished. You return a pointer that
points into some buffer that is managed by the temporary std::string
object. The std::string object dies. The pointer "dangles". Any access
is formally UB (undefined behaviour).

It's obvious that you are used to a Java-programming style and that
you try to emulate this style in C++. That's generally a bad approach.

Try to understand how separate compilation works, what #include
exactly does. Learn the terminology ("translation unit", ...).

Try to avoid large hirachies of polymorphic classes. Polymorphic
classes have their use but Java developers that migrate to C++ tend to
overuse this feature (in my experience). Runtime polymorphism is one
of the few abstraction mechanisms that are available to Java
programmers. C++ offers some other nice features that are sometimes
more appropriate.

Learn about destructors. Appreciate them. It may not be obvious first,
but they can be very useful when it comes to managing "internal
details". For example, std::string manages its own dynamically
allocated buffer but you can use it like any other data (int, double,
etc). You can add std::string as *real* data member to a class without
having to worry about memory management. Prefer "real members" over
pointers to "logical members" when possible. Also, prefer aggregation
over inheritance. Don't inherit from std::string, or std::vector or
something like that. There's little excuse to do that. Just like you
can store ints and doubles on the stack you can create most class-type
objects on the stack, too. Such objects have an "automatic life-time".
That's a good thing (tm). Exploit it when it makes sense. One of C++'s
goals is to minimize the differences bewteen in-built types and user-
defined types.

Every time you deal with pointers, references and iterators you have
to make sure that they are valid before you use them. Java protects
you from "dangling pointers" by restricting the set of things you can
refer to (only dynamically allocated objects) and deletes "pointees"
automatically only in case they cannot be reached anymore -- but not
earlier.

Avoid implementing member functions directly in classes. You usually
write a class definition that contains more function *declarations*
than *definitions* in header files. By implementing them inside a
class definition you make the functions implicitly inline which has
important implications. Understand them.


Yes, that's because you declared functions in acme::Time but didn't
define them. Make your functions _pure_ virtual. The syntax for that
is:

         class Time {
           public:
             virtual ~Time(){}
             virtual int getHour() const =0;
             virtual int getMinute() const =0;
             virtual int getSecond() const =0;
         ...


Alternativly you could try to get hold of one of the C++ books that
are often recommended.

Cheers,
SG

--
      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated. First time posters: Do this! ]