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

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

C++, Ada, ...

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

Contents

  C++, Ada, ... pozz <pozzugno@gmail.com> - 2021-04-17 17:48 +0200
    Re: C++, Ada, ... David Brown <david.brown@hesbynett.no> - 2021-04-17 18:45 +0200
      Re: C++, Ada, ... Tom Gardner <spamjunk@blueyonder.co.uk> - 2021-04-17 19:55 +0100
        Re: C++, Ada, ... David Brown <david.brown@hesbynett.no> - 2021-04-18 12:53 +0200
          Re: C++, Ada, ... Niklas Holsti <niklas.holsti@tidorum.invalid> - 2021-04-18 18:48 +0300
            Re: C++, Ada, ... David Brown <david.brown@hesbynett.no> - 2021-04-18 18:59 +0200
              Re: C++, Ada, ... Niklas Holsti <niklas.holsti@tidorum.invalid> - 2021-04-19 13:51 +0300
                Re: C++, Ada, ... David Brown <david.brown@hesbynett.no> - 2021-04-19 14:22 +0200
                  Re: C++, Ada, ... Niklas Holsti <niklas.holsti@tidorum.invalid> - 2021-04-19 19:16 +0300
                    Re: C++, Ada, ... David Brown <david.brown@hesbynett.no> - 2021-04-19 22:19 +0200
                      Re: C++, Ada, ... Niklas Holsti <niklas.holsti@tidorum.invalid> - 2021-04-20 01:03 +0300
                        Re: C++, Ada, ... Richard Damon <Richard@Damon-Family.org> - 2021-04-19 18:09 -0400
                        Re: C++, Ada, ... David Brown <david.brown@hesbynett.no> - 2021-04-20 06:58 +0200
                          Re: C++, Ada, ... Paul Rubin <no.email@nospam.invalid> - 2021-04-19 23:18 -0700
                            Re: C++, Ada, ... David Brown <david.brown@hesbynett.no> - 2021-04-20 09:36 +0200
                Re: C++, Ada, ... Paul Rubin <no.email@nospam.invalid> - 2021-04-19 12:20 -0700
                  Re: C++, Ada, ... Niklas Holsti <niklas.holsti@tidorum.invalid> - 2021-04-20 00:26 +0300
                    Re: C++, Ada, ... Paul Rubin <no.email@nospam.invalid> - 2021-04-19 16:01 -0700
                      Re: C++, Ada, ... Niklas Holsti <niklas.holsti@tidorum.invalid> - 2021-04-20 10:47 +0300
                  Re: C++, Ada, ... Tom Gardner <spamjunk@blueyonder.co.uk> - 2021-04-19 23:30 +0100
      Re: C++, Ada, ... Clifford Heath <no.spam@please.net> - 2021-04-18 08:29 +1000
      Re: C++, Ada, ... Niklas Holsti <niklas.holsti@tidorum.invalid> - 2021-04-18 10:39 +0300
        Re: C++, Ada, ... David Brown <david.brown@hesbynett.no> - 2021-04-18 14:59 +0200
          Re: C++, Ada, ... Niklas Holsti <niklas.holsti@tidorum.invalid> - 2021-04-18 19:23 +0300
            Re: C++, Ada, ... David Brown <david.brown@hesbynett.no> - 2021-04-18 19:26 +0200
              Re: C++, Ada, ... Tom Gardner <spamjunk@blueyonder.co.uk> - 2021-04-18 19:29 +0100
                Re: C++, Ada, ... David Brown <david.brown@hesbynett.no> - 2021-04-18 22:23 +0200
                  Re: C++, Ada, ... Tom Gardner <spamjunk@blueyonder.co.uk> - 2021-04-18 23:09 +0100
                    Re: C++, Ada, ... David Brown <david.brown@hesbynett.no> - 2021-04-19 08:56 +0200
                  Re: C++, Ada, ... Niklas Holsti <niklas.holsti@tidorum.invalid> - 2021-04-19 14:04 +0300
                    Re: C++, Ada, ... Dimiter_Popoff <dp@tgi-sci.com> - 2021-04-19 15:16 +0300
                      Re: C++, Ada, ... Paul Rubin <no.email@nospam.invalid> - 2021-04-19 12:47 -0700
                        Re: C++, Ada, ... Niklas Holsti <niklas.holsti@tidorum.invalid> - 2021-04-20 00:37 +0300
                          Re: C++, Ada, ... David Brown <david.brown@hesbynett.no> - 2021-04-20 07:50 +0200
                    Re: C++, Ada, ... David Brown <david.brown@hesbynett.no> - 2021-04-19 14:26 +0200
              Re: C++, Ada, ... Tom Gardner <spamjunk@blueyonder.co.uk> - 2021-04-18 19:30 +0100
                Re: C++, Ada, ... David Brown <david.brown@hesbynett.no> - 2021-04-18 22:17 +0200
                  Re: C++, Ada, ... Tom Gardner <spamjunk@blueyonder.co.uk> - 2021-04-18 23:17 +0100
                    Re: C++, Ada, ... David Brown <david.brown@hesbynett.no> - 2021-04-19 08:52 +0200
                      Re: C++, Ada, ... Tom Gardner <spamjunk@blueyonder.co.uk> - 2021-04-19 10:08 +0100
                        Re: C++, Ada, ... David Brown <david.brown@hesbynett.no> - 2021-04-19 12:15 +0200
                          Re: C++, Ada, ... Tom Gardner <spamjunk@blueyonder.co.uk> - 2021-04-19 12:00 +0100
                      Re: C++, Ada, ... Tauno Voipio <tauno.voipio@notused.fi.invalid> - 2021-04-19 16:15 +0300
                        Re: C++, Ada, ... David Brown <david.brown@hesbynett.no> - 2021-04-19 15:43 +0200
      Re: C++, Ada, ... pozz <pozzugno@gmail.com> - 2021-04-19 18:38 +0200
        Re: C++, Ada, ... Paul Rubin <no.email@nospam.invalid> - 2021-04-19 10:48 -0700
        Re: C++, Ada, ... Tom Gardner <spamjunk@blueyonder.co.uk> - 2021-04-19 19:33 +0100
          Re: C++, Ada, ... Tauno Voipio <tauno.voipio@notused.fi.invalid> - 2021-04-20 15:09 +0300
            Re: C++, Ada, ... Tom Gardner <spamjunk@blueyonder.co.uk> - 2021-04-20 15:29 +0100
        Re: C++, Ada, ... David Brown <david.brown@hesbynett.no> - 2021-04-19 22:48 +0200
          Re: C++, Ada, ... pozz <pozzugno@gmail.com> - 2021-04-19 23:17 +0200
            Re: C++, Ada, ... Paul Rubin <no.email@nospam.invalid> - 2021-04-19 15:55 -0700
              Re: C++, Ada, ... David Brown <david.brown@hesbynett.no> - 2021-04-20 08:21 +0200
            Re: C++, Ada, ... David Brown <david.brown@hesbynett.no> - 2021-04-20 08:20 +0200
    Re: C++, Ada, ... Dave Nadler <drn@nadler.com> - 2021-04-17 21:07 -0400
      Re: C++, Ada, ... Don Y <blockedofcourse@foo.invalid> - 2021-04-17 18:53 -0700
      Re: C++, Ada, ... Tom Gardner <spamjunk@blueyonder.co.uk> - 2021-04-18 09:42 +0100
    Re: C++, Ada, ... dalai lamah <antonio12358@hotmail.com> - 2021-04-18 14:39 +0200

