On Tue, 2020-05-12 at 11:16 +0200, Florian Weimer wrote: > That can only happen if the embedded people do not bother to show up > in > numbers. Of course the tools will move in different directions.
True (; > > That's why the proposal by Herb is a real surprise and I really > > hope > > it could be implemented someday. > > Would you use it if switching from -fno-exceptions to this new > approach > resulted in an immediate 20% code size increase, without actually > using > the new error handling feature at all? What about 10%? As I understand the proposal, it would basically boil down to returning something like std::pair<XXX, HerbCeption> where XXX is what you return explicitly in the code. Or sth like returning std::variant<> or std::optional<>. I use these approaches in my own code all the time (mostly std::pair<int, XXX>, as it's the simplest one). The rest of the proposal seems to be syntax sugar for catching this "HerbCeption" and so on. As my code basically does the same now, I guess the increase for me would be ~0%. I perfectly understand that error handling has some non-zero cost and the only way to avoid it is to completely ignore the errors (; But it seems to me that what is proposed there is really very cheap and very fast. As long as the committee will drop std::string and such from std::error_code (; With current C++ exceptions the increase is not very proportional to the size of the rest of the application. It's more like a one-time ~60 kB increase, even if the application without it would be 5 kB total. In a huge application the increase may be less noticeable, as parts of the pulled code may be used anyway by the app (things like dynamic allocation, fprintf() and so on), but this is still ~25% of total available ROM size. To summarize. Current C++ exceptions have very huge, mostly "one-time" kind, cost on the size, even if not used at all by the user, mosly due to std::terminate() and all the string handling code inside it, as well as the unwind tables. The proposal by Herb seems to be more reasonable in this regard - the amount of extra code generated under the hood will probably be proportional to the amount of code involved and actually similar to what C programmers do manually for decades. Regards, FCh
