Examples of C++ in Safety Critical Systems

My company makes a motion controller that has a C API. But nearly all
of our customers implement C++ logic on top of our C library (that
includes internal customers too). These controllers are used in a wide
variety of applications including the medical industry (including LASIK
eye surgery and CT-scan machines), the semiconductor industry (you
don't want to break that wafer whose dies will sell for a total of
$200k), industrial machines (large lumber saws, milling machines,
etc...), and even a couple at NASA and the space station. Safety is
part of our everyday dealings and we have found that is sufficiently
safe as long as (as P.J. Plauger already pointed out earlier) the
programmer is sufficiently knowledgable about his environment and the
proper testing has taken place.

I'd be happy to answer any specific questions about our experience and
what we have encountered.


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

kanze wrote:

> Branimir Maksimovic wrote:
> > James Kanze wrote:
>
> > >> Branimir Maksimovic wrote:
>
> > >>> > Carlos Moreno wrote:
>
> > >>>> >>Personally, I think C is like 180 degrees opposed to
> > >>>> >>safety-critical systems. C is satirically described as
> > >>>> >>operating a chainsaw (or a table-saw, or whatever other
> > >>>> >>power tools) with all the safety switches off -- you
> > >>>> >>get all the raw power, but you're taking very high
> > >>>> >>risks in exchange.
>
> > >>> > C's power is in simplicity. One who writes safe
> > >>> > critical code doesn't like complex language. If one is
> > >>> > not able to write safe code in C it is not capable to
> > >>> > write safe code in ADA or C++ or anything.
>
> > >> That's probably true. The question is how much it costs to
> > >> acheive the same level of reliability.
>
> > It is of course cheaper to use safety mechanisms of tools then
> > to code it, but then again, what if mechanism fail?
>
> This is, of course, a major problem. What if there is an error
> in the compiler, and it generates incorrect code? One frequent
> argument against C++ for critical code is that the language is
> too complex, which leads to a larger risk of compiler errors.
> (Whether it is a valid argument is another question. But it is
> certainly an argument which cannot be dismissed off hand as
> irrelevant.)
While not dismissible off hand, I will argue that the tool is not what
we should be most afraid of. I consider myself a coder of average
skills. The number of bugs generated by me usually dwarfs the number of
bugs generated by tools by many magnitudes. Since the laws of
statistics makes it likely average developers will appear in many
projects, tool bugs will not be much danger.
While this is mainly a discussion about C vs C++, I have met a similar
attitude in safety-critical environments - but then about the dangers
of C compilers, when assembly language is so pure and simple. I guess
these folks forgot that their macro assemblers and linkers could have
bugs too...
My experience is that any tool that prevents programmers from making
simple errors will be worth it, even if the tool-generated errors
increase slightly.
Also, rather than worrying about the complexity level of the tool, one
should look at its maturity. The worst experience I have ever had was
when we decided to use a brand-new C compiler for a brand-new chip. We
were swamped with compiler bugs, and would tend to single-step through
the code in assembly view in hope to catch where the compiler messed
up. In contrast, I have worked with mature high-level code generating
tools (SDL) that had very few bugs, maybe only a couple per year.


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

In article <1130361311.900251.273420@g47g2000cwa.googlegroups .com>,
kevin.hall@motioneng.com writes
> Safety is
>part of our everyday dealings and we have found that is sufficiently
>safe as long as (as P.J. Plauger already pointed out earlier) the
>programmer is sufficiently knowledgable about his environment and the
>proper testing has taken place.

And that is the real nub of the issue. Safety critical systems should
only be developed by those who are certified competent as programmers in
the relevant domains. That competence should include the ability to
select an appropriate language and set of tools for the task.

No tools, process or language is going to turn an average programmer
into one suitable for working on critical (life threatening)
applications.

Almost any computer language can be used in a safe way, and every
computer language I have ever come across is a dangerous tool in the
hands of those who know less than they think they do. The problem with
C++ is that it is such a large language with so many corner cases that
it places heavy demands on the programmer. Reliance on tools to avoid
such corner cases is, at best, misguided.

I would consider an expert programmer who lacked adequate domain
knowledge about as dangerous as a domain expert who lacked adequate
programming knowledge. Unfortunately a great number of those currently
working in development fall foul of one or the other of those
requirements.