Page 3 of 3 — ← Prev page 1 2 [3]

#30507

On 19/04/2021 11:08, Tom Gardner wrote:
> On 19/04/21 07:52, David Brown wrote:
>> On 19/04/2021 00:17, Tom Gardner wrote:
>>> Infamously, getting a valid C++ program that cause the
>>> compiler to generate the sequence of prime numbers during
>>> compilation came as an unpleasant /surprise/ to the C++
>>> standards committee.
>>
>> I don't believe that the surprise was "unpleasant" - it's just something
>> they hadn't considered.  (I'm not even sure of that either - my feeling
>> is that this is an urban myth, or at least a story exaggerated in the
>> regular retelling.)
> 
> I was thinking of "unpleasant" /because/ it was a surprise.
> Bjarne dismissed the possibility before being stunned a
> couple of days later.
> 
> Here's a google (mis)translation of the Erwin Unruh's account at
> http://www.erwin-unruh.de/meta.html
> 
> Temple meta programming

<snip for brevity>

> 
> 
>> Template-based calculations are a bit like trying to do calculations and
>> data structures in LaTeX.  It is all possible, but it doesn't roll off
>> the tongue very easily.
> 
> Being perverse can be fun, /provided/ it doesn't happen
> accidentally in everyday life.

Usually it is not a problem when you discover something has extra
features or possibilities beyond what you imagined.  About the only
disadvantage of "turbine-complete" templates is that compilers need to
have limits to how hard they will try to compile them - it would be
quite inconvenient to have your compiler work for hours trying to
calculate Ackerman(5, 2) before melting your processor.

