using noexcept in potentially throwing functions #1460
-
DataBypass class has a lot of methods, marked as noexcept, like this: mipt-mips/simulator/modules/decode/bypass/data_bypass.h Lines 30 to 34 in 63eb993 Although, there is absolutely no guarantee, that they won't throw, because invocations like instr.get_src() are not noexcept. Why are we using it? It makes code non reusable and not exception-safe |
Beta Was this translation helpful? Give feedback.
Replies: 4 comments 1 reply
-
Could you please prove your statement?
This method is a GPROF bottleneck, so we remove exception handling code to optimize more aggressively. |
Beta Was this translation helpful? Give feedback.
-
This will fail to compile: auto is_in_RF( const Instr& instr, size_t src_index) const noexcept
{
static_assert(noexcept(instr.get_src( src_index)), "instr.get_src( src_index) may throw");
const auto reg_num = instr.get_src( src_index);
return get_entry( reg_num).current_stage.is_in_RF();
} And this too void RegisterStage::inc() noexcept
{
static_assert(noexcept(value + 1_lt), "Latency::operator +() is not noexcept too");
value = value + 1_lt;
} So we are relying on some implicit thoughts about operations behaviour |
Beta Was this translation helpful? Give feedback.
-
I don't get it. Why should we add these static assertions?
These thoughts are explicit, since they are defined in unit tests. I suspect you are trying to sell me "defensive programming" paradigm, where each function or procedure assumes the inputs may be incorrect. |
Beta Was this translation helpful? Give feedback.
-
Ok, I understood, thanks for answer |
Beta Was this translation helpful? Give feedback.
I don't get it. Why should we add these static assertions?
These thoughts are explicit, since they are defined in unit tests.
Please correct me if I'm wrong.
I suspect you are trying to sell me "defensive programming" paradigm, where each function or procedure assumes the inputs may be incorrect.
MIPT-V does not use it. Instead, we prove there are no chances to generate these incorrect inputs.