Re: why learn C?

["jimmaureenrogers@worldnet.att.net" <jimmaureenrogers@worldnet.att.net>]

On Mar 30, 12:30 am, "Case Crab" <casec...@gmail.com> wrote:
> On Mar 29, 10:52 pm, "jimmaureenrog...@worldnet.att.net"
>
> <jimmaureenrog...@worldnet.att.net> wrote:
> > On Mar 29, 6:51 pm, "kevin  cline" <kevin.cl...@gmail.com> wrote:
>
> > > No, what actually happened is that expert C++ developers learned to
> > > use C++ in such a way that those errors can not happen.  While it is
> > > possible to write unsafe code in C++, it is also possible to adopt
> > > coding guidelines that makes it easy to find and eliminate unsafe
> > > code, and for most applications, that's quite good enough.
>
> > Coding guidelines cannot by themselves prevent any errors.
>
> Really?  I have found that coding practices can preclude certain
> classes of errors.

The JSF C++ coding standards are available from several sources on the
web. One link is http://www.research.att.com/~bs/JSF-AV-rules.pdf

The corresponding Ada coding standard is found at
http://software.gsfc.nasa.gov/AssetsApproved/PA2.4.1.1.1.pdf

>
> > For example,
> > the JSF AV C++ Coding Standard, which is intended to limit the unsafe
> > features of C++, contains 221 rules.
>
> How many rules distinguish SPARK from the full Ada language?
>
> > It is not possible to check
> > 6 million lines of code against 221 rules by hand in any timely or
> > economical manner.
>
> I expect that most of the checking can and will be done
> automatically.  In any case, I would expect such
> mission-critical code would be inspected, regardless of whether the
> implementation language is C++ or Ada.
>

Inspection is the problem. It is inefficient and error prone to
manually inspect 6 million lines of code against 221 rules.

There is an automated tool for checking the JSF standard. That
tool cannot perform a 100% check either due to the nature of the
rules.

>
>
> > The NASA Ada Flight Software coding guidelines contain 14 rules.
> > The intent of both coding standards is to produce software safe enough
> > to use for airborne avionics systems.
>
> Interesting that one organization has 221 rules while the other has
> only 14.

If you analyze the two standards, and understand the two languages,
you
will see that the 221 rules for C++ bring you close to the same safety
level you achieve with the 14 rules for Ada.

Many of the language features prohibited in the C++ standard simply do
not exist in Ada. This explains the bulk of the differences in the two
standards. For instance:

AV Rule 20 (MISRA Rule 122)
The setjmp macro and the longjmp function shall not be used.

Ada has no macros and no equivalent to the longjmp function.
There is no reason to prohibit their use in Ada.

Similarly:

AV Rule 29
  The #define pre-processor directive shall not be used to create
inline macros. Inline functions shall be used instead.
  Rationale: Inline functions do not require text substitutions
and behave well when called with arguments
(e.g. type checking is performed).

Ada does allow inline functions and procedures, but has no
language defined macro capability.

AV Rule 71.1
  A class's virtual functions shall not be invoked from its
destructor or any of its constructors.
  Rationale: A class's virtual functions are resolved
statically (not dynamically) in its constructors and
destructor.

Ada does not provide a direct equivalent to C++ constructors
and destructors. While this may seem a problem to a C++ or
Java programmer, it does have the virtue of not providing
an avenue for the error handled by this rule.

And the C++ multiple inheritance model provides interesting
opportunities for unsafe code:

AV Rule 89
  A base class shall not be both virtual and non-virtual in
the same hierarchy.
  Rationale: Hierarchy becomes difficult to comprehend and use.

Do not forget about all the wonders of pointers in C and C++.
For example:

AV Rule 97
  Arrays shall not be used in interfaces. Instead, the Array
class should be used.
  Rationale: Arrays degenerate to pointers when passed as
parameters. This "array decay" problem has long been known to be
a source of errors.

Ada arrays do not decay to pointers. This problem is unknown in
Ada with or without coding standards.

>
> > Coding standards can help up to a point. When the coding standards are
> > oppresively complex they cease to help.
>
> Compile-time checks can also help, up to a point.  But they don't
> solve the whole problem.

No, run time checks are needed for things that cannot be checked at
compile time. Ada helps is more helpful with run time checks than is
C or C++ due to the automated check writing built by the compilers.
For instance, if you define an integer type with a valid range of
values from -10 to 10, the compiler will perform all necessary
range checking for that type.

type My_Int is range -10..10;

You can provide run time checking in any language. In C++ you would
need to define a class for My_Int. The assignment operator would need
to be re-defined to check for the range, and throw an exception when
the range limits are violated.

C++ provides additional challenges to the definition and checking of
limited range integer types. In C and C++ (and Java) all numeric types
are initialized by default to 0. What does that do to your program if
0 is not within the valid range for your type? The compiler will
simply initialize the data member of your class to an invalid value.
You will need to provide a default constructor to initialize the value
to some valid value, along with the overridden assignment operator.

Jim Rogers