(I've done "perverted" stuff in LaTeX - but it wasn't an accident.
Fortunately I don't have to do it /every/ day.)

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

#30509

On 19/04/21 11:15, David Brown wrote:
> (I've done "perverted" stuff in LaTeX - but it wasn't an accident.
> Fortunately I don't have to do it/every/  day.)

We've all done that in one language or another!

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

#30514

On 19.4.21 9.52, David Brown wrote:
> On 19/04/2021 00:17, Tom Gardner wrote:
>> On 18/04/21 21:17, David Brown wrote:
>>> On 18/04/2021 20:30, Tom Gardner wrote:
>>>> On 18/04/21 18:26, David Brown wrote:
>>>>> C++ has got a lot stronger at compile-time work in recent versions.
>>>>> Not
>>>>> only have templates got more powerful, but we've got "concepts" (named
>>>>> sets of features or requirements for types), constexpr functions (that
>>>>> can be evaluated at compile time or runtime), consteval functions (that
>>>>> must be evaluated at compile time), constinit data (that must have
>>>>> compile-time constant initialisers), etc.  And constants determined at
>>>>> compile-time are not restricted to scaler or simple types.
>>>>
>>>> Sounds wordy ;)
>>>
>>> Have you looked at the C++ standards documents?  There are more than a
>>> few words there!
>>
>> No. I value my sanity.
> 
> I have looked at it, and come back as sane as ever (apart from the
> pencils up my nose and underpants on my head).  But I've worked up to it
> through many versions of the C standards.
> 
> More seriously, if I need to look up any details of C or C++, I find
> <https://en.cppreference.com/w/> vastly more user-friendly.
> 
>>
>>
>>> I'm not suggesting C++ is a perfect language - not by a long way.  It
>>> has plenty of ugliness, and in this thread we've covered several points
>>> where Ada can do something neater and clearer than you can do it in C++.
>>>
>>> But it's a good thing that it has more ways for handling things at
>>> compile time.  In many of my C projects, I have had Python code for
>>> pre-processing, for computing tables, and that kind of thing.  With
>>> modern C++, these are no longer needed.
>>
>> The useful question is not whether something is good,
>> but whether there are better alternatives. "Better",
>> of course, can include /anything/ relevant!
>>
> 
> Yes - and "better" is usually highly subjective.
> 
> In the case of compile-time calculations, modern C++ is certainly better
> than older C++ versions or C (or, AFAIK, Ada).  It can't do everything
> that I might do with external Python scripts - it can't do code
> generation, or make tables that depend on multiple source files, or make
> CRC checks for the final binary.  But it can do some things that
> previously required external scripts, and that's nice.
> 
>>
>>
>>> An odd thing about the compile-time calculation features of C++ is that
>>> they came about partly by accident, or unforeseen side-effects.  Someone
>>> discovered that templates with integer parameters could be used to do
>>> quite a lot of compile-time calculations.  The code was /really/ ugly,
>>> slow to compile, limited in scope.  But people were finding use for it.
>>>    So the motivation for "constexpr" was that programmers were already
>>> doing compile-time calculations, and so it was best to let them do it in
>>> a nicer way.
>>
>> Infamously, getting a valid C++ program that cause the
>> compiler to generate the sequence of prime numbers during
>> compilation came as an unpleasant /surprise/ to the C++
>> standards committee.
> 
> I don't believe that the surprise was "unpleasant" - it's just something
> they hadn't considered.  (I'm not even sure of that either - my feeling
> is that this is an urban myth, or at least a story exaggerated in the
> regular retelling.)
> 
>>
>> The code is short; whether it is ugly is a matter of taste!
>> https://en.wikibooks.org/wiki/C%2B%2B_Programming/Templates/Template_Meta-Programming#History_of_TMP
>>
> 
> Template-based calculations were certainly very convoluted - they needed
> a functional programming style structure but with much more awkward
> syntax (and at the height of their "popularity", horrendous compiler
> error messages when you made a mistake - that too has improved greatly).
>   And that is why constexpr (especially in latest versions) is so much
> better.
> 
> Template-based calculations are a bit like trying to do calculations and
> data structures in LaTeX.  It is all possible, but it doesn't roll off
> the tongue very easily.
> 
> 
> (I wonder if anyone else understands the pencil and underpants
> reference.  I am sure Tom does.)


