Re: C++, Ada, ...

From	David Brown <david.brown@hesbynett.no>
Newsgroups	comp.arch.embedded
Subject	Re: C++, Ada, ...
Date	2021-04-18 18:59 +0200
Organization	A noiseless patient Spider
Message-ID	<s5hogv$77o$1@dont-email.me> (permalink)
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>

Show all headers | View raw

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.  And you don't have automatic initialisation of
subobjects and ancestors in a controlled order, nor automatic
finalisation of them in the reverse order.

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");
}

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


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

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?

> 
> AUI that also holds for C++, although I believe recent C++ standards may
> have simplified the definition and use of reference-counted data
> structures.
> 
> 
>> On the other hand, some of Ada's type mechanisms make it a lot easier to
>> make new types with similar properties while remaining distinct (such as
>> subranges of integer types).  You can do that in C++, but someone needs
>> to make the effort to make the appropriate class templates.  Thus these
>> are more often used in Ada coding than in C++ coding.
> 
> 
> (That relative ease in Ada was the point of my other response -- more to
> come on that.)
> 
> 
>> On the third hand (three hands are always useful for programming), the
>> wordy nature of type conversions in Ada mean programmers would be
>> tempted to take shortcuts and skip these extra types.
> 
> 
> Huh? A normal conversion in C is written "(newtype)expression", the same
> in Ada is written "newtype(expression)". Exactly the same number of
> characters, only the placement of the () is different. The C form might
> even require an extra set of parentheses around it, to demarcate the
> expression to be converted from any containing expression.
> 
> Of course, in C you have implicit conversions between all kinds of
> numerical types, often leading to a whole lot of errors... not only
> apples+oranges, but also truncation or other miscomputation.

C also makes explicit conversions wordy, yes.  In C++, you can choose
which conversions are explicit and which are implicit - done carefully,
your safe conversions will be implicit and unsafe ones need to be explicit.

(C++ suffers from its C heritage and backwards compatibility, meaning it
can't fix things that were always implicit conversion.  It's too late to
make "int x = 123.4;" an error.  The best C++ can do is add a new syntax
with better safety - so "int y { 123 };" is fine but "int z { 123.4 };"
is an error.)

Thread

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

csiph-web