--
Francis Glassborow ACCU
Author of 'You Can Do It!' see http://www.spellen.org/youcandoit
For project ideas and contributions: http://www.spellen.org/youcandoit/projects


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

Hans Odeberg wrote:

>
> kanze wrote:
>
> > Branimir Maksimovic wrote:
> > > James Kanze wrote:
> >
> > > >> Branimir Maksimovic wrote:
> >
> > > >>> > Carlos Moreno wrote:
> >
> > > >>>> >>Personally, I think C is like 180 degrees opposed to
> > > >>>> >>safety-critical systems. C is satirically described as
> > > >>>> >>operating a chainsaw (or a table-saw, or whatever other
> > > >>>> >>power tools) with all the safety switches off -- you
> > > >>>> >>get all the raw power, but you're taking very high
> > > >>>> >>risks in exchange.
> >
> > > >>> > C's power is in simplicity. One who writes safe
> > > >>> > critical code doesn't like complex language. If one is
> > > >>> > not able to write safe code in C it is not capable to
> > > >>> > write safe code in ADA or C++ or anything.
> >
> > > >> That's probably true. The question is how much it costs to
> > > >> acheive the same level of reliability.
> >
> > > It is of course cheaper to use safety mechanisms of tools then
> > > to code it, but then again, what if mechanism fail?
> >
> > This is, of course, a major problem. What if there is an error
> > in the compiler, and it generates incorrect code? One frequent
> > argument against C++ for critical code is that the language is
> > too complex, which leads to a larger risk of compiler errors.
> > (Whether it is a valid argument is another question. But it is
> > certainly an argument which cannot be dismissed off hand as
> > irrelevant.)
> While not dismissible off hand, I will argue that the tool is not what
> we should be most afraid of. I consider myself a coder of average
> skills. The number of bugs generated by me usually dwarfs the number
> of bugs generated by tools by many magnitudes. Since the laws of
> statistics makes it likely average developers will appear in many
> projects, tool bugs will not be much danger.
> While this is mainly a discussion about C vs C++, I have met a similar
> attitude in safety-critical environments - but then about the dangers
> of C compilers, when assembly language is so pure and simple. I guess
> these folks forgot that their macro assemblers and linkers could have
> bugs too...
> My experience is that any tool that prevents programmers from making
> simple errors will be worth it, even if the tool-generated errors
> increase slightly.
> Also, rather than worrying about the complexity level of the tool, one
> should look at its maturity. The worst experience I have ever had was
> when we decided to use a brand-new C compiler for a brand-new chip. We
> were swamped with compiler bugs, and would tend to single-step through
> the code in assembly view in hope to catch where the compiler messed
> up. In contrast, I have worked with mature high-level code generating
> tools (SDL) that had very few bugs, maybe only a couple per year.
>
>

While what you say is not precisely wrong, it's based on a premise that
is somewhat flawed in safety critical work.

When doing safety critical work, the engineering process is concerned
(over-simplistically) with achieving a high level of assurance that
design correctly meets requirements and then that code correctly meets
design. This occurs regardless of what language is used. In such a
scenario, errors in the tool (development environment, compiler,
linker, etc) become a more significant contributor to faults in the end
product. While that doesn't mean that one should "be afraid of the
tool" it does mean that assurance of the tool (in terms of ensuring
that correct code is translated to a correct executable) becomes a
significant determinant with being able to offer assurance that the end
product works --- and convince an independent review of that.

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

Francis Glassborow wrote:
> In article
> <1130361311.900251.273420@g47g2000cwa.googlegroups .com>,
> kevin.hall@motioneng.com writes

> > Safety is part of our everyday dealings and we have found
> >that is sufficiently safe as long as (as P.J. Plauger already
> >pointed out earlier) the programmer is sufficiently
> >knowledgable about his environment and the proper testing has
> >taken place.

> And that is the real nub of the issue. Safety critical systems
> should only be developed by those who are certified competent
> as programmers in the relevant domains. That competence should
> include the ability to select an appropriate language and set
> of tools for the task.

> No tools, process or language is going to turn an average
> programmer into one suitable for working on critical (life
> threatening) applications.

