"Why < cstlib > is more complicated than you might think"

[Lynn McGuire]

"Why < cstlib > is more complicated than you might think"
https://developerblog.redhat.com/2016/02/29/why-cstdlib-is-more-complicated-than-you-might-think/?

I still want a standard user interface library and a standard graphics library.

Lynn

[Paavo Helde]

On 2.03.2016 0:41, Lynn McGuire wrote:
> "Why < cstlib > is more complicated than you might think"
>
> https://developerblog.redhat.com/2016/02/29/why-cstdlib-is-more-complicated-than-you-might-think/?

Strange that the URL uses correct spelling and the headline is invalid.

About the std:: namespace: yes it's a total mess. I found it out the
hard way when some new gcc version unexpectedly started to call abs(int)
instead of the intended abs(double). The problem was full mystique as
the only symptoms were slightly skewed unit test results in the
beginning and it took lots of time to track the problem down to abs().

[w...@totalbb.net.tw]

In C++, nothing can really be certain, for example:
try {
auto x=printf("abc"); // how to understand this?
...
}
catch(std::exception&) {
// may be nothing related to printf or "abc"
// basically, everything is unknown here
};

[Christopher Pisz]

I wish we could just have C++ without C. So, many problems come from C.
So many developers that would use C++ if not for the messes C made.

--
I have chosen to troll filter/ignore all subthreads containing the
words: "Rick C. Hodgins", "Flibble", and "Islam"
So, I won't be able to see or respond to any such messages
---

[Scott Lurndal]

Christopher Pisz <nos...@notanaddress.com> writes:
>On 3/1/2016 4:41 PM, Lynn McGuire wrote:
>> "Why < cstlib > is more complicated than you might think"
>>
>> https://developerblog.redhat.com/2016/02/29/why-cstdlib-is-more-complicated-than-you-might-think/?
>>
>>
>> I still want a standard user interface library and a standard graphics
>> library.
>>
>> Lynn
>
>I wish we could just have C++ without C. So, many problems come from C.
>So many developers that would use C++ if not for the messes C made.

I suspect that C++ wouldn't exist if it hadn't maintained compatibility
with C.

If you want C++ without C, use Java.

[Lynn McGuire]

On 3/2/2016 11:38 AM, Christopher Pisz wrote:
> On 3/1/2016 4:41 PM, Lynn McGuire wrote:
>> "Why < cstlib > is more complicated than you might think"
>>
>> https://developerblog.redhat.com/2016/02/29/why-cstdlib-is-more-complicated-than-you-might-think/?
>>
>>
>> I still want a standard user interface library and a standard graphics
>> library.
>>
>> Lynn
>
> I wish we could just have C++ without C. So, many problems come from C. So many developers that would use C++ if not for the messes C
> made.

I believe that the major usage of C nowadays is embedded software such as EMS (engine management systems) where dynamic allocation of
memory is strictly forbidden. C++ will probably never be used in such environments.

And of course, device drivers. And the basic portions of operating systems. And, etc.

Lynn

[Wouter van Ooijen]

Op 02-Mar-16 om 7:32 PM schreef Lynn McGuire:

> On 3/2/2016 11:38 AM, Christopher Pisz wrote:
>> On 3/1/2016 4:41 PM, Lynn McGuire wrote:
>>> "Why < cstlib > is more complicated than you might think"
>>>
>>> https://developerblog.redhat.com/2016/02/29/why-cstdlib-is-more-complicated-than-you-might-think/?
>>>
>>>
>>>
>>> I still want a standard user interface library and a standard graphics
>>> library.
>>>
>>> Lynn
>>
>> I wish we could just have C++ without C. So, many problems come from
>> C. So many developers that would use C++ if not for the messes C
>> made.
>
> I believe that the major usage of C nowadays is embedded software such
> as EMS (engine management systems) where dynamic allocation of memory is
> strictly forbidden. C++ will probably never be used in such environments.

Why? C++, when applied appropriately, is so much better than C on such
targets.

Wouter

[Scott Lurndal]

Truth. Many of the embedded projects that our processors are used with
are written in C++. Perhaps a majority of them. Aided by the fact
that C++ _is_ derived from C.

[Lynn McGuire]

What do you do when your embedded program runs out of ram? Does the car crash?

Lynn

[Ian Collins]

Most smaller embedded applications (whether C or C++) don't use dynamic
allocation.

--
Ian Collins

[Richard]

[Please do not mail me a copy of your followup]

Lynn McGuire <l...@winsim.com> spake the secret code
<nb55m4$nos$1...@dont-email.me> thusly:

>I still want a standard user interface library and a standard graphics library.

You write this as if there were no portable way of writing graphics
applications, but the plethora of such programs puts the lie to your
portrayal of the state of affairs.

Plenty of solutions already exist and there is no need to try and cram
them into the standard.
--
"The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline>
The Computer Graphics Museum <http://computergraphicsmuseum.org>
The Terminals Wiki <http://terminals.classiccmp.org>
Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com>

[Richard]

[Please do not mail me a copy of your followup]

Lynn McGuire <l...@winsim.com> spake the secret code

<nb7bf6$qvb$1...@dont-email.me> thusly:

>I believe that the major usage of C nowadays is embedded software such

I thought the major use of C nowadays was on the linux kernel because
linus got a stick up his ass about C++.

Plenty of people are doing device drivers, operating system components
(or even entire operating systems) and embedded applications in C++.

20 years ago an entire operating system (BeOS) was written in C++.

[Richard]

[Please do not mail me a copy of your followup]

Lynn McGuire <l...@winsim.com> spake the secret code

<nb7l7e$5l1$1...@dont-email.me> thusly:

This has nothing to do with C++. C has a heap as well.

Just like in C, you can choose not to use the heap.

[Juha Nieminen]

Lynn McGuire <l...@winsim.com> wrote:
> I believe that the major usage of C nowadays is embedded software such as EMS (engine management systems) where dynamic allocation of
> memory is strictly forbidden. C++ will probably never be used in such environments.

You seem to be implying that it's impossible to write a C++ program
without dynamic memory allocation.

Is there an *actual* reason why C++ is forbidden, rather than a
completely false made-up one?

--- news://freenews.netfront.net/ - complaints: ne...@netfront.net ---

[Juha Nieminen]

Richard <legaliz...@mail.xmission.com> wrote:
>>I believe that the major usage of C nowadays is embedded software such
>
> I thought the major use of C nowadays was on the linux kernel because
> linus got a stick up his ass about C++.

Yeah. His argument against using C and abhorring C++ is, essentially,
that C automatically leads to good and efficient code, while C++
automatically leads to very inefficient and problematic code.
Because reasons. (Also, he still seems to live in the early 90's
in terms of what he knows about C++.)

[SG]

On Wednesday, March 2, 2016 at 6:39:15 PM UTC+1, Christopher Pisz wrote:
>
> I wish we could just have C++ without C. So, many problems come from C.
> So many developers that would use C++ if not for the messes C made.

Have you tried Rust yet? To me it feels like a cleaned up, simplified
C++ that shares many of its goals (e.g. zero overhead principle). It
strives for better type-, memory- and thread-safety and already offers
features the C++ standardization committee/community is currently
working on (like modular checking of generics, convenient ways of
destructuring/matching tuples and other kinds of values, or something
like an overloadable dot operator for "smart proxies").

Cheers!
sg

[David Brown]

On 03/03/16 15:40, Juha Nieminen wrote:
> Lynn McGuire <l...@winsim.com> wrote:
>> I believe that the major usage of C nowadays is embedded software
>> such as EMS (engine management systems) where dynamic allocation of
>> memory is strictly forbidden. C++ will probably never be used in
>> such environments.
>
> You seem to be implying that it's impossible to write a C++ program
> without dynamic memory allocation.
>
> Is there an *actual* reason why C++ is forbidden, rather than a
> completely false made-up one?
>

There are actual reasons why dynamic memory is often forbidden in
embedded software (it makes it hard to reason about correctness, it is
hard to determine worst case timing, code can work fine in testing but
fail in practice due to heap fragmentation, and if memory runs out then
an embedded system typically cannot just print a nice error message and
exit).

There are no requirements in C++ to use dynamic memory, though it is
often used "behind the scenes" - you have to be careful and know what
you are doing if you want to avoid dynamic memory entirely. Of course,
you have to be careful and know what you are doing if you want to write
good, correct embedded software anyway.

There are lots of reasons why many people object to using C++ in
embedded systems, and prefer, recommend or require plain C. But there
are also lots of reasons why C++ is a better choice than plain C. Some
of the reasons used to argue either way are in fact reasonable and
applicable to modern microcontrollers, modern tools, modern programmers
and modern projects - but many (especially those arguing against C++)
are based on outdated issues or myths.

In real-world practice, C++ is on the increase in embedded development.

[Scott Lurndal]

I've written parts of two major operating systems and a distributed hypervisor
all written in C++.

Like any useful language, allocation is up to the programmer, not the
language. Using placement new or ::new operators with memory pool objects
works just fine when memory is constrained. No heap necessary. STL generally
not useful. Exceptions disabled. RTTI disabled.

[Scott Lurndal]

legaliz...@mail.xmission.com (Richard) writes:
>[Please do not mail me a copy of your followup]
>
>Lynn McGuire <l...@winsim.com> spake the secret code
><nb7bf6$qvb$1...@dont-email.me> thusly:
>
>>I believe that the major usage of C nowadays is embedded software such
>
>I thought the major use of C nowadays was on the linux kernel because
>linus got a stick up his ass about C++.
>
>Plenty of people are doing device drivers, operating system components
>(or even entire operating systems) and embedded applications in C++.
>
>20 years ago an entire operating system (BeOS) was written in C++.

25 years ago, the Chorus systemes microkernel, the Unisys OPUS operating system
and the European Amadeus distributed operating system were all written
in C++ or a mix of C++ and legacy C driver code.

[Wouter van Ooijen]

Op 03-Mar-16 om 4:46 PM schreef David Brown:

