4 ms·
> problems with mixed collection types I don't understand. C++ has exactly the same model for collections of polymorphic types. But you can also pursue data or
by rubashov 15y ago
> problems with mixed collection types
I don't understand. C++ has exactly the same model for collections of polymorphic types. But you can also pursue data oriented designs that aren't feasible in Java.
> knowing types at runtime
RTTI works fine. Querying object types at run time is probably a sign of horrible design.
> stability
By this do you mean unhandled runtime exceptions? If anything it's easier to write C++ free of fatal "null pointer" exceptions by avoiding pointers in favor of references and using RAII well.
- angelbob 15y agoBy this do you mean unhandled runtime exceptions? Partially. Mostly I mean that bad code can make your runtime unstable by corrupting memory. You could say "but I write code that never does that". Pretending for a moment that I believe you, you're still assuming nobody else does that, either. RAII is great, modulo the problem that you have to handle the whole "no exceptions in constructors" problem to avoid resource leaks. Querying object types at run time is probably a sign of horrible design Querying object types at run time is usually a sign of doing something that wasn't anticipated at design time. As systems get larger and older, and as they get pieces patched at runtime, doing unanticipated things becomes inevitable. Java isn't designed to be maximally clean and flexible for a tiny team. It's designed to build behemoth software for industry which is very forgiving of problems. C++ doesn't do that as well. I don't understand. C++ has exactly the same model for collections of polymorphic types. Yes and no. C++ has more restrictions in terms of using only RTTI-capable types in mixed collections. What types aren't RTTI-capable? Primitives and structs. Java has the same problem, patched by autoboxing in such a way that you can't actually screw it up thoroughly. C++ lets you get into unfixable problems pretty quickly. You're right - use only instances of classes with virtual functions, never a primitive or non-virtual class, and you can avoid it. But "with enough auditing, the problem goes away" assumes some pretty specific things about your final environment, including the assumption that errors either don't make it through or are very recoverable.