Приколько поговорить про гадость, которую можно отловить на этапе компиляции.

Но есть разная дурка, которая аффектит рантайм, но проходит мимо всех ворнингов (иногда это ловят всякие clang-tidy и прочие PVS студии).

Вот канонический пример:

#include<iostream>
#include <map>
#include <vector>
#include <string>

using namespace std;
using Vec = vector<string>;

void f(pair<string, Vec>&& arg) {
    for (const auto& v: arg.second) {
        puts(v.c_str());
    }
}

int main(){
    auto m = map<string, Vec>{
        {"first", {"1","2"}},
        {"second", {"3","4","5"}},
    };

    for (auto&& p: m) {
        f(std::move(p));
    }
}

Мы создаем мапу (она будет создана в компайл тайме), а потом все объекты из нее эффективно муваются.

Но если мы внимательно посмотрим в исхродный код, то найдем там вот такое:

        call    memcpy@PLT

Я прошу прощения...? Какое копирование?! Где?

И вообще весь блок выглядит подозрительно похоже на конструктор копирования:

.LBB1_84:
        mov     qword ptr [rsp + 56], r13
        mov     r14, qword ptr [rbx + 32]
        mov     rbp, qword ptr [rbx + 40]
        cmp     rbp, 16
        jb      .LBB1_87
        lea     r15, [rbp + 1]
        mov     rdi, r15
        call    operator new(unsigned long)@PLT
        mov     qword ptr [rsp + 56], rax
        mov     qword ptr [rsp + 72], rbp
        jmp     .LBB1_89
.LBB1_87:
        test    rbp, rbp
        je      .LBB1_106
        lea     r15, [rbp + 1]
        mov     rax, r13
.LBB1_89:
        mov     rdi, rax
        mov     rsi, r14
        mov     rdx, r15
        call    memcpy@PLT
.LBB1_90:
        mov     qword ptr [rsp + 64], rbp
        mov     r14, qword ptr [rbx + 64]
        mov     qword ptr [rsp + 88], r14
        movups  xmm0, xmmword ptr [rbx + 72]
        mov     r15, qword ptr [rbx + 72]
        movups  xmmword ptr [rsp + 96], xmm0
        xorps   xmm0, xmm0
        movups  xmmword ptr [rbx + 64], xmm0
        mov     qword ptr [rbx + 80], 0
        cmp     r14, r15
        je      .LBB1_98

Не буду тут показывать, но, если провести перфоманс тесты, мы тоже увидим, что тут все тормозит.
И если детально разобраться: так и есть - это конструктор копирования.

Проблема вот в этой функции:

void f(pair<string, Vec>&& arg) 

Если поменять объявление этой функции на