I disagree with regards to the process, although it may depend
on our definition of "average". I've worked on half-critical
projects; nobody would die if the program crashed, but the
customer wanted 24 hours a day, 7 days a week of up time, with
contractual penalties for down time. (I've also worked on truly
critical systems, but that was a long time ago.)

What we found is that with a good process, at least 90% of the
programmers could be used for productive work. And the process
generally was capable of finding useful things for the other 10%
to do. Typically, the problem with the average programmer with
regards to critical work is attitude, not competence, and a good
process can have a very positive effect on attitude.

When the process for a critical system fails, management does
like to blame it on programmer incompetence, but it just isn't
true. When a critical system fails, it's management's fault.
Period.

> Almost any computer language can be used in a safe way, and
> every computer language I have ever come across is a dangerous
> tool in the hands of those who know less than they think they
> do.

That's true enough. The question is never: is it possible? but
rather, is it the most cost efficient means to achieve the goal.

> The problem with C++ is that it is such a large language with
> so many corner cases that it places heavy demands on the
> programmer.

I'll disagree here. Most of the corner cases can easily be
avoided with some simple rules. These simple rules may limit
what you can do somewhat, but not to the point of eliminating
such advantages as stricter type checking, etc. (In fact, they
actually don't limit that much. Avoiding uncertain areas of the
compiler is generally more limiting.)

> Reliance on tools to avoid such corner cases is, at best,
> misguided.

It depends. For the moment, I've not seen such tools, so it's
hard to say.

> I would consider an expert programmer who lacked adequate
> domain knowledge about as dangerous as a domain expert who
> lacked adequate programming knowledge. Unfortunately a great
> number of those currently working in development fall foul of
> one or the other of those requirements.

In practice, the key is teamwork. It's almost inexistant to
find someone who is truly expert in both the domain and the
technical aspects. In a well run team, however, there will be
different experts in different areas, and the entire team
benefits from their knowledge. (FWIW: I've very little
knowledge of either banking or telephone networks, but I've
played a critical role in developing systems for both. The key
is realizing that while having one person with my skill set on
the team is essential, having everyone with the same skill set
would be a disaster.)

--
James Kanze GABI Software
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34


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

Hans Odeberg wrote:
> kanze wrote:

> > Branimir Maksimovic wrote:
> > > James Kanze wrote:

> > > >> Branimir Maksimovic wrote:

> > > >>> > Carlos Moreno wrote:

> > > >>>> >>Personally, I think C is like 180 degrees opposed
> > > >>>> >>to safety-critical systems. C is satirically
> > > >>>> >>described as operating a chainsaw (or a table-saw,
> > > >>>> >>or whatever other power tools) with all the safety
> > > >>>> >>switches off -- you get all the raw power, but
> > > >>>> >>you're taking very high risks in exchange.

> > > >>> > C's power is in simplicity. One who writes safe
> > > >>> > critical code doesn't like complex language. If one
> > > >>> > is not able to write safe code in C it is not
> > > >>> > capable to write safe code in ADA or C++ or
> > > >>> > anything.

> > > >> That's probably true. The question is how much it
> > > >> costs to acheive the same level of reliability.

> > > It is of course cheaper to use safety mechanisms of tools
> > > then to code it, but then again, what if mechanism fail?

> > This is, of course, a major problem. What if there is an
> > error in the compiler, and it generates incorrect code? One
> > frequent argument against C++ for critical code is that the
> > language is too complex, which leads to a larger risk of
> > compiler errors. (Whether it is a valid argument is another
> > question. But it is certainly an argument which cannot be
> > dismissed off hand as irrelevant.)

> While not dismissible off hand, I will argue that the tool is
> not what we should be most afraid of. I consider myself a
> coder of average skills. The number of bugs generated by me
> usually dwarfs the number of bugs generated by tools by many
> magnitudes. Since the laws of statistics makes it likely
> average developers will appear in many projects, tool bugs
> will not be much danger.

In a critical system, no error can be tolerated. The company
you are working for has control over the quality of your work,
and will take the necessary steps to ensure that your code has
no errors. (Obviously, I'm talking here about the code which is
fully integrated into the final product. Obviously, you don't
just sit down in fron the terminal and type in 100% correct
code. But before the code you write ends up in the product, it
will have been sufficiently reviewed and tested that the company
can be 100% sure of it.)

