- 01
- 02
- 03
- 04
- 05
- 06
- 07
- 08
- 09
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
#include <iostream>
using namespace std;
class lock_guard_ext{
public:
lock_guard_ext() { cout << "lock_guard_ext ctor" << endl; }
~lock_guard_ext() { cout << "lock_guard_ext dtor" << endl; }
};
struct Access {
lock_guard_ext lock;
int & ref_to_value;
};
int & t() {
throw 0;
}
Access foo1() {
return { {}, t() };
}
int main () {
try {
volatile auto a = foo1();
} catch (int) {
}
}
В шланге деструктор вызывается, в gcc не вызывается.
https://wandbox.org/permlink/7sbsqzhbo0o7dOse
j123123 12.12.2019 22:55 # 0
xyu_100cm 13.12.2019 04:00 # 0
xyu_100cm 13.12.2019 04:00 # 0
gost 12.12.2019 23:25 # 0
Впрочем, причём здесь RAII я так и не понял. Баг-то не в RAII, баг в «GCC».
j123123 13.12.2019 00:15 # +1
Вот если взять сишку, вручную свои деструкторы и конструкторы пилить без всей этой дрисни с trow catch и прочей хуйни, такого бы не было.
Если серьезно, язык C++ настолько запутан и погряз во всякой хуйне, что вряд ли сегодня существует хотя бы один незабагованный C++ компилятор, полностью соответствующий стандарту (пусть даже и не самому свежему, C++98, С++03 или C++11 там)
j123123 13.12.2019 00:31 # +3
https://bugs.llvm.org/show_bug.cgi?id=7469
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=29027
тот же самый баг в Clang и GCC
Притом в GCC он висит аж с 2006 года
xyu_100cm 13.12.2019 04:00 # −1
xyu_100cm 13.12.2019 04:00 # −1
xyu_100cm 13.12.2019 04:00 # −1
XYPO3BO3 13.12.2019 05:41 # 0
xyu_100cm 13.12.2019 04:00 # 0
gost 13.12.2019 08:22 # +1
XYPO3BO3 13.12.2019 08:56 # +1
Если для него 600 страниц стандарта — это слишком сложно, чтобы построить компилятор с прогнозируемым поведением, то что же для него крестостандарт?
bormand 13.12.2019 09:10 # +2
nemywok_Ha_naJlO4KE 14.12.2019 21:42 # −1
Доводится ли он Адочке?
j123123 13.12.2019 18:42 # +3
XYPO3BO3 13.12.2019 10:21 # +2
https://en.wikipedia.org/wiki/CompCert
https://ru.wikipedia.org/wiki/CompCert
Они обещают, что компилятор будет гарантированно выдавать код, соответствующий исходнику. Правда, им пришлось что-то удалить из языка (кажется, поддержку устройства Даффа).
За компилятор же крестов с математической гарантией даже в «INRIA» не взялись.
XYPO3BO3 13.12.2019 10:26 # +2
CompCert C supports all of ISO C 99, with the following exceptions:
• switch statements must be structured as in MISRA-C; unstructured "switch", as in Duff's device, is not supported.
• longjmp and setjmp are not guaranteed to work.
• Variable-length array types are not supported.
Consequently, CompCert supports all of the MISRA-C 2004 subset of C, plus many features excluded by MISRA (such as recursive functions and dynamic heap memory allocation).
Ну вот, ещё setjmp/longjmp не гарантируют и VLA не осилили.
j123123 14.12.2019 12:06 # 0
Можно вместо этого проверять бинарник, который выдал компилятор. Т.е. доказывать, что он по смыслу соответствует исходнику:
https://en.wikipedia.org/wiki/L4_microkernel_family#High_assurance:_se L4
> The NICTA team also proved correctness of the translation from C to executable machine code, taking the compiler out of the trusted computing base of seL4. This implies that the high-level security proofs hold for the kernel executable
Fluttie 25.12.2019 03:26 # 0
gost 25.12.2019 07:14 # 0
Fluttie 25.12.2019 07:26 # 0
>implementation-defined whether or not the stack is unwound
Стеки не крутятся, деструкторы не мутятся же, явно сказано, что пусть там std::terminate (предполагаемый) ебётся.
gost 25.12.2019 07:54 # +1
https://wandbox.org/permlink/KMo3T8EeLfSAwkYE
Это баг в «GCC».
XYPO3BO3 27.12.2019 00:43 # 0
guest8 27.12.2019 01:01 # −999
XYPO3BO3 27.12.2019 01:46 # 0
Konardyan 27.12.2019 02:22 # 0
xyu_100cm 13.12.2019 04:20 # −1
xyu_100cm 13.12.2019 04:00 # −1
xyu_100cm 13.12.2019 04:00 # −1
xyu_100cm 13.12.2019 04:00 # −1
xyu_100cm 13.12.2019 04:00 # −1
xyu_100cm 13.12.2019 04:00 # −1