On Tue, 12 May 2020, 21:57 Freddie Chopin, <freddie_cho...@op.pl> wrote: > > On Tue, 2020-05-12 at 12:07 +0100, Jonathan Wakely wrote: > > You're talking about C++ exceptions in general, but the problems you > > mention seems to be issues with specific implementation properties. > > Possibly true, but this argument - that all the problems are related to > specific implementation and thus can be easily fixed
I didn't say anything about it being easy to fix. I'm just trying to stop misinformation about std::terminate requiring string handling or I/O, which isn't true for C++ in general, and isn't even true for libstdc++ because it's configurable. If you want a smaller EH runtime, that's already possible with libstdc++. Could it be even smaller? Yes, probably, but we need bug reports or concrete suggestions, not outdated or misleading claims about optional properties of the libstdc++ runtime. > - is the same for > years and yet the problem is still there (; I guess that if this could > be easily fixed, then it would be done years ago. Along with the > performance and non-deterministic execution issues... Nobody said it can easily be fixed though. > > If the comments above are referring to the libstdc++ verbose > > terminate > > handler, that's configurable. Configuring GCC with > > --disable-libstdcxx-verbose will disable that, and so will building > > libstdc++ with -fno-exceptions. That was fixed years ago. > > True, sorry for the confusion, indeed I was talking about verbose > terminate handler. I check the state of C++ exceptions for MCUs only > once every few years, so that's why I got that mixed with > std::terminate(). I use my custom compilation with disabled exceptions > (toolchain & libstdc++ built with -fno-exceptions -fno-rtti) and this > works perfectly fine. It's been a few years since we changed anything, because disabling the verbose handler solved one of the biggest issues. > Anyway... If you have to recompile the toolchain, the problem is still > there. Most of the people (like 99,666%) will not do that for various > reasons. Some don't know how, some use only Windows, some don't have > time to deal with the compilation (the whole toolchain takes around an > hour here, but this excludes the time to prepare the script that builds > it), some other consider the toolchain provided by MCU vendor (or by > ARM) as "tested to work correctly" so they don't want to replace that > with their custom built solution, and so on, and so on... There is no one-size-fits-all solution that gives everybody their ideal set of defaults, so we provide configuration options to tune things for your needs. Complaining that you have to rebuild things to get different defaults seems silly. Would you prefer we don't offer the options at all? If you have concrete suggestions for improvements or can identify places we can improve, I'd like to hear them. If you just want to complain about C++ exceptions, that's not very helpful.
