Tidy более жесткий

Там вплоть до кодстайла чекается

http://www.mariobadr.com/using-clang-tidy-with-cmake-36.html

tidy еще исправлять умеет

Это же разное...

Не вижу существенной разницы. noexcept - функция не бросает исключений, иначе std::terminate. -fno-exceptions - никакая функция в компилируемом коде не кидает исключений, иначе std::terminate.

Спасибо, гуглить я умею. Несмотря на то, что там написано "the behavior is quite different when you use -fno-exceptions and when you mark the function as noexcept", я в упор не вижу разницы (разве что в одном случае код с throw скомпилируется, а в другом - нет, но разве это существенно?).

Так где же разница в поведении? Даже если библиотека кинет исключение, то и в том, и в другом случае я получу std::terminate.

ребят, кто знает, почему std::regex expr("[0-9]+"); бросается ексепшенами

уже пробовала и "\\d+"

может проблема не в регулярке?

вроде с ней всё норм

и "\\d" - одно и то же

может проблема не в регулярке?

так именно на этой строке падает

точнее, бросается ексепшеном

точнее, бросается ексепшеном

Каким?

regex_error

может что-то память регэкспа попортило?

тогда валгриндом погулять?

если gcc/clang, я бы с включенным asan скомпилировал и позапускал

regex_error

Пустое работает?

Местами вверх/вниз с чем нить

Проблема точно не в regex'e

Барьеры расставить

Пустое работает?

да

да

точно memory corruption

точно memory corruption

интересно, где это оно могло покораптиться, если я эту переменную только инициализирую на этой строке

интересно, где это оно могло покораптиться, если я эту переменную только инициализирую на этой строке

покажи код?

интересно, где это оно могло покораптиться, если я эту переменную только инициализирую на этой строке

А раньше неё какой код? Покажи стектрейс

мог испортиться сам строковый литерал, например)

В обратном порядке, не? Валгринд больше ловит и дальше работает

кстати, спасибо за совет с СЛион - дебажить стало намного удобнее

У меня наоборот

мог испортиться сам строковый литерал, например)

Они же в read-only памяти по умолчанию. Упало бы раньше.

Вместе не вижу смысла, обычно компилирую с asan, если не работает, загоняю в valgrind

нет

Есть UB при попытке их изменить (const жеж). Гарантии segfault'a, естественно, нет, но на практике компилятор всегда помещает их в .rodata сегмент, который мапится как read-only.

UB не стоит понимать буквально, в большинстве случаев поведение на конкретной платформе с конкретным компилятором достаточно определенное.

Ну любое неопределенное поведение в итоге как-то определено

Разработчики компиляторов адекватные люди.

Ну гарантий нет, но если стоит rand%42 уже 8 версий и никто код не трогает, то это вполне определенно)

если

Я говорю о том, что такой код: ''' int* x = nullptr; *x = 123; ''' скомпилированный череез g++\clang на x86(-64) под линуксом гарантированно дает segfault хоть это и UB. Ядерные ракеты такой код (внезапно!) не запустит.

не те 'кавычки' -_-

Я говорю о том, что такой код: ''' int* x = nullptr; *x = 123; ''' скомпилированный череез g++\clang на x86(-64) под линуксом гарантированно дает segfault хоть это и UB. Ядерные ракеты такой код (внезапно!) не запустит.

Внезапно этот код работает если вы пишите под BIOS

Ещё хуже... Современные компиляторы оптимизируют основвываясь на UB. Если код с UB работает на gcc-6.2, то на gcc-6.3 могут добавить оптимизацию и код работать перестанет.

Да, я из него черпал инфу :)

Ещё хуже... Современные компиляторы оптимизируют основвываясь на UB. Если код с UB работает на gcc-6.2, то на gcc-6.3 могут добавить оптимизацию и код работать перестанет.

Наоборот же, часть UB ситуаций были введены чтобы компиляторам было проще оптимизировать.

Речь с самого начала шла о таких ограниченниях

UB не стоит понимать буквально, в большинстве случаев поведение на конкретной платформе с конкретным компилятором достаточно определенное.

Внезапно этот код работает если вы пишите под BIOS

Да в любом месте, где разрешена запись в нулевой адрес. Где-т тут на днях была статья про фишку ядра линя, связанную с тем, что где-то нуллптр был writable, а разрабы в некоторых местах писали в него с надеждой, что писать туда нельзя ( т.е., для падения ядра)

Хз, мб ща найду

#include <iostream> int main (){ std::cout << "Hello World!"; return 0; }

/tmp/ccea35T1.o: In function `main': learn.cpp:(.text+0xa): undefined reference to `std::cout' learn.cpp:(.text+0xf): undefined reference to `std::basic_ostream<char, std::char_traits<char> >& std::operator<< <std::char_traits<char> >(std::basic_ostream<char, std::char_traits<char> >&, char const*)' /tmp/ccea35T1.o: In function `__static_initialization_and_destruction_0(int, int)': learn.cpp:(.text+0x3d): undefined reference to `std::ios_base::Init::Init()' learn.cpp:(.text+0x4c): undefined reference to `std::ios_base::Init::~Init()' collect2: error: ld returned 1 exit status

Вот почему, нльзя сесть спокойно ипо урокам делать??

Мне дали ссылку на уроки learncpp.com

Вот написал как там написано и вот что.

Подскажите плиз чо за фигня.

это уже С++, там компилятор С?

Ну я делаю gcc file.cpp

Ну я делаю gcc file.cpp

1. g++ 2. #supapro

Извиняюсь за тупость.

Парни, есть какие-нибудь каналы в телеграме по C++?

Уже вот тут

Добро пожаловать

> каналы

🙈

А, в глаза долблюсь, бывает )

Парни, есть какие-нибудь каналы в телеграме по C++?

@procxxnews

также по новостям туда можно мне в лс писать

А по Qt есть какие-нибудь живые чаты и каналы? Язык не важен, лишь бы поговорить можно было.

тут можно. и в супапро. отдельных чатов не видел, но можно создать, если будет народ

да можно и сюда я думаю

тут кутешников много, я один из них

алсо вот, ребят. вспомнил. поставил сегодня на пробу resharper - плагин для V2013. прогнал его на одном проекте. и он выдал такое странное предупреждение. суть в следующем

class C { public: C() { val |= some_bitmask; // warning - value may be unitialized } int val = 0; }

ну примерно так

мне казалось - если с C++11-style что-то инициализируется, то в теле конструктора оно уже присвоено, разве нет?