search

esa / pagmo2

A C++ platform to perform parallel computations of optimisation tasks (global and local) via the asynchronous generalized island model.
https://esa.github.io/pagmo2/
GNU General Public License v3.0
823 stars 161 forks source link

throw -> std::terminate in problem.hpp #467

Closed ow97 closed 3 years ago

ow97 commented 3 years ago

Usage of throw outside a catch block is equivalent to a call to std::terminate as per https://en.cppreference.com/w/cpp/language/throw

This change preserves semantics while permitting use of -fno-exceptions

bluescarni commented 3 years ago

@ow97 looks good to me. Out of curiosity, why are only these two lines a problem for -fno-exceptions? Is it just a matter of compiler warnings or is there more to it?

ow97 commented 3 years ago

Every other throw in a header is a result of expansion of the (imho brilliant) pagmo_throw macro. One can redefine this macro not to use throw, but instead tap into a different exception mechanism, avoiding any appearance of throw in a preprocessed header. These two lines are the exception to this, and cause the compiler to complain about use of throw.

If compilation with -fno-exceptions is something that we want to support more fully, this could be made cleaner and we could even document it. But for the moment I'm happy with this solution as I'm aware that mine is a rather niche use case.

bluescarni commented 3 years ago

@ow97 this is interesting, thanks for the explanation. I have never used -fno-exceptions myself, but I understand it's widely used in some communities. I was under the impression that the compiler would just ignore all throws and replace them with some terminate-like function.

I have in principle no issues against enabling exception-less builds, as long as it's feasible without too much disruption to the existing code. As you say, probably the best way to do this would be via some hijacking of the pagmo_throw() macro...