I just wonder if templates and C++ would be valid for the IOCCC contest.
The example would be a good candidate.

-- 

-TV

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

#30515

On 19/04/2021 15:15, Tauno Voipio wrote:
> On 19.4.21 9.52, David Brown wrote:
>> On 19/04/2021 00:17, Tom Gardner wrote:

>>>
>>> The code is short; whether it is ugly is a matter of taste!
>>> https://en.wikibooks.org/wiki/C%2B%2B_Programming/Templates/Template_Meta-Programming#History_of_TMP
>>>
>>>
>>
>> Template-based calculations were certainly very convoluted - they needed
>> a functional programming style structure but with much more awkward
>> syntax (and at the height of their "popularity", horrendous compiler
>> error messages when you made a mistake - that too has improved greatly).
>>   And that is why constexpr (especially in latest versions) is so much
>> better.
>>
>> Template-based calculations are a bit like trying to do calculations and
>> data structures in LaTeX.  It is all possible, but it doesn't roll off
>> the tongue very easily.
>>
>>
>> (I wonder if anyone else understands the pencil and underpants
>> reference.  I am sure Tom does.)
> 
> 
> I just wonder if templates and C++ would be valid for the IOCCC contest.
> The example would be a good candidate.
> 

I am sure that if the IOCCC were open to C++ entries, templates would be
involved.

But that particular example is not hard to follow IMHO.  The style is
more like functional programming, with recursion and pattern matching
rather than loops and conditionals, so that might make it difficult to
understand at first.

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

#30517

Il 17/04/2021 18:45, David Brown ha scritto:
> On 17/04/2021 17:48, pozz wrote:
>> What do you think about different languages than usual C for embedded
>> systems?
>>
>> I mean C++, Ada but also Python. Always more powerful embedded
>> processors are coming, so I expect new and modern languages will enter
>> in the embedded world.
>>
>> Hardware are cheaper and more powerful than ever, but software stays
>> expensive. New and modern languages could reduce the software cost,
>> because they are simpler than C and much more similar to desktop/server
>> programming paradigm.
>>
>> We embedded sw developers were lucky: electronics and technologies
>> change rapidly, but sw for embedded has changed slower than
>> desktop/mobile sw. Think of mobile app developers: maybe they already
>> changed IDEs, tools and languages ten times in a few years.
>> C language for embedded is today very similar than 10 years ago.
>>
>> However I think this situation for embedded developers will change in
>> the very next years. And we will be forced to learn modern technologies,
>> such as new languages and tools.
>> Is it ok for me to study and learn new things... but it will be more
>> difficult to acquire new skills for real jobs.
>>
>> What do you think?
> 
> You should probably add Rust to your list - I think its popularity will
> increase.
> 
> Python is great when you have the resources.  It's the language I use
> most on PC's and servers, and it is very common on embedded Linux
> systems (like Pi's, and industrial equivalents).  Micropython is
> sometimes found on smaller systems, such as ESP32 devices.
> 
> Ada involves a fair amount of change to how you work, compared to C
> development.  (Disclaimer - I have only done a very small amount of Ada
> coding, and no serious projects.  But I have considered it as an
> option.)  I really don't see it becoming much more common, and outside
> of niche areas (defence, aerospace) it is very rare.  Programming in Ada
> often takes a lot more effort even for simple things, leading quickly to
> code that is so wordy that it is unclear what is going on.  And most of
> the advantages of Ada (such as better typing) can be achieved in C++
> with less effort, and at the same time C++ can give additional safety on
> resources that is harder to get on Ada.  (But Ada has some nice features
> introspective that C++ programmers currently only dream about.)
> 
> C++ is not uncommon in embedded systems, and I expect to see more of it.
>   I use it as my main embedded language now.  C++ gives more scope for
> getting things wrong in weird ways, and more scope for accidentally
> making your binary massively larger than you expect, but with care it
> makes it a lot easier to write clear code and safe code, where common C
> mistakes either can't happen or you get compile-time failures.
> 
> It used to be the case that C++ compilers were expensive and poor
> quality, that the resulting code was very slow on common
> microcontrollers, and that the language didn't have much extra to offer
> small-systems embedded developers.  That, I think, has changed in all
> aspects.  I use gcc 10 with C++17 on Cortex-M devices, and features like
> templates, strong enumerations, std::array, and controlled automatic
> conversions make it easier to write good code.

What do you suggest for a poor C embedded developer that wants to try 
C++ on the next project?

I would use gcc on Cortex-M MCUs.

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

#30518

pozz <pozzugno@gmail.com> writes:
> What do you suggest for a poor C embedded developer that wants to try
> C++ on the next project?

I'm not sure what kind of answer you are looking for, but I recommend
the book "Effective Modern C++" by Scott Meyers.  C++ is a mudball with
many layers of cruft, that improved tremendously over the past few
revisions.  The book shows you how to do things the right way, using the
improvements instead of the cruft.

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

#30519

On 19/04/21 17:38, pozz wrote:

> What do you suggest for a poor C embedded developer that wants to try C++ on the 
> next project?

Choose a /very/ small project, and try to Get It Right (TM).

When you think there might be a better set of implementation
cliches and design strategies, refactor bits of your code to
investigate them.

Don't forget to use your favourite IDE to do the mechanics
of that refactoring.

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

#30540

On 19.4.21 21.33, Tom Gardner wrote:
> On 19/04/21 17:38, pozz wrote:
> 
>> What do you suggest for a poor C embedded developer that wants to try 
>> C++ on the next project?
> 
> Choose a /very/ small project, and try to Get It Right (TM).
> 
> When you think there might be a better set of implementation
> cliches and design strategies, refactor bits of your code to
> investigate them.
> 
> Don't forget to use your favourite IDE to do the mechanics
> of that refactoring.

I'd like to add: Read the generated assembly code. C++ is
prone to exlpode surprises into it.

An experienced C embedded programmer would read the code,
anyway ...

-- 

-TV

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

#30541

On 20/04/21 13:09, Tauno Voipio wrote:
> On 19.4.21 21.33, Tom Gardner wrote:
>> On 19/04/21 17:38, pozz wrote:
>>
>>> What do you suggest for a poor C embedded developer that wants to try C++ on 
>>> the next project?
>>
>> Choose a /very/ small project, and try to Get It Right (TM).
>>
>> When you think there might be a better set of implementation
>> cliches and design strategies, refactor bits of your code to
>> investigate them.
>>
>> Don't forget to use your favourite IDE to do the mechanics
>> of that refactoring.
> 
> I'd like to add: Read the generated assembly code. C++ is
> prone to exlpode surprises into it.
> 
> An experienced C embedded programmer would read the code,
> anyway ...

Agreed.

Unfortunately I've come across too many interview
candidates that haven't a clue about the code emitted
by a compiler when it encounters a function call.

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

#30523

On 19/04/2021 18:38, pozz wrote:

> What do you suggest for a poor C embedded developer that wants to try
> C++ on the next project?
> 
> I would use gcc on Cortex-M MCUs.
> 

I'm not entirely sure what you are asking - "gcc on Cortex-M" is, I
would say, the right answer if you are asking about tools.

Go straight to a new C++ standard - C++17.  (If you see anything that
mentions C++98 or C++03, run away - it is pointless unless you have to
maintain old code.)  Lots of things got a lot easier in C++11, and have
improved since.  Unfortunately the law of backwards compatibility means
old cruft still has to work, and is still there in language.  But that
doesn't mean you have to use it.

Go straight to a newer gcc - gcc 10 from GNU Arm Embedded.  The error
messages are much better (or at least less horrendous), and the static
checking is better.  Be generous with your warnings, and use a good IDE
with syntax highlighting and basic checking in the editor.

Disable exceptions and RTTI (-fno-exceptions -fno-rtti), and enable
optimisation.  C++ (used well) results in massive and incomprehensible
assembly unless you have at least -O1.

Don't try and learn everything at once.  Some things, like rvalue
references, are hard and rarely useful unless you are writing serious
template libraries.  There are many features of C++ that are needed to
write libraries rather than use them.

Don't be afraid of templates - they are great.

Be wary of the bigger parts of the C++ standard library - std::vector
and std::unordered_map are very nice for PC programming, but are far too
dynamic for small systems embedded programming.  (std::array, however,
is extremely useful.  And I like std::optional.)

Think about how the code might be implemented - if it seems that a
feature or class could be implemented in reasonably efficient object
code on a Cortex-M, then it probably will be.  If it looks like it will
need dynamic memory, it probably does.

Big class inheritance hierarchies, especially with multiple inheritance,
virtual functions, etc., is old-fashioned.  Where you can, use
compile-time (static) polymorphism rather than run-time polymorphism.
That means templates, overloaded functions, CRTP, etc.


Keep <https://en.cppreference.com/w/cpp> handy.  Same goes for
<https://godbolt.org>.

And keep smiling! [](){}();  (That's the C++11 smiley - when you
understand what it means, you're laughing!)

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

#30524

Il 19/04/2021 22:48, David Brown ha scritto:
> On 19/04/2021 18:38, pozz wrote:
> 
>> What do you suggest for a poor C embedded developer that wants to try
>> C++ on the next project?
>>
>> I would use gcc on Cortex-M MCUs.
>>
> 
> I'm not entirely sure what you are asking - "gcc on Cortex-M" is, I
> would say, the right answer if you are asking about tools.

I mentioned the tools just as a starting point. I don't know almost 
anything about C++, but I coded C for many years. I think there are some 
precautions to take in this situation to learn C++ respect learing C++ 
as the first language.


> Go straight to a new C++ standard - C++17.  (If you see anything that
> mentions C++98 or C++03, run away - it is pointless unless you have to
> maintain old code.)  Lots of things got a lot easier in C++11, and have
> improved since.  Unfortunately the law of backwards compatibility means
> old cruft still has to work, and is still there in language.  But that
> doesn't mean you have to use it.
> 
> Go straight to a newer gcc - gcc 10 from GNU Arm Embedded.  The error
> messages are much better (or at least less horrendous), and the static
> checking is better.  Be generous with your warnings, and use a good IDE
> with syntax highlighting and basic checking in the editor.
> 
> Disable exceptions and RTTI (-fno-exceptions -fno-rtti), and enable
> optimisation.  C++ (used well) results in massive and incomprehensible
> assembly unless you have at least -O1.
> 
> Don't try and learn everything at once.  Some things, like rvalue
> references, are hard and rarely useful unless you are writing serious
> template libraries.  There are many features of C++ that are needed to
> write libraries rather than use them.
> 
> Don't be afraid of templates - they are great.
> 
> Be wary of the bigger parts of the C++ standard library - std::vector
> and std::unordered_map are very nice for PC programming, but are far too
> dynamic for small systems embedded programming.  (std::array, however,
> is extremely useful.  And I like std::optional.)
> 
> Think about how the code might be implemented - if it seems that a
> feature or class could be implemented in reasonably efficient object
> code on a Cortex-M, then it probably will be.  If it looks like it will
> need dynamic memory, it probably does.

Dynamic memory... is it possible to have a C++ project without using 
heap at all?


> Big class inheritance hierarchies, especially with multiple inheritance,
> virtual functions, etc., is old-fashioned.  Where you can, use
> compile-time (static) polymorphism rather than run-time polymorphism.
> That means templates, overloaded functions, CRTP, etc.
> 
> 
> Keep <https://en.cppreference.com/w/cpp> handy.  Same goes for
> <https://godbolt.org>.
> 
> And keep smiling! [](){}();  (That's the C++11 smiley - when you
> understand what it means, you're laughing!)
> 

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

#30531

pozz <pozzugno@gmail.com> writes:
> I mentioned the tools just as a starting point. I don't know almost
> anything about C++, but I coded C for many years. I think there are
> some precautions to take in this situation to learn C++ respect
> learing C++ as the first language.

In this case use the book I mentioned, plus Stroustrup's introductory
book "Programming: Principles and Practice Using C++" is supposed to be
good (I haven't used it).  He also wrote "The C++ Programming language"
which is more of a reference manual and which I found indispensible.
Make sure to get the most recent edition in either case.  C++ changed
tremendously with C++11 and anything from before that should be
considered near-useless.  So that means 4th edition or later for the
reference manual: I'm not sure for the intro book.

Alternatively it might be best to skip C++ entirely and use Ada or
Rust.  I don't have a clear picture in my mind of how to address that.

> Dynamic memory... is it possible to have a C++ project without using
> heap at all?

Yes, C++ is a superset of C, more or less.  You do have to maintain some
awareness of where dynamic allocation can happen, to avoid using it,
at least after program initialization is finished.

>> And keep smiling! [](){}();  (That's the C++11 smiley - when you
>> understand what it means, you're laughing!)

Heh, if that means what I think it means.  

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

#30537

On 20/04/2021 00:55, Paul Rubin wrote:

>>> And keep smiling! [](){}();  (That's the C++11 smiley - when you
>>> understand what it means, you're laughing!)
> 
> Heh, if that means what I think it means.  
> 

If you think it means anything at all, then you are probably correct
about what you think it means.  (That sounds a bit cryptic, but it is
meant literally.)

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

#30536

On 19/04/2021 23:17, pozz wrote:
> Il 19/04/2021 22:48, David Brown ha scritto:
>> On 19/04/2021 18:38, pozz wrote:
>>
>>> What do you suggest for a poor C embedded developer that wants to try
>>> C++ on the next project?
>>>
>>> I would use gcc on Cortex-M MCUs.
>>>
>>
>> I'm not entirely sure what you are asking - "gcc on Cortex-M" is, I
>> would say, the right answer if you are asking about tools.
> 
> I mentioned the tools just as a starting point. I don't know almost
> anything about C++, but I coded C for many years. I think there are some
> precautions to take in this situation to learn C++ respect learing C++
> as the first language.
> 
> 
>> Go straight to a new C++ standard - C++17.  (If you see anything that
>> mentions C++98 or C++03, run away - it is pointless unless you have to
>> maintain old code.)  Lots of things got a lot easier in C++11, and have
>> improved since.  Unfortunately the law of backwards compatibility means
>> old cruft still has to work, and is still there in language.  But that
>> doesn't mean you have to use it.
>>
>> Go straight to a newer gcc - gcc 10 from GNU Arm Embedded.  The error
>> messages are much better (or at least less horrendous), and the static
>> checking is better.  Be generous with your warnings, and use a good IDE
>> with syntax highlighting and basic checking in the editor.
>>
>> Disable exceptions and RTTI (-fno-exceptions -fno-rtti), and enable
>> optimisation.  C++ (used well) results in massive and incomprehensible
>> assembly unless you have at least -O1.
>>
>> Don't try and learn everything at once.  Some things, like rvalue
>> references, are hard and rarely useful unless you are writing serious
>> template libraries.  There are many features of C++ that are needed to
>> write libraries rather than use them.
>>
>> Don't be afraid of templates - they are great.
>>
>> Be wary of the bigger parts of the C++ standard library - std::vector
>> and std::unordered_map are very nice for PC programming, but are far too
>> dynamic for small systems embedded programming.  (std::array, however,
>> is extremely useful.  And I like std::optional.)
>>
>> Think about how the code might be implemented - if it seems that a
>> feature or class could be implemented in reasonably efficient object
>> code on a Cortex-M, then it probably will be.  If it looks like it will
>> need dynamic memory, it probably does.
> 
> Dynamic memory... is it possible to have a C++ project without using
> heap at all?
> 

Baring a few minor issues and easy tweaks, pretty much any C code will
also be valid C++ code.  Some people use C++ as ABC (A Better C), taking
advantage of a few features like better constants, references (rather
than pointers), namespaces, and other points that look like they could
work as extensions to C rather than a new language.

In general, you avoid dynamic memory in C++ by avoiding "new" or any
standard library functions that might use it - just as you avoid
"malloc" in C by not using it.  There are many standard types and
functions that can use dynamic memory in C++, but usually it is quite
obvious if they will need it or not.

When you want to be more sophisticated, C++ gives you features to
override and control "new" and memory allocation in many ways, with
memory pools and custom code.  But don't try that in the first couple of
days.

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

#30480

On 4/17/2021 11:48 AM, pozz wrote:
> What do you think about different languages than usual C for embedded 
> systems?
> 
> I mean C++, Ada but also Python. Always more powerful embedded 
> processors are coming, so I expect new and modern languages will enter 
> in the embedded world.

Another +1 for C++. We started using C++ for embedded ~25 years ago, and 
the tool quality (and language) is vastly better now. Main problem using 
C++ is lack of available qualified staff - too many still only trained 
in C. C++, even more than C, *requires* painful amount of knowledge of 
how things work under the hood to use safely, not a good quality for any 
tool in any realm. But for *qualified* developers, C++ certainly gives 
faster development, produces better (ie faster/smaller) code, and 
generally improves life (compared to C).

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

#30481

On 4/17/2021 6:07 PM, Dave Nadler wrote:

> Another +1 for C++. We started using C++ for embedded ~25 years ago, and the 
> tool quality (and language) is vastly better now. Main problem using C++ is 
> lack of available qualified staff - too many still only trained in C. C++, even 
> more than C, *requires* painful amount of knowledge of how things work under 
> the hood to use safely, not a good quality for any tool in any realm. But for 
> *qualified* developers, C++ certainly gives faster development, produces better 
> (ie faster/smaller) code, and generally improves life (compared to C).

This is exactly why I *don't* use C++ (or any "new fangled" languages)
for product development.  I'm often the "Rev 1" author of a product.
Then, move on (to another product, another client, another application
domain).

I'm contractually obligated to fix bugs in my code (indefinitely and at no
charge) -- it's one of my selling points ("Yes, I'm *that* confident in the
code I've created for you!")

The last thing I need is some coder-wannabe tweeking my code with some
"harmless" change... then, defiantly claiming (to his management)
that the newly broken code is a consequence of my initial design
(he's just UNCOVERED a bug).

So, I get called back to *teach* the dweeb why what he's done
won't work.  And, in the process, inevitably have to show him
how to do what he wants to do.

Yeah, I can bill the client -- which is countered with "but you said
you'd support your code, for free?" (yeah, but that wasn't MY code!).
Regardless, I'm not keen on spending my time as a tutor!

Or, swallow it as cost of doing business.

It's considerably easier to find multiple C coders (and hope one
of them will catch the guy's mistake) than a qualified C++, Erlang,
Python, etc. coder -- esp when you're dealing with small firms.

So, my strategy becomes:  "Have you rebuilt MY sources using the
tools that *I* used?  Does the product exhibit this bug?  If not,
it's not my problem!"

[I can do this even with some other language.  But, the dweeb will
inevitably claim -- to the owner/management -- that his changes are
benign.  They, of course, won't want to think they hired an inept
employee, so...]

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

#30483

On 18/04/21 02:07, Dave Nadler wrote:
> Main problem using C++ is lack of available qualified staff - too many still 
> only trained in C. C++, even more than C, *requires* painful amount of knowledge 
> of how things work under the hood to use safely, not a good quality for any tool 
> in any realm.

Yes indeed. Especially when coupled with inexperience leading
someone to believe they understand C or C++.

Your other (valid) caveats and points snipped for brevity.

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

#30486

Un bel giorno pozz digitò:

> What do you think about different languages than usual C for embedded 
> systems?
> 
> I mean C++, Ada but also Python. Always more powerful embedded 
> processors are coming, so I expect new and modern languages will enter 
> in the embedded world.

I wouldn't include C++ in the list of "modern languages". One might as well
use C.

As for the "more modern" languages (Python, C#, Java etc) I've used most of
them and maybe it's the old man in me speaking, but I haven't felt any
inherent important advantages in using them. Their success is mostly due to
better support by popular development tools.

These days, smarter people praise functional programming languages
(Haskell, Clojure, etc...). They promise tangible advantages compared to
imperative languages, especially for maintainability and reliability. But I
think that even if they will gain popularity, years would pass before you
will see real applications in the embedded world.

Python is a "hybrid", it can be also used as a functional programming
language, and it will probably gain popularity in embedded systems.

-- 
Fletto i muscoli e sono nel vuoto.

[toc] | [prev] | [standalone]

Page 3 of 3 — ← Prev page 1 2 [3]

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

csiph-web