@kamelito
Objects another abstraction that do not comply (map) the underlying HW like assembly or C.
Sorry?
But you
do know that a class is ultimately just a struct?
And that an C++ object is just an instance of that struct in memory, just like a C struct?
And that a member function call like ObjType* object->Func() is ultimately nothing else than writing Func(struct ObjType *this) in C?
And that a virtual function is ultimately nothing else than invoking a function-pointer in C?
And that, if you wanted to achieve the same semantics / behaviour in C, you'd either have to write / maintain some switch-case-construct or a function-pointer-table by hand?
And that deriving one class from another is first of all nothing else than creating a new struct, either copying over the stuff from the other or by putting the other inside, just in a much more convenient way?
And I repeat it: since many of the additional language-features of C++ help the compiler to better grasp what you want to achieve (or what you explicitely DONT want to do, e.g. const), it has a chance to create
superior code.
@Plaz
C++ can be buried in layers of abstraction if the coder so chooses, Trying to unravel what they've written can be soul killing.
And in C you can easily be confronted with funny spaghetti-code that's equally hard to unravel
Whether non-trivial code is hard to understand or not is pretty much language independent. You can create a mess in C++, you can in C, you can in Java - and you can create well structured code in all of those too. C++ just offers some features over C that can help here.
And whether comments help depends on the quality of those.
@psxphill
If you've got good documentation, then it's likely the person isn't a developer at all and you might as well throw the code away.
Ahh, no, that's not true. You cannot really make a generalization like that.
And actually, at least if working in a team it's very likely that your boss will force you to document the stuff you write. For four reasons mainly:
1. a mismatch in documentation / code indicates a bug and probably also quickly reveals if you're good or bad at what you do.
2. other team members may have to mess around with your stuff and a decent documentation is simply a tool to help them get on track quicker.
3. it's a myth that well-named variables and funcs and such are always enough documentation, especially if things are getting a bit more complex. A good additional documentation at least of non-trivial code areas can't hurt (especially if you dig out (even your own) code after some years).
4. it makes it easier to get rid of you and to put somebody else there
That being said, in my
personal projects most comments look like that:
// don't change that!!!
// FIXME
// ouch
// X can never be >15, no check required
@thread
For me one of the most powerful features of C++ is to have constructors and a destructor which are called in an absolute predictive way.
And, again: that you can freely chose what to use or not. For example, you could decide to simply write plain C style, enriched with some templated functions.
