Re: Is C++ used in life-critical systems?
"James Kanze" <james.kanze@gmail.com>
On Dec 30, 7:33 pm, Ian Collins <ian-n...@hotmail.com> wrote:
On 12/30/10 11:46 PM, James Kanze wrote:
On Dec 30, 8:55 am, Jorgen Grahn<grahn+n...@snipabacken.se> wrote:
On Tue, 2010-12-21, Balog Pal wrote:
[...]
Member functions? That is not such a big deal alone,
easily worked around with "python style".
RAII is a big deal, and function/operator overloading, and
private/public. Probably other things too.
FWIW: private/public, in connection with member functions, are,
even today, the single most important improvement in C++ over C.
The rest is just icing on the cake---pretty nice icing, in a lot
of cases, but not as important as the encapsulation.
I'd say the automatic construction and destruction that enables RAII is
the single most important improvement in C++ over C. It's one thing
that you simply can't do in C. Encapsulation is just icing on the cake!
The two are related; without the encapsulation, I doubt that
automatic construction and destruction would work. They're both
related to the idea that everything which happens to objects of
the class type is through members.
I would not put them (access control vs auto executing functions) on the
same table. What the compiler (language) does for us (IMO):
access control:
- no need to encode AC into function names
- catch mistakes outider trying access of what not supposed to
auto functions:
- removes all those function calls from visible source
- makes impossible to forget init
- makes impossible to forget cleanup
Fo me, the impact of the latter weigh like a ton, and the first like a few
gramms. Both in my code and that I saw written by others. I saw endless
amount of bugs due to forgotten init, and even more resource leaks or state
discrepancies due to misplaced returns or simple forgetfulness.
Also RAII-ized code becomes readable and understandable while its *correct*
equivalent is a verbose mess full of either repetitions or control flow
management.
For the other group, fighting the disciplene issues would not be way that
hard, and in my work where compiler flagged me for illegal access it was
(wild guess) 80% design issue of the class, and solution was to create the
access.
IOW, when documentation states
- you shall not write priv_* in your code unless ...
- you shall call fclose() on the obtained pointer
though similar in simplicity appear not the same in the extent they are
actually obeyed, neither the ease to catch discrepancies with review or
tools.
Certainly I *do* like and use 'private', and it is great to have, it fades
only in comparision.
I suspect the different opinion is related to the size of the
projects we've worked on, however.
Surely, the scale factor works differently -- IMO the autofuncs are
important in any size, starting at 1 lines, and I'd say scale sinearly.
While benefits of AC scales in a combinatoric way with number of classes (or
something like that) -- it is mostly redundant at beginning and the picture
will change when you have classes by hundreds and thousands.
As we started talking embedded, I think quite many projects here fall in the
first category. ( And for the big ones the issue is going away as there as
you will be able to access C++, if not else asking for a Cameau port... )
I remember back when I was
programming in C: I'd define a struct and a set of functions to
manipulate it... and then cross my fingers that no one accessed
it except through the functions I'd provided. In smaller
projects, you may have more control over the programmers, and be
able to ensure that this doesn't happen.
Yeah, that is the way. It is PITA, but can be covered.
And ensuring the
initialization and automatic destruction---regardless of the
path which causes the variable to go out of scope---is an
important feature.
My experience shows covering that is way harder.