It does not have similar control over the tools.

> While this is mainly a discussion about C vs C++, I have met a
> similar attitude in safety-critical environments - but then
> about the dangers of C compilers, when assembly language is so
> pure and simple. I guess these folks forgot that their macro
> assemblers and linkers could have bugs too...

> My experience is that any tool that prevents programmers from
> making simple errors will be worth it, even if the
> tool-generated errors increase slightly.

Certainly. Tools which prevent programmers from making simple
errors reduce the total development cost for the same level of
quality. A plus. As long as the tool doesn't introduce other
errors.

My personal opinion is that if C++ were available, I would not
even consider C for a critical system. Depending on the
maturity of the C++ compiler, I might very likely ban the use of
the more complex and newer features. I might also ban the use
of the code which makes absolute rigorous analysis more
difficult, like exceptions or operator overloaded (or anything
else which introduced hidden flow paths or potential state
changes in the code)

> Also, rather than worrying about the complexity level of the
> tool, one should look at its maturity.

I agree here. The problem is that the two are often related.

In the case of C++, compiler maturity, at least with regards to
the newer features (where "newer" means anything added since
CFront 2.1), is often a serious problem.

--
James Kanze GABI Software
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34


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

Francis Glassborow wrote:
> In article <1130361311.900251.273420@g47g2000cwa.googlegroups .com>,
> kevin.hall@motioneng.com writes
> > Safety is
> >part of our everyday dealings and we have found that is sufficiently
> >safe as long as (as P.J. Plauger already pointed out earlier) the
> >programmer is sufficiently knowledgable about his environment and the
> >proper testing has taken place.
>
> And that is the real nub of the issue. Safety critical systems should
> only be developed by those who are certified competent as programmers in
> the relevant domains.

Not all (or maybe not many) domain experts are competent programmers. I
consider programming a different responsibility to being a domain
expert. I have met very competent domain experts that write code that
only they can maintain. They cannot use the programming language to
convey their intent, but they can use English and Math to such an
extent that a good programmer can. I would like to believe that a
domain expert in tandem with a competent programmer could be used for
this purpose too. Competent programmers don't start out knowing their
problem domain. They learn it on the fly in close consultation with
domain experts.

> That competence should include the ability to
> select an appropriate language and set of tools for the task.

How many languages would you consider as appropriate when developing
safety critical systems? Would you as programmer be biased towards
certain languages? What would make you select C ahead of C++ or Ada.
Does personal taste of tools make you favour the worst instead of the
better, or lack of experience with one make you favour the other?

>
> No tools, process or language is going to turn an average programmer
> into one suitable for working on critical (life threatening)
> applications.

Therefore a competent programmer will always be able to achieve what is
required without necessarily relying on a large bag of languages/tools,
but just by sticking with what he knows. Lets say for example, that you
are a very proficient ADA programmer - you know SW Engineering
concepts, OO design etc, but you haven't programmed in C++ before,
would you choose it as language, or would you allow yourself on a team
that are to develop a safety critical system where C++ was the language
of choice - maybe as architect or consultant, yes, but not developer.

I must ask this question. If I'm proficient at OOD, does this mean I'm
automatically proficient in assembler, or in functional programming.
Certain people have stronger preference (and more ability) towards
certain paradigms. The saying goes that a good programmer can write
good code in any language. I'm not saying that this is not true, but I
have my doubts (I may be wrong, of course).

>
> Almost any computer language can be used in a safe way, and every
> computer language I have ever come across is a dangerous tool in the
> hands of those who know less than they think they do.

Yes, agreed.

> The problem with
> C++ is that it is such a large language with so many corner cases that
> it places heavy demands on the programmer. Reliance on tools to avoid
> such corner cases is, at best, misguided.

Yes, and I'm certainly still learning the corner cases :-). The less
experienced should have the opportunity to learn from the more
experienced, and the more experienced should have the opportunity to
learn from (and become) the experts. Of course, some people will never
because of lack of ability, but they are (can be) recognized.

> I would consider an expert programmer who lacked adequate domain
> knowledge about as dangerous as a domain expert who lacked adequate
> programming knowledge. Unfortunately a great number of those currently
> working in development fall foul of one or the other of those
> requirements.

