Learning C++ Over VB

[iago]

Storing Object relies on polymorphism.  Everything in the table is still its own object, but are stored as a superclass.

Generally, while programming anything real, anything in the list will be the same type of object, or a subclass of the same object (ie, cars/trucks/planes -> Vehicle).  One way to do this is to subclass Vector and redefine the constructor/add/remove methods, but that's ewwy.  It's easiest to just have a command saying what goes in, and if anything else is put in a ClassCastException is throws when it tries to read it.

And void* isn't the greatest for storing types, like, for instance, a std::string.  Treating objects as pointers in C++ gets messy, especially when they rely on operator overriding and other things.

At first, I didn't like Object either, but since I've been using it I've found it a lot nicer than templates.  If I had a sample handy, I'd post it.  Maybe I'll look for one tonight

[Adron]

Yes, an example would be nice. Show how you make a vector that can reference all your vehicles. I'll start by showing how to do it in C++:

Code Select Expand


typedef vector<Vehicle*> VehicleVector;

VehicleVector myvehicles;


[iago]

Well, not including the imports, I would do this:

Vector v = new Vector();

If you really wanted to be anal about it, you would have to do a wrapper, like

Code Select Expand

public class VehicleVector
{
 public VehicleVector( super(); }
 public void add(Object o)
 {
    if(o instanceof Vehicle == false)
        blowup;
    super.add(o);
  }
}

But, like I said, that's just a headache, the reason Object is there is to generically store everything.

[iago]

How about a hashtable/hashmap, though?  Here is the Java implementation:

Code Select Expand

Hashtable h = new Hashtable();
h.put("key1", "number1");
h.put("key2", someObject);
String a = (String)h.get("key1");
MyObject b = (MyObject) h.get("key2");

Note that if the programmer blows the object types, he will get a run-time exception.  


The other major difference I've found is in documentation.  I tried to use a std::StringBuffer (or whatever the name is) in c++ and got so many cryptic erros I went back to sprintf().  For java. I would just go to java.sun.com and look up the error, but generally the error itself will be clear enough to understand.

[Banana fanna fo fanna]

I think having a common base class + templates would be ideal.

Wait, that's Java 1.5

[Kp]

I think having a common base class + templates would be ideal.

As Adron remarked, I still don't see any place in real code where you actually benefit from having a universal base class, as opposed to deriving all the objects in the list from some custom base class.  Perhaps you could provide an example, since iago hasn't?

iago: the only advantage I can see to your sample code over equivalent C++ code using a void* type is that the program will automatically crash itself with a ClassCastException if you screw up.  This does not seem helpful to me.

[Eibro]

How about a hashtable/hashmap, though?  Here is the Java implementation:

Code Select Expand

Hashtable h = new Hashtable();
h.put("key1", "number1");
h.put("key2", someObject);
String a = (String)h.get("key1");
MyObject b = (MyObject) h.get("key2");

Note that if the programmer blows the object types, he will get a run-time exception.  


The other major difference I've found is in documentation.  I tried to use a std::StringBuffer (or whatever the name is) in c++ and got so many cryptic erros I went back to sprintf().  For java. I would just go to java.sun.com and look up the error, but generally the error itself will be clear enough to understand.

std::stringstream? You can find decent STL references if you look around: http://www.sgi.com/tech/stl/
Yes, the errors are slightly cryptic at first, but it usually tells you exactly what is wrong on the first line. For instance, VC7 will spit out ~10 lines of error message if you use an ::iterator instead of a ::const_iterator. They tell you exactly what went wrong, most of the crap it spits out can be ignored. If it's that much of a problem use something like STLfilt: http://www.bdsoft.com/tools/stlfilt.html to "decrypt" errors. The STL can be extremely ugly to work with; you need to be very judicious with typedefs.

[iago]

iago: the only advantage I can see to your sample code over equivalent C++ code using a void* type is that the program will automatically crash itself with a ClassCastException if you screw up.  This does not seem helpful to me.

Technically, it can also be caught and handled.

[Adron]

It sounds a bit like enabling RTTI in C++... What you're missing then is the ability to add an object such as an "int" and then later get type information for it. But I don't think that makes sense anyway because of the size of an int and the size of type information. And if you *really* want it, you can implement your own class "CInt", overloading the +, -, etc operators.

[iago]

It sounds a bit like enabling RTTI in C++... What you're missing then is the ability to add an object such as an "int" and then later get type information for it. But I don't think that makes sense anyway because of the size of an int and the size of type information. And if you *really* want it, you can implement your own class "CInt", overloading the +, -, etc operators.

You can get the type in Java with the .getClass() method.  You can also create a new instance of the object by calling .getClass().newInstance() or something along those lines.

[Skywing]

What kp said is completely right.  Another thing you should think about is Java, though:

*cons*
-It builds to larger files which run slower
-Some features are missing

*pros*
- Code ends up A LOT cleaner (compared to using the STL)
- TONS of built-in functionality
- Complete cross-platform (dont' have to recompile for different platforms)
- Full (superior) use of object oriented programming, and automatic pointers (all objects are pointers).

Having used Java and C++ with STL, I don't see how Java is so much cleaner looking than C++ code using STL.  In fact, I think code using STL looks much better, because you have to make lots of (unsafe) casts everywhere when using Java because instead of using something like templates, all the default Java containers use a class which is a base class of all other classes.

[Banana fanna fo fanna]

I think having a common base class + templates would be ideal.

As Adron remarked, I still don't see any place in real code where you actually benefit from having a universal base class, as opposed to deriving all the objects in the list from some custom base class.  Perhaps you could provide an example, since iago hasn't?

iago: the only advantage I can see to your sample code over equivalent C++ code using a void* type is that the program will automatically crash itself with a ClassCastException if you screw up.  This does not seem helpful to me.

.toString()

[Kp]

.toString()

toString returns essentially useless data from Object; therefore, any variable on which you would want to use toString is already known to have overridden it to behave in a useful fashion.  Thus, you know something about the type of the variable -- a universal base class is therefore not required.