Rocksolid Light

Welcome to novaBBS (click a section below)

mail  files  register  newsreader  groups  login

Message-ID:  

Most public domain software is free, at least at first glance.


devel / comp.arch.embedded / Re: C++, Ada, ...

SubjectAuthor
* C++, Ada, ...pozz
+* Re: C++, Ada, ...David Brown
|+* Re: C++, Ada, ...Tom Gardner
||`* Re: C++, Ada, ...David Brown
|| `* Re: C++, Ada, ...Niklas Holsti
||  `* Re: C++, Ada, ...David Brown
||   `* Re: C++, Ada, ...Niklas Holsti
||    +* Re: C++, Ada, ...David Brown
||    |`* Re: C++, Ada, ...Niklas Holsti
||    | `* Re: C++, Ada, ...David Brown
||    |  `* Re: C++, Ada, ...Niklas Holsti
||    |   +- Re: C++, Ada, ...Richard Damon
||    |   `* Re: C++, Ada, ...David Brown
||    |    `* Re: C++, Ada, ...Paul Rubin
||    |     `- Re: C++, Ada, ...David Brown
||    `* Re: C++, Ada, ...Paul Rubin
||     +* Re: C++, Ada, ...Niklas Holsti
||     |`* Re: C++, Ada, ...Paul Rubin
||     | `- Re: C++, Ada, ...Niklas Holsti
||     `- Re: C++, Ada, ...Tom Gardner
|+- Re: C++, Ada, ...Clifford Heath
|+* Re: C++, Ada, ...Niklas Holsti
||`* Re: C++, Ada, ...David Brown
|| `* Re: C++, Ada, ...Niklas Holsti
||  `* Re: C++, Ada, ...David Brown
||   +* Re: C++, Ada, ...Tom Gardner
||   |`* Re: C++, Ada, ...David Brown
||   | +* Re: C++, Ada, ...Tom Gardner
||   | |`- Re: C++, Ada, ...David Brown
||   | `* Re: C++, Ada, ...Niklas Holsti
||   |  +* Re: C++, Ada, ...Dimiter_Popoff
||   |  |`* Re: C++, Ada, ...Paul Rubin
||   |  | `* Re: C++, Ada, ...Niklas Holsti
||   |  |  `- Re: C++, Ada, ...David Brown
||   |  `- Re: C++, Ada, ...David Brown
||   `* Re: C++, Ada, ...Tom Gardner
||    `* Re: C++, Ada, ...David Brown
||     `* Re: C++, Ada, ...Tom Gardner
||      `* Re: C++, Ada, ...David Brown
||       +* Re: C++, Ada, ...Tom Gardner
||       |`* Re: C++, Ada, ...David Brown
||       | `- Re: C++, Ada, ...Tom Gardner
||       `* Re: C++, Ada, ...Tauno Voipio
||        `- Re: C++, Ada, ...David Brown
|`* Re: C++, Ada, ...pozz
| +- Re: C++, Ada, ...Paul Rubin
| +* Re: C++, Ada, ...Tom Gardner
| |`* Re: C++, Ada, ...Tauno Voipio
| | `- Re: C++, Ada, ...Tom Gardner
| `* Re: C++, Ada, ...David Brown
|  `* Re: C++, Ada, ...pozz
|   +* Re: C++, Ada, ...Paul Rubin
|   |`- Re: C++, Ada, ...David Brown
|   `- Re: C++, Ada, ...David Brown
+* Re: C++, Ada, ...Dave Nadler
|+- Re: C++, Ada, ...Don Y
|`- Re: C++, Ada, ...Tom Gardner
`- Re: C++, Ada, ...dalai lamah

Pages:123
Re: C++, Ada, ...

<ie55l3F3ou7U1@mid.individual.net>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=330&group=comp.arch.embedded#330

 copy link   Newsgroups: comp.arch.embedded
Path: i2pn2.org!i2pn.org!news.swapon.de!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail
From: niklas.h...@tidorum.invalid (Niklas Holsti)
Newsgroups: comp.arch.embedded
Subject: Re: C++, Ada, ...
Date: Mon, 19 Apr 2021 13:51:14 +0300
Organization: Tidorum Ltd
Lines: 285
Message-ID: <ie55l3F3ou7U1@mid.individual.net>
References: <s5f01b$4j3$1@dont-email.me> <s5f3c1$s06$1@dont-email.me>
<AaGeI.148580$qHh9.147135@fx18.ams4> <s5h32f$edv$1@dont-email.me>
<ie32luFlvghU1@mid.individual.net> <s5hogv$77o$1@dont-email.me>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-15; format=flowed
Content-Transfer-Encoding: 8bit
X-Trace: individual.net xFGeLXYPgtIh4bOOfCkw5wfIGuIECT/3qnCigQoscPEzF0urRm
Cancel-Lock: sha1:5F9bB57ndFXVNdBSoWvtn0zgZW4=
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:78.0)
Gecko/20100101 Thunderbird/78.7.0
In-Reply-To: <s5hogv$77o$1@dont-email.me>
Content-Language: en-US
 by: Niklas Holsti - Mon, 19 Apr 2021 10:51 UTC

On 2021-04-18 19:59, David Brown wrote:
> On 18/04/2021 17:48, Niklas Holsti wrote:
>> On 2021-04-18 13:53, David Brown wrote:
>>> On 17/04/2021 20:55, Tom Gardner wrote:
>>>> On 17/04/21 17:45, David Brown wrote:
>>>>> 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.
>>>>
>>>> Interesting. Could you give a quick outline of that?
>>>>
>>>
>>> Which part?
>>>
>>> My understanding of Ada classes is that, like Pascal classes, you need
>>> to explicitly construct and destruct objects.  This gives far greater
>>> scope for programmers to get things wrong than when they are handled
>>> automatically by the language.
>>
>>
>> If you mean automatic allocation and deallocation of storage, Ada lets
>> you define types that have an "initializer" that is called
>> automatically, and can allocate memory if it needs to, and a "finalizer"
>> that is automatically called when leaving the scope of the object in
>> question. The finalizer does have to explicitly deallocate any
>> explicitly allocated and owned resources, and it may have to use
>> reference counting for that, for complex data structures.
>
> I had a little look for this (these discussions are great for inspiring
> learning!). The impression I got was that it was possible, but what
> takes a few lines of C++ (excluding whatever work must be done inside
> the constructor and destructor bodies) involves inheriting from a
> specific library type.

Yes, you must inherit from one of the types Ada.Finalization.Controlled
or Ada.Finalization.Limited_Controlled when you create a type for which
you can program an initializer and/or a finalizer.

However, you can aggregate a component of such a type into some other
composite type, and then that component's initializer and finalizer will
be called automatically when any object of the containing composite type
is constructed and destroyed.

> And you don't have automatic initialisation of
> subobjects and ancestors in a controlled order, nor automatic
> finalisation of them in the reverse order.

No, and yes. Subobjects (components) are automatically initialized
before the composite is initialized (bottom-up), and are automatically
finalized after the composite is finalized (top-down). But there is no
automatic invocation of the initializer or finalizer of the parent
class; that would have to be called explicitly (except in the case of an
"extension aggregate" expression, where an object of the parent type is
created and then extended to an object of the derived class).

The Ada initializer and finalizer concept is subtly different from the
C++ constructor and destructor concept. In Ada, the construction and
destruction are considered to happen implicitly and automatically. The
construction step can assign some initial values that can be defined by
default (pointers default to null, for example) or can be specified for
the type of the component in question, or can be defined for that
component explicitly. For example:

type Down_Counter is range 0 .. 100 with Default_Value => 100;

type Zero_Handler is access procedure;

type Counter is record
Count   : Down_Counter; -- Implicit init to 100.
Running : Boolean := False; -- Explicit init.
At_Zero : Zero_Handler; -- Default init to null.
end record;

Beyond that automatic construction step, the programmable initializer is
used to perform further automatic activities that may further initialize
the object, or may have some other effects. For example, we might want
to automatically register every instance of a Counter (as above) with
the kernel, and that would be done in the initializer. Conversely, the
finalizer would then deregister the Counter, before the Counter is
automatically destroyed (removed from the stack or from the heap).

So the Ada "initializer" is not like a C++ constructor, which in Ada
corresponds more closely to a function returning an object of the class.

An Ada "finalizer" is more similar to a C++ destructor, taking care of
any clean-up that is needed before the object disappears.

>
> Let's take a little example. And since this is comp.arch.embedded,
> let's take a purely embedded example of disabling interrupts, rather
> than shunned dynamic memory allocations:
>
> static inline uint32_t disableGlobalInterrupts(void) {
> uint32_t pri;
> asm volatile(
> " mrs %[pri], primask\n\t" // Get old mask
> " cpsid i\n\t" // Disable interrupts entirely
> " dsb" // Ensures that this takes effect before next
> // instruction
> : [pri] "=r" (pri) :: "memory");
> return pri;
> }
>
> static inline void restoreGlobalInterrupts(uint32_t pri) {
> asm volatile(
> " msr primask, %[pri]" // Restore old mask
> :: [pri] "r" (pri) : "memory");
> }

I won't try to write Ada equivalents of the above :-) though I have of
course written much Ada code to manage and handle interrupts.

> class CriticalSectionLock {
> private :
> uint32_t oldpri;
> public :
> CriticalSectionLock() { oldpri = disableGlobalInterrupts(); }
> ~CriticalSectionLock() { restoreGlobalInterrupts(oldpri); }
> };

Here is the same in Ada. I chose to derive from Limited_Controlled
because that makes it illegal to assign a Critical_Section value from
one object to another.

-- Declaration of the type:

type Critical_Section is new Ada.Finalization.Limited_Controlled
with record
old_pri : Interfaces.Unsigned_32;
end record;

overriding procedure Initialize (This : in out Critical_Section);
overriding procedure Finalize (This : in out Critical_Section);

-- Implementation of the operations:

procedure Initialize (This : in out Critical_Section)
is begin
This.old_pri := disableGlobalInterrupts;
end Initialize;

procedure Finalize (This : in out Critical_Section)
is begin
restoreGlobalInterrupts (This.old_pri);
end Finalize;

>
> You can use it like this:
>
> bool compare_and_swap64(uint64_t * p, uint64_t old, uint64_t x)
> {
> CriticalSectionLock lock;
>
> if (*p != old) return false;
> *p = x;
> return true;
> }
>

function Compare_and_Swap64 (
p : access Interfaces.Unsigned_64;
old, x : in Interfaces.Unsigned_64)
return Boolean
is
Lock : Critical_Section;
begin
if p.all /= old then
return False;
else
p.all := x;
return True;
end if;
end Compare_and_Swap64;

(I think there should be a "volatile" spec for the "p" object, don't you?)

> This is the code compiled for a 32-bit Cortex-M device:
>
> <https://godbolt.org/z/7KM9M6Kcd>
>
> The use of the class here has no overhead compared to manually disabling
> and re-enabling interrupts.
>
> What would be the Ada equivalent of this class, and of the
> "compare_and_swap64" function?

See above. I don't have an Ada-to-Cortex-M compiler at hand to compare
the target code, sorry.

But critical sections in Ada applications are more often written using
the Ada "protected object" feature. Here is the same as a protected
object "CS", with separate declaration and body as usual in Ada. Here I
must write the operation as a procedure instead of a function, because
protected objects have "single writer, multiple readers" semantics, and
any function is considered a "reader" although it may have side effects:

protected CS
with Priority => System.Interrupt_Priority'Last
is

procedure Compare_and_Swap64 (
p : access Interfaces.Unsigned_64;
old, x : in Interfaces.Unsigned_64;
result : out Boolean);

end CS;

protected body CS
is

procedure Compare_and_Swap64 (
p : access Interfaces.Unsigned_64;
old, x : in Interfaces.Unsigned_64;
result : out Boolean);
is begin
result := p.all = old;
if result then
p.all := x;
end if;
end Compare_and_Swap64;

end CS;

However, it would be more in the style of Ada to focus on the thing that
is being "compared and swapped", so that "p" would be either a
discriminant of the protected object, or a component of the protected
object, instead of a parameter to the copy-and-swap operation. But it
would look similar to the above.


Click here to read the complete article
Re: C++, Ada, ...

<EpdfI.187757$k0F8.104244@fx27.ams4>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=331&group=comp.arch.embedded#331

 copy link   Newsgroups: comp.arch.embedded
Path: i2pn2.org!i2pn.org!usenet.goja.nl.eu.org!2.eu.feeder.erje.net!feeder.erje.net!newsfeed.xs4all.nl!newsfeed7.news.xs4all.nl!50.7.236.10.MISMATCH!news-out.netnews.com!news.alt.net!fdc2.netnews.com!peer03.ams1!peer.ams1.xlned.com!news.xlned.com!peer03.ams4!peer.am4.highwinds-media.com!news.highwinds-media.com!fx27.ams4.POSTED!not-for-mail
Reply-To: spamjunk@blueyonder.co.uk
Subject: Re: C++, Ada, ...
Newsgroups: comp.arch.embedded
References: <s5f01b$4j3$1@dont-email.me> <s5f3c1$s06$1@dont-email.me>
<ie260rFghneU1@mid.individual.net> <s5hafg$g1$1@dont-email.me>
<ie34olFmda9U1@mid.individual.net> <s5hq48$k2e$1@dont-email.me>
<WU_eI.237389$KHwf.63256@fx25.ams4> <s5i441$tro$1@dont-email.me>
<Kd2fI.273342$zV01.166134@fx49.ams4> <s5j9bk$ced$1@dont-email.me>
<BMbfI.171837$9Poc.19162@fx24.ams4> <s5jl7g$sdh$1@dont-email.me>
From: spamj...@blueyonder.co.uk (Tom Gardner)
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101
Firefox/52.0 SeaMonkey/2.49.4
MIME-Version: 1.0
In-Reply-To: <s5jl7g$sdh$1@dont-email.me>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Lines: 5
Message-ID: <EpdfI.187757$k0F8.104244@fx27.ams4>
X-Complaints-To: http://netreport.virginmedia.com
NNTP-Posting-Date: Mon, 19 Apr 2021 11:00:52 UTC
Organization: virginmedia.com
Date: Mon, 19 Apr 2021 12:00:52 +0100
X-Received-Bytes: 1387
 by: Tom Gardner - Mon, 19 Apr 2021 11:00 UTC

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!

Re: C++, Ada, ...

<ie56dqF3t0qU1@mid.individual.net>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=332&group=comp.arch.embedded#332

 copy link   Newsgroups: comp.arch.embedded
Path: i2pn2.org!i2pn.org!news.swapon.de!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail
From: niklas.h...@tidorum.invalid (Niklas Holsti)
Newsgroups: comp.arch.embedded
Subject: Re: C++, Ada, ...
Date: Mon, 19 Apr 2021 14:04:26 +0300
Organization: Tidorum Ltd
Lines: 50
Message-ID: <ie56dqF3t0qU1@mid.individual.net>
References: <s5f01b$4j3$1@dont-email.me> <s5f3c1$s06$1@dont-email.me>
<ie260rFghneU1@mid.individual.net> <s5hafg$g1$1@dont-email.me>
<ie34olFmda9U1@mid.individual.net> <s5hq48$k2e$1@dont-email.me>
<qU_eI.237388$KHwf.234963@fx25.ams4> <s5i4gh$nb$1@dont-email.me>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-15; format=flowed
Content-Transfer-Encoding: 8bit
X-Trace: individual.net K5zrHccmaoB8QH2Y3/bgzwTffj/Pwmpjv2PPjktmRbpeQDIOyv
Cancel-Lock: sha1:FPkN/9xYG7Nz0LYpFdJsBXjRPwo=
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:78.0)
Gecko/20100101 Thunderbird/78.7.0
In-Reply-To: <s5i4gh$nb$1@dont-email.me>
Content-Language: en-US
 by: Niklas Holsti - Mon, 19 Apr 2021 11:04 UTC

On 2021-04-18 23:23, David Brown wrote:
> On 18/04/2021 20:29, Tom Gardner wrote:
>> On 18/04/21 18:26, David Brown wrote:
>>> But some programmers have not changed, and the way they write C code has
>>> not changed.  Again, it's a question of whether you are comparing how
>>> languages/could/  be used at their best, or how some people use them at
>>> their worst, or guessing something in between.
>>
>> That is indeed a useful first question.
>>
>> A second question is "how easy is it to get intelligent
>> but inexperienced programmers to avoid the worst features
>> and use the languages well?" (We'll ignore all the programmers
>> that shouldn't be given a keyboard :) )
>>
>> A third is "will that happen in company X's environment when
>> they are extending code written by people that left 5 years
>> ago?"
>
> All good questions.
>
> Another is what will happen to the company when the one person that
> understood the language at all, leaves?

If the company trained only one person in the language, that was a
stupid (risky) decision by the company, or they should not have started
using that language at all.

> With C++, you can hire another
> qualified and experienced C++ programmer. (Okay, so you might have to
> beat them over the head with an 8051 emulator until they stop using
> std::vector and realise you don't want UCS2 encoding for your 2x20
> character display, but they'll learn that soon enough.) With Ada, or
> Forth, or any other minor language, you are scuppered.

During all my years (since about 1995) working on on-board SW for ESA
spacecraft, the company hired one person with earlier experience in Ada,
and that was I. All other hires working in Ada projects learned Ada on
the job (and some became enthusiasts).

Sadly, some of the large aerospace "prime" companies in Europe are
becoming unwilling to accept subcontracted SW products in Ada, for the
reason discussed: because their HR departments say that they cannot find
programmers trained in Ada. Bah, a competent programmer will pick up the
core concepts quickly, says I.

Of course there are also training companies that offer Ada training courses.

Re: C++, Ada, ...

<s5jsao$cpu$1@dont-email.me>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=333&group=comp.arch.embedded#333

 copy link   Newsgroups: comp.arch.embedded
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: dp...@tgi-sci.com (Dimiter_Popoff)
Newsgroups: comp.arch.embedded
Subject: Re: C++, Ada, ...
Date: Mon, 19 Apr 2021 15:16:24 +0300
Organization: TGI
Lines: 19
Message-ID: <s5jsao$cpu$1@dont-email.me>
References: <s5f01b$4j3$1@dont-email.me> <s5f3c1$s06$1@dont-email.me>
<ie260rFghneU1@mid.individual.net> <s5hafg$g1$1@dont-email.me>
<ie34olFmda9U1@mid.individual.net> <s5hq48$k2e$1@dont-email.me>
<qU_eI.237388$KHwf.234963@fx25.ams4> <s5i4gh$nb$1@dont-email.me>
<ie56dqF3t0qU1@mid.individual.net>
Reply-To: dp@tgi-sci.com
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-15; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Mon, 19 Apr 2021 12:16:24 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="961d7975367260de5583debfd729ccf4";
logging-data="13118"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+uunGQBB6B1cua529OLML+niQz9UUfPGo="
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101
Thunderbird/78.9.1
Cancel-Lock: sha1:v3X4F0dJJhJa/BYfZwgjZKlski0=
In-Reply-To: <ie56dqF3t0qU1@mid.individual.net>
Content-Language: en-US
 by: Dimiter_Popoff - Mon, 19 Apr 2021 12:16 UTC

On 4/19/2021 14:04, Niklas Holsti wrote:
> ....
> Sadly, some of the large aerospace "prime" companies in Europe are
> becoming unwilling to accept subcontracted SW products in Ada, for the
> reason discussed: because their HR departments say that they cannot find
> programmers trained in Ada. Bah, a competent programmer will pick up the
> core concepts quickly, says I.

This is valid not just for ADA. An experienced programmer will need days
to adjust to this or that language. I guess most if not all of us have
been through it.

Dimiter

======================================================
Dimiter Popoff, TGI http://www.tgi-sci.com
======================================================
http://www.flickr.com/photos/didi_tgi/

Re: C++, Ada, ...

<s5jslh$gl8$1@dont-email.me>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=334&group=comp.arch.embedded#334

 copy link   Newsgroups: comp.arch.embedded
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: david.br...@hesbynett.no (David Brown)
Newsgroups: comp.arch.embedded
Subject: Re: C++, Ada, ...
Date: Mon, 19 Apr 2021 14:22:09 +0200
Organization: A noiseless patient Spider
Lines: 384
Message-ID: <s5jslh$gl8$1@dont-email.me>
References: <s5f01b$4j3$1@dont-email.me> <s5f3c1$s06$1@dont-email.me>
<AaGeI.148580$qHh9.147135@fx18.ams4> <s5h32f$edv$1@dont-email.me>
<ie32luFlvghU1@mid.individual.net> <s5hogv$77o$1@dont-email.me>
<ie55l3F3ou7U1@mid.individual.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-15
Content-Transfer-Encoding: 8bit
Injection-Date: Mon, 19 Apr 2021 12:22:09 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="f21b347e432a7da8c8112e546840e277";
logging-data="17064"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18c8CUOmTSyhhUzrgyC4wCIO9agID11Kzc="
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
Thunderbird/68.10.0
Cancel-Lock: sha1:DQdVvusayaNj4tXwdL1LrX31RAo=
In-Reply-To: <ie55l3F3ou7U1@mid.individual.net>
Content-Language: en-GB
 by: David Brown - Mon, 19 Apr 2021 12:22 UTC

On 19/04/2021 12:51, Niklas Holsti wrote:
> On 2021-04-18 19:59, David Brown wrote:
>> On 18/04/2021 17:48, Niklas Holsti wrote:
>>> On 2021-04-18 13:53, David Brown wrote:
>>>> On 17/04/2021 20:55, Tom Gardner wrote:
>>>>> On 17/04/21 17:45, David Brown wrote:
>>>>>> 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.
>>>>>
>>>>> Interesting. Could you give a quick outline of that?
>>>>>
>>>>
>>>> Which part?
>>>>
>>>> My understanding of Ada classes is that, like Pascal classes, you need
>>>> to explicitly construct and destruct objects.  This gives far greater
>>>> scope for programmers to get things wrong than when they are handled
>>>> automatically by the language.
>>>
>>>
>>> If you mean automatic allocation and deallocation of storage, Ada lets
>>> you define types that have an "initializer" that is called
>>> automatically, and can allocate memory if it needs to, and a "finalizer"
>>> that is automatically called when leaving the scope of the object in
>>> question. The finalizer does have to explicitly deallocate any
>>> explicitly allocated and owned resources, and it may have to use
>>> reference counting for that, for complex data structures.
>>
>> I had a little look for this (these discussions are great for inspiring
>> learning!).  The impression I got was that it was possible, but what
>> takes a few lines of C++ (excluding whatever work must be done inside
>> the constructor and destructor bodies) involves inheriting from a
>> specific library type.
>
>
> Yes, you must inherit from one of the types Ada.Finalization.Controlled
> or Ada.Finalization.Limited_Controlled when you create a type for which
> you can program an initializer and/or a finalizer.
>
> However, you can aggregate a component of such a type into some other
> composite type, and then that component's initializer and finalizer will
> be called automatically when any object of the containing composite type
> is constructed and destroyed.
>
>
>> And you don't have automatic initialisation of
>> subobjects and ancestors in a controlled order, nor automatic
>> finalisation of them in the reverse order.
>
>
> No, and yes. Subobjects (components) are automatically initialized
> before the composite is initialized (bottom-up), and are automatically
> finalized after the composite is finalized (top-down). But there is no
> automatic invocation of the initializer or finalizer of the parent
> class; that would have to be called explicitly (except in the case of an
> "extension aggregate" expression, where an object of the parent type is
> created and then extended to an object of the derived class).
>

OK. Am I right in assuming the subobjects here also need to inherit
from the "Finalization" types individually, in order to be automatically
initialised in order?

Are there any overheads (other than in the source code) for all this
inheriting? Ada (like C++) aims to be minimal overhead, AFAIUI, but its
worth checking.

> The Ada initializer and finalizer concept is subtly different from the
> C++ constructor and destructor concept. In Ada, the construction and
> destruction are considered to happen implicitly and automatically. The
> construction step can assign some initial values that can be defined by
> default (pointers default to null, for example) or can be specified for
> the type of the component in question, or can be defined for that
> component explicitly. For example:
>
>    type Down_Counter is range 0 .. 100 with Default_Value => 100;
>
>    type Zero_Handler is access procedure;
>
>    type Counter is record
>       Count   : Down_Counter;      -- Implicit init to 100.
>       Running : Boolean := False;  -- Explicit init.
>       At_Zero : Zero_Handler;      -- Default init to null.
>    end record;
>
> Beyond that automatic construction step, the programmable initializer is
> used to perform further automatic activities that may further initialize
> the object, or may have some other effects. For example, we might want
> to automatically register every instance of a Counter (as above) with
> the kernel, and that would be done in the initializer. Conversely, the
> finalizer would then deregister the Counter, before the Counter is
> automatically destroyed (removed from the stack or from the heap).
>
> So the Ada "initializer" is not like a C++ constructor, which in Ada
> corresponds more closely to a function returning an object of the class.
>
> An Ada "finalizer" is more similar to a C++ destructor, taking care of
> any clean-up that is needed before the object disappears.
>

C++ gives you the choice. You can do work in a constructor, or you can
leave it as a minimal (often automatically generated) function. You can
give default values to members. You can add "initialise" member
functions as you like. You can have "factory functions" that generate
instances. This lets you structure the code and split up functionality
in whatever way suits your requirements.

For a well-structured class, the key point is that a constructor will
always establish the class invariant. Any publicly accessible function
will assume that invariant, and maintain it. Private functions might
temporarily break the invariant - these are only accessible by code that
"knows what it is doing". And the destructor will always clean up after
the object, recycling any resources used.

Having C++ style constructors are not a requirement for having control
of the class invariant, but they do make it more convenient and more
efficient (both at run-time and in the source code) than separate
minimal constructors (or default values) and initialisers.

>>
>> Let's take a little example.  And since this is comp.arch.embedded,
>> let's take a purely embedded example of disabling interrupts, rather
>> than shunned dynamic memory allocations:
>>
>> static inline uint32_t disableGlobalInterrupts(void) {
>>      uint32_t pri;
>>      asm volatile(
>>          "  mrs %[pri], primask\n\t" // Get old mask
>>          "  cpsid i\n\t"             // Disable interrupts entirely
>>          "  dsb"        // Ensures that this takes effect before next
>>                      // instruction
>>          : [pri] "=r" (pri) :: "memory");
>>      return pri;
>> }
>>
>> static inline void restoreGlobalInterrupts(uint32_t pri) {
>>      asm volatile(
>>          "  msr primask, %[pri]"         // Restore old mask
>>          :: [pri] "r" (pri) : "memory");
>> }
>
>
> I won't try to write Ada equivalents of the above :-) though I have of
> course written much Ada code to manage and handle interrupts.

I think Ada has built-in (or standard library) support for critical
sections, does it not? But this is just an example, not necessarily
something that would be directly useful. Obviously the code above is
highly target-specific.

>
>
>> class CriticalSectionLock {
>> private :
>>      uint32_t oldpri;
>> public :
>>      CriticalSectionLock() { oldpri = disableGlobalInterrupts(); }
>>      ~CriticalSectionLock() { restoreGlobalInterrupts(oldpri); }
>> };
>
>
> Here is the same in Ada. I chose to derive from Limited_Controlled
> because that makes it illegal to assign a Critical_Section value from
> one object to another.
>
>    -- Declaration of the type:
>
>    type Critical_Section is new Ada.Finalization.Limited_Controlled
>    with record
>       old_pri : Interfaces.Unsigned_32;
>    end record;
>
>    overriding procedure Initialize (This : in out Critical_Section);
>    overriding procedure Finalize   (This : in out Critical_Section);
>
>    -- Implementation of the operations:
>
>    procedure Initialize (This : in out Critical_Section)
>    is begin
>       This.old_pri := disableGlobalInterrupts;
>    end Initialize;
>
>    procedure Finalize (This : in out Critical_Section)
>    is begin
>       restoreGlobalInterrupts (This.old_pri);
>    end Finalize;
>
>


Click here to read the complete article
Re: C++, Ada, ...

<s5jssq$i53$1@dont-email.me>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=335&group=comp.arch.embedded#335

 copy link   Newsgroups: comp.arch.embedded
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: david.br...@hesbynett.no (David Brown)
Newsgroups: comp.arch.embedded
Subject: Re: C++, Ada, ...
Date: Mon, 19 Apr 2021 14:26:02 +0200
Organization: A noiseless patient Spider
Lines: 58
Message-ID: <s5jssq$i53$1@dont-email.me>
References: <s5f01b$4j3$1@dont-email.me> <s5f3c1$s06$1@dont-email.me>
<ie260rFghneU1@mid.individual.net> <s5hafg$g1$1@dont-email.me>
<ie34olFmda9U1@mid.individual.net> <s5hq48$k2e$1@dont-email.me>
<qU_eI.237388$KHwf.234963@fx25.ams4> <s5i4gh$nb$1@dont-email.me>
<ie56dqF3t0qU1@mid.individual.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-15
Content-Transfer-Encoding: 8bit
Injection-Date: Mon, 19 Apr 2021 12:26:02 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="f21b347e432a7da8c8112e546840e277";
logging-data="18595"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1//ehQvE0mT3cGM1PsDQJQQOQD/Pl+ssRc="
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
Thunderbird/68.10.0
Cancel-Lock: sha1:RHz2pbddsE+xN4Ox7hNZIKfmlSQ=
In-Reply-To: <ie56dqF3t0qU1@mid.individual.net>
Content-Language: en-GB
 by: David Brown - Mon, 19 Apr 2021 12:26 UTC

On 19/04/2021 13:04, Niklas Holsti wrote:
> On 2021-04-18 23:23, David Brown wrote:
>> On 18/04/2021 20:29, Tom Gardner wrote:
>>> On 18/04/21 18:26, David Brown wrote:
>>>> But some programmers have not changed, and the way they write C code
>>>> has
>>>> not changed.  Again, it's a question of whether you are comparing how
>>>> languages/could/  be used at their best, or how some people use them at
>>>> their worst, or guessing something in between.
>>>
>>> That is indeed a useful first question.
>>>
>>> A second question is "how easy is it to get intelligent
>>> but inexperienced programmers to avoid the worst features
>>> and use the languages well?" (We'll ignore all the programmers
>>> that shouldn't be given a keyboard :) )
>>>
>>> A third is "will that happen in company X's environment when
>>> they are extending code written by people that left 5 years
>>> ago?"
>>
>> All good questions.
>>
>> Another is what will happen to the company when the one person that
>> understood the language at all, leaves?
>
>
> If the company trained only one person in the language, that was a
> stupid (risky) decision by the company, or they should not have started
> using that language at all.
>
>
>> With C++, you can hire another
>> qualified and experienced C++ programmer.  (Okay, so you might have to
>> beat them over the head with an 8051 emulator until they stop using
>> std::vector and realise you don't want UCS2 encoding for your 2x20
>> character display, but they'll learn that soon enough.)  With Ada, or
>> Forth, or any other minor language, you are scuppered.
>
>
> During all my years (since about 1995) working on on-board SW for ESA
> spacecraft, the company hired one person with earlier experience in Ada,
> and that was I. All other hires working in Ada projects learned Ada on
> the job (and some became enthusiasts).
>
> Sadly, some of the large aerospace "prime" companies in Europe are
> becoming unwilling to accept subcontracted SW products in Ada, for the
> reason discussed: because their HR departments say that they cannot find
> programmers trained in Ada. Bah, a competent programmer will pick up the
> core concepts quickly, says I.
>

I agree with you there. But so many people learn "programming in C++"
or "programming in Java", rather than learning "programming".

> Of course there are also training companies that offer Ada training
> courses.

Re: C++, Ada, ...

<s5jvoo$4pk$1@dont-email.me>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=336&group=comp.arch.embedded#336

 copy link   Newsgroups: comp.arch.embedded
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: tauno.vo...@notused.fi.invalid (Tauno Voipio)
Newsgroups: comp.arch.embedded
Subject: Re: C++, Ada, ...
Date: Mon, 19 Apr 2021 16:15:04 +0300
Organization: A noiseless patient Spider
Lines: 102
Message-ID: <s5jvoo$4pk$1@dont-email.me>
References: <s5f01b$4j3$1@dont-email.me> <s5f3c1$s06$1@dont-email.me>
<ie260rFghneU1@mid.individual.net> <s5hafg$g1$1@dont-email.me>
<ie34olFmda9U1@mid.individual.net> <s5hq48$k2e$1@dont-email.me>
<WU_eI.237389$KHwf.63256@fx25.ams4> <s5i441$tro$1@dont-email.me>
<Kd2fI.273342$zV01.166134@fx49.ams4> <s5j9bk$ced$1@dont-email.me>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-15; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Mon, 19 Apr 2021 13:15:04 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="3c4bf5283297dc6031a7bebeb02de98d";
logging-data="4916"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18cv/ZkW9OmBAexIgivc7/cOXrQPaSjY3I="
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0)
Gecko/20100101 Thunderbird/78.9.1
Cancel-Lock: sha1:w7IW/3Uyh1/ugZ1iaPni9ag5bFg=
In-Reply-To: <s5j9bk$ced$1@dont-email.me>
Content-Language: en-GB
 by: Tauno Voipio - Mon, 19 Apr 2021 13:15 UTC

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

Re: C++, Ada, ...

<s5k1dd$jfe$1@dont-email.me>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=337&group=comp.arch.embedded#337

 copy link   Newsgroups: comp.arch.embedded
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: david.br...@hesbynett.no (David Brown)
Newsgroups: comp.arch.embedded
Subject: Re: C++, Ada, ...
Date: Mon, 19 Apr 2021 15:43:08 +0200
Organization: A noiseless patient Spider
Lines: 38
Message-ID: <s5k1dd$jfe$1@dont-email.me>
References: <s5f01b$4j3$1@dont-email.me> <s5f3c1$s06$1@dont-email.me>
<ie260rFghneU1@mid.individual.net> <s5hafg$g1$1@dont-email.me>
<ie34olFmda9U1@mid.individual.net> <s5hq48$k2e$1@dont-email.me>
<WU_eI.237389$KHwf.63256@fx25.ams4> <s5i441$tro$1@dont-email.me>
<Kd2fI.273342$zV01.166134@fx49.ams4> <s5j9bk$ced$1@dont-email.me>
<s5jvoo$4pk$1@dont-email.me>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-15
Content-Transfer-Encoding: 8bit
Injection-Date: Mon, 19 Apr 2021 13:43:09 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="f21b347e432a7da8c8112e546840e277";
logging-data="19950"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX185RejmR2nc4CoV9gvJ0X/e4JXCMT4C+C4="
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
Thunderbird/68.10.0
Cancel-Lock: sha1:KgifD2RPXxFIqEWs3W1gbMXYwSs=
In-Reply-To: <s5jvoo$4pk$1@dont-email.me>
Content-Language: en-GB
 by: David Brown - Mon, 19 Apr 2021 13:43 UTC

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.

Re: C++, Ada, ...

<ie5onhF7e7mU1@mid.individual.net>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=338&group=comp.arch.embedded#338

 copy link   Newsgroups: comp.arch.embedded
Path: i2pn2.org!i2pn.org!news.swapon.de!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail
From: niklas.h...@tidorum.invalid (Niklas Holsti)
Newsgroups: comp.arch.embedded
Subject: Re: C++, Ada, ...
Date: Mon, 19 Apr 2021 19:16:48 +0300
Organization: Tidorum Ltd
Lines: 355
Message-ID: <ie5onhF7e7mU1@mid.individual.net>
References: <s5f01b$4j3$1@dont-email.me> <s5f3c1$s06$1@dont-email.me>
<AaGeI.148580$qHh9.147135@fx18.ams4> <s5h32f$edv$1@dont-email.me>
<ie32luFlvghU1@mid.individual.net> <s5hogv$77o$1@dont-email.me>
<ie55l3F3ou7U1@mid.individual.net> <s5jslh$gl8$1@dont-email.me>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-15; format=flowed
Content-Transfer-Encoding: 8bit
X-Trace: individual.net NsnUufjDs17YzyihGaOTZgYrWKPOIqTF4uODMxfIWmG7LqqyHz
Cancel-Lock: sha1:odwB+2mfkmLB1Cx75ojMfeS+XJI=
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:78.0)
Gecko/20100101 Thunderbird/78.7.0
In-Reply-To: <s5jslh$gl8$1@dont-email.me>
Content-Language: en-US
 by: Niklas Holsti - Mon, 19 Apr 2021 16:16 UTC

On 2021-04-19 15:22, David Brown wrote:
> On 19/04/2021 12:51, Niklas Holsti wrote:
>> On 2021-04-18 19:59, David Brown wrote:
>>> On 18/04/2021 17:48, Niklas Holsti wrote:
>>>> On 2021-04-18 13:53, David Brown wrote:
>>>>> On 17/04/2021 20:55, Tom Gardner wrote:
>>>>>> On 17/04/21 17:45, David Brown wrote:
>>>>>>> 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.
>>>>>>
>>>>>> Interesting. Could you give a quick outline of that?
>>>>>>
>>>>>
>>>>> Which part?
>>>>>
>>>>> My understanding of Ada classes is that, like Pascal classes, you need
>>>>> to explicitly construct and destruct objects.  This gives far greater
>>>>> scope for programmers to get things wrong than when they are handled
>>>>> automatically by the language.
>>>>
>>>>
>>>> If you mean automatic allocation and deallocation of storage, Ada lets
>>>> you define types that have an "initializer" that is called
>>>> automatically, and can allocate memory if it needs to, and a "finalizer"
>>>> that is automatically called when leaving the scope of the object in
>>>> question. The finalizer does have to explicitly deallocate any
>>>> explicitly allocated and owned resources, and it may have to use
>>>> reference counting for that, for complex data structures.
>>>
>>> I had a little look for this (these discussions are great for inspiring
>>> learning!).  The impression I got was that it was possible, but what
>>> takes a few lines of C++ (excluding whatever work must be done inside
>>> the constructor and destructor bodies) involves inheriting from a
>>> specific library type.
>>
>>
>> Yes, you must inherit from one of the types Ada.Finalization.Controlled
>> or Ada.Finalization.Limited_Controlled when you create a type for which
>> you can program an initializer and/or a finalizer.
>>
>> However, you can aggregate a component of such a type into some other
>> composite type, and then that component's initializer and finalizer will
>> be called automatically when any object of the containing composite type
>> is constructed and destroyed.
>>
>>
>>> And you don't have automatic initialisation of
>>> subobjects and ancestors in a controlled order, nor automatic
>>> finalisation of them in the reverse order.
>>
>>
>> No, and yes. Subobjects (components) are automatically initialized
>> before the composite is initialized (bottom-up), and are automatically
>> finalized after the composite is finalized (top-down). But there is no
>> automatic invocation of the initializer or finalizer of the parent
>> class; that would have to be called explicitly (except in the case of an
>> "extension aggregate" expression, where an object of the parent type is
>> created and then extended to an object of the derived class).
>>
>
> OK. Am I right in assuming the subobjects here also need to inherit
> from the "Finalization" types individually, in order to be automatically
> initialised in order?

Yes, if they need more initialization than provided by the automatic
"construction" step (Default_Value etc.)

>
> Are there any overheads (other than in the source code) for all this
> inheriting? Ada (like C++) aims to be minimal overhead, AFAIUI, but its
> worth checking.
>

If the compiler sees the actual type of an object that needs
finalization (as in the critical-section example) it can generate direct
calls to Initialize and Finalize without dispatching. If the object is
polymorphic (what in Ada is called a "class") the calls must go through
a dispatch table according to the actual type of the object.

>> So the Ada "initializer" is not like a C++ constructor, which in Ada
>> corresponds more closely to a function returning an object of the class.
>>
>> An Ada "finalizer" is more similar to a C++ destructor, taking care of
>> any clean-up that is needed before the object disappears.
>>
>
> C++ gives you the choice. You can do work in a constructor, or you can
> leave it as a minimal (often automatically generated) function. You can
> give default values to members. You can add "initialise" member
> functions as you like. You can have "factory functions" that generate
> instances. This lets you structure the code and split up functionality
> in whatever way suits your requirements.

So, just as in Ada.

> For a well-structured class, the key point is that a constructor will
> always establish the class invariant. Any publicly accessible function
> will assume that invariant, and maintain it. Private functions might
> temporarily break the invariant - these are only accessible by code that
> "knows what it is doing". And the destructor will always clean up after
> the object, recycling any resources used.
>
> Having C++ style constructors are not a requirement for having control
> of the class invariant, but they do make it more convenient and more
> efficient (both at run-time and in the source code) than separate
> minimal constructors (or default values) and initialisers.

In Ada one can write the preconditions, invariants and postconditions in
the source code itself, with standard "aspects" and Ada Boolean
expressions, and have them either checked at run-time or verified by
static analysis/proof.

>>> Let's take a little example.  And since this is comp.arch.embedded,
>>> let's take a purely embedded example of disabling interrupts, rather
>>> than shunned dynamic memory allocations:
>>>
>>> static inline uint32_t disableGlobalInterrupts(void) {
>>>      uint32_t pri;
>>>      asm volatile(
>>>          "  mrs %[pri], primask\n\t" // Get old mask
>>>          "  cpsid i\n\t"             // Disable interrupts entirely
>>>          "  dsb"        // Ensures that this takes effect before next
>>>                      // instruction
>>>          : [pri] "=r" (pri) :: "memory");
>>>      return pri;
>>> }
>>>
>>> static inline void restoreGlobalInterrupts(uint32_t pri) {
>>>      asm volatile(
>>>          "  msr primask, %[pri]"         // Restore old mask
>>>          :: [pri] "r" (pri) : "memory");
>>> }
>>
>>
>> I won't try to write Ada equivalents of the above :-) though I have of
>> course written much Ada code to manage and handle interrupts.
>
> I think Ada has built-in (or standard library) support for critical
> sections, does it not?

Yes, "protected objects". See below.

> But this is just an example, not necessarily
> something that would be directly useful. Obviously the code above is
> highly target-specific.
>
>>
>>
>>> class CriticalSectionLock {
>>> private :
>>>      uint32_t oldpri;
>>> public :
>>>      CriticalSectionLock() { oldpri = disableGlobalInterrupts(); }
>>>      ~CriticalSectionLock() { restoreGlobalInterrupts(oldpri); }
>>> };
>>
>>
>> Here is the same in Ada. I chose to derive from Limited_Controlled
>> because that makes it illegal to assign a Critical_Section value from
>> one object to another.
>>
>>    -- Declaration of the type:
>>
>>    type Critical_Section is new Ada.Finalization.Limited_Controlled
>>    with record
>>       old_pri : Interfaces.Unsigned_32;
>>    end record;
>>
>>    overriding procedure Initialize (This : in out Critical_Section);
>>    overriding procedure Finalize   (This : in out Critical_Section);
>>
>>    -- Implementation of the operations:
>>
>>    procedure Initialize (This : in out Critical_Section)
>>    is begin
>>       This.old_pri := disableGlobalInterrupts;
>>    end Initialize;
>>
>>    procedure Finalize (This : in out Critical_Section)
>>    is begin
>>       restoreGlobalInterrupts (This.old_pri);
>>    end Finalize;
>>
>>
>
> Are "Initialize" and "Finalize" overloaded global procedures, or is this
> the syntax always used for member functions?


Click here to read the complete article
Re: C++, Ada, ...

<s5kbmv$528$1@dont-email.me>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=339&group=comp.arch.embedded#339

 copy link   Newsgroups: comp.arch.embedded
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: pozzu...@gmail.com (pozz)
Newsgroups: comp.arch.embedded
Subject: Re: C++, Ada, ...
Date: Mon, 19 Apr 2021 18:38:56 +0200
Organization: A noiseless patient Spider
Lines: 69
Message-ID: <s5kbmv$528$1@dont-email.me>
References: <s5f01b$4j3$1@dont-email.me> <s5f3c1$s06$1@dont-email.me>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-15; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Mon, 19 Apr 2021 16:38:55 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="8e347c36efe1133544d59b4435e371a7";
logging-data="5192"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/K6p5f7Q6Lm9TUG0fMaxCkOtG90vlTDMc="
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101
Thunderbird/78.9.1
Cancel-Lock: sha1:lastmwGTzM31haUfKs/cu+2WpyA=
In-Reply-To: <s5f3c1$s06$1@dont-email.me>
Content-Language: it
 by: pozz - Mon, 19 Apr 2021 16:38 UTC

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.

Re: C++, Ada, ...

<87lf9ego7j.fsf@nightsong.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=340&group=comp.arch.embedded#340

 copy link   Newsgroups: comp.arch.embedded
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: no.em...@nospam.invalid (Paul Rubin)
Newsgroups: comp.arch.embedded
Subject: Re: C++, Ada, ...
Date: Mon, 19 Apr 2021 10:48:32 -0700
Organization: A noiseless patient Spider
Lines: 9
Message-ID: <87lf9ego7j.fsf@nightsong.com>
References: <s5f01b$4j3$1@dont-email.me> <s5f3c1$s06$1@dont-email.me>
<s5kbmv$528$1@dont-email.me>
Mime-Version: 1.0
Content-Type: text/plain
Injection-Info: reader02.eternal-september.org; posting-host="9309f7be5b1d8e24271c45a8f9cf0e07";
logging-data="1709"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+HXbTed07oFJVGIKHv/1oz"
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux)
Cancel-Lock: sha1:gSYNOTPqC/YgoqRZZFgKKRNZGaY=
sha1:oayHlVK7cbPW6Hkv45zd70fIenk=
 by: Paul Rubin - Mon, 19 Apr 2021 17:48 UTC

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.

Re: C++, Ada, ...

<I1kfI.556583$W%q8.146759@fx36.ams4>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=341&group=comp.arch.embedded#341

 copy link   Newsgroups: comp.arch.embedded
Path: i2pn2.org!i2pn.org!usenet.goja.nl.eu.org!3.eu.feeder.erje.net!feeder.erje.net!news-out.netnews.com!newsin.alt.net!fdcspool1.netnews.com!news-out.netnews.com!news.alt.net!fdc2.netnews.com!peer01.ams1!peer.ams1.xlned.com!news.xlned.com!peer02.iad!feed-me.highwinds-media.com!peer03.ams4!peer.am4.highwinds-media.com!news.highwinds-media.com!fx36.ams4.POSTED!not-for-mail
Reply-To: spamjunk@blueyonder.co.uk
Subject: Re: C++, Ada, ...
Newsgroups: comp.arch.embedded
References: <s5f01b$4j3$1@dont-email.me> <s5f3c1$s06$1@dont-email.me>
<s5kbmv$528$1@dont-email.me>
From: spamj...@blueyonder.co.uk (Tom Gardner)
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101
Firefox/52.0 SeaMonkey/2.49.4
MIME-Version: 1.0
In-Reply-To: <s5kbmv$528$1@dont-email.me>
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit
Lines: 13
Message-ID: <I1kfI.556583$W%q8.146759@fx36.ams4>
X-Complaints-To: http://netreport.virginmedia.com
NNTP-Posting-Date: Mon, 19 Apr 2021 18:33:12 UTC
Organization: virginmedia.com
Date: Mon, 19 Apr 2021 19:33:12 +0100
X-Received-Bytes: 1381
 by: Tom Gardner - Mon, 19 Apr 2021 18:33 UTC

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.

Re: C++, Ada, ...

<87blaagjyc.fsf@nightsong.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=342&group=comp.arch.embedded#342

 copy link   Newsgroups: comp.arch.embedded
Path: i2pn2.org!i2pn.org!usenet.goja.nl.eu.org!weretis.net!feeder8.news.weretis.net!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: no.em...@nospam.invalid (Paul Rubin)
Newsgroups: comp.arch.embedded
Subject: Re: C++, Ada, ...
Date: Mon, 19 Apr 2021 12:20:27 -0700
Organization: A noiseless patient Spider
Lines: 44
Message-ID: <87blaagjyc.fsf@nightsong.com>
References: <s5f01b$4j3$1@dont-email.me> <s5f3c1$s06$1@dont-email.me>
<AaGeI.148580$qHh9.147135@fx18.ams4> <s5h32f$edv$1@dont-email.me>
<ie32luFlvghU1@mid.individual.net> <s5hogv$77o$1@dont-email.me>
<ie55l3F3ou7U1@mid.individual.net>
Mime-Version: 1.0
Content-Type: text/plain
Injection-Info: reader02.eternal-september.org; posting-host="9309f7be5b1d8e24271c45a8f9cf0e07";
logging-data="7383"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18JfPjRukX6Fhpw8x7gRjq8"
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux)
Cancel-Lock: sha1:i+8JkL/1GlGGGZWz6S4ZkHnF/As=
sha1:DkPlpDekEiJ1i656P/XC4zhEyRM=
 by: Paul Rubin - Mon, 19 Apr 2021 19:20 UTC

Niklas Holsti <niklas.holsti@tidorum.invalid> writes:
> In Ada... The construction step can assign some initial values that
> can be defined by default (pointers default to null, for example)...
>
> type Zero_Handler is access procedure;
> type Counter is record ...
> At_Zero : Zero_Handler; -- Default init to null.

Wow, that is disappointing. I had thought Ada access types were like
C++ or ML references, i.e. they have to be initialized to point to a
valid object, so they can never be null. I trust or at least hope that
SPARK has good ways to ensure that a given access variable is always
valid.

Debugging null pointer exceptions is a standard time-waster in most
languages that have null pointers. Is it that way in Ada as well?

Fwiw, I'm not a C++ expert but I do use it. I try to write in a style
that avoids pointers (e.g. by using references instead), and still find
myself debugging stuff with invalid addresses that I think wouldn't
happen in Ada. But I've never used Ada beyond some minor playing
around. It seems like a big improvement over C. C++ it seems to me
also improves on C, but by going in a different direction than Ada.

I plan to spend some time on Rust pretty soon. This is based on
impression rather than experience, but ISTM that a lot of Rust is
designed around managing dynamic memory allocation by ownership
tracking, like C++ unique_ptr on steroids built into the language. That
lets you write big applications that heavily use dynamic allocation
while avoiding the usual malloc/free bugs and without using garbage
collection. Ada on the other hand is built for high assurance embedded
applications that don't use dynamic allocation much, except maybe at
program initialization time. So Rust and Ada aim to solve different
problems.

I like to think it is reasonable to write the outer layers of complex
applications in garbage collected languages, with critical or realtime
parts written in something like Ada. Tim Sweeney talks about this in
his old slide deck "The Next Mainstream Programming Language":

https://www.st.cs.uni-saarland.de//edu/seminare/2005/advanced-fp/docs/sweeny.pdf

The above url currently throws an expired-certificate warning but it is
ok to click past that.

Re: C++, Ada, ...

<877dkygips.fsf@nightsong.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=343&group=comp.arch.embedded#343

 copy link   Newsgroups: comp.arch.embedded
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: no.em...@nospam.invalid (Paul Rubin)
Newsgroups: comp.arch.embedded
Subject: Re: C++, Ada, ...
Date: Mon, 19 Apr 2021 12:47:11 -0700
Organization: A noiseless patient Spider
Lines: 40
Message-ID: <877dkygips.fsf@nightsong.com>
References: <s5f01b$4j3$1@dont-email.me> <s5f3c1$s06$1@dont-email.me>
<ie260rFghneU1@mid.individual.net> <s5hafg$g1$1@dont-email.me>
<ie34olFmda9U1@mid.individual.net> <s5hq48$k2e$1@dont-email.me>
<qU_eI.237388$KHwf.234963@fx25.ams4> <s5i4gh$nb$1@dont-email.me>
<ie56dqF3t0qU1@mid.individual.net> <s5jsao$cpu$1@dont-email.me>
Mime-Version: 1.0
Content-Type: text/plain
Injection-Info: reader02.eternal-september.org; posting-host="9309f7be5b1d8e24271c45a8f9cf0e07";
logging-data="7383"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19hYn7aQpw41brVZlGN4g+y"
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux)
Cancel-Lock: sha1:3Z+oFF7TYrwlS4u83gjmXTerTNA=
sha1:C+KItBI/zBxX+B+saLv64ccnzMQ=
 by: Paul Rubin - Mon, 19 Apr 2021 19:47 UTC

Dimiter_Popoff <dp@tgi-sci.com> writes:
> On 4/19/2021 14:04, Niklas Holsti wrote:
>> ...their HR departments say that they cannot find programmers trained
>> in Ada. Bah, a competent programmer will pick up the core concepts
>> quickly, says I.
>
> This is valid not just for ADA. An experienced programmer will need days
> to adjust to this or that language. I guess most if not all of us have
> been through it.

No it's much worse than that. First of all some languages are really
different and take considerable conceptual adjustment: it took me quite
a while as a C and Python programmer to become anywhere near clueful
about Haskell. But understanding Haskell then demystified parts of C++
that had made no sense to me at all.

Secondly, being competent in a language now means far more than the
language itself. There is also a culture and a code corpus out there
which also have to be assimilated for each language. E.g. Ruby is a
very simple language, but coming up to speed as a Ruby developer means
getting used to a decade of Rails hacks, ORM internals, 100's of "gems"
(packages) scattered over 100s of Github repositories, etc. It's the
same way with Javascript and the NPM universe plus whatever
framework-of-the-week your project is using. Python is not yet that
bad, because it traditionally had a "batteries included" ethic that
tried to standardize more useful functions than other languages did, but
it seems to have given up on that in the past few years.

Maybe things are better in the embedded world, but in the internet world
any significant application will have far too much internal
functionality (dealing with complex network protocols, file formats,
etc) for the developers to get anything done without bringing in a mass
of external dependencies. A lot of dev work ISTM now is about
understanding and managing those dependencies, and also in connecting to
a wider dev community that you can exchange wisdom with. "Computer
science", such as knowing how to balance binary trees, is now almost a
useless subject. (On the other hand, math in general, particularly
probability, has become a lot more useful. This is kind of satisfying
for me since I studied a lot of it in school and then for many years
never used it in programming.)

Re: C++, Ada, ...

<s5kokj$e1r$1@dont-email.me>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=344&group=comp.arch.embedded#344

 copy link   Newsgroups: comp.arch.embedded
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: david.br...@hesbynett.no (David Brown)
Newsgroups: comp.arch.embedded
Subject: Re: C++, Ada, ...
Date: Mon, 19 Apr 2021 22:19:31 +0200
Organization: A noiseless patient Spider
Lines: 190
Message-ID: <s5kokj$e1r$1@dont-email.me>
References: <s5f01b$4j3$1@dont-email.me> <s5f3c1$s06$1@dont-email.me>
<AaGeI.148580$qHh9.147135@fx18.ams4> <s5h32f$edv$1@dont-email.me>
<ie32luFlvghU1@mid.individual.net> <s5hogv$77o$1@dont-email.me>
<ie55l3F3ou7U1@mid.individual.net> <s5jslh$gl8$1@dont-email.me>
<ie5onhF7e7mU1@mid.individual.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-15
Content-Transfer-Encoding: 8bit
Injection-Date: Mon, 19 Apr 2021 20:19:31 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="ff5cff51fe06147ec8ac8879084ca6c4";
logging-data="14395"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19Cje4XLpyOL7Xg5bwwo0XKoLQMuX+YSK8="
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
Thunderbird/68.10.0
Cancel-Lock: sha1:mgGCQ+a92sT8dAYX1OjfOm+VLhM=
In-Reply-To: <ie5onhF7e7mU1@mid.individual.net>
Content-Language: en-GB
 by: David Brown - Mon, 19 Apr 2021 20:19 UTC

On 19/04/2021 18:16, Niklas Holsti wrote:
> On 2021-04-19 15:22, David Brown wrote:
>> On 19/04/2021 12:51, Niklas Holsti wrote:
>>> On 2021-04-18 19:59, David Brown wrote:

(I'm snipping for brevity - I appreciate your comments even though I've
snipped many.)

>
> In Ada one can write the preconditions, invariants and postconditions in
> the source code itself, with standard "aspects" and Ada Boolean
> expressions, and have them either checked at run-time or verified by
> static analysis/proof.
>

Yes, I like that for Ada. These are on the drawing board for C++, but
it will be a while yet before they are in place.

>>>
>>> (I think there should be a "volatile" spec for the "p" object, don't
>>> you?)
>>
>> It might be logical to make it volatile, but the code would not be
>> different (the inline assembly has memory clobbers already, which force
>> the memory accesses to be carried out without re-arrangements).
>
>
> So you are relying on the C++ compiler actually respecting the "inline"
> directive? Are C++ compilers required to do that?
>

No, it is not relying on the "inline" at all - it is relying on the
semantics of the inline assembly code (which is compiler-specific,
though several major compilers support the gcc inline assembly syntax).

Compilers are required to support "inline" correctly, of course - but
the keyword doesn't actually mean "generate this code inside the calling
function". It is one of these historical oddities - it was originally
conceived as a hint to the compiler for optimisation purposes, but what
it /actually/ means is roughly "It's okay for there to be multiple
definitions of this function in the program - I promise they will all do
the same thing, so I don't mind which you use in any given case".

The compiler is likely to generate the code inline as part of normal
optimisation, but it would do that anyway.

>
>> But adding "volatile" would do no harm, and let the user of the
>> function pass a volatile pointer. >
>> The Ada and C++ code is basically the same here, which is nice.
>
>
> (Personally I dislike this style of critical sections. I think it is a
> confusing mis-use of local variables. Its only merit is that it ensures
> that the finalization occurs even in the case of an exception or other
> abnormal exit from the critical section.)

Fair enough - styles are personal things. And they are heavily
influenced by what is convenient or idiomatic in the language(s) we
commonly use (and vice versa).

>
>
>> How would it look with block scope?
>>
>> extern int bar(int x);
>> int foo(volatile int * p, int x, int y) {
>>     int u = bar(x);
>>     {
>>         CriticalSectionLock lock;
>>         *p += z;
>>     }
>>     int v = bar(y);
>>     return v;
>> }
>>
>> The point of this example is that the "*p += z;" line should be within
>> the calls to disableGlobalInterrupts and restoreGlobalInterrupts, but
>> the calls to "bar" should be outside.  This requires the lifetime of the
>> lock variable to be more limited.
>
>
> Much as you would expect; the block is
>
>    declare
>       Lock : Critical_Section;
>    begin
>       p.all := p.all + z:
>    end:

Fair enough. (I expected there was some way to have smaller block-scope
variables in Ada, though I didn't know how to write them. And it is not
a given that the scope and the lifetime would be the same, though it
looks like it is the case here.)

As a matter of style, I really do not like the "declare all variables at
the start of the block" style, standard in Pascal, C90 (or older), badly
written (IMHO) newer C, and apparently also Ada. I much prefer to avoid
defining variables until I know what value they should hold, at least
initially. Amongst other things, it means I can be much more generous
about declaring them as "const", there are almost no risks of using
uninitialised data, and the smaller scope means it is easier to see all
use of the variable.

>
> (In the next Ada standard -- probably Ada 2022 -- one can write such
> updating assignments more briefly, as
>
>     p.all := @ + z;
>
> but the '@' can be anywhere in the right-hand-side expression, in one or
> more places, which is more flexible than the C/C++ combined
> assignment-operations like "+=".)
>

It may be flexible, but I'm not convinced it is clearer nor that it
would often be useful. But I guess that will be highly related to
familiarity.

>
>>> But critical sections in Ada applications are more often written
>>> using the Ada "protected object" feature.
>>>
>>> <snip PO example> >>>
>> I think the idea of language support for protected sections is nice, but
>> I'd be concerned about how efficiently it would map to the requirements
>> of the program and the target.
>
>
> I haven't had any problems so far. Though in some highly stressed
> real-time applications I have resorted to communicating through shared
> atomic variables with lock-free protocols.
>
>
>> Such things are often a bit "brute
>> force", because they have to emphasise "always works" over efficiency.
>> For example, if you have a 64-bit atomic type (on a 32-bit device), you
>> don't /always/ need to disable interrupts around it.  If you are already
>> in an interrupt routine and know that no higher priority interrupt
>> accesses the data, no locking is needed.
>
>
> Interrupt handlers in Ada are written as procedures in protected
> objects, with the protected object given the appropriate priority. Other
> operations in that same protected object can then be executed in
> automatic mutual exclusion with the interrupt handler. The protected
> object can also provide one or more "entry" operations with Boolean
> "guards" on which tasks can wait, for example to wait for an interrupt
> to have occurred. I find this works very well in practice.
>
>
>> If you are in main thread code but only read the data, maybe
>> repeatedly reading it until you get two reads with the same value is
>> more efficient.  Such shortcuts must, of course, be used with care.
>
> Sure.
>
>
>> In C and C++, there are atomic types (since C11/C++11).  They require
>> library support for different targets, which are (unfortunately) not
>> always good.  But certainly it is common in C++ to think of an atomic
>> type here rather than atomic access functions, just as you describe in
>> Ada.
>
>
> The next Ada standard includes several generic atomic operations on
> typed objects in the standard package System.Atomic_Operations and its
> child packages. The proposal is at
>
> http://www.ada-auth.org/standards/2xaarm/html/AA-C-6-1.html
>
> Follow the "Next" arrows to see all of it.
>
> In summary, it seems to me that the main difference we have found in
> this discussion, so far, between Ada and C++ services in the areas we
> have looked at, is that Ada makes it simpler to define one's own scalar
> types, while C++ has more compile-time programmability like constexpr
> functions.
>

These are certainly example differences. In general it would appear
that most things that can be written in one language could be written in
the other in roughly the same way (given appropriate libraries or type
definitions).

And we can probably agree that both are better than plain old C in terms
of expressibility and (in the right hands) writing safer code by
reducing tedious and error-prone manual boilerplate.

Re: C++, Ada, ...

<s5kqa4$pm2$1@dont-email.me>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=345&group=comp.arch.embedded#345

 copy link   Newsgroups: comp.arch.embedded
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: david.br...@hesbynett.no (David Brown)
Newsgroups: comp.arch.embedded
Subject: Re: C++, Ada, ...
Date: Mon, 19 Apr 2021 22:48:04 +0200
Organization: A noiseless patient Spider
Lines: 56
Message-ID: <s5kqa4$pm2$1@dont-email.me>
References: <s5f01b$4j3$1@dont-email.me> <s5f3c1$s06$1@dont-email.me>
<s5kbmv$528$1@dont-email.me>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-15
Content-Transfer-Encoding: 7bit
Injection-Date: Mon, 19 Apr 2021 20:48:04 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="ff5cff51fe06147ec8ac8879084ca6c4";
logging-data="26306"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19p8tPNbJK+bbMKofw0EcA2xTvfc3u/vWw="
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
Thunderbird/68.10.0
Cancel-Lock: sha1:yz66L1ft+Y9B6cDnMX8LXp5PLNY=
In-Reply-To: <s5kbmv$528$1@dont-email.me>
Content-Language: en-GB
 by: David Brown - Mon, 19 Apr 2021 20:48 UTC

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!)

Re: C++, Ada, ...

<s5ks1p$6k1$1@dont-email.me>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=346&group=comp.arch.embedded#346

 copy link   Newsgroups: comp.arch.embedded
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: pozzu...@gmail.com (pozz)
Newsgroups: comp.arch.embedded
Subject: Re: C++, Ada, ...
Date: Mon, 19 Apr 2021 23:17:45 +0200
Organization: A noiseless patient Spider
Lines: 68
Message-ID: <s5ks1p$6k1$1@dont-email.me>
References: <s5f01b$4j3$1@dont-email.me> <s5f3c1$s06$1@dont-email.me>
<s5kbmv$528$1@dont-email.me> <s5kqa4$pm2$1@dont-email.me>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-15; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Mon, 19 Apr 2021 21:17:45 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="8e347c36efe1133544d59b4435e371a7";
logging-data="6785"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19/dmIaNCAAMdF8y3r2n3JAsMhZaGQKxco="
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101
Thunderbird/78.9.1
Cancel-Lock: sha1:X00Lw/K4VvWW7JVPcjt9kW8z3AE=
In-Reply-To: <s5kqa4$pm2$1@dont-email.me>
Content-Language: it
 by: pozz - Mon, 19 Apr 2021 21:17 UTC

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!)
>

Re: C++, Ada, ...

<ie6aruFat9fU1@mid.individual.net>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=348&group=comp.arch.embedded#348

 copy link   Newsgroups: comp.arch.embedded
Path: i2pn2.org!i2pn.org!news.swapon.de!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail
From: niklas.h...@tidorum.invalid (Niklas Holsti)
Newsgroups: comp.arch.embedded
Subject: Re: C++, Ada, ...
Date: Tue, 20 Apr 2021 00:26:21 +0300
Organization: Tidorum Ltd
Lines: 51
Message-ID: <ie6aruFat9fU1@mid.individual.net>
References: <s5f01b$4j3$1@dont-email.me> <s5f3c1$s06$1@dont-email.me>
<AaGeI.148580$qHh9.147135@fx18.ams4> <s5h32f$edv$1@dont-email.me>
<ie32luFlvghU1@mid.individual.net> <s5hogv$77o$1@dont-email.me>
<ie55l3F3ou7U1@mid.individual.net> <87blaagjyc.fsf@nightsong.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: individual.net NeKGtDHlnP2OPVNnaANRowZBSTi5ffWZutE5phdN8kFBjeZ0nV
Cancel-Lock: sha1:uH6dpe6R0my4VWEA3Gh/4qwg6oc=
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:78.0)
Gecko/20100101 Thunderbird/78.7.0
In-Reply-To: <87blaagjyc.fsf@nightsong.com>
Content-Language: en-US
 by: Niklas Holsti - Mon, 19 Apr 2021 21:26 UTC

On 2021-04-19 22:20, Paul Rubin wrote:
> Niklas Holsti <niklas.holsti@tidorum.invalid> writes:
>> In Ada... The construction step can assign some initial values that
>> can be defined by default (pointers default to null, for example)...
>>
>> type Zero_Handler is access procedure;
>> type Counter is record ...
>> At_Zero : Zero_Handler; -- Default init to null.
>
> Wow, that is disappointing. I had thought Ada access types were like
> C++ or ML references, i.e. they have to be initialized to point to a
> valid object, so they can never be null.

You can impose that constraint if you want to: if I had defined

type Zero_Handler is not null access procedure;

then the above declaration of the At_Zero component would be illegal,
and the compiler would insist on a non-null initial value.

But IMO sometimes you need pointers that can be null, just as you
sometimes need null values in a database.

There are also other means in Ada to force the explicit initialization
of objects at declaration (the "unspeficied discriminants" method).

The state of the art in Ada implementations of critical systems is
slowly becoming to use static analysis and proof tools to verify that no
run-time check failures, such as accessing a null pointer, can happen.
That is already fairly easy to do with the AdaCore tools (CodePeer,
SPARK and others). Proving functional correctness still remains hard.

> I plan to spend some time on Rust pretty soon. This is based on
> impression rather than experience, but ISTM that a lot of Rust is
> designed around managing dynamic memory allocation by ownership
> tracking, like C++ unique_ptr on steroids built into the language. That
> lets you write big applications that heavily use dynamic allocation
> while avoiding the usual malloc/free bugs and without using garbage
> collection. Ada on the other hand is built for high assurance embedded
> applications that don't use dynamic allocation much, except maybe at
> program initialization time. So Rust and Ada aim to solve different
> problems.

There is a proposal and an implementation from AdaCore to augment Ada
pointers with an "ownership" concept, as in Rust. I believe that SPARK
supports that proposal. Again, in some cases you want shared ownership
(multiple pointers to the same object), and then the Rust ownership
concept is not enough, as I understand it (not expert at all).

Re: C++, Ada, ...

<ie6bglFb0rhU1@mid.individual.net>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=349&group=comp.arch.embedded#349

 copy link   Newsgroups: comp.arch.embedded
Path: i2pn2.org!i2pn.org!news.swapon.de!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail
From: niklas.h...@tidorum.invalid (Niklas Holsti)
Newsgroups: comp.arch.embedded
Subject: Re: C++, Ada, ...
Date: Tue, 20 Apr 2021 00:37:25 +0300
Organization: Tidorum Ltd
Lines: 51
Message-ID: <ie6bglFb0rhU1@mid.individual.net>
References: <s5f01b$4j3$1@dont-email.me> <s5f3c1$s06$1@dont-email.me>
<ie260rFghneU1@mid.individual.net> <s5hafg$g1$1@dont-email.me>
<ie34olFmda9U1@mid.individual.net> <s5hq48$k2e$1@dont-email.me>
<qU_eI.237388$KHwf.234963@fx25.ams4> <s5i4gh$nb$1@dont-email.me>
<ie56dqF3t0qU1@mid.individual.net> <s5jsao$cpu$1@dont-email.me>
<877dkygips.fsf@nightsong.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: individual.net zwowMdbRnDYYNhZ8WmHtjA8iHFLEGBTS3wSWFdKJW4NIes9NEk
Cancel-Lock: sha1:nKF8OmB7E7Z50dG9625492Pg4xk=
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:78.0)
Gecko/20100101 Thunderbird/78.7.0
In-Reply-To: <877dkygips.fsf@nightsong.com>
Content-Language: en-US
 by: Niklas Holsti - Mon, 19 Apr 2021 21:37 UTC

On 2021-04-19 22:47, Paul Rubin wrote:
> Dimiter_Popoff <dp@tgi-sci.com> writes:
>> On 4/19/2021 14:04, Niklas Holsti wrote:
>>> ...their HR departments say that they cannot find programmers trained
>>> in Ada. Bah, a competent programmer will pick up the core concepts
>>> quickly, says I.
>>
>> This is valid not just for ADA. An experienced programmer will need days
>> to adjust to this or that language. I guess most if not all of us have
>> been through it.
>
> No it's much worse than that. First of all some languages are really
> different and take considerable conceptual adjustment: it took me quite
> a while as a C and Python programmer to become anywhere near clueful
> about Haskell. But understanding Haskell then demystified parts of C++
> that had made no sense to me at all.

I agree that it takes a mental leap to go from an imperative language to
a functional languge, or to a logic-programming / declarative language.

To maintain a Haskell program, one would certainly prefer to hire a
programmer experienced in functional programming, over one experienced
only in C, C++ or Ada.

> Secondly, being competent in a language now means far more than the
> language itself. There is also a culture and a code corpus out there
> which also have to be assimilated for each language. E.g. Ruby is a
> very simple language, but coming up to speed as a Ruby developer means
> getting used to a decade of Rails hacks, ORM internals, 100's of "gems"
> (packages) scattered over 100s of Github repositories, etc. It's the
> same way with Javascript and the NPM universe plus whatever
> framework-of-the-week your project is using. Python is not yet that
> bad, because it traditionally had a "batteries included" ethic that
> tried to standardize more useful functions than other languages did, but
> it seems to have given up on that in the past few years.

Relying on libraries/packages from the Internet is also a huge
vulnerability. Not long ago a large part of the world's programs in one
of these languages (unfortunately I forget which -- it was reported on
comp.risks) suddenly stopped working because they all depended on
real-time download of a small library package from a certain repository,
where the maintainer of that package had quarreled with the repository
owner/provider and had removed the package. Boom... Fortunately it was a
very small piece of SW and was easily replaced.

The next step is for a malicious actor to replace some such package with
malware... the programs which use it will seem to go on working, but may
not do what they are supposed to do.

Re: C++, Ada, ...

<ie6d1iFb9dgU1@mid.individual.net>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=350&group=comp.arch.embedded#350

 copy link   Newsgroups: comp.arch.embedded
Path: i2pn2.org!i2pn.org!news.swapon.de!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail
From: niklas.h...@tidorum.invalid (Niklas Holsti)
Newsgroups: comp.arch.embedded
Subject: Re: C++, Ada, ...
Date: Tue, 20 Apr 2021 01:03:30 +0300
Organization: Tidorum Ltd
Lines: 101
Message-ID: <ie6d1iFb9dgU1@mid.individual.net>
References: <s5f01b$4j3$1@dont-email.me> <s5f3c1$s06$1@dont-email.me>
<AaGeI.148580$qHh9.147135@fx18.ams4> <s5h32f$edv$1@dont-email.me>
<ie32luFlvghU1@mid.individual.net> <s5hogv$77o$1@dont-email.me>
<ie55l3F3ou7U1@mid.individual.net> <s5jslh$gl8$1@dont-email.me>
<ie5onhF7e7mU1@mid.individual.net> <s5kokj$e1r$1@dont-email.me>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-15; format=flowed
Content-Transfer-Encoding: 8bit
X-Trace: individual.net /BKrCgN3GCRLJdAxn1s01ghvMGrVGSPvXgm0uUSgfQxREQxoYJ
Cancel-Lock: sha1:paTvlEB5ASui4TNFVTMXuz+VfMY=
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:78.0)
Gecko/20100101 Thunderbird/78.7.0
In-Reply-To: <s5kokj$e1r$1@dont-email.me>
Content-Language: en-US
 by: Niklas Holsti - Mon, 19 Apr 2021 22:03 UTC

On 2021-04-19 23:19, David Brown wrote:
> On 19/04/2021 18:16, Niklas Holsti wrote:
>> On 2021-04-19 15:22, David Brown wrote:
>>> On 19/04/2021 12:51, Niklas Holsti wrote:
>>>>
>>>> (I think there should be a "volatile" spec for the "p" object, don't
>>>> you?)
>>>
>>> It might be logical to make it volatile, but the code would not be
>>> different (the inline assembly has memory clobbers already, which force
>>> the memory accesses to be carried out without re-arrangements).
>>
>>
>> So you are relying on the C++ compiler actually respecting the "inline"
>> directive? Are C++ compilers required to do that?
>>
>
> No, it is not relying on the "inline" at all - it is relying on the
> semantics of the inline assembly code (which is compiler-specific,
> though several major compilers support the gcc inline assembly syntax).
>
> Compilers are required to support "inline" correctly, of course - but
> the keyword doesn't actually mean "generate this code inside the calling
> function". It is one of these historical oddities - it was originally
> conceived as a hint to the compiler for optimisation purposes, but what
> it /actually/ means is roughly "It's okay for there to be multiple
> definitions of this function in the program - I promise they will all do
> the same thing, so I don't mind which you use in any given case".

If the call is not in fact inlined, it seems to me that the compilation
of the caller does not see the "asm volatile" in the callee, and
therefore might reorder non-volatile accesses in the caller with respect
to the call. But perhaps such reordering is forbidden in this example,
because p is a pointer, and the callee might access the same underlying
object (*p) through some other pointer to it, or directly.

> As a matter of style, I really do not like the "declare all variables at
> the start of the block" style, standard in Pascal, C90 (or older), badly
> written (IMHO) newer C, and apparently also Ada. I much prefer to avoid
> defining variables until I know what value they should hold, at least
> initially. Amongst other things, it means I can be much more generous
> about declaring them as "const", there are almost no risks of using
> uninitialised data, and the smaller scope means it is easier to see all
> use of the variable.

I mostly agree. However, there is always the possibility of having an
exception, and the question of which variables an exception handler can
see and use.

When all variable declarations are collected in one place, as in

declare
<local var declarations>
begin
<statements>
exception
<handlers>
end

it is easy and safe to say that the handlers can rely on all the
variables declared between "declare" and "begin" being in existence when
handling some exception from the <statements>. If variables are declared
here and there in the <statements>, they might or might not yet exist
when the exception happens, and it would not be safe for the local
exception handler to access them in any way.

Of course one can nest exception handlers when one nests blocks, but
that becomes cumbersome pretty quickly.

I don't know how C++ really addresses this problem.

>> (In the next Ada standard -- probably Ada 2022 -- one can write such
>> updating assignments more briefly, as
>>
>>     p.all := @ + z;
>>
>> but the '@' can be anywhere in the right-hand-side expression, in one or
>> more places, which is more flexible than the C/C++ combined
>> assignment-operations like "+=".)
>>
>
> It may be flexible, but I'm not convinced it is clearer nor that it
> would often be useful. But I guess that will be highly related to
> familiarity.

Yes, I have not yet used it at all, although I believe GNAT already
implements it.

I imagine one not uncommon use might be in function calls, such as

x := Foo (@, ...);

I believe that the main reason this new Ada feature was formulated in
this "more flexible" way was not the desire for more flexibility, but to
avoid the introduction of many more lexical tokens and variations like
"+=", or "+:=" as it would have been for Ada.

Re: C++, Ada, ...

<wcnfI.64287$J_5.19904@fx46.iad>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=351&group=comp.arch.embedded#351

 copy link   Newsgroups: comp.arch.embedded
Path: i2pn2.org!i2pn.org!aioe.org!news.uzoreto.com!tr2.eu1.usenetexpress.com!feeder.usenetexpress.com!tr3.iad1.usenetexpress.com!peer02.iad!feed-me.highwinds-media.com!news.highwinds-media.com!fx46.iad.POSTED!not-for-mail
Subject: Re: C++, Ada, ...
Newsgroups: comp.arch.embedded
References: <s5f01b$4j3$1@dont-email.me> <s5f3c1$s06$1@dont-email.me> <AaGeI.148580$qHh9.147135@fx18.ams4> <s5h32f$edv$1@dont-email.me> <ie32luFlvghU1@mid.individual.net> <s5hogv$77o$1@dont-email.me> <ie55l3F3ou7U1@mid.individual.net> <s5jslh$gl8$1@dont-email.me> <ie5onhF7e7mU1@mid.individual.net> <s5kokj$e1r$1@dont-email.me> <ie6d1iFb9dgU1@mid.individual.net>
From: Rich...@Damon-Family.org (Richard Damon)
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.9.1
MIME-Version: 1.0
In-Reply-To: <ie6d1iFb9dgU1@mid.individual.net>
Content-Type: text/plain; charset=iso-8859-15
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Lines: 43
Message-ID: <wcnfI.64287$J_5.19904@fx46.iad>
X-Complaints-To: abuse@easynews.com
Organization: Forte - www.forteinc.com
X-Complaints-Info: Please be sure to forward a copy of ALL headers otherwise we will be unable to process your complaint properly.
Date: Mon, 19 Apr 2021 18:09:31 -0400
X-Received-Bytes: 3242
X-Received-Body-CRC: 1362399540
 by: Richard Damon - Mon, 19 Apr 2021 22:09 UTC

On 4/19/21 6:03 PM, Niklas Holsti wrote:
> On 2021-04-19 23:19, David Brown wrote:
>> On 19/04/2021 18:16, Niklas Holsti wrote:
>>> On 2021-04-19 15:22, David Brown wrote:
>>>> On 19/04/2021 12:51, Niklas Holsti wrote:
>>>>>
>>>>> (I think there should be a "volatile" spec for the "p" object, don't
>>>>> you?)
>>>>
>>>> It might be logical to make it volatile, but the code would not be
>>>> different (the inline assembly has memory clobbers already, which force
>>>> the memory accesses to be carried out without re-arrangements).
>>>
>>>
>>> So you are relying on the C++ compiler actually respecting the "inline"
>>> directive? Are C++ compilers required to do that?
>>>
>>
>> No, it is not relying on the "inline" at all - it is relying on the
>> semantics of the inline assembly code (which is compiler-specific,
>> though several major compilers support the gcc inline assembly syntax).
>>
>> Compilers are required to support "inline" correctly, of course - but
>> the keyword doesn't actually mean "generate this code inside the calling
>> function".  It is one of these historical oddities - it was originally
>> conceived as a hint to the compiler for optimisation purposes, but what
>> it /actually/ means is roughly "It's okay for there to be multiple
>> definitions of this function in the program - I promise they will all do
>> the same thing, so I don't mind which you use in any given case".
>
>
> If the call is not in fact inlined, it seems to me that the compilation
> of the caller does not see the "asm volatile" in the callee, and
> therefore might reorder non-volatile accesses in the caller with respect
> to the call. But perhaps such reordering is forbidden in this example,
> because p is a pointer, and the callee might access the same underlying
> object (*p) through some other pointer to it, or directly.

Unless the compiler knows otherwise, it must assume that a call to a
function might access volatile information, so can not migrate volatile
access across that call. Non-volatile accesses. that can not be affected
by the call, can be.
>

Re: C++, Ada, ...

<4wnfI.318062$XX1d.3203@fx31.ams4>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=352&group=comp.arch.embedded#352

 copy link   Newsgroups: comp.arch.embedded
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!4.us.feeder.erje.net!2.eu.feeder.erje.net!feeder.erje.net!newsfeed.xs4all.nl!newsfeed7.news.xs4all.nl!peer01.ams4!peer.am4.highwinds-media.com!news.highwinds-media.com!fx31.ams4.POSTED!not-for-mail
Reply-To: spamjunk@blueyonder.co.uk
Subject: Re: C++, Ada, ...
Newsgroups: comp.arch.embedded
References: <s5f01b$4j3$1@dont-email.me> <s5f3c1$s06$1@dont-email.me>
<AaGeI.148580$qHh9.147135@fx18.ams4> <s5h32f$edv$1@dont-email.me>
<ie32luFlvghU1@mid.individual.net> <s5hogv$77o$1@dont-email.me>
<ie55l3F3ou7U1@mid.individual.net> <87blaagjyc.fsf@nightsong.com>
From: spamj...@blueyonder.co.uk (Tom Gardner)
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101
Firefox/52.0 SeaMonkey/2.49.4
MIME-Version: 1.0
In-Reply-To: <87blaagjyc.fsf@nightsong.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Lines: 23
Message-ID: <4wnfI.318062$XX1d.3203@fx31.ams4>
X-Complaints-To: http://netreport.virginmedia.com
NNTP-Posting-Date: Mon, 19 Apr 2021 22:30:24 UTC
Organization: virginmedia.com
Date: Mon, 19 Apr 2021 23:30:24 +0100
X-Received-Bytes: 2067
 by: Tom Gardner - Mon, 19 Apr 2021 22:30 UTC

On 19/04/21 20:20, Paul Rubin wrote:

> I plan to spend some time on Rust pretty soon. This is based on
> impression rather than experience, but ISTM that a lot of Rust is
> designed around managing dynamic memory allocation by ownership
> tracking, like C++ unique_ptr on steroids built into the language. That
> lets you write big applications that heavily use dynamic allocation
> while avoiding the usual malloc/free bugs and without using garbage
> collection.

It also helps with concurrency. From
https://doc.rust-lang.org/book/ch16-00-concurrency.html

"Initially, the Rust team thought that ensuring memory safety
and preventing concurrency problems were two separate challenges
to be solved with different methods. Over time, the team
discovered that the ownership and type systems are a powerful
set of tools to help manage memory safety and concurrency
problems! By leveraging ownership and type checking, many
concurrency errors are compile-time errors in Rust rather
than runtime errors."

I haven't kicked Rust's tyres, but that seems plausible

Re: C++, Ada, ...

<87bla9yjdr.fsf@nightsong.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=353&group=comp.arch.embedded#353

 copy link   Newsgroups: comp.arch.embedded
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: no.em...@nospam.invalid (Paul Rubin)
Newsgroups: comp.arch.embedded
Subject: Re: C++, Ada, ...
Date: Mon, 19 Apr 2021 15:55:28 -0700
Organization: A noiseless patient Spider
Lines: 29
Message-ID: <87bla9yjdr.fsf@nightsong.com>
References: <s5f01b$4j3$1@dont-email.me> <s5f3c1$s06$1@dont-email.me>
<s5kbmv$528$1@dont-email.me> <s5kqa4$pm2$1@dont-email.me>
<s5ks1p$6k1$1@dont-email.me>
Mime-Version: 1.0
Content-Type: text/plain
Injection-Info: reader02.eternal-september.org; posting-host="cf83179cb835020c3574515608d2f977";
logging-data="7310"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+X2mHee2+OyIsJJ+cUcD6q"
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux)
Cancel-Lock: sha1:/7B5WdSifATDLyr4ITBrdy5UXUY=
sha1:aXRJEo+lta1CBiwZSyjVrWoTwjI=
 by: Paul Rubin - Mon, 19 Apr 2021 22:55 UTC

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.

Re: C++, Ada, ...

<877dkxyj3o.fsf@nightsong.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=354&group=comp.arch.embedded#354

 copy link   Newsgroups: comp.arch.embedded
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: no.em...@nospam.invalid (Paul Rubin)
Newsgroups: comp.arch.embedded
Subject: Re: C++, Ada, ...
Date: Mon, 19 Apr 2021 16:01:31 -0700
Organization: A noiseless patient Spider
Lines: 29
Message-ID: <877dkxyj3o.fsf@nightsong.com>
References: <s5f01b$4j3$1@dont-email.me> <s5f3c1$s06$1@dont-email.me>
<AaGeI.148580$qHh9.147135@fx18.ams4> <s5h32f$edv$1@dont-email.me>
<ie32luFlvghU1@mid.individual.net> <s5hogv$77o$1@dont-email.me>
<ie55l3F3ou7U1@mid.individual.net> <87blaagjyc.fsf@nightsong.com>
<ie6aruFat9fU1@mid.individual.net>
Mime-Version: 1.0
Content-Type: text/plain
Injection-Info: reader02.eternal-september.org; posting-host="cf83179cb835020c3574515608d2f977";
logging-data="7310"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19gByQBetZIiDesMYWfrJDV"
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux)
Cancel-Lock: sha1:UGAsnEgBfvXZCNbZzqTzLeKSoT4=
sha1:qPZ/oAkERAiH9fYu/JXka1jV/KI=
 by: Paul Rubin - Mon, 19 Apr 2021 23:01 UTC

Niklas Holsti <niklas.holsti@tidorum.invalid> writes:
> You can impose that constraint if you want to: if I had defined
> type Zero_Handler is not null access procedure;
> then the above declaration of the At_Zero component would be illegal,
> and the compiler would insist on a non-null initial value.

Oh, this is nice.

> But IMO sometimes you need pointers that can be null, just as you
> sometimes need null values in a database.

Preferable these days is to use a separate type for a value that is
nullable or optional, so failing to check for null gives a compile-time
type error. This is 't Option in ML, Maybe a in Haskell, and iirc
std::Optional<T> these days in C++.

> The state of the art in Ada implementations of critical systems is
> slowly becoming to use static analysis and proof tools to verify that
> no run-time check failures, such as accessing a null pointer, can
> happen. That is already fairly easy to do with the AdaCore tools
> (CodePeer, SPARK and others). Proving functional correctness still
> remains hard.

I know about SPARK. Is CodePeer something along the same lines? Is it
available through GNU, or is it Adacore proprietary or what?

I still have Burns & Wellings' book on SPARK on the recommendation of
someone here. It looks good but has been in my want-to-read pile since
forever. One of these days.

Re: C++, Ada, ...

<s5ln1h$p5h$1@dont-email.me>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=355&group=comp.arch.embedded#355

 copy link   Newsgroups: comp.arch.embedded
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: david.br...@hesbynett.no (David Brown)
Newsgroups: comp.arch.embedded
Subject: Re: C++, Ada, ...
Date: Tue, 20 Apr 2021 06:58:24 +0200
Organization: A noiseless patient Spider
Lines: 145
Message-ID: <s5ln1h$p5h$1@dont-email.me>
References: <s5f01b$4j3$1@dont-email.me> <s5f3c1$s06$1@dont-email.me>
<AaGeI.148580$qHh9.147135@fx18.ams4> <s5h32f$edv$1@dont-email.me>
<ie32luFlvghU1@mid.individual.net> <s5hogv$77o$1@dont-email.me>
<ie55l3F3ou7U1@mid.individual.net> <s5jslh$gl8$1@dont-email.me>
<ie5onhF7e7mU1@mid.individual.net> <s5kokj$e1r$1@dont-email.me>
<ie6d1iFb9dgU1@mid.individual.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-15
Content-Transfer-Encoding: 8bit
Injection-Date: Tue, 20 Apr 2021 04:58:25 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="a7a1df4d651df37abbff711f9ed53e00";
logging-data="25777"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/EA8amt2ieQj1gjE4tgeSovVHNbFwd6RA="
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
Thunderbird/68.10.0
Cancel-Lock: sha1:vnMg5HfuSfLbBYU6du237uEl9/0=
In-Reply-To: <ie6d1iFb9dgU1@mid.individual.net>
Content-Language: en-GB
 by: David Brown - Tue, 20 Apr 2021 04:58 UTC

On 20/04/2021 00:03, Niklas Holsti wrote:
> On 2021-04-19 23:19, David Brown wrote:
>> On 19/04/2021 18:16, Niklas Holsti wrote:
>>> On 2021-04-19 15:22, David Brown wrote:
>>>> On 19/04/2021 12:51, Niklas Holsti wrote:
>>>>>
>>>>> (I think there should be a "volatile" spec for the "p" object, don't
>>>>> you?)
>>>>
>>>> It might be logical to make it volatile, but the code would not be
>>>> different (the inline assembly has memory clobbers already, which force
>>>> the memory accesses to be carried out without re-arrangements).
>>>
>>>
>>> So you are relying on the C++ compiler actually respecting the "inline"
>>> directive? Are C++ compilers required to do that?
>>>
>>
>> No, it is not relying on the "inline" at all - it is relying on the
>> semantics of the inline assembly code (which is compiler-specific,
>> though several major compilers support the gcc inline assembly syntax).
>>
>> Compilers are required to support "inline" correctly, of course - but
>> the keyword doesn't actually mean "generate this code inside the calling
>> function".  It is one of these historical oddities - it was originally
>> conceived as a hint to the compiler for optimisation purposes, but what
>> it /actually/ means is roughly "It's okay for there to be multiple
>> definitions of this function in the program - I promise they will all do
>> the same thing, so I don't mind which you use in any given case".
>
>
> If the call is not in fact inlined, it seems to me that the compilation
> of the caller does not see the "asm volatile" in the callee, and
> therefore might reorder non-volatile accesses in the caller with respect
> to the call. But perhaps such reordering is forbidden in this example,
> because p is a pointer, and the callee might access the same underlying
> object (*p) through some other pointer to it, or directly.

Either the compiler "sees" the definition of the functions, and can tell
that there are things that force the memory access to be done in middle
(whether these functions are inlined or not), or the compiled does not
"see" the definitions and must therefore make pessimistic assumptions
about what the functions might do. The compiler can't re-order things
unless it can /prove/ that it is safe to do so.

>
>
>> As a matter of style, I really do not like the "declare all variables at
>> the start of the block" style, standard in Pascal, C90 (or older), badly
>> written (IMHO) newer C, and apparently also Ada.  I much prefer to avoid
>> defining variables until I know what value they should hold, at least
>> initially.  Amongst other things, it means I can be much more generous
>> about declaring them as "const", there are almost no risks of using
>> uninitialised data, and the smaller scope means it is easier to see all
>> use of the variable.
>
>
> I mostly agree. However, there is always the possibility of having an
> exception, and the question of which variables an exception handler can
> see and use.
>

In C++ (and C99, but it doesn't have exceptions), you don't need to put
your variables at the start of a block. But their scope and lifetime
will last until the end of the block. So if you need a variable in an
exception, you have to have declared it before the exception handling
but you don't need it in a rigid variables-then-code-block structure :

{
foo1();
int x = foo2(); // <- Not at start of block
foo3(x);
try {
foo4(x, x);
} catch (...) {
foo5(x);
}
}

> When all variable declarations are collected in one place, as in
>
>    declare
>       <local var declarations>
>    begin
>       <statements>
>    exception
>       <handlers>
>    end
>
> it is easy and safe to say that the handlers can rely on all the
> variables declared between "declare" and "begin" being in existence when
> handling some exception from the <statements>. If variables are declared
> here and there in the <statements>, they might or might not yet exist
> when the exception happens, and it would not be safe for the local
> exception handler to access them in any way.

Flexible placement of declarations does not mean /random/ placement, nor
does it mean you don't know what is in scope and what is not!

And you can be pretty sure the compiler will tell you if you are trying
to use a variable outside its scope.

>
> Of course one can nest exception handlers when one nests blocks, but
> that becomes cumbersome pretty quickly.
>
> I don't know how C++ really addresses this problem.
>

For the kinds of code I write - on small systems - I disable exceptions
in C++. I prefer to write code that doesn't go wrong (unusual
circumstances are just another kind of value), and the kind of places
where exceptions might be most useful don't turn up often. (I use
exceptions in Python in PC programming, but the balance is different there.)

>
>>> (In the next Ada standard -- probably Ada 2022 -- one can write such
>>> updating assignments more briefly, as
>>>
>>>      p.all := @ + z;
>>>
>>> but the '@' can be anywhere in the right-hand-side expression, in one or
>>> more places, which is more flexible than the C/C++ combined
>>> assignment-operations like "+=".)
>>>
>>
>> It may be flexible, but I'm not convinced it is clearer nor that it
>> would often be useful.  But I guess that will be highly related to
>> familiarity.
>
>
> Yes, I have not yet used it at all, although I believe GNAT already
> implements it.
>
> I imagine one not uncommon use might be in function calls, such as
>
>    x := Foo (@, ...);
>
> I believe that the main reason this new Ada feature was formulated in
> this "more flexible" way was not the desire for more flexibility, but to
> avoid the introduction of many more lexical tokens and variations like
> "+=", or "+:=" as it would have been for Ada.

Sounds reasonable.

Pages:123
server_pubkey.txt

rocksolid light 0.9.7
clearnet tor