60 антипаттернов для С++ программиста, часть 4 (совет 16 — 20)

Есть с clang-format несколько серьезных проблем.

Его нельзя настроить так, чтобы код не выглядел убогой лапшой без всякой семантики. Из самого забавного, в нём невозможно настроить вот такое форматирование:

static inline ::some::deep::namespace::ClassName::Ptr
someQuiteLongFunctionName (
    int param1,
    int param2,
    int param3
) {
}

Максимум, что может породить clang-format:

static inline ::some::deep::namespace::ClassName::Ptr
someQuiteLongFunctionName ( int param1,
    int param2,
    int param3) 
{
}

Или даже что-то банальное, вроде вот такогого выравнивания в условиях:

if(
    condition1
    || condition2
    || condition3
) {
}

И еще огромную кучу вещей. Например, у нас есть кодовая база, где было принято все лямбды оформлять следующим образом:

auto some_lambda = 
    [a, b, c, d, movable = std::move(val)]
    (int x, void* ptr) -> bool
    {
        //Body content
        return true;
    };

И такой код пускай и слегка громоздкий, зато оч легко читать, т.к. список захвата, параметры, возвращаемое значение и тело лямбды разделены логически.

Опять же, много где в алгоритмах передаются лямбды и когда они небольшие - проблем нет, можно хоть в одну строку всё писать. А вот когда условия становятся сложнее, то неплохо бы иметь форматирование вроде такого:

std::transform(                    //Семантически разделяем
    std::begin(in), std::end(in),  //Вход
    std::back_inserted(out),       //Выход
    [](auto&& v) {
         //Какое-то сложное преобразование
    }
)

И хоть об стену убейся невозможно настроить clang-format соответствующим образом, а проект уже есть и код есть.

И тут или плодить мегакоммитище, который из стройного кода которому все привыкли породит тонну мерзкой лапши, или написать свой тул по форматированию, или забить понадеяться, что люди в целом не дураки и способны плюс/минус соблюдать соглашения принятые в коде.

Не смотря на то, что у меня есть некоторые расхождения во вмении с автором по ряду "советов", с удовольствием приобрету печатную версию. Хочу использовать как пособие для юных подаванов. PDF тоже не плохо было бы получить. Спасибо.

в начале 2000х сталкивался с таким подходом: программе в случае нехватки памяти надо было в любом случае выполнять некий пост-код. Для этого отъедали глобально небольшой кусок памяти при старте, и в случае нехватки перед выходом освобождали глобал - выполняли нужный пост-код на освободившейся памяти.

и да, не работало :)

Поэтому Строустроп и Ко в C++ заставили оператор new выкидывать исключение а не возвращать код ошибки. «А мужики то и не знают…»

Корректно завершить значит вызвать все деструкторы, которые должны освободить ресурсы. При нехватке памяти никаких гарантий нет. Идея зарезервировать память а в случае исключения словоблудить -так себе костыль. Если лишнюю не резервировать то может быть и нехватки памяти бы не было.

Плюс вы не можете контролировать выделение памяти в ОС. Поскольку куча процессов свои буфеты резервирует