Re: why learn C?

["kevin cline" <kevin.cline@gmail.com>]

On Mar 30, 9:41 pm, "jimmaureenrog...@worldnet.att.net"  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.

I haven't seen setjmp or longjmp used in about twenty years.  This is
not a practical problem in C++ programming.
>
> 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).

Preprocessor macros are quite out of fashion for C++ programming.

>
> 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's a huge problem when a class needs initialization.  Then you have
to mess around with controlled types.

> it does have the virtue of not providing
> an avenue for the error handled by this rule.

No, instead you get to deal with the problem of having objects that
have been created but require further initialization before use.  Or
else you have to create a controlled type, which is just complex
enough that most Ada programmers probably don't quite understand it,
so mostly it doesn't get done.

>
> 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.

And in 10 years of C++ programming I never saw anyone even tempted to
do this.

>
> 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.

It's not a practical problem for C++ programmers either, because we
don't much use arrays anymore, except as needed to call C libraries.

>
>
>
> > > 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;

That's perfect if it happens to be the exact thing that you need.  It
doesn't help much if what you need is a point inside the unit circle.

In C++ the language provides neither of these things, but they are
both be implemented in a few lines of code.

In Ada, the implementation of the constrained point is not so
obvious.