Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.arch.embedded > #18693 > unrolled thread

validity of ... reasons for preferring C over C++

Back to article view | Back to comp.arch.embedded

Contents

  validity of ... reasons for preferring C over C++ Nobody <nobody@nowhere.invalid> - 2014-10-17 00:00 +0100
    Re: validity of ... reasons for preferring C over C++ Wouter van Ooijen <wouter@voti.nl> - 2014-10-17 07:38 +0200
    Re: validity of ... reasons for preferring C over C++ David Brown <david.brown@hesbynett.no> - 2014-10-17 09:27 +0200
      Re: validity of ... reasons for preferring C over C++ Tom Gardner <spamjunk@blueyonder.co.uk> - 2014-10-17 09:29 +0100
        Re: validity of ... reasons for preferring C over C++ David Brown <david.brown@hesbynett.no> - 2014-10-17 11:19 +0200
          Re: validity of ... reasons for preferring C over C++ Paul Rubin <no.email@nospam.invalid> - 2014-10-17 02:35 -0700
            Re: validity of ... reasons for preferring C over C++ Arlet Ottens <usenet+5@c-scape.nl> - 2014-10-17 11:43 +0200
              Re: validity of ... reasons for preferring C over C++ Tom Gardner <spamjunk@blueyonder.co.uk> - 2014-10-17 12:12 +0100
                Re: validity of ... reasons for preferring C over C++ Arlet Ottens <usenet+5@c-scape.nl> - 2014-10-17 13:25 +0200
                  Re: validity of ... reasons for preferring C over C++ Tom Gardner <spamjunk@blueyonder.co.uk> - 2014-10-17 12:40 +0100
              Re: validity of ... reasons for preferring C over C++ Niklas Holsti <niklas.holsti@tidorum.invalid> - 2014-10-17 20:12 +0300
                Re: validity of ... reasons for preferring C over C++ Rob Gaddi <rgaddi@technologyhighland.invalid> - 2014-10-17 10:18 -0700
                  Re: validity of ... reasons for preferring C over C++ upsidedown@downunder.com - 2014-10-17 21:53 +0300
                    Re: validity of ... reasons for preferring C over C++ Niklas Holsti <niklas.holsti@tidorum.invalid> - 2014-10-17 22:59 +0300
                      Re: validity of ... reasons for preferring C over C++ Paul Rubin <no.email@nospam.invalid> - 2014-10-17 13:23 -0700
                        Re: validity of ... reasons for preferring C over C++ Jacob Sparre Andersen <jacob@jacob-sparre.dk> - 2014-10-18 17:46 +0200
                          Re: validity of ... reasons for preferring C over C++ Paul Rubin <no.email@nospam.invalid> - 2014-10-18 11:45 -0700
                            Re: validity of ... reasons for preferring C over C++ Niklas Holsti <niklas.holsti@tidorum.invalid> - 2014-10-19 01:51 +0300
                              Re: validity of ... reasons for preferring C over C++ Jacob Sparre Andersen <jacob@jacob-sparre.dk> - 2014-10-19 12:43 +0200
                  Re: validity of ... reasons for preferring C over C++ Jacob Sparre Andersen <jacob@jacob-sparre.dk> - 2014-10-18 17:44 +0200
            Re: validity of ... reasons for preferring C over C++ David Brown <david.brown@hesbynett.no> - 2014-10-17 12:44 +0200
              Re: validity of ... reasons for preferring C over C++ Tom Gardner <spamjunk@blueyonder.co.uk> - 2014-10-17 12:13 +0100
              Re: validity of ... reasons for preferring C over C++ Niklas Holsti <niklas.holsti@tidorum.invalid> - 2014-10-17 20:15 +0300
                Re: validity of ... reasons for preferring C over C++ Arlet Ottens <usenet+5@c-scape.nl> - 2014-10-17 19:18 +0200
                Re: validity of ... reasons for preferring C over C++ David Brown <david.brown@hesbynett.no> - 2014-10-17 23:03 +0200
                  Re: validity of ... reasons for preferring C over C++ Paul Rubin <no.email@nospam.invalid> - 2014-10-17 14:11 -0700
                    Re: validity of ... reasons for preferring C over C++ David Brown <david.brown@hesbynett.no> - 2014-10-18 20:14 +0200
                      Re: validity of ... reasons for preferring C over C++ Tom Gardner <spamjunk@blueyonder.co.uk> - 2014-10-18 22:15 +0100
                        Re: validity of ... reasons for preferring C over C++ glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-10-18 23:07 +0000
                          Re: validity of ... reasons for preferring C over C++ Tom Gardner <spamjunk@blueyonder.co.uk> - 2014-10-19 00:36 +0100
                            Re: validity of ... reasons for preferring C over C++ Niklas Holsti <niklas.holsti@tidorum.invalid> - 2014-10-19 10:55 +0300
                              Re: validity of ... reasons for preferring C over C++ Tom Gardner <spamjunk@blueyonder.co.uk> - 2014-10-19 09:33 +0100
                          Re: validity of ... reasons for preferring C over C++ "Boudewijn Dijkstra" <sp4mtr4p.boudewijn@indes.com> - 2014-10-20 15:04 +0200
                        Re: validity of ... reasons for preferring C over C++ David Brown <david.brown@hesbynett.no> - 2014-10-19 13:32 +0200
                  Re: validity of ... reasons for preferring C over C++ Wouter van Ooijen <wouter@voti.nl> - 2014-10-17 23:44 +0200
                    Re: validity of ... reasons for preferring C over C++ David Brown <david.brown@hesbynett.no> - 2014-10-18 20:10 +0200
                      Re: validity of ... reasons for preferring C over C++ Niklas Holsti <niklas.holsti@tidorum.invalid> - 2014-10-18 23:38 +0300
                      Re: validity of ... reasons for preferring C over C++ Tom Gardner <spamjunk@blueyonder.co.uk> - 2014-10-18 22:21 +0100
                  Re: validity of ... reasons for preferring C over C++ Niklas Holsti <niklas.holsti@tidorum.invalid> - 2014-10-19 10:43 +0300
                    Re: validity of ... reasons for preferring C over C++ Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> - 2014-10-19 09:38 +0000
                    Re: validity of ... reasons for preferring C over C++ David Brown <david.brown@hesbynett.no> - 2014-10-19 14:07 +0200
                      Re: validity of ... reasons for preferring C over C++ Paul Rubin <no.email@nospam.invalid> - 2014-10-19 19:47 -0700
                        Re: validity of ... reasons for preferring C over C++ Niklas Holsti <niklas.holsti@tidorum.invalid> - 2014-10-20 06:55 +0300
                          Re: validity of ... reasons for preferring C over C++ Paul Rubin <no.email@nospam.invalid> - 2014-10-19 21:02 -0700
                            Re: validity of ... reasons for preferring C over C++ britt.snodgrass@gmail.com - 2014-10-20 04:02 -0700
                            Re: validity of ... reasons for preferring C over C++ Niklas Holsti <niklas.holsti@tidorum.invalid> - 2014-10-20 18:51 +0300
                              C and Ada, was: Re: validity of ... reasons for preferring C over C++ Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> - 2014-10-21 00:30 +0000
                                Re: C and Ada, was: Re: validity of ... reasons for preferring C over C++ Les Cargill <lcargill99@comcast.com> - 2014-10-20 20:49 -0500
                                  Re: C and Ada, was: Re: validity of ... reasons for preferring C over C++ Jacob Sparre Andersen <jacob@jacob-sparre.dk> - 2014-10-21 09:11 +0200
                                    Re: C and Ada, was: Re: validity of ... reasons for preferring C over C++ Les Cargill <lcargill99@comcast.com> - 2014-10-21 08:34 -0500
                  Re: validity of ... reasons for preferring C over C++ Niklas Holsti <niklas.holsti@tidorum.invalid> - 2014-10-19 21:23 +0300
                  Re: validity of ... reasons for preferring C over C++ Nobody <nobody@nowhere.invalid> - 2014-10-20 03:39 +0100
            Re: validity of ... reasons for preferring C over C++ Tom Gardner <spamjunk@blueyonder.co.uk> - 2014-10-17 12:07 +0100
          Re: validity of ... reasons for preferring C over C++ Tom Gardner <spamjunk@blueyonder.co.uk> - 2014-10-17 12:06 +0100
            Re: validity of ... reasons for preferring C over C++ David Brown <david.brown@hesbynett.no> - 2014-10-17 14:12 +0200
              Re: validity of ... reasons for preferring C over C++ Tom Gardner <spamjunk@blueyonder.co.uk> - 2014-10-17 13:16 +0100
            Re: validity of ... reasons for preferring C over C++ Stef <stef33d@yahooI-N-V-A-L-I-D.com.invalid> - 2014-10-17 14:13 +0200
              Re: validity of ... reasons for preferring C over C++ Arlet Ottens <usenet+5@c-scape.nl> - 2014-10-17 14:35 +0200
                Re: validity of ... reasons for preferring C over C++ Tom Gardner <spamjunk@blueyonder.co.uk> - 2014-10-17 13:59 +0100
              Re: validity of ... reasons for preferring C over C++ Wouter van Ooijen <wouter@voti.nl> - 2014-10-17 17:06 +0200
              Re: validity of ... reasons for preferring C over C++ upsidedown@downunder.com - 2014-10-17 19:41 +0300
        Re: validity of ... reasons for preferring C over C++ Clifford Heath <no.spam@please.net> - 2014-10-18 10:14 +1100
          Re: validity of ... reasons for preferring C over C++ Tom Gardner <spamjunk@blueyonder.co.uk> - 2014-10-18 00:36 +0100
            Re: validity of ... reasons for preferring C over C++ Clifford Heath <no.spam@please.net> - 2014-10-20 09:45 +1100
          Re: validity of ... reasons for preferring C over C++ Niklas Holsti <niklas.holsti@tidorum.invalid> - 2014-10-18 08:52 +0300
            Re: validity of ... reasons for preferring C over C++ Tom Gardner <spamjunk@blueyonder.co.uk> - 2014-10-18 09:41 +0100
    Re: validity of ... reasons for preferring C over C++ Dave Nadler <drn@nadler.com> - 2014-10-20 09:46 -0700
      Re: validity of ... reasons for preferring C over C++ Paul Rubin <no.email@nospam.invalid> - 2014-10-20 16:26 -0700
        Re: validity of ... reasons for preferring C over C++ Dave Nadler <drn@nadler.com> - 2014-10-20 16:42 -0700
          Re: validity of ... reasons for preferring C over C++ Paul Rubin <no.email@nospam.invalid> - 2014-10-20 17:24 -0700
            Re: validity of ... reasons for preferring C over C++ John Devereux <john@devereux.me.uk> - 2014-10-21 19:09 +0100
              Re: validity of ... reasons for preferring C over C++ Wouter van Ooijen <wouter@voti.nl> - 2014-10-24 16:38 +0200
            Re: validity of ... reasons for preferring C over C++ Dave Nadler <drn@nadler.com> - 2014-10-21 15:12 -0700
              Re: validity of ... reasons for preferring C over C++ Paul Rubin <no.email@nospam.invalid> - 2014-10-21 16:39 -0700
                Re: validity of ... reasons for preferring C over C++ Nobody <nobody@nowhere.invalid> - 2014-10-22 01:43 +0100
                Re: validity of ... reasons for preferring C over C++ Hans-Bernhard Bröker <HBBroeker@t-online.de> - 2014-10-22 20:00 +0200
            Re: validity of ... reasons for preferring C over C++ Stefan Reuther <stefan.news@arcor.de> - 2014-10-22 18:49 +0200
        Re: validity of ... reasons for preferring C over C++ Dave Nadler <drn@nadler.com> - 2014-10-21 15:15 -0700
        Re: validity of ... reasons for preferring C over C++ Dave Nadler <drn@nadler.com> - 2014-10-22 04:45 -0700
          Re: validity of ... reasons for preferring C over C++ Paul Rubin <no.email@nospam.invalid> - 2014-10-22 09:30 -0700
            Re: validity of ... reasons for preferring C over C++ Dave Nadler <drn@nadler.com> - 2014-10-23 12:25 -0700
              Re: validity of ... reasons for preferring C over C++ Paul Rubin <no.email@nospam.invalid> - 2014-10-23 15:17 -0700
                Re: validity of ... reasons for preferring C over C++ glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-10-23 22:59 +0000
                  Re: validity of ... reasons for preferring C over C++ Paul Rubin <no.email@nospam.invalid> - 2014-10-23 16:02 -0700
                Re: validity of ... reasons for preferring C over C++ Dave Nadler <drn@nadler.com> - 2014-10-27 08:30 -0700
                  Re: validity of ... reasons for preferring C over C++ Paul Rubin <no.email@nospam.invalid> - 2014-10-27 09:00 -0700
                    Re: validity of ... reasons for preferring C over C++ Dave Nadler <drn@nadler.com> - 2014-10-27 09:24 -0700
                      Re: validity of ... reasons for preferring C over C++ Paul Rubin <no.email@nospam.invalid> - 2014-10-27 09:30 -0700
                      Re: validity of ... reasons for preferring C over C++ glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-10-28 00:52 +0000
                Re: validity of ... reasons for preferring C over C++ David Brown <david.brown@hesbynett.no> - 2014-10-28 08:45 +0100
                  Re: validity of ... reasons for preferring C over C++ Paul Rubin <no.email@nospam.invalid> - 2014-10-28 02:00 -0700
                    Re: validity of ... reasons for preferring C over C++ George Neuner <gneuner2@comcast.net> - 2014-10-30 11:56 -0400
                  Re: validity of ... reasons for preferring C over C++ upsidedown@downunder.com - 2014-10-28 19:59 +0200
                    Re: validity of ... reasons for preferring C over C++ David Brown <david.brown@hesbynett.no> - 2014-10-28 23:46 +0100
                      Re: validity of ... reasons for preferring C over C++ upsidedown@downunder.com - 2014-10-29 07:27 +0200
                        Re: validity of ... reasons for preferring C over C++ David Brown <david.brown@hesbynett.no> - 2014-10-29 10:11 +0100
                    Re: validity of ... reasons for preferring C over C++ Robert Wessel <robertwessel2@yahoo.com> - 2014-10-29 10:21 -0500
                      Re: validity of ... reasons for preferring C over C++ glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-10-29 20:15 +0000
                        Re: validity of ... reasons for preferring C over C++ Robert Wessel <robertwessel2@yahoo.com> - 2014-10-30 11:33 -0500
                          Re: validity of ... reasons for preferring C over C++ glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-10-30 19:07 +0000
                            Re: validity of ... reasons for preferring C over C++ Robert Wessel <robertwessel2@yahoo.com> - 2014-10-30 16:19 -0500
                        Re: validity of ... reasons for preferring C over C++ Nobody <nobody@nowhere.invalid> - 2014-10-31 07:32 +0000
                          Re: validity of ... reasons for preferring C over C++ glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-10-31 08:45 +0000
                            Re: validity of ... reasons for preferring C over C++ Reinhardt Behm <rbehm@hushmail.com> - 2014-10-31 18:15 +0800
                              Re: validity of ... reasons for preferring C over C++ glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-10-31 22:03 +0000
                            Re: validity of ... reasons for preferring C over C++ Robert Wessel <robertwessel2@yahoo.com> - 2014-10-31 09:53 -0500
                              Re: validity of ... reasons for preferring C over C++ glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-10-31 22:17 +0000
                          Re: validity of ... reasons for preferring C over C++ Les Cargill <lcargill99@comcast.com> - 2014-10-31 17:50 -0500
              Re: validity of ... reasons for preferring C over C++ Nobody <nobody@nowhere.invalid> - 2014-10-28 04:37 +0000
      Re: validity of ... reasons for preferring C over C++ Stefan Reuther <stefan.news@arcor.de> - 2014-10-21 19:12 +0200
        Re: validity of ... reasons for preferring C over C++ Dave Nadler <drn@nadler.com> - 2014-10-21 15:06 -0700
          Re: validity of ... reasons for preferring C over C++ Stefan Reuther <stefan.news@arcor.de> - 2014-10-22 19:06 +0200

Page 1 of 6  [1] 2 3 4 5 6  Next page →

#18693 — validity of ... reasons for preferring C over C++

On Wed, 15 Oct 2014 19:21:11 +0200, Wouter van Ooijen wrote:

> PS I am (in the context of this question) NOT interested in

> - whether a reason is valid (please start a different thread for 
> discussing this, I'll surely join in).

Okay, then.

To start with some comments from the original post:

> - semantic distance to the machine code (I can't easily see what code 
> this C++ construct will cause)

If you think you know what code a given C construct will generate, you've
been out of the loop too long.

Modern C compilers can be very aggressive when it comes to optimisation,
taking full advantage of the concept of "undefined behaviour", including
what used to be obscure cases such as aliasing.

If you need the kind of control you get from assembler, you either need to
use assembler, or at least look at the actual assembler code the compiler
is generating. If you think you know, think again.

> - C++ stronger typing gets in the way (forces you to write lots of casts)

This is an advantage, not a disadvantage.

If you're targeting a specific CPU, you don't need to worry about one
of the reasons why casts are problematic: the fact that the standard
doesn't actually define representation. You can ignore the fact that ...

Integers may be big-endian, little-endian, Vax-endian or something else;
signed integers may use twos-complement, ones-complement, or sign-bit
representation; floats could be just about anything; structures may have
padding anywhere other than before the first element; pointers may be
simple indices into a flat address space or complex structures involving
tags, segments and/or whatever else.

You do, however, still need to consider the effects of the cast with
respect to C's aliasing rules. The compiler is entitled to assume (with
some caveats) that objects with different types do not overlap; modifying
one will not affect the other. But casts tend to result in exactly that.

And the "entitled to assume" isn't just for language lawyers any more;
modern compilers (at least the ones for desktop/server architectures,
which are enveloping an increasing proportion of the "embedded" space) do
actually take advantage of that freedom.

[toc] | [next] | [standalone]

#18698

Nobody schreef op 17-Oct-14 1:00 AM:
> On Wed, 15 Oct 2014 19:21:11 +0200, Wouter van Ooijen wrote:
>
>> PS I am (in the context of this question) NOT interested in
>
>> - whether a reason is valid (please start a different thread for
>> discussing this, I'll surely join in).
>
> Okay, then.
>
> To start with some comments from the original post:
>
>> - semantic distance to the machine code (I can't easily see what code
>> this C++ construct will cause)

or write

volatile float x = 1.75;
x = sin( x );

for an 8-bit chip. If you really know and understand what code that will 
generate (or cause to be included) you are a compiler writer.

Wouter van Ooijen

[toc] | [prev] | [next] | [standalone]

#18699

On 17/10/14 01:00, Nobody wrote:
> On Wed, 15 Oct 2014 19:21:11 +0200, Wouter van Ooijen wrote:
> 
>> PS I am (in the context of this question) NOT interested in
> 
>> - whether a reason is valid (please start a different thread for 
>> discussing this, I'll surely join in).
> 
> Okay, then.
> 
> To start with some comments from the original post:
> 
>> - semantic distance to the machine code (I can't easily see what code 
>> this C++ construct will cause)
> 
> If you think you know what code a given C construct will generate, you've
> been out of the loop too long.
> 
> Modern C compilers can be very aggressive when it comes to optimisation,
> taking full advantage of the concept of "undefined behaviour", including
> what used to be obscure cases such as aliasing.
> 
> If you need the kind of control you get from assembler, you either need to
> use assembler, or at least look at the actual assembler code the compiler
> is generating. If you think you know, think again.
> 

It is quite possible to estimate the assembly generating for some types
of code in C.  If you've got a complex function, or using floating point
on an 8-bit micro, or have whole-program optimisation, then the
generated assembly is going to be incomprehensible.  But for smaller
functions or code snippets, it is often easy and helpful to understand
the generated assembly, and if it is critical code then it can be good
to work with the source until the generated assembly matches your
expected assembly structures (or you file a "missed optimisation" bug
report - that is part of how compilers improve over time).

So I don't know the details of what my compiler will end up producing
for large sections of code - but I /do/ know how it works and what it
will do for small and important sections.


However, /exactly/ the same applies to C++ as to C.  It's the same
compiler, it works in the same way, and for code where I am interested
in the generated assembly, I can work with the tools in the same way.


What people seem to think is different about C++ is that "innocent"
statements such as defining an instance of a class "A a;" can lead to
"hidden" code generation (via constructor calls, etc.), or that an
"innocent" statement of "a = b + c" can lead to "hidden" code due to
operator overloading.

This is clearly nonsense.  Nothing is hidden, as you have the source -
if you want to know about the constructor, look it up.  The equivalent C
code would be "A a; initA(&A);", generating similar code.  Operator
overloads will generate extra code on something like "a = b + c" /if/
the operation requires more code - just like in C (where you would say
"matrixAdd(&a, &b, &c);" or whatever).

If you don't know what your C++ code is doing, that's /your/ problem,
not the language's problem.

[toc] | [prev] | [next] | [standalone]

#18700

On 17/10/14 08:27, David Brown wrote:
> If you don't know what your C++ code is doing, that's /your/ problem,
> not the language's problem.

Well yes. But some languages do have more obscured traps that
that require higher levels of skill and more continual alertness.

The interesting question is always "given circumstances X, is
Y or Z the more appropriate language".

One of the problems with modern C and C compilers (compared with
K&R C) is that their sophistication places far more subtle traps
that require language lawyers to understand. When even the language
lawyers disagree amongst themselves, that's not a good starting
point.

K&R C had 228 pages. C Traps and Pitfalls had 228 pages. They
were all you needed in the 80. How long are the modern equivalents?

So I will assert that nowadays there are fewer circumstances in
which C/C++ is the best choice for circumstances X.  But I will
add two important caveats: carefully-chosen language subsets
significantly mitigate the problems, and interoperability with
existing code bases dictate the language (the COBOL problem/argument).

[toc] | [prev] | [next] | [standalone]

#18701

On 17/10/14 10:29, Tom Gardner wrote:
> On 17/10/14 08:27, David Brown wrote:
>> If you don't know what your C++ code is doing, that's /your/ problem,
>> not the language's problem.
> 
> Well yes. But some languages do have more obscured traps that
> that require higher levels of skill and more continual alertness.
> 
> The interesting question is always "given circumstances X, is
> Y or Z the more appropriate language".
> 
> One of the problems with modern C and C compilers (compared with
> K&R C) is that their sophistication places far more subtle traps
> that require language lawyers to understand. When even the language
> lawyers disagree amongst themselves, that's not a good starting
> point.

If you were purely discussing the compilers, then I might partially
agree - modern compilers are more advanced and have more optimisations
than old tools that were closer to C-to-assembly translators.  So there
are issues, such as aliasing problems, that can make code that /looks/
correct behave incorrectly with modern tools.

Countering that, modern C is a better language - for example, it
requires proper function declaration, which eliminates a source of
obscure problems in K&R C.  And modern tools are far better at static
error checking and spotting issues that sailed past unnoticed in the
"good old days" - as long as you know how to use your tools, you will
write safer code with fewer bugs using modern tools.

Yes, there are fine points in the "law" that lead to disagreement
amongst the "lawyers".  The way to handle this is simple - the same way
as it has always been handled, and the same way you suggest below.
Avoid using such constructs or language features.

The same applies with C++, which has more scope for confusion and
complications (such as figuring out exactly which template instantiation
will be used).  If you are not sure, don't write code that you don't
understand.


> 
> K&R C had 228 pages. C Traps and Pitfalls had 228 pages. They
> were all you needed in the 80. How long are the modern equivalents?
> 
> So I will assert that nowadays there are fewer circumstances in
> which C/C++ is the best choice for circumstances X.  

I disagree, in the embedded world.  In PC programming, I agree - very
often you are better with a language like Python than with C or C++.

> But I will
> add two important caveats: carefully-chosen language subsets
> significantly mitigate the problems, and interoperability with
> existing code bases dictate the language (the COBOL problem/argument).


Yes (to both).

[toc] | [prev] | [next] | [standalone]

#18702

David Brown <david.brown@hesbynett.no> writes:
> I disagree, in the embedded world.  In PC programming, I agree - very
> often you are better with a language like Python than with C or C++.

I have to think that even in MCU programming there have to be better
alternatives to C or C++.  Ada seems like a possibility except that the
toolchains are either obscure or very expensive.  There have been some C
dialects like Cyclone that were clever but never got traction.  And I
guess there are some specialty EDSL's like Atom that aren't so good for
general purpose development.  Forth is interesting but it's from a
different world, and still unsafe though with fewer traps than C.

[toc] | [prev] | [next] | [standalone]

#18703

On 10/17/2014 11:35 AM, Paul Rubin wrote:
> David Brown <david.brown@hesbynett.no> writes:
>> I disagree, in the embedded world.  In PC programming, I agree - very
>> often you are better with a language like Python than with C or C++.
>
> I have to think that even in MCU programming there have to be better
> alternatives to C or C++.  Ada seems like a possibility except that the
> toolchains are either obscure or very expensive.  There have been some C

I don't know. I think Ada only helps protect against some superficial 
mistakes. It does nothing to prevent someone from using a poor overall 
design or conceptual errors that may be much harder to catch.

[toc] | [prev] | [next] | [standalone]

#18707

On 17/10/14 10:43, Arlet Ottens wrote:
> On 10/17/2014 11:35 AM, Paul Rubin wrote:
>> David Brown <david.brown@hesbynett.no> writes:
>>> I disagree, in the embedded world.  In PC programming, I agree - very
>>> often you are better with a language like Python than with C or C++.
>>
>> I have to think that even in MCU programming there have to be better
>> alternatives to C or C++.  Ada seems like a possibility except that the
>> toolchains are either obscure or very expensive.  There have been some C
>
> I don't know. I think Ada only helps protect against some superficial mistakes. It does nothing to prevent someone from using a poor overall design or conceptual errors that may be much harder to catch.

That's unhelpful. Nothing can protect against conceptual errors or
poor design. In the absence of anything better, I'll gratefully
accept any help in avoiding errors.

Apart from that, I wouldn't class some of the problems in C
(let alone C++) as being "superficial".  The problems that appear
can be very subtle, deep-seated, difficult to detect and, most
importantly, effectively impossible to ensure they aren't lurking
in the code.

[toc] | [prev] | [next] | [standalone]

#18709

On 10/17/2014 01:12 PM, Tom Gardner wrote:

>> I don't know. I think Ada only helps protect against some superficial
>> mistakes. It does nothing to prevent someone from using a poor overall
>> design or conceptual errors that may be much harder to catch.
>
> That's unhelpful. Nothing can protect against conceptual errors or
> poor design. In the absence of anything better, I'll gratefully
> accept any help in avoiding errors.

Sure, as long as it doesn't get in the way and doesn't have other 
disadvantages. In the case of Ada, there is a problem with availability 
of good tools and libraries, and there aren't as many users.

> Apart from that, I wouldn't class some of the problems in C
> (let alone C++) as being "superficial".  The problems that appear
> can be very subtle, deep-seated, difficult to detect and, most
> importantly, effectively impossible to ensure they aren't lurking
> in the code.

Can you give an example of such a problem (that another language would 
prevent) ?

[toc] | [prev] | [next] | [standalone]

#18710

On 17/10/14 12:25, Arlet Ottens wrote:
> On 10/17/2014 01:12 PM, Tom Gardner wrote:
>
>>> I don't know. I think Ada only helps protect against some superficial
>>> mistakes. It does nothing to prevent someone from using a poor overall
>>> design or conceptual errors that may be much harder to catch.
>>
>> That's unhelpful. Nothing can protect against conceptual errors or
>> poor design. In the absence of anything better, I'll gratefully
>> accept any help in avoiding errors.
>
> Sure, as long as it doesn't get in the way and doesn't have other disadvantages. In the case of Ada, there is a problem with availability of good tools and libraries, and there aren't as many users.
>
>> Apart from that, I wouldn't class some of the problems in C
>> (let alone C++) as being "superficial".  The problems that appear
>> can be very subtle, deep-seated, difficult to detect and, most
>> importantly, effectively impossible to ensure they aren't lurking
>> in the code.
>
> Can you give an example of such a problem (that another language would prevent) ?

Google is your friend :)

Start with aliasing, consider libraries and applications using
different compilers and optimisation settings, Nick MacLaren's
"Objects Diatribe". Etc.

[toc] | [prev] | [next] | [standalone]

#18732

On 14-10-17 12:43 , Arlet Ottens wrote:
> On 10/17/2014 11:35 AM, Paul Rubin wrote:
>> David Brown <david.brown@hesbynett.no> writes:
>>> I disagree, in the embedded world.  In PC programming, I agree - very
>>> often you are better with a language like Python than with C or C++.
>>
>> I have to think that even in MCU programming there have to be better
>> alternatives to C or C++.  Ada seems like a possibility except that the
>> toolchains are either obscure or very expensive.

Ada toolchains remain a problem, but things are changing. AdaCore now
provides a free (both free-beer and free-speech) ARM Cortex version of
the GNU Ada compiler, GNAT. There is also a version for the AVR
8-bitters. The TI MSP430 is also being worked on. No Ada compiler yet
(as far as I know) for the 8051 series.

> I don't know. I think Ada only helps protect against some superficial
> mistakes. It does nothing to prevent someone from using a poor overall
> design or conceptual errors that may be much harder to catch.

I disagree. The set of problem-modelling tools in Ada is much stronger
and more expressive than in C. It is much easier to think and design in
problem-domain terms. A real module / package system, integer types
defined by what you need and not by the implementation, private and
abstract types, classes and inheritance, ...

Ada is of course more comparable to C++ than to C, but Ada has none of
the inherited "C baggage" that distorts and weakens C++.

-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
      .      @       .

[toc] | [prev] | [next] | [standalone]

#18735

On Fri, 17 Oct 2014 20:12:03 +0300
Niklas Holsti <niklas.holsti@tidorum.invalid> wrote:

> On 14-10-17 12:43 , Arlet Ottens wrote:
> > On 10/17/2014 11:35 AM, Paul Rubin wrote:
> >> David Brown <david.brown@hesbynett.no> writes:
> >>> I disagree, in the embedded world.  In PC programming, I agree - very
> >>> often you are better with a language like Python than with C or C++.
> >>
> >> I have to think that even in MCU programming there have to be better
> >> alternatives to C or C++.  Ada seems like a possibility except that the
> >> toolchains are either obscure or very expensive.
> 
> Ada toolchains remain a problem, but things are changing. AdaCore now
> provides a free (both free-beer and free-speech) ARM Cortex version of
> the GNU Ada compiler, GNAT. There is also a version for the AVR
> 8-bitters. The TI MSP430 is also being worked on. No Ada compiler yet
> (as far as I know) for the 8051 series.
> 
> > I don't know. I think Ada only helps protect against some superficial
> > mistakes. It does nothing to prevent someone from using a poor overall
> > design or conceptual errors that may be much harder to catch.
> 
> I disagree. The set of problem-modelling tools in Ada is much stronger
> and more expressive than in C. It is much easier to think and design in
> problem-domain terms. A real module / package system, integer types
> defined by what you need and not by the implementation, private and
> abstract types, classes and inheritance, ...
> 
> Ada is of course more comparable to C++ than to C, but Ada has none of
> the inherited "C baggage" that distorts and weakens C++.
> 
> -- 
> Niklas Holsti
> Tidorum Ltd
> niklas holsti tidorum fi
>       .      @       .

The last time I even thought about using Ada, I got scared off by the
size of the runtime you needed to go with it (tens of KB).  Anyone know
if that's still the case?

-- 
Rob Gaddi, Highland Technology -- www.highlandtechnology.com
Email address domain is currently out of order.  See above to fix.

[toc] | [prev] | [next] | [standalone]

#18743

On Fri, 17 Oct 2014 10:18:21 -0700, Rob Gaddi
<rgaddi@technologyhighland.invalid> wrote:

>On Fri, 17 Oct 2014 20:12:03 +0300
>Niklas Holsti <niklas.holsti@tidorum.invalid> wrote:
>
>> On 14-10-17 12:43 , Arlet Ottens wrote:
>> > On 10/17/2014 11:35 AM, Paul Rubin wrote:
>> >> David Brown <david.brown@hesbynett.no> writes:
>> >>> I disagree, in the embedded world.  In PC programming, I agree - very
>> >>> often you are better with a language like Python than with C or C++.
>> >>
>> >> I have to think that even in MCU programming there have to be better
>> >> alternatives to C or C++.  Ada seems like a possibility except that the
>> >> toolchains are either obscure or very expensive.
>> 
>> Ada toolchains remain a problem, but things are changing. AdaCore now
>> provides a free (both free-beer and free-speech) ARM Cortex version of
>> the GNU Ada compiler, GNAT. There is also a version for the AVR
>> 8-bitters. The TI MSP430 is also being worked on. No Ada compiler yet
>> (as far as I know) for the 8051 series.
>> 
>> > I don't know. I think Ada only helps protect against some superficial
>> > mistakes. It does nothing to prevent someone from using a poor overall
>> > design or conceptual errors that may be much harder to catch.
>> 
>> I disagree. The set of problem-modelling tools in Ada is much stronger
>> and more expressive than in C. It is much easier to think and design in
>> problem-domain terms. A real module / package system, integer types
>> defined by what you need and not by the implementation, private and
>> abstract types, classes and inheritance, ...
>> 
>> Ada is of course more comparable to C++ than to C, but Ada has none of
>> the inherited "C baggage" that distorts and weakens C++.
>> 
>> -- 
>> Niklas Holsti
>> Tidorum Ltd
>> niklas holsti tidorum fi
>>       .      @       .
>
>The last time I even thought about using Ada, I got scared off by the
>size of the runtime you needed to go with it (tens of KB).  Anyone know
>if that's still the case?

How much non-military application has actually been written in any
dialect of ADA ? 

The only one I know of, were some Nokia MPS-10 systems intended for
banking in the early 1980's. 

Some countries, in the addition to the USA, required ADA for their
military applications in the same era.

[toc] | [prev] | [next] | [standalone]

#18747

On 14-10-17 21:53 , upsidedown@downunder.com wrote:
> On Fri, 17 Oct 2014 10:18:21 -0700, Rob Gaddi
> <rgaddi@technologyhighland.invalid> wrote:
> 
>> On Fri, 17 Oct 2014 20:12:03 +0300
>> Niklas Holsti <niklas.holsti@tidorum.invalid> wrote:
>>
>>> On 14-10-17 12:43 , Arlet Ottens wrote:
>>>> On 10/17/2014 11:35 AM, Paul Rubin wrote:
>>>>> David Brown <david.brown@hesbynett.no> writes:
>>>>>> I disagree, in the embedded world.  In PC programming, I agree - very
>>>>>> often you are better with a language like Python than with C or C++.
>>>>>
>>>>> I have to think that even in MCU programming there have to be better
>>>>> alternatives to C or C++.  Ada seems like a possibility except that the
>>>>> toolchains are either obscure or very expensive.
>>>
>>> Ada toolchains remain a problem, but things are changing. AdaCore now
>>> provides a free (both free-beer and free-speech) ARM Cortex version of
>>> the GNU Ada compiler, GNAT. There is also a version for the AVR
>>> 8-bitters. The TI MSP430 is also being worked on. No Ada compiler yet
>>> (as far as I know) for the 8051 series.
>>>
>>>> I don't know. I think Ada only helps protect against some superficial
>>>> mistakes. It does nothing to prevent someone from using a poor overall
>>>> design or conceptual errors that may be much harder to catch.
>>>
>>> I disagree. The set of problem-modelling tools in Ada is much stronger
>>> and more expressive than in C. It is much easier to think and design in
>>> problem-domain terms. A real module / package system, integer types
>>> defined by what you need and not by the implementation, private and
>>> abstract types, classes and inheritance, ...
>>>
>>> Ada is of course more comparable to C++ than to C, but Ada has none of
>>> the inherited "C baggage" that distorts and weakens C++.
>>>
>>> -- 
>>> Niklas Holsti
>>> Tidorum Ltd
>>> niklas holsti tidorum fi
>>>       .      @       .
>>
>> The last time I even thought about using Ada, I got scared off by the
>> size of the runtime you needed to go with it (tens of KB).  Anyone know
>> if that's still the case?

You can choose to include the parts of the run-time libraries that you
want to use. The GNAT compiler has a "zero foot-print" mode where the
run-time is empty; of course this means that the application must manage
without some Ada features (tasking, mainly). GNAT provides a range of
run-times of various sizes and capabilities, and you can configure your
own selection too.

Same thing applies to C/C++: if you want to use threads/tasks, you must
include a kernel of some sort. Is "tens of KB" a lot these days?

That said, the main problem with Ada on microcontrollers today is still
the limited range of compilers/targets. I haven't tried it, but the
common opinion is that porting the gcc-based GNAT, and its run-time
system, to new targets is not an easy task, even if gcc already supports
the new target. Some people have succeeded to target ARM Cortex, Atmel
AVR, and TI MSP430. The run-time systems in these "amateur" ports are
still rudimentary, without tasking support, I believe.

The AdaCore GPL GNAT for ARM Cortex has a very usable tasking subset
(the "Ravenscar" profile).

> How much non-military application has actually been written in any
> dialect of ADA ? 

(Pro forma nit-pick: the name of the language is spelled Ada, after Ada
Lovelace, http://en.wikipedia.org/wiki/Ada_Lovelace.)

Typical uses are airplane control systems (civilian and military), air
traffic control systems (mainly civilian), railroad control systems,
space applications (civilian and military). I'm told that
banking/finance applications exist. More listed at www.adaic.org.

Some other resources: Reference manuals at
http://www.ada-auth.org/standards/. Free compilers at
http://libre.adacore.com/, also available in many Linux distributions
(best support in Debian). Also available in the MinGW gcc environment
for Windows, http://www.mingw.org/.

-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
      .      @       .

[toc] | [prev] | [next] | [standalone]

#18748

Niklas Holsti <niklas.holsti@tidorum.invalid> writes:
> That said, the main problem with Ada on microcontrollers today is still
> the limited range of compilers/targets. I haven't tried it, but the
> common opinion is that porting the gcc-based GNAT, and its run-time
> system, to new targets is not an easy task, even if gcc already supports
> the new target. 

I've heard of an Ada to C translator and I've been meaning to look into
it.  I guess it would be like the early implementations of C++ that
translated C++ to C.  You'd translate your Ada code and then run it
through a C compiler, using C as a portable assembler.

[toc] | [prev] | [next] | [standalone]

#18796

Paul Rubin <no.email@nospam.invalid> writes:

> I've heard of an Ada to C translator and I've been meaning to look
> into it.  I guess it would be like the early implementations of C++
> that translated C++ to C.  You'd translate your Ada code and then run
> it through a C compiler, using C as a portable assembler.

The (still working) Vermont Technical College cubesat was developed that
way. - Except that they actually developed in SPARK to ensure the
absence of run-time errors.

Greetings,

Jacob
-- 
"Hungh. You see! More bear. Yellow snow is always dead give-away."

[toc] | [prev] | [next] | [standalone]

#18803

Jacob Sparre Andersen <jacob@jacob-sparre.dk> writes:
>> I've heard of an Ada to C translator
> The (still working) Vermont Technical College cubesat was developed that
> way. - Except that they actually developed in SPARK to ensure the
> absence of run-time errors.

Do you know what Ada-to-C translation tools they used?
What do the tools do about the Ada runtime?
Thanks.

[toc] | [prev] | [next] | [standalone]

#18810

On 14-10-18 21:45 , Paul Rubin wrote:
> Jacob Sparre Andersen <jacob@jacob-sparre.dk> writes:
>>> I've heard of an Ada to C translator
>> The (still working) Vermont Technical College cubesat was developed that
>> way. - Except that they actually developed in SPARK to ensure the
>> absence of run-time errors.
> 
> Do you know what Ada-to-C translation tools they used?

I believe they used the AdaMagic compiler from SofCheck
(www.sofcheck.com). However, SofCheck has merged with AdaCore, and it
seems the Ada-to-C translator is no longer available -- darn. Perhaps is
AdaCore gets many requests...

There seems to be another such translator by MapuSoft,
http://www.mapusoft.com/ada-to-c-changer/.

> What do the tools do about the Ada runtime?

If the VTC cubesat was done in SPARK, they probably did not use tasking.

For the MapuSoft translator, they claim to support several real-time
kernels, and claim to support all of Ada 83 and Ada 95, but the easily
viewable descriptions of the translator do not mention tasking and
run-times explicitly.

-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
      .      @       .

[toc] | [prev] | [next] | [standalone]

#18826

Niklas Holsti wrote:
> On 14-10-18 21:45 , Paul Rubin wrote:

>> Do you know what Ada-to-C translation tools they used?
>
> I believe they used the AdaMagic compiler from SofCheck
> (www.sofcheck.com). However, SofCheck has merged with AdaCore, and it
> seems the Ada-to-C translator is no longer available -- darn. Perhaps
> is AdaCore gets many requests...

It is still available, even if they don't advertise it.

>> What do the tools do about the Ada runtime?

AdaMagic has a (supposedly) full Ada runtime written in C.  How much of
it is included depends on how much is used and how good the C compiler
for the target is at eliminating unused code.

> If the VTC cubesat was done in SPARK, they probably did not use
> tasking.

I've never seen the VTC team mention RavenSPARK (i.e. SPARK with
tasking), so that is probably true.  And as they have proved the absence
of exceptions, there isn't much runtime use left (if any).

Greetings,

Jacob
-- 
The backhoe is the natural predator of the fiber optic cable.

[toc] | [prev] | [next] | [standalone]

#18795

Rob Gaddi wrote:

> The last time I even thought about using Ada, I got scared off by the
> size of the runtime you needed to go with it (tens of KB).  Anyone
> know if that's still the case?

I'm not sure if that is quite the case today.  You can do actual "work"
with GNAT for Mindstorms NXT, where you have the application and
run-time for ARM Cortex M series in 64 kb.  (The run-time may still
account for a few tens of kb.)

When I target the 8 bit Atmel AVR MCUs I usually work with a
"zero-footprint run-time".

Greetings,

Jacob
-- 
"I just might be wrong."

[toc] | [prev] | [next] | [standalone]

Page 1 of 6  [1] 2 3 4 5 6  Next page →

Back to top | Article view | comp.arch.embedded

csiph-web