void f(pair<const string, Vec>&& arg) {

то этот блок строк на 70 машинного кода уйдет, а перфоманс выровняется.

Почему так? Если посмотреть на cpp reference, то мы увидим, что

key_type Key
mapped_type T
value_type std::pair<const Key, T>

значение в мапе содержит константный ключ. А конвертировать из структуры с константным ключем в структуру с неконстантным ключом.... Это копирование!...


И ни одного ворнинга! Мой же ты любимый С++.

Внимание, шутка!!

Умножение в С++ некоммутативно.

Вот пример:

#include <iostream>
 
int main() {
    std::cout << (2,0 * 2,5) << std::endl; // 5
    std::cout << (2,5 * 2,0) << std::endl; // ???
    return 0;
}

Выведет 5 только на первую строчку. А на вторую нет.
Живите с этим.


Разумеется, тут проблема в том, что в С++ числа с плавающей запятой пишутся с точкой. Запятая - это отдельный оператор С++, который выводит второе значение.

Молодцы, что разгадали этот простенький паззл 🎁

К слову, clang выводит ворнинг на это. А gcc только при включенном Wall.

Немного про новые стандарты: когда я показываю какую-то упячку, часто мне говорят "просто не пользуйся вот этим...".
Например, "не пользуйся new/delete, пользуйся умными указателями".

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


Увы, новые конструкции просто создают другое подмножество проблем.

Вот к примеру, что выведет вот такой код?

#include <iostream>

int main() {
    auto a = std::string{48};
 
    std::cout << a << std::endl;
}

Правильно, он выведет 0. Потому что идет неявное преобразование инта к чару. И chr(48) == '0'.

Что характерно, вот такая строчка

auto b = std::string(48); // error: no matching function for call to

Не скомпилируется. Потому что у строки нет конструктора от char. Точнее есть, но там надо развлекаться веселее.

#include <iostream>

int main() {
    auto b = std::string(48, 48.0); 
    std::cout << b << std::endl;
}

Это будет

000000000000000000000000000000000000000000000000

Так или иначе, но у нас новые конструкции просто создают новые проблемы.


Ну и самая большая проблема, когда эти вещи вызываются неявно.

Человек, который прислал мне похожий пример, утверждает, что он пришел из продакшн кода.

#include <iostream>
#include <unordered_map>

int main() {
    std::unordered_map<std::string, std::string> m;
    double i = 65.5;
    m["hello"] = i;

    std::cout << m.at("hello");
    return 0;
}

Что тут происходит? double кастится к int, int кастится к char, char кастится к string, в мапу записывается буква A. Прекрасно!

implicit конструирование типов вообще сплошная головная боль.

Но мой любимый лефтикус в одном из своих докладов (чет не помню, в каком, но в последние пару лет) поделился синтаксическим трюком, как их запретить.

Вот у нас есть пример.

struct Path {
    Path(const std::string& p) : path(p) {}
    Path(const char* p) : path(p) {}
    std::string path;
};

void f(const Path& path, const std::string& mode) {
    std::cout << "Path: " << path.path << std::endl;
    std::cout << "Mode: " << mode << std::endl;
}

Мы хотим как-то запускать функцию f.

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

f(Path("/etc/tmp"), std::string{"rw"});

// f(std::string{"rw"}, Path("/etc/tmp"));
// error: no matching function for call to 'f'

Но есть проблема. Оба типа могут неявно конструироваться от строки. Вот эти обе строчки сработают:

f("/etc/tmp", "rw");
f("rw", "/etc/tmp");

Есть решение! Нам поможет вот такая конструкция:

```cpp
void f(const auto&, const auto&) = delete;
void f(const Path& path, const std::string& mode) {
std::cout << "Path: " << path.path << std::endl;
std::cout << "Mode: " << mode << std::endl;
}
```

Что мы теперь получим при вызове функций от голых строк?

```
<source>:18:5: error: call to deleted function 'f'
18 | f("/etc/tmp", "rw");
```

Прекрасный трюк, очень мне нравится.

Валидная программа на lisp C++.

int main(){(([](){})());}

😣

Ну а как еще можно было назвать канал, как не "Дурка"?

Ну сам факт, что вот такой код компилируется, запускается, а еще и не падает, и выводит 0!!!

#include <iostream>
 
class Test {
public:
 void test() {
  std::cout << this << std::endl;
 }
};
 
Test & create()
{
 return *((Test*)NULL);
}
 
int main()
{
 Test &t = create();
 t.test();
}

Нет, конечно, понятно даже почему, если разобрать поднаготную устройства функций-членов класса. Но блииииин........

Неожиданный пример гонки в С++.

Возьмем такой код.

struct Task {
    virtual ~Task() = default;
    virtual void run() = 0;
};

class AutorunTask : public Task {
public:
    AutorunTask() : t_([this]() {
        this->run();
    }) {}
    ~AutorunTask() { t_.join(); }
private:
    std::thread t_;
};

struct Impl : public AutorunTask {
    void run() override {
        puts("The string");
    }
};

int main(){
    Impl impl;
    std::this_thread::sleep_for(1ms);
}

Что мы тут видим?

Класс Task с чисто виртуальной функцией. Интерфейс, типичный интерфейс.

Промежуточный класс AutorunTask, который в конструкторе запускает в конструкторе виртуальный метод, и в деструкторе дожидается его окончания.

И в конце концов реализация виртуальной функции, которая и вызывается.
И в таком виде код работает, и выводит

Program returned: 0
The string

Но зачем мы поставили sleep в конце? Дело в том, что если его закомментировать, то код упадет с ошибкой.

Program returned: 139
pure virtual method called
terminate called without an active exception
Program terminated with signal: SIGSEGV

Итак. Давайте разбираться.

Можно ли вообще в конструкторе/деструкторе использовать виртуальные функции?

Смотрим
paragraph 4 [ISO/IEC 14882-2014]

Member functions, including virtual functions, can be called during construction or destruction. When a virtual function is called directly or indirectly from a constructor or from a destructor, including during the construction or destruction of the class’s non-static data members, and the object to which the call applies is the object (call it x) under construction or destruction, the function called is the final overrider in the constructor’s or destructor’s class and not one overriding it in a more-derived class. If the virtual function call uses an explicit class member access and the object expression refers to the complete object of x or one of that object’s base class subobjects but not x or one of its base class subobjects, the behavior is undefined.

Тоесть, можно.

Что же они запускают? Ведь функция в классе-наследнике может обращаться к несконструированному классу?

На самом деле, в конструкторе и деструкторе вызывается реализация "текущего" класса. Смотрим пример.

struct A {
    virtual void f() {
        puts("A");
    }

    A() { f(); }
};

struct B : public A {
public:
    void f() override {
        puts("B");
    }
    B() { f(); }
};

int main(){
    B b;
}

Это код выводит

Program returned: 0
A
B

конструктор первого класса выведет A. Второго B.


А как это достигается? На самом деле, в программе переписывается указатель в таблице виртуальных вызовов.
Ооооо, вот тут и возникает гонка.

AutorunTask::~AutorunTask() [base object destructor]:
        push    rbx
        mov     rbx, rdi
        lea     rax, [rip + vtable for AutorunTask+16]
        mov     qword ptr [rdi], rax
        add     rbx, 8
        mov     rdi, rbx
        call    std::thread::join()@PLT

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

vtable for AutorunTask:
        .quad   0
        .quad   typeinfo for AutorunTask
        .quad   AutorunTask::~AutorunTask() [base object destructor]
        .quad   AutorunTask::~AutorunTask() [deleting destructor]
        .quad   __cxa_pure_virtual

А вызов внутри лямбды происходит не конкретной функции, а по указателю из таблицы виртуальных вызовов.

std::thread::_State_impl<std::thread::_Invoker<std::tuple<AutorunTask::AutorunTask()::'lambda'()>>>::_M_run() [complete object constructor]:
        mov     rdi, qword ptr [rdi + 8]
        mov     rax, qword ptr [rdi]
        jmp     qword ptr [rax + 16]

И дальше происходит гонка. Если деструктор вызовется раньше, чем запустится поток (версия без `sleep`), то вызовется чистовиртуальный метод, что приведет к ошибке.

А если деструктор вызывается позже (версия со `sleep`), то все отработает штатно.

Добро пожаловать в красивые примеры нашей любимой дурки. 🤡

Иногда нам приходится использовать самое страшное и отвратительное что досталось С++ по наследству: препроцессор.

По разным причинам - или средствами языка нельзя что-то емко выразить (как в либах Unreal Engine), или для производительности (иногда голый код лучше оптимизируется чем функции, и макросы пишутся вместо функций под комментарием "счастливого дебага, тварь"), иногда просто по дурости (как в QT).

И там можно выстрелить себе в ногу самым неожиданным образом.

Вот простой макрос:

#define INCREMENT_BOTH(x, y) x++; y++ 

Что тут не так?
Да много чего.

Вот такой пример:

    int a = 0; int b = 0;
    INCREMENT_BOTH(a+b, b);

Вообще это преобразуется в

a+b++; b++;

И это явно не то, что мы хотели. Мы хотели тут ошибку компиляции на том, что "пытаемся инкрементить lvalue", а вместо этого простой ворнинг про "неиспользуемый результат".

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

Какой-нибудь вот такой пример:

int main() {
    int a = 0; int b = 0;

    for (const auto f: {true, false}) {
        if (f)
            INCREMENT_BOTH(a, b);
    }

    std::cout << "a: " << a << "\n"
              << "b: " << b << "\n"
              << std::endl;

    return 0;
}

Разумно выведет

Program returned: 0
a: 1
b: 2

а clang даже со включенным Wall не выдаст ни одного ворнинга.

И это далеко не все проблемы. Когда-то давно, когда мне надо было писать макросы, мне к задачам выдали 18-страничный гайд "как правильно писать макросы", согласно которому единственно верным способом написать такой макрос будет

#define INCREMENT_BOTH(x, y) \
    do {                     \
        (x)++;               \
        (y)++;               \
    } while (0)

Не используйте макросы без крайней необходимости. А если используете - найдите тот гайд, и пришлите его мне (я его потерял и очень об этом жалею 🙁 )

Еще одна абсолютно бесполезная, но унаследнованная штука в С++. Заголовок может заинклюдить сам себя.


Например вот такой заголовок:

// megaheader.hpp
#ifndef MEGAHEADER_HPP
int foo() {
    return 1;
}
#define MEGAHEADER_HPP
#include "megaheader.hpp"

#else 
int bar() {
    return 2;
}

#endif

Сработает совершенно нормально.

#include <iostream>

#include "megaheader.hpp"

int main() {
    std::cout << "foo: " << foo() << std::endl;
    std::cout << "bar: " << bar() << std::endl;
    return 0;
}

foo: 1
bar: 2

Ни ворнингов, ничего. А самое главное - как бы так передефайнить разные куски, чтобы на этом механизме устроить перебор? Ну, перебрать все комбинации из 5 дефайнов, и для каждого определить функцию? Было бы... Забавно?...

(незапланированный пост)

А есть инфа, я что-то найти не могу.

Вот это в язык вводят?

template <class P, class Q>
auto dot_product(P p, Q q) {
    // no indirection!
    auto&& [...p_elems] = p;
    auto&& [...q_elems] = q;
    return (... + (p_elems * q_elems));
}

Причины, по которым этот канал называется "дурка".

Вот такой вот метод:

    void Suicide() {
        delete this;
    }

Компиляторы сожрут. И не выведут ни одного ворнинга при Wall.

Вот полный пример.

#include <iostream>
#include <vector>

struct S {
    int a = 13;
    std::vector<int> v{};
    void Suicide() {
        delete this;
    }

};

int main(){
    auto* s = new S();
    s->Suicide();
    return 0;
}

У меня все, увидимся в дурдоме

Разберем вот такой вот пример. Что в нем не так?

template<typename U>
struct Scheduler {

  // ...

  void Add(U&& callback) {
    callback_ = std::move(callback);
  }

  // ...
  U callback_;
};

И это какая-то иллюстрация Эффекта Манделлы, потому что часто на вопрос "что не так?" слышу простое, легкое для понимания, неправильное решение в духе

forwarding reference passed to std::move(), which may unexpectedly cause lvalues to be moved; use std::forward() instead

На самом деле, использование std::forward тут нежелательно.

Давайте разберем сразу 4 примера:

// 1
template<typename U>
struct Scheduler {
  // ...

  void Add(U&& callback) {
    callback_ = std::move(callback);
  }

  // ...
  U callback_;
};


// 2
template<typename U>
struct Scheduler {
  // ...

  void Add(U&& callback) {
    callback_ = std::forward<U>(callback);
  }

  // ...
  U callback_;
};


// 3
struct AnotherScheduler {
  // ...

  template<typename U>
  void Add(U&& callback) {
    callback_ = std::move(callback);
  }

  // ...
  std::function<void()> callback_;
};


// 4
struct AnotherScheduler {
  // ...

  template<typename U>
  void Add(U&& callback) {
    callback_ = std::forward<U>(callback);
  }

  // ...
  std::function<void()> callback_;
};

В первом примере все хорошо: тип зафиксирован в момент объявления инстанса класса

    Scheduler<std::function<void()>> sh;

поэтому в объявлении функции U&& -> это rvalue reference. И поскольку rvalue reference is lvalue, мы должны его мувать. Если использовать std::forward (Как в примере номер 2), то ничего страшного не случиться, но будет выглядеть странно, и заставит ругаться clang-tidy. Возможно, будут какие-то гадости, которые я не смог воспроизвести.


В примерах 3-4 все наоборот. Тип U определяется на этапе вызова функции, и его мувать опасно: у нас аргумент функции - forwarding reference, а значит там может быть как rvalue, так и просто ссылка. Если вы муваете ссылку внутри функции, тот, кто ее вызывает, может внезапно обнаружить, что переданный объект, который он не мувал, изчез:

    AnotherScheduler ash;
    auto af = []() -> void {};
    ash.Add(std::ref(af)); // moved here inside function
    af(); // UB

А потому пример 3 - неверный и потенциальный источник багов. А пример 4 - норм.

Итого, "корректные" решения - 1 и 4. И, как и положено в С++, примеры 2 и 3 нормально скомпилируются... И даже будут как-то работать, наверное, в большинстве случаев, но делать так не надо.


И вообще, читаем cpp core guidelines.