Yes, an expert programmer without domain knowledge is dangerous, but
not if he has the ability to learn from the domain expert. Eventually
he does not have to become a domain expert to develop good software
(IMHO). He must be able to portray his understanding of the domain to
such an extent that the domain expert can recognize where he err's (a
good communicator). If this is not possible (one can't expect every
programmer to be a good communicator), a mediator may exist that
understands software to such an extent that he can do this.

All said, I would like to believe (maybe I'm an idealist) that being a
domain expert, a requirements analyst, a developer, and an software
architect are all entities within the programming paradigm. If these
entities can collaborate well, it is possible to develop safety
critical software.

Regards,

Werner


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

kevin.hall@motioneng.com wrote:

> etc...), and even a couple at NASA and the space station. Safety is
> part of our everyday dealings and we have found that is sufficiently
> safe as long as (as P.J. Plauger already pointed out earlier) the
> programmer is sufficiently knowledgable about his environment and the
> proper testing has taken place.

This depends on whether or not the system can reach a safe state when a
failure occurs. For example, a radiation machine can be turned off, a
respiratory ventilator cannot; a train engine can be turned off, its
breaks cannot. As the stakes are raised, the correctness of the tools
used to build the system becomes increasingly important.

The cost of an accident is another factor that determine the importance
of correct tools.

--
mail1dotstofanetdotdk

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

Rob wrote:

> Hans Odeberg wrote:
>
> > While not dismissible off hand, I will argue that the tool is not what
> > we should be most afraid of. I consider myself a coder of average
> > skills. The number of bugs generated by me usually dwarfs the number
> > of bugs generated by tools by many magnitudes. Since the laws of
> > statistics makes it likely average developers will appear in many
> > projects, tool bugs will not be much danger.
> > While this is mainly a discussion about C vs C++, I have met a similar
> > attitude in safety-critical environments - but then about the dangers
> > of C compilers, when assembly language is so pure and simple. I guess
> > these folks forgot that their macro assemblers and linkers could have
> > bugs too...
> > My experience is that any tool that prevents programmers from making
> > simple errors will be worth it, even if the tool-generated errors
> > increase slightly.
> > Also, rather than worrying about the complexity level of the tool, one
> > should look at its maturity. The worst experience I have ever had was
> > when we decided to use a brand-new C compiler for a brand-new chip. We
> > were swamped with compiler bugs, and would tend to single-step through
> > the code in assembly view in hope to catch where the compiler messed
> > up. In contrast, I have worked with mature high-level code generating
> > tools (SDL) that had very few bugs, maybe only a couple per year.
> >
> >
>
> While what you say is not precisely wrong, it's based on a premise that
> is somewhat flawed in safety critical work.
>
> When doing safety critical work, the engineering process is concerned
> (over-simplistically) with achieving a high level of assurance that
> design correctly meets requirements and then that code correctly meets
> design. This occurs regardless of what language is used. In such a
> scenario, errors in the tool (development environment, compiler,
> linker, etc) become a more significant contributor to faults in the end
> product. While that doesn't mean that one should "be afraid of the
> tool" it does mean that assurance of the tool (in terms of ensuring
> that correct code is translated to a correct executable) becomes a
> significant determinant with being able to offer assurance that the end
> product works --- and convince an independent review of that.

No, I do not think the premise is flawed. We can never rely on a tool,
no matter how simple, to translate to a correct executable. We always
need tests.

Each of the steps in a process generates some errors, and removes
others. As we define requirements, we forget some and distort some.
During later reviews, some of the errors are caught. One of the steps
in the process will include programming. This activity will generate
errors - with a good process, good tools and disciplined developers
hopefully few errors, but still. Then system test ought to catch most
safety-critical errors.

Focusing on the programming part: Suppose I had do write some SW that
included signal processing. I then have the choice to:
1) write a 20-line Matlab script, resulting in a very clean, simple and
testable source file. This is then converted to C code using a complex
code generator. While I cannot guarantee this code generator is fault
free, it ought to be of reasonably high quality, assuming it has been
in use for some years.
2) write thousands of lines of C code that handles all that is built
into Matlab, and pass this source code to a C compiler that I know
always produces correct code (assuming I can find one).

