What is the point of using noexcept as specificator?
-
Hello..
the most of my functions do not throw any exception... so all of them are in an undefined state i guess... may or not may throw an exception...
Does that means the noexcept specificator is a token used only for other programmers as a kind of protection?... something like to say : Hey Mike!.. this function does not throw an excepto, so be sure not to use try catch please..
still don't get it!..
-
-
@Christian-Ehrlicher
Specifies if a function may not throw an exception and if it does it, the program crashesOf course i understand that my friend, what i do not get is when to use it, it is supposed that you write your funtions and you know when you throw an exception and when not, so nothrow is somekind of redundant... The evaluation is in compiling time, thats why my doubt.
-
@Christian-Ehrlicher
Specifies if a function may not throw an exception and if it does it, the program crashesOf course i understand that my friend, what i do not get is when to use it, it is supposed that you write your funtions and you know when you throw an exception and when not, so nothrow is somekind of redundant... The evaluation is in compiling time, thats why my doubt.
@U7Development said in What is the point of using noexcept as specificator?:
Of course i understand that my friend, what i do not get is when to use it, it is supposed that you write your funtions and you know when you throw an exception and when not, so nothrow is somekind of redundant... The evaluation is in compiling time, thats why my doubt.
If you're unsure when to use it, then don't. That's a modifier for specific cases where you can be sure you don't throw and allow the compiler to skip generating the relevant exception code. By default all C++ functions/methods (unless disabled by a compiler flag) throw, so leave it be, unless you're absolutely certain you can and should use it.
-
@U7Development said in What is the point of using noexcept as specificator?:
Of course i understand that my friend, what i do not get is when to use it, it is supposed that you write your funtions and you know when you throw an exception and when not, so nothrow is somekind of redundant... The evaluation is in compiling time, thats why my doubt.
If you're unsure when to use it, then don't. That's a modifier for specific cases where you can be sure you don't throw and allow the compiler to skip generating the relevant exception code. By default all C++ functions/methods (unless disabled by a compiler flag) throw, so leave it be, unless you're absolutely certain you can and should use it.
@kshegunov ok!.. if compiler skips procedures that has sense to remark as noexcept, so i think i could use noexcept(false) to every of my functions as well..
Thanks.. -
@kshegunov ok!.. if compiler skips procedures that has sense to remark as noexcept, so i think i could use noexcept(false) to every of my functions as well..
Thanks..@U7Development said in What is the point of using noexcept as specificator?:
so i think i could use noexcept(false) to every of my functions as well..
This is the default. Leave it alone (that is, just don't use it) and it's going to be just fine.
-
@U7Development said in What is the point of using noexcept as specificator?:
Of course i understand that my friend, what i do not get is when to use it, it is supposed that you write your funtions and you know when you throw an exception and when not, so nothrow is somekind of redundant... The evaluation is in compiling time, thats why my doubt.
If you're unsure when to use it, then don't. That's a modifier for specific cases where you can be sure you don't throw and allow the compiler to skip generating the relevant exception code. By default all C++ functions/methods (unless disabled by a compiler flag) throw, so leave it be, unless you're absolutely certain you can and should use it.
@kshegunov said in What is the point of using noexcept as specificator?:
That's a modifier for specific cases where you can be sure you don't throw and allow the compiler to skip generating the relevant exception code.
It may also unblock certain optimizations, for example I've seen the case where disabling exceptions allowed compiler to inline constructor of temporary object, which didn't happen otherwise.
-
All compilers have implementations of exceptions that violate the "you don't pay for what you don't use"-principle. By default all functions need to be compiled to support exception handling (i.e. at least pass exception along). Since the implementations are inefficient in todays compilers, for high performance applications developers turn exceptions entirely off. This basically leads to exception-free code. It also means that the STL might not work correctly. Furthermore, it means that everyone is inventing their own error reporting mechanism to replace exceptions. If your project pulls in several libraries they won't play nice with each other concerning error handling. Most of the time this leads to code that does not check errors at all.
Now, entering
noexcept: Withnoexcept, marked functions are compiled without any exception handling. First of all, this makes code fast again. The general hope is that all developers turn on exceptions again (without then sacrificing performance) and reporting of exceptional behavior is once again unified.Herb Sutter is also pushing forward a new exception specification which merges exceptions with the return type and would be a lot faster on all compilers.
-
@SimonSchroeder said in What is the point of using noexcept as specificator?:
Herb Sutter is also pushing forward a new exception specification which merges exceptions with the return type and would be a lot faster on all compilers.
exceptions merged with return types? Bleck!
-
@SimonSchroeder said in What is the point of using noexcept as specificator?:
Herb Sutter is also pushing forward a new exception specification which merges exceptions with the return type and would be a lot faster on all compilers.
exceptions merged with return types? Bleck!
@Kent-Dorfman said in What is the point of using noexcept as specificator?:
exceptions merged with return types? Bleck!
The basic tenet is that you either return some value or you return an exception, never both at the same time. Furthermore, those exceptions should be returned by value instead of thrown by reference. Exceptions merged with return types is only what the compiler does, but the programmer will see nothing from this.
Here is Herb Sutter's talk that I watched: https://www.youtube.com/watch?v=ARYP83yNAWk
Or if you prefer to read: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0709r0.pdf -
All compilers have implementations of exceptions that violate the "you don't pay for what you don't use"-principle. By default all functions need to be compiled to support exception handling (i.e. at least pass exception along). Since the implementations are inefficient in todays compilers, for high performance applications developers turn exceptions entirely off. This basically leads to exception-free code. It also means that the STL might not work correctly. Furthermore, it means that everyone is inventing their own error reporting mechanism to replace exceptions. If your project pulls in several libraries they won't play nice with each other concerning error handling. Most of the time this leads to code that does not check errors at all.
Now, entering
noexcept: Withnoexcept, marked functions are compiled without any exception handling. First of all, this makes code fast again. The general hope is that all developers turn on exceptions again (without then sacrificing performance) and reporting of exceptional behavior is once again unified.Herb Sutter is also pushing forward a new exception specification which merges exceptions with the return type and would be a lot faster on all compilers.
@SimonSchroeder said in What is the point of using noexcept as specificator?:
All compilers have implementations of exceptions that violate the "you don't pay for what you don't use"-principle.
To bring this to an extreme - you may as well write
asm, put everything in the global memory space and ditch the c++ nonsense altogether, then you're going to have no overhead of some stinkin' local stack, overhead of function calls, etc.By default all functions need to be compiled to support exception handling (i.e. at least pass exception along). Since the implementations are inefficient in todays compilers
How inefficient exactly? Or are you just citing the scripture?
Here, have a look:
https://godbolt.org/z/3wLWB4
GCC is smart enough to put the exception handling code into a cold page. If the throw doesn't actually happen you pay next to nothing for it (runtime). Binary code's larger, no doubt.for high performance applications developers turn exceptions entirely off.
Define high performance. If you mean numbercrunching, no we don't. If you mean real-time mission-critical code, sure. Not everybody falls in either category, though. The sort of blanket-term-mentality Herb's been chanting for years doesn't help nobody.
Furthermore, it means that everyone is inventing their own error reporting mechanism to replace exceptions.
Everybody? I mean do you really think some can be equated to everybody? That's the kind of logic that explodes nuclear powerplants and brings planes crashing into the ground.
If your project pulls in several libraries they won't play nice with each other concerning error handling. Most of the time this leads to code that does not check errors at all.
That just shows bad code hygiene, not an argument for or against exceptions.
Now, entering
noexcept: Withnoexcept, marked functions are compiled without any exception handling. First of all, this makes code fast again.Again, you're talking absolute terms. Fast and slow (and cheap and costly) are terms that are applied to something in relation to something else. They're not absolute by any measure. If your code is bad, no modifier is going to make it good.
Herb Sutter is also pushing forward a new exception specification which merges exceptions with the return type and would be a lot faster on all compilers.
Herb's been pushing many things, some of which are rather dubious in quality and argumentation, to put it mildly. Not everything the messiah says or writes is applicable to everybody, nor are his conclusions correct in the general case.
To put some context in, he's been pushing for the almost always auto for ages now, "cause the compiler can deduce it". Yeah, sure, the compiler can, but when you start working with someone's code that applies that philosophy you rather quickly realize it's a big pile of bull. You're not the compiler, nor do you want to stare at some call trying to deduce what the thing returns out of its name. I imagine you have better things to do than to instantiate templates in your head, or think about what the previous guy had in mind.
The basic tenet is that you either return some value or you return an exception, never both at the same time.
To paraphrase my signature: "Even if we accept, as the basic tenet of true code, that Herb Sutter is right, is it necessary to go a further step and hold that he's always right?"
PS: I don't hide it, the guy annoys me greatly, but not because he's not smart or because he doesn't have good ideas. Rather that a religion has formed where everyone that doesn't support "the modern" c++ has become a heretic to be burned at the stake. That doesn't fly that well in the real world, though ...
-
@kshegunov said in What is the point of using noexcept as specificator?:
almost always auto
I have run into problems with this. You can write code you think is doing one thing. Yet because you didn't explicitly provide the type, you may be getting something else altogether. Then you wonder why something downstream is not working as you thought. I find it useful to specify the type in cases where there might be ambiguity in my mind as to what I am actually getting. auto sometimes clouds this perception and makes for confusing moments in coding.
