On 12/11/16 01:53, Dave Nadler wrote:> On Thursday, November 10, 2016 at 4:43:35 AM UTC-5, David Brown wrote: >> On 10/11/16 07:34, Wouter van Ooijen wrote: >>> Op 09-Nov-16 om 9:23 AM schreef David Brown: >>>> On 08/11/16 23:30, Wouter van Ooijen wrote: >>>>> Op 08-Nov-16 om 8:59 PM schreef Dave Nadler: >>>>>> On Monday, November 7, 2016 at 12:59:30 PM UTC-5, Tim Wescott wrote: >>>>>>> If you're not going to allow global constructors, >>>>>>> what's the point of using C++? >>>>>> >>>>>> Because of ordering issues, I've typically placed "global lifetime" >>>>>> objects as static objects inside (ordered by code) subsystem >>>>>> initialization >>>>>> routines. Then referred to them via static pointers. Not ideal but >>>>>> workable >>>>>> way to order the initialization. >>>>>> >>>>>> Global ctors aside, C++ provides huge advantages: >>>>>> - type safety >>>>>> - RAII especially preventing resource leaks in dtors >>>>>> - templates >>>>>> - specialized storage allocation by class if required >>>>>> and so forth. >>>>>> All without any dynamic allocation except on stack. >>>>>> >>>>>> If only there was a way to have exceptions without heap; >>>>>> exceptions really do help make safer code. >>>>>> Might be possible in some C++ toolchains if throws are >>>>>> limited to pointers (to static exception info)? >>>>>> Depends I guess on the implementation (ie does exception >>>>>> processing rely on RTTI). >>>>> >>>>> To my knowledge exception handling requires something like RTTI, but not >>>>> necessarily a heap (AFAIK current implemnentations do). >>>> >>>> I believe that exception handling does not need RTTI, unless you are >>>> using polymorphic exceptions (i.e., throwing specific exceptions and >>>> catching generic ones). >>>> >>>>> >>>>> I've had a few discussions about exceptions. The current aim of the >>>>> anti-exception advocates (as heared in SG14) is that exceptions are too >>>>> costly in time. This is mostly from gaming, fast trading and google. >>>>> >>>> >>>> I am not keen on exceptions in embedded code, but the time costs are not >>>> the main issue. The run-time costs for code that could throw, but does >>>> not, are very small - often smaller than alternative explicit error >>>> handling code. I think the possibility of exceptions occurring may >>>> hinder optimisations - in particular, it could limit certain types of >>>> code re-ordering. There is also the cost in code space for all the >>>> stack unwind stuff. >>>> >>>> I dislike exceptions simply because they are undocumented gotos. I >>>> don't like the idea of functions that can quietly fail in some way and >>>> hope that something further up the system can deal with it in a sensible >>>> manner. It can be okay on a PC desktop program to say that a particular >>>> operation failed, and carry on with rest of the tasks - if one web page >>>> fails to open correctly, the rest of the browser is still usable. But >>>> on embedded systems, /everything/ should work correctly all the time - >>>> if a bit of software is not necessary, it should not be part of the >>>> program. (Note that some things, such as hardware, may fail - but the >>>> software should correctly deal with those problems.) >>>> >>>>> My (main) problem with exceptions is the use of the heap. >>>>> >>>> >>>> Exceptions do not /have/ to use the heap. >>> >>> Maybe, but the current implementations do. >>> >>>> I had a quick google for >>>> this, and found that the gcc C++ library will try to get heap memory for >>>> an exception - but if it fails, it will use memory from a statically >>>> allocated "emergency buffer". >>> >>> That sound weird. If it can use the static buffer, why not use that >>> anyway? Are you sure it isn't the other way round (a small-expection >>> optimization similar to small-string optimization)? >>> >> >> >> I haven't looked at this in detail, nor have I tried to find >> documentation about /why/ it has this sort of implementation. So I can >> only speculate. And just to be clear, I am talking about PC or "big >> embedded system" implementations here, not memory-constrained devices. >> >> Using an emergency buffer for exceptions will be limited. It puts a >> tight limit on the size of the object thrown (since it is statically >> allocated, and a bigger buffer is a waste of space), and it can only be >> used for one exception (unless you want to re-invent malloc). In a >> multi-threaded program, only one thread can use the emergency buffer at >> a time - there is a lock to protect it. >> >> I don't think it would be a bad idea to have a small buffer per thread >> that would be used for common exception types as a first choice, then >> fall back to heap for big exceptions, then to the emergency buffer if >> that fails too. But the current libstdc++ does not have such an >> implementation. > > Here's a nice write-up on how libstdc++ manages exceptions, > and how to write a replacement: > https://monoinfinito.wordpress.com/series/exception-handling-in-c/ >Thanks. I haven't read it yet, so I can't comment on it - but I will do so as soon as I get the chance.
g++ on Cortex-M with no dynamic memory
Started by ●November 5, 2016
Reply by ●November 12, 20162016-11-12
Reply by ●November 21, 20162016-11-21
Il giorno sabato 12 novembre 2016 01:53:53 UTC+1, Dave Nadler ha scritto:> On Thursday, November 10, 2016 at 4:43:35 AM UTC-5, David Brown wrote: > > On 10/11/16 07:34, Wouter van Ooijen wrote: > > > Op 09-Nov-16 om 9:23 AM schreef David Brown: > > >> On 08/11/16 23:30, Wouter van Ooijen wrote: > > >>> Op 08-Nov-16 om 8:59 PM schreef Dave Nadler: > > >>>> On Monday, November 7, 2016 at 12:59:30 PM UTC-5, Tim Wescott wrote: > > >>>>> If you're not going to allow global constructors, > > >>>>> what's the point of using C++? > > >>>> > > >>>> Because of ordering issues, I've typically placed "global lifetime" > > >>>> objects as static objects inside (ordered by code) subsystem > > >>>> initialization > > >>>> routines. Then referred to them via static pointers. Not ideal but > > >>>> workable > > >>>> way to order the initialization. > > >>>> > > >>>> Global ctors aside, C++ provides huge advantages: > > >>>> - type safety > > >>>> - RAII especially preventing resource leaks in dtors > > >>>> - templates > > >>>> - specialized storage allocation by class if required > > >>>> and so forth. > > >>>> All without any dynamic allocation except on stack. > > >>>> > > >>>> If only there was a way to have exceptions without heap; > > >>>> exceptions really do help make safer code. > > >>>> Might be possible in some C++ toolchains if throws are > > >>>> limited to pointers (to static exception info)? > > >>>> Depends I guess on the implementation (ie does exception > > >>>> processing rely on RTTI). > > >>> > > >>> To my knowledge exception handling requires something like RTTI, but not > > >>> necessarily a heap (AFAIK current implemnentations do). > > >> > > >> I believe that exception handling does not need RTTI, unless you are > > >> using polymorphic exceptions (i.e., throwing specific exceptions and > > >> catching generic ones). > > >> > > >>> > > >>> I've had a few discussions about exceptions. The current aim of the > > >>> anti-exception advocates (as heared in SG14) is that exceptions are too > > >>> costly in time. This is mostly from gaming, fast trading and google. > > >>> > > >> > > >> I am not keen on exceptions in embedded code, but the time costs are not > > >> the main issue. The run-time costs for code that could throw, but does > > >> not, are very small - often smaller than alternative explicit error > > >> handling code. I think the possibility of exceptions occurring may > > >> hinder optimisations - in particular, it could limit certain types of > > >> code re-ordering. There is also the cost in code space for all the > > >> stack unwind stuff. > > >> > > >> I dislike exceptions simply because they are undocumented gotos. I > > >> don't like the idea of functions that can quietly fail in some way and > > >> hope that something further up the system can deal with it in a sensible > > >> manner. It can be okay on a PC desktop program to say that a particular > > >> operation failed, and carry on with rest of the tasks - if one web page > > >> fails to open correctly, the rest of the browser is still usable. But > > >> on embedded systems, /everything/ should work correctly all the time - > > >> if a bit of software is not necessary, it should not be part of the > > >> program. (Note that some things, such as hardware, may fail - but the > > >> software should correctly deal with those problems.) > > >> > > >>> My (main) problem with exceptions is the use of the heap. > > >>> > > >> > > >> Exceptions do not /have/ to use the heap. > > > > > > Maybe, but the current implementations do. > > > > > >> I had a quick google for > > >> this, and found that the gcc C++ library will try to get heap memory for > > >> an exception - but if it fails, it will use memory from a statically > > >> allocated "emergency buffer". > > > > > > That sound weird. If it can use the static buffer, why not use that > > > anyway? Are you sure it isn't the other way round (a small-expection > > > optimization similar to small-string optimization)? > > > > > > > > > I haven't looked at this in detail, nor have I tried to find > > documentation about /why/ it has this sort of implementation. So I can > > only speculate. And just to be clear, I am talking about PC or "big > > embedded system" implementations here, not memory-constrained devices. > > > > Using an emergency buffer for exceptions will be limited. It puts a > > tight limit on the size of the object thrown (since it is statically > > allocated, and a bigger buffer is a waste of space), and it can only be > > used for one exception (unless you want to re-invent malloc). In a > > multi-threaded program, only one thread can use the emergency buffer at > > a time - there is a lock to protect it. > > > > I don't think it would be a bad idea to have a small buffer per thread > > that would be used for common exception types as a first choice, then > > fall back to heap for big exceptions, then to the emergency buffer if > > that fails too. But the current libstdc++ does not have such an > > implementation. > > Here's a nice write-up on how libstdc++ manages exceptions, > and how to write a replacement: > https://monoinfinito.wordpress.com/series/exception-handling-in-c/thanks, really interesting article. Bye Jack