Now, which approach do you think would lead to the fewest errors in the
code? Which would be easiest to maintain during the products 10-year
life span?


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

Hans Odeberg wrote:
> Rob wrote:

[...]
> No, I do not think the premise is flawed. We can never rely on
> a tool, no matter how simple, to translate to a correct
> executable. We always need tests.

We need tests. But if the tests show up an error, that's cause
to be worried.

> Each of the steps in a process generates some errors, and
> removes others. As we define requirements, we forget some and
> distort some. During later reviews, some of the errors are
> caught. One of the steps in the process will include
> programming. This activity will generate errors - with a good
> process, good tools and disciplined developers hopefully few
> errors, but still.

With a good process, the error rate can be as low as one error
per million lines of code. One error in less than a 100000 is
relatively frequent, although I don't think it would be
considered sufficient in a place developing critical software.

If an error is found in the tests, there is an investigation as
to why, and the process is changed so that it doesn't happen
again.

When a compiler (or any other critical element in the tool
chain) is validated for use in critical systems, the development
process of the tool is evaluated; if the development process
used on the compiler is not capable of producing similarly low
error rates, then the compiler doesn't pass validation.

> Then system test ought to catch most safety-critical errors.

> Focusing on the programming part: Suppose I had do write some
> SW that included signal processing. I then have the choice to:

> 1) write a 20-line Matlab script, resulting in a very clean,
> simple and testable source file. This is then converted to C
> code using a complex code generator. While I cannot guarantee
> this code generator is fault free, it ought to be of
> reasonably high quality, assuming it has been in use for some
> years.

> 2) write thousands of lines of C code that handles all that is
> built into Matlab, and pass this source code to a C compiler
> that I know always produces correct code (assuming I can find
> one).

> Now, which approach do you think would lead to the fewest
> errors in the code?

If your process ensures that your couple of thousand lines of C
code don't contain an error, and the code generated code might,
then the answer is clear. Approach 2.

> Which would be easiest to maintain during the products 10-year
> life span?

We're talking about critical software here. Ease of
maintainance only becomes an issue after we've assured that
there are no errors.

--
James Kanze GABI Software
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34


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

kanze wrote:
> Francis Glassborow wrote:
>
> > The problem with C++ is that it is such a large language with
> > so many corner cases that it places heavy demands on the
> > programmer.
>
> I'll disagree here. Most of the corner cases can easily be
> avoided with some simple rules. These simple rules may limit
> what you can do somewhat, but not to the point of eliminating
> such advantages as stricter type checking, etc. (In fact, they
> actually don't limit that much. Avoiding uncertain areas of the
> compiler is generally more limiting.)

Yes, the rule "I don't use what I don't know" ,
works best.One doesn't have to know or use everything
available in C++, in order to write successful programs.

> > I would consider an expert programmer who lacked adequate
> > domain knowledge about as dangerous as a domain expert who
> > lacked adequate programming knowledge. Unfortunately a great
> > number of those currently working in development fall foul of
> > one or the other of those requirements.
>
> In practice, the key is teamwork. It's almost inexistant to
> find someone who is truly expert in both the domain and the
> technical aspects. In a well run team, however, there will be
> different experts in different areas, and the entire team
> benefits from their knowledge.

Yes, this is also my experience,I didn't have to know what is SID,
STAR,VHF navaid,non directional beacon,holding pattern or
departure profile etc, because there were people who know.
My job was to write code and help others with C++ and also there were
people who educate in domain we were working.
Problem is that people does not realise that software engineering
is domain also. One cannot be devoted to two domains, or can, but
will always be behind ones who are solely devoted to one
domain, because one learns and gain experience constantly.
Programers usually learn something about domain of program,
but that is just dubious knowledge.I worked in blood transfusion,
accounting,banking, airline business etc, but I just have dubious
knowledge
about those. Alright I generally know how things work, but
I can't write any app in those domains without help from
domain experts. Domain experts can neither write app as good
without help from programmers. There are tools that help domain
experts to write apps without programer,but such tools usually have
limits.
Finaly, there is no point in time when one can say alright, I know
everything, let's move to other domain. This is impossible.
There will be always many more things then one don't knows
that one knows even when solely devoted to only one domain
such as programming.

Greetings, Bane.


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