> On 03/03/16 15:40, Juha Nieminen wrote:
>> Lynn McGuire <l...@winsim.com> wrote:
>>> I believe that the major usage of C nowadays is embedded software
>>> such as EMS (engine management systems) where dynamic allocation of
>>> memory is strictly forbidden. C++ will probably never be used in
>>> such environments.
>>
>> You seem to be implying that it's impossible to write a C++ program
>> without dynamic memory allocation.
>>
>> Is there an *actual* reason why C++ is forbidden, rather than a
>> completely false made-up one?
>>
>
> There are actual reasons why dynamic memory is often forbidden in
> embedded software (it makes it hard to reason about correctness, it is
> hard to determine worst case timing, code can work fine in testing but
> fail in practice due to heap fragmentation, and if memory runs out then
> an embedded system typically cannot just print a nice error message and
> exit).
>
> There are no requirements in C++ to use dynamic memory, though it is
> often used "behind the scenes" - you have to be careful and know what
> you are doing if you want to avoid dynamic memory entirely.

Luckily its is fairly easy to check (as opposed to being certain
upfront, which would of course be better): link with a missing
implementation of free().

Actually, I link with

#include <stdlib.h>

// using malloc must cause a linker error
void * malloc( size_t n ){
void if_you_see_this_you_are_using_new_or_malloc();
if_you_see_this_you_are_using_new_or_malloc();
return NULL;
}

// using free must cause a linker error
void free( void * p ){
void if_you_see_this_you_are_using_free_or_delete();
if_you_see_this_you_are_using_free_or_delete();
}

> (snip)

> In real-world practice, C++ is on the increase in embedded development.

Are there any sites, lists, congresses, publications, etc. dedicated to
exeactly this (C++ on embedded systems, especially realy small
micro-controllers)? It is my favourite subject, but I have a hard time
finding people and ideas in this direction.

"objects no thanks" Wouter van Ooijen

[Ian Collins]

Juha Nieminen wrote:
> Richard <legaliz...@mail.xmission.com> wrote:
>>> I believe that the major usage of C nowadays is embedded software such
>>
>> I thought the major use of C nowadays was on the linux kernel because
>> linus got a stick up his ass about C++.
>
> Yeah. His argument against using C and abhorring C++ is, essentially,
> that C automatically leads to good and efficient code, while C++
> automatically leads to very inefficient and problematic code.

Maybe he is correct in the case of the Linux kernel. The way code gets
added I can see why he would think like that!

--
Ian Collins

[Ian Collins]

Wouter van Ooijen wrote:
>
> Are there any sites, lists, congresses, publications, etc. dedicated to
> exeactly this (C++ on embedded systems, especially realy small
> micro-controllers)? It is my favourite subject, but I have a hard time
> finding people and ideas in this direction.

Not that I have found. Where I have been involved with small embedded
C++ projects, all of the useful information has been in the project
coding guidelines.

Maybe those of us in this field should be making more noise, if only to
counter some of the ancient FUD that is still doing the rounds!

--
Ian Collins

[Ian Collins]

David Brown wrote:
>
> There are lots of reasons why many people object to using C++ in
> embedded systems, and prefer, recommend or require plain C. But there
> are also lots of reasons why C++ is a better choice than plain C. Some
> of the reasons used to argue either way are in fact reasonable and
> applicable to modern microcontrollers, modern tools, modern programmers
> and modern projects - but many (especially those arguing against C++)
> are based on outdated issues or myths.

Alas, most of the "reasons" against C++ are soft: someone in the company
with a loud voice has a flea up (usually) his arse about C++. Linus
being a good example!

--
Ian Collins

[David Brown]

Sometimes C++ discussions turn up in comp.arch.embedded, and sometimes
embedded discussions turn up here in comp.lang.c++. Both are
appropriate newsgroups for this sort of thing.

But I don't know of any dedicated sites or publications.

[Nobody]

On Thu, 03 Mar 2016 14:43:39 +0000, Juha Nieminen wrote:

> (Also, he still seems to live in the early 90's in terms of what he
> knows about C++.)

He still seems to live in the early 90's in terms of what he "knows"
about C.

The Linux kernel isn't actually written in C. It's written in
"C as implemented by gcc with -fno-strict-aliasing".

Compiling the Linux kernel with some random perfectly-conforming
C compiler will probably result in a kernel which doesn't actually work.

[Ian Collins]

Compiling any kernel with some random perfectly-conforming C compiler
will probably result in a kernel which doesn't actually work!

I've yet to com across one that isn't tied to specific versions of one
or more compilers.

--
Ian Collins

[Richard]

[Please do not mail me a copy of your followup]

sl...@pacbell.net spake the secret code
<%pZBy.10422$w23....@fx23.iad> thusly:

> I've written parts of two major operating systems and a distributed hypervisor
>all written in C++.

>[...]
>STL generally not useful.

I assume you are referring to containers when you say "STL".
I can't see why the algorithms wouldn't be useful in a constrained
environment.

[Richard]

[Please do not mail me a copy of your followup]

David Brown <david...@hesbynett.no> spake the secret code
<nb9m34$v9r$1...@dont-email.me> thusly:

>There are no requirements in C++ to use dynamic memory, though it is
>often used "behind the scenes" - you have to be careful and know what
>you are doing if you want to avoid dynamic memory entirely.

You're making it sound harder than it is:

- don't dynamically allocate memory yourself
- don't use standard library container classes (string, vector, list,
map, etc.)

That pretty much covers it.

[Richard]

[Please do not mail me a copy of your followup]

Ian Collins <ian-...@hotmail.com> spake the secret code
<djrhdb...@mid.individual.net> thusly:

>Maybe those of us in this field should be making more noise, if only to
>counter some of the ancient FUD that is still doing the rounds!

A good blog post backed up by personal experience would very likely
get promoted on the ISO C++ blog.

[Wouter van Ooijen]

Op 04-Mar-16 om 4:41 PM schreef Richard:

> [Please do not mail me a copy of your followup]
>
> sl...@pacbell.net spake the secret code
> <%pZBy.10422$w23....@fx23.iad> thusly:
>
>> I've written parts of two major operating systems and a distributed hypervisor
>> all written in C++.
>> [...]
>> STL generally not useful.
>
> I assume you are referring to containers when you say "STL".
> I can't see why the algorithms wouldn't be useful in a constrained
> environment.

Algorithms are usefull once you have containser they can operate on. But
most containers relay on the heap...

There are initiatives (from the agme and embedded communities - it is
remarkable how their needs match!) to create a set of fixed-maximum-size
containers.

Wouter

[Wouter van Ooijen]

Op 04-Mar-16 om 4:47 PM schreef Richard:

> [Please do not mail me a copy of your followup]
>
> Ian Collins <ian-...@hotmail.com> spake the secret code
> <djrhdb...@mid.individual.net> thusly:
>
>> Maybe those of us in this field should be making more noise, if only to
>> counter some of the ancient FUD that is still doing the rounds!
>
> A good blog post backed up by personal experience would very likely
> get promoted on the ISO C++ blog.

My attempt: http://www.voti.nl/blog/

But I am mainly a teacher (not an practicioner).

Wouter "Objecst? No thanks!" van Ooijen

[Wouter van Ooijen]

Op 04-Mar-16 om 4:45 PM schreef Richard:

> [Please do not mail me a copy of your followup]
>
> David Brown <david...@hesbynett.no> spake the secret code
> <nb9m34$v9r$1...@dont-email.me> thusly:
>
>> There are no requirements in C++ to use dynamic memory, though it is
>> often used "behind the scenes" - you have to be careful and know what
>> you are doing if you want to avoid dynamic memory entirely.
>
> You're making it sound harder than it is:
>
> - don't dynamically allocate memory yourself
> - don't use standard library container classes (string, vector, list,
> map, etc.)
>
> That pretty much covers it.

It does (when you add exceptions, functors, etc.) , but the second point
is a very large one. And undocumented: there is for instance no hard
requirement that sin() doesn't use the heap.

Wouter "Objects? No thanks!" van Ooijen

[Scott Lurndal]

legaliz...@mail.xmission.com (Richard) writes:
>[Please do not mail me a copy of your followup]
>
>sl...@pacbell.net spake the secret code
><%pZBy.10422$w23....@fx23.iad> thusly:
>
>> I've written parts of two major operating systems and a distributed hypervisor
>>all written in C++.
>>[...]
>>STL generally not useful.
>
>I assume you are referring to containers when you say "STL".
>I can't see why the algorithms wouldn't be useful in a constrained
>environment.

To be fair, one of those projects predated SGI's work on STL, and
the one of the others was developed _at_ SGI at the same time that
the STL work was being done at SGI/MIPS. The first OS predated templates
(was written using Cfront 2.1 starting in 1988/9). The project at SGI mid 90's
operated under serious memory constraints and templates were avoided due to code footprint
issues (partially resolved in more modern compilers).

[David Brown]

On 04/03/16 16:45, Richard wrote:
> [Please do not mail me a copy of your followup]
>
> David Brown <david...@hesbynett.no> spake the secret code
> <nb9m34$v9r$1...@dont-email.me> thusly:
>
>> There are no requirements in C++ to use dynamic memory, though it is
>> often used "behind the scenes" - you have to be careful and know what
>> you are doing if you want to avoid dynamic memory entirely.
>
> You're making it sound harder than it is:
>
> - don't dynamically allocate memory yourself
> - don't use standard library container classes (string, vector, list,
> map, etc.)
>
> That pretty much covers it.
>

You can use /some/ standard container classes, such as std::array. And
I think you could probably use at least some of the other container
classes with customer allocators, placement new, memory pools, etc., to
use their features without a "dangerous" general purpose heap.

But are there any other standard library classes or functions that use
dynamic memory without it being obvious? I don't know, but I suspect
that shared_ptr does (even when managing something that is not a "new"
pointer). The standard does not go out of its way to make this sort of
thing easy to see - after all, most C++ users don't need to think about it.

(The same applies to C and its standard libraries or any additional
libraries - the only key difference is that the C++ standard libraries
are a good deal bigger than those of C.)

[Gareth Owen]

Wouter van Ooijen <wou...@voti.nl> writes:

> Algorithms are usefull once you have containser they can operate
> on. But most containers relay on the heap...

But one could certainly do --

std::array<int,16> foo;
/// fill in values
std::sort(foo.begin(),foo.end());

which is a lot easier than calling qsort()

And while its common to avoid exceptions (and the standard exception
hierarchies cannot be used with no heap) you can throw/catch and use
RAII to unwind exceptional conditions (strongly typed enums make
excellent projectiles).

You may also benefit from some specialised library implementation of
std::accumulate() or std::inner_product() that uses SIMD instructions
appropriately.

[Richard]

[Please do not mail me a copy of your followup]

Wouter van Ooijen <wou...@voti.nl> spake the secret code
<56d9b577$0$4282$e4fe...@newszilla.xs4all.nl> thusly:

>Op 04-Mar-16 om 4:41 PM schreef Richard:

>> sl...@pacbell.net spake the secret code
>> <%pZBy.10422$w23....@fx23.iad> thusly:
>>
>>> I've written parts of two major operating systems and a distributed
>hypervisor
>>> all written in C++.
>>> [...]
>>> STL generally not useful.
>>
>> I assume you are referring to containers when you say "STL".
>> I can't see why the algorithms wouldn't be useful in a constrained
>> environment.
>
>Algorithms are usefull once you have containser they can operate on. But
>most containers relay on the heap...

Algorithms work on anything that supports the concepts of iterators.
That includes fixed-size arrays or any other fixed-size container you
might want to create.

[Richard]

[Please do not mail me a copy of your followup]

Gareth Owen <gwo...@gmail.com> spake the secret code
<87fuw69...@gmail.com> thusly:

>Wouter van Ooijen <wou...@voti.nl> writes:
>
>> Algorithms are usefull once you have containser they can operate
>> on. But most containers relay on the heap...
>
>But one could certainly do --
>
>std::array<int,16> foo;
>/// fill in values
>std::sort(foo.begin(),foo.end());

or:

int foo[16];
// fill in values
std::sort(std::begin(foo), std::end(foo));

[Richard]

[Please do not mail me a copy of your followup]

Wouter van Ooijen <wou...@voti.nl> spake the secret code

<56d9b651$0$4282$e4fe...@newszilla.xs4all.nl> thusly:

>Op 04-Mar-16 om 4:45 PM schreef Richard:
>> [Please do not mail me a copy of your followup]
>>
>> David Brown <david...@hesbynett.no> spake the secret code
>> <nb9m34$v9r$1...@dont-email.me> thusly:
>>
>>> There are no requirements in C++ to use dynamic memory, though it is
>>> often used "behind the scenes" - you have to be careful and know what
>>> you are doing if you want to avoid dynamic memory entirely.
>>
>> You're making it sound harder than it is:
>>
>> - don't dynamically allocate memory yourself
>> - don't use standard library container classes (string, vector, list,
>> map, etc.)
>>
>> That pretty much covers it.
>
>It does (when you add exceptions, functors, etc.)

I'm talking about his point about avoiding dynamic memory allocation.
Functors and exceptions don't have to do with dynamic memory
allocation unless you start writing calls to new yourself. Since by
definition you're trying to avoid using the heap, then it would be
stupid to write functors that call new. I have to assume some basic
intelligence on behalf of the programmer that doesn't want to use the
heap, so I find it pointless to act as if the programmer that doesn't
want to use the heap is too stupid to understand that writing 'new'
means using the heap.

> but the second point is a very large one.

If you'r in a constrained environment where you can't use the heap,
then it isn't such a big deal. You're either using statically
allocated data structures or you're using the stack. C style arrays
can live in both places just fine.

>And undocumented: there is for instance no hard
>requirement that sin() doesn't use the heap.

Sorry, this is either a pointless exercise in pedantry or it is a
straw man argument.

[Richard]

[Please do not mail me a copy of your followup]

David Brown <david...@hesbynett.no> spake the secret code

<nbceo6$311$1...@dont-email.me> thusly:

>You can use /some/ standard container classes, such as std::array. And
>I think you could probably use at least some of the other container
>classes with customer allocators, placement new, memory pools, etc., to
>use their features without a "dangerous" general purpose heap.

Yes, you could do that. However, it is highly likely that the
resulting code would be harder to understand than just using a
fixed-size array. It isn't a question of what is *possible*, it is a
question of how would you do things in practice under a constrained
environment where using the heap is out of the question. Avoiding being
"clever" here is probably the best advice.

>But are there any other standard library classes or functions that use
>dynamic memory without it being obvious? I don't know, but I suspect

>that shared_ptr does [...]

Again -- shared_ptr is for using the heap. Why would you be
attempting to use shared_ptr when you don't want to use the heap?

Seriously folks, let's get real in this discussion instead of
hypothetical crazy shit like "sin(double)" allocating memory from the
heap or insisting on using shared_ptr<> when we don't want to use the
heap.

[Richard]

[Please do not mail me a copy of your followup]

sl...@pacbell.net spake the secret code

<O2jCy.6828$V53...@fx38.iad> thusly:

Oh yeah, I remember Cfront on SGIs :-).

In ancient times (aka the late 1980s/early 1990s), C++ compilers
weren't as efficient at generating code of small size and/or from
templates.

However, I don't think that's relevant to the discussion today because
things have changed significantly.

[David Brown]

On 04/03/16 18:34, Richard wrote:
> [Please do not mail me a copy of your followup]
>
> David Brown <david...@hesbynett.no> spake the secret code
> <nbceo6$311$1...@dont-email.me> thusly:
>
>> You can use /some/ standard container classes, such as std::array. And
>> I think you could probably use at least some of the other container
>> classes with customer allocators, placement new, memory pools, etc., to
>> use their features without a "dangerous" general purpose heap.
>
> Yes, you could do that. However, it is highly likely that the
> resulting code would be harder to understand than just using a
> fixed-size array. It isn't a question of what is *possible*, it is a
> question of how would you do things in practice under a constrained
> environment where using the heap is out of the question. Avoiding being
> "clever" here is probably the best advice.

On that last point, I agree entirely - being "clever" is rarely a good plan!

Without a heap, classes like vector would be of limited value. However,
I could see the use of a map or queue container of some sort (not
necessarily the standard library types) with either a fixed constant
maximum size, or perhaps with a fixed size given when the structure is
allocated on the stack (like a VLA).

>
>> But are there any other standard library classes or functions that use
>> dynamic memory without it being obvious? I don't know, but I suspect
>> that shared_ptr does [...]
>
> Again -- shared_ptr is for using the heap. Why would you be
> attempting to use shared_ptr when you don't want to use the heap?

The concept of "smart pointers" can be used for a variety of purposes,
not just to track memory. Whenever you have RAII to control a resource,
and you might want to access that resource from several contexts (like
different RTOS threads), you could have a shared pointer type of
management class. But in such cases, you would probably know in advance
exactly how many such managers you would want, and be able to have
statically allocated data (such as reference counters) for them - you
would perhaps want your own specialised sharer class, rather than a
shared_ptr.

There are also other types of dynamic memory that can be allowed in
embedded systems even if a general malloc-style heap is banned. In
systems with Ethernet, it is common to have dynamically allocated
buffers and other resources - but they would come from specific pools in
order to be sure that you have control over allocation/deallocation
times, avoid memory fragmentation, and do not end up with low-priority
processes using all the memory and leaving nothing for high-priority
situations. A standard smart_ptr may be a suitable way of handling such
buffers - but only if the pointer's control block can be allocated in a
controlled manner rather than on the heap.

[Gareth Owen]

legaliz...@mail.xmission.com (Richard) writes:

> [Please do not mail me a copy of your followup]
>
> Gareth Owen <gwo...@gmail.com> spake the secret code
> <87fuw69...@gmail.com> thusly:
>
>>Wouter van Ooijen <wou...@voti.nl> writes:
>>
>>> Algorithms are usefull once you have containser they can operate
>>> on. But most containers relay on the heap...
>>
>>But one could certainly do --
>>
>>std::array<int,16> foo;
>>/// fill in values
>>std::sort(foo.begin(),foo.end());
>
> or:
>
> int foo[16];
> // fill in values
> std::sort(std::begin(foo), std::end(foo));

or, if you're just lazy...

int foo[16];
// fill in values

std::sort(foo,foo+16);

[Scott Lurndal]

legaliz...@mail.xmission.com (Richard) writes:

>>To be fair, one of those projects predated SGI's work on STL, and
>>the one of the others was developed _at_ SGI at the same time that
>>the STL work was being done at SGI/MIPS. The first OS predated templates
>>(was written using Cfront 2.1 starting in 1988/9). The project at SGI
>>mid 90's
>>operated under serious memory constraints and templates were avoided due
>>to code footprint
>>issues (partially resolved in more modern compilers).
>
>Oh yeah, I remember Cfront on SGIs :-).

To be accurate, the cfront project was a Burroughs/Convergent Technologies -> Unisys
distributed operating system for a massively parallel system (called OPUS)
and development servers were motorola 88100 VME boxes (later Unisys S/8400
88100 boxes) using NCD-16 X-terminals. We were far more concerned with the
C compiler used to compile the output of cfront (it was a PCC port to M88100).

SGI had a real C++ compiler (and a pretty good one, too).

[Juha Nieminen]

Nobody <nob...@nowhere.invalid> wrote:
> Compiling the Linux kernel with some random perfectly-conforming
> C compiler will probably result in a kernel which doesn't actually work.

Given that the linux kernel (as most kernels) contains some inline asm,
it's not exactly 100% C-standard compliant in the first place...

(I don't think a kernel can be implemented with zero inline-asm, at
least not for the x86 architecture, assuming the kernel is 32-bit or
64-bit. At the very least you need code to perform a mode switch.)

--- news://freenews.netfront.net/ - complaints: ne...@netfront.net ---

[Juha Nieminen]

David Brown <david...@hesbynett.no> wrote:
> There are no requirements in C++ to use dynamic memory, though it is
> often used "behind the scenes" - you have to be careful and know what
> you are doing if you want to avoid dynamic memory entirely.

I'm not sure in which non-obvious situation a C++ program would use
dynamic memory allocation. I don't think even virtual functions (if
you wanted to use them for some strange reason) would cause dynamic
memory allocation. (AFAIK virtual tables are static, with at most their
pointers being set at launch time, if even then.)

Sure, if you use the standard containers, dynamic allocations will
be made, but that's a no-brainer. (Although there's a way to use them
without dynamic allocation, if you really need to. You simply have to
implement your own allocator for them, which uses a static buffer.)

I'd say there are many things in C that might or might not use
dynamic memory allocation, and it's hard to know for sure. For
example, does fopen() or fread() use dynamic memory allocation?
I have no idea. (I think that these may be needed even in small
embedded environments in some cases.)

[David Brown]

I think you would rarely need such functions in an embedded system that
is too constrained (in resources or timing requirements) to have a heap.
But your point is perfectly valid - C functions may use heap memory
without making it clear, just like C++ functions or classes.

[Scott Lurndal]

Juha Nieminen <nos...@thanks.invalid> writes:
>Nobody <nob...@nowhere.invalid> wrote:
>> Compiling the Linux kernel with some random perfectly-conforming
>> C compiler will probably result in a kernel which doesn't actually work.
>
>Given that the linux kernel (as most kernels) contains some inline asm,
>it's not exactly 100% C-standard compliant in the first place...
>
>(I don't think a kernel can be implemented with zero inline-asm, at
>least not for the x86 architecture, assuming the kernel is 32-bit or
>64-bit. At the very least you need code to perform a mode switch.)

GCC already has various __builtin functions that can be used to
generate specific assembly (__builtin_popcount is one I use heavily).
Other high-level languages I've used for OS development implemented
similar intrinsic functions (e.g. ALGOL for Burroughs Large Systems,
SPRITE for Burroughs medium systems, SPL for HP-3000's, BLISS-32 on
Digital systems, et alia) to generate specific instructions.

Burroughs medium systems COBOL68 compiler had a statement called 'ENTER
SYMBOLIC' that allowed inline assembler in COBOL programs. There was
no assembler offered to customers with either of the Medium or Large
systems mainframe lines and COBOL74 removed the ability to ENTER SYMBOLIC.

[Scott Lurndal]

In our C++ hypervisor, we did this:

/*
* This is called by setup64.S to call the constructors of global objects,
* before it calls dvmm_bsp_start().
*
* GNU LD lays out the __CTOR_LIST__ as an array of function pointers. The
* first element of the array (index == 0) contains an integer which
* represents the value derived from subtracting two from the actual number
* of entries in the table. Thus the content of the first element is
* one less than the index of the last entry in the table.
*
* Call in reverse order XXX - why? Check crt0.o for canonical behavior
*/
extern "C" void
__call_constructors()
{
size_t count = *(size_t *)__CTOR_LIST__;

for(count++; count; --count) {
__CTOR_LIST__[count]();
}
}

/*
* G++'s generated code calls this if a pure virtual member is ever called.
*/
extern "C" void
__cxa_pure_virtual()
{
panic("pure virtual function called\n");
}

/*
* This is needed even though we don't ever use the delete operator because
* G++ generates an extra (unused) virtual destructor that calls it.
*/
void
operator delete(void *)
{
panic("operator delete(void*) called\n");
}

/*
* Catch unintended calls to new.
*/
void*
operator new(size_t)
{
panic("operator new(void*) called\n");
}

[Wouter van Ooijen]

Op 04-Mar-16 om 6:31 PM schreef Richard:

> [Please do not mail me a copy of your followup]
>
> Wouter van Ooijen <wou...@voti.nl> spake the secret code
> <56d9b651$0$4282$e4fe...@newszilla.xs4all.nl> thusly:
>
>> Op 04-Mar-16 om 4:45 PM schreef Richard:
>>> [Please do not mail me a copy of your followup]
>>>
>>> David Brown <david...@hesbynett.no> spake the secret code
>>> <nb9m34$v9r$1...@dont-email.me> thusly:
>>>
>>>> There are no requirements in C++ to use dynamic memory, though it is
>>>> often used "behind the scenes" - you have to be careful and know what
>>>> you are doing if you want to avoid dynamic memory entirely.
>>>
>>> You're making it sound harder than it is:
>>>
>>> - don't dynamically allocate memory yourself
>>> - don't use standard library container classes (string, vector, list,
>>> map, etc.)
>>>
>>> That pretty much covers it.
>>
>> It does (when you add exceptions, functors, etc.)
>
> I'm talking about his point about avoiding dynamic memory allocation.
> Functors and exceptions don't have to do with dynamic memory
> allocation unless you start writing calls to new yourself.

IME that is not true. The exception handling 'framework' that is added
when you use exception does use the heap, as does std::function.

(snip)

>> And undocumented: there is for instance no hard
>> requirement that sin() doesn't use the heap.
>
> Sorry, this is either a pointless exercise in pedantry or it is a
> straw man argument.

Why? The point is that without trying I can make an educated guess what
kind of library elements do or don't use any of (heap, exception, RTTI),
but I can't be sure.

Wouter

[Ian Collins]

On 03/05/16 04:41, Richard wrote:
> [Please do not mail me a copy of your followup]
>
> sl...@pacbell.net spake the secret code
> <%pZBy.10422$w23....@fx23.iad> thusly:
>
>> I've written parts of two major operating systems and a distributed hypervisor
>> all written in C++.
>> [...]
>> STL generally not useful.
>
> I assume you are referring to containers when you say "STL".
> I can't see why the algorithms wouldn't be useful in a constrained
> environment.

I did suggest on the low traffic comp.std.c++ group that standard
library headers that don't require run time (especially dynamic
allocation) support should be identified in the standard. One of these
days I'll follow this up.

--
Ian Collins

[Richard]

[Please do not mail me a copy of your followup]

Gareth Owen <gwo...@gmail.com> spake the secret code

<87d1ra8...@gmail.com> thusly:

>legaliz...@mail.xmission.com (Richard) writes:
>> or:
>>
>> int foo[16];
>> // fill in values
>> std::sort(std::begin(foo), std::end(foo));
>
>or, if you're just lazy...
>
>int foo[16];
>// fill in values
>std::sort(foo,foo+16);

Good point. I wouldn't say you even have to be lazy :-). The form
with begin/end doesn't need to be updated if the number of elements in
the array change later-on. Having to make the same change (16 to 20
for instance) in multiple places in the code is a code smell.

The std::begin/end usefulness for fixed length C style arrays comes in
most handy with a range for statement.

[Richard]

[Please do not mail me a copy of your followup]

sl...@pacbell.net spake the secret code

<RukCy.6642$ow2....@fx39.iad> thusly:

>SGI had a real C++ compiler (and a pretty good one, too).

Only after they had a Cfront based compiler. I know because I was
using their compiler at the point when they switched.

[Stuart Redmann]

Ian Collins wrote:
> I did suggest on the low traffic comp.std.c++ group that standard
> library headers that don't require run time (especially dynamic
> allocation) support should be identified in the standard. One of these
> days I'll follow this up.
>

Nice to hear. I will follow your efforts with interest.

Regards,
Stuart

[Juha Nieminen]

Scott Lurndal <sc...@slp53.sl.home> wrote:
> /*
> * G++'s generated code calls this if a pure virtual member is ever called.
> */
> extern "C" void
> __cxa_pure_virtual()
> {
> panic("pure virtual function called\n");
> }

What's wrong with pure virtual functions? They don't cause dynamic
memory allocation. (And why *pure* virtual functions only? They are
no different from normal virtual functions. The only difference
between them happens at compile time. At runtime there's no difference.)

[Ian Collins]

On 03/07/16 11:56, Juha Nieminen wrote:
> Scott Lurndal <sc...@slp53.sl.home> wrote:
>> /*
>> * G++'s generated code calls this if a pure virtual member is ever called.
>> */
>> extern "C" void
>> __cxa_pure_virtual()
>> {
>> panic("pure virtual function called\n");
>> }
>
> What's wrong with pure virtual functions? They don't cause dynamic
> memory allocation. (And why *pure* virtual functions only? They are
> no different from normal virtual functions. The only difference
> between them happens at compile time. At runtime there's no difference.)

Calling a pure virtual functions usually ends in tears...

--
Ian Collins

[Juha Nieminen]

Ian Collins <ian-...@hotmail.com> wrote:
> Calling a pure virtual functions usually ends in tears...

Why? It's just a normal virtual function call.

Unless you mean circumvent somehow the compiler checks and call it
on an object of the base class type? You would really need to do it
deliberately, so you would be asking for it.

[Ian Collins]

On 03/07/16 12:09, Juha Nieminen wrote:
> Ian Collins <ian-...@hotmail.com> wrote:
>> Calling a pure virtual functions usually ends in tears...
>
> Why? It's just a normal virtual function call.
>
> Unless you mean circumvent somehow the compiler checks and call it
> on an object of the base class type? You would really need to do it
> deliberately, so you would be asking for it.

The usual route to tears is to accidentally call a virtual function in a
constructor.

--
Ian Collins

[Juha Nieminen]

Ian Collins <ian-...@hotmail.com> wrote:
> The usual route to tears is to accidentally call a virtual function in a
> constructor.

Don't call virtual functions in constructors?

[Alf P. Steinbach]

On 07.03.2016 10:13, Juha Nieminen wrote:
> Ian Collins <ian-...@hotmail.com> wrote:
>> The usual route to tears is to accidentally call a virtual function in a
>> constructor.
>
> Don't call virtual functions in constructors?

Worth noting that as opposed to Java and C#, in C++ it's safe to call
virtual functions in constructors, in particular calling them indirectly
via base class functions.

In Java and C# a virtual method call from a constructor can easily end
up being processed in derived class code, where the necessary
initialization of things that code depends on, has not yet been done.

This common error – perhaps the most common cause of bugs in Java –
simply can't happen with calls of virtual functions from a class T
constructor in C++, because in C++ the dynamic type of the object is T.

• • •

The “don't call virtuals” advice, which is not uncommon, is therefore
misplaced for C++.

• • •

It's IMHO about the same as using all uppercase names for constants, an
uncritical adoption of an originally meaningful convention in a new
setting where it's not appropriate, and even has negative utility.

This also explains the not uncommon argument for the “don't call
virtuals” advice, namely, that one allegedly don't get the effect one
would expect.

For only by being ignorant of the C++ rules could one expect something
else than the effect actually delivered, e.g. expecting Java behavior.


Cheers!,

- Alf

[Scott Lurndal]

The compiler generates calls to __cxa_pure_virtual (normally provided
by crt0 or libc) in the vtable slots for any non-overridden pure-virtual
functions. Can't link without it.