Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Remove dynamic exception specifiers #62

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

hainest
Copy link

@hainest hainest commented May 4, 2022

This language feature was deprecated in C++11 and removed in C++17. Starting with gcc-11 and clang-12, the default C++ standard is C++17- preventing LaunchMON from being built with those compilers without forcing an earlier standard (e.g., -std=c++11).

Fixes #61

@dongahn It's me again! I'm working my way through the tools SDK.

This language feature was deprecated in C++11 and removed in C++17. Starting with gcc-11 and clang-12, the default C++ standard is C++17- preventing LaunchMON from being built with those compilers without forcing an earlier standard (e.g., -std=c++11).
@dongahn
Copy link
Collaborator

dongahn commented May 4, 2022

@hainest: great to see you again obviously :-). So we never declared this code base support latest C++ like 17. So some questions when you remove throw construct but still an exception occurs, what happens?

@hainest
Copy link
Author

hainest commented May 4, 2022

So some questions when you remove throw construct but still an exception occurs, what happens?

void foo() { throw X{};} and void foo() throw(X) { throw X{}; } have had identical behavior since C++98. The standard never required that compilers check that a function only throws a given exception type. In fact, there are cases where such a check is impossible. That is why it was removed.

There are two points to consider:

  1. void foo() throw() {} and void foo() noexcept {} have identical behavior. If an exception escapes foo (e.g., it doesn't catch all exceptions thrown by functions it calls), then std::terminate is called and the program will abort. I didn't see any usage of empty throw specifications (throw()) or noexcept, so this won't be an issue right now.

  2. Starting in C++17, noexcept is now part of the type system. This means that taking pointers to noexcept functions works differently.

void do_call_noexcept(void (*)(int) noexcept) {}
void do_call(void (*)(int)) {}

void foo(int) {}
void bar(int) noexcept {}

int main() {
    do_call(&foo);  // compiles
    do_call(&bar);  // compiles

    do_call_noexcept(&foo);  // Error! type mismatch
    do_call_noexcept(&bar);  // compiles
}

Neither of these is happening in the code base right now, but they are something to consider for the future.

@hainest
Copy link
Author

hainest commented Jul 28, 2022

@lee218llnl Dong mentioned you would be a good contact for updates to this repo. Could you take a look at this? Thanks!

@lee218llnl
Copy link
Collaborator

@hainest and @dongahn, I'm not up to date on my C++ programming, so I'm not particularly qualified to review this. @mplegendre may also be able to lend an eye too. Otherwise, you'll have to wait for me to get time to catch up on C++ standards.

@hainest
Copy link
Author

hainest commented Jul 28, 2022

@lee218llnl Not a problem. Let me know if you have any questions.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Compile issues with GCC 11 / spack 0.17.0
3 participants