Пример честно украденный отсюда.

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

Пример выглядит следующим образом:

struct A {
    using T = T1;
    using U = U1;
    operator U1 T1::*();
    operator U1 T2::*();
    operator U2 T1::*();
    operator U2 T2::*();
};

inline auto which(U1 T1::*) { return "gcc"; }
inline auto which(U1 T2::*) { return "icc"; }
inline auto which(U2 T1::*) { return "msvc"; }
inline auto which(U2 T2::*) { return "clang"; }

int main() {
    A a;
    using T = T2;
    using U = U2;
    puts(which(a.operator U T::*()));
}

В этом примере мы дважны создаем алиасы с помощью using на четыре типа. Типы` U1` и U2, и типы их членов T1 и T2.
А дальше проверяем подстановку типов: какой из using-ов будет подставлен.


И подсказка есть в самом коде: четыре разных компилятора дадут четыре разных ответа.
Вот тут версия с запуском программ. И до сих пор дают разные варианты ответа....

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

Я ему верю, но код на всякий перекрещу, и святой водой ноутбук побрызгаю...

Небольшой опрос про мою любимую тему - сраный move....

Есть у нас вот такой код:

template<class T>
inline constexpr T id(T x) { return x; }


int main() {
   S y = id(id(S(42)));
}

У структуры S есть явно определенный noexcept move-конструктор.

Вопрос: сколько раз вызовется move-конструктор?

(ответ завтра)

Уточню флаги компиляции:

-O2 -std=c++20

Ответ: два раза.

А все почему? А вот почему:

У нас есть конкретные правила, когда copy-ellision разрешен, и когда явно запрещен. И там один абзац, и в абзаце этом черт ногу сломит. Нас интересует вот это

with automatic storage duration (other than a function parameter or a variable introduced by the exception-declaration of a handler)

Нам явно запрещено оптимизировать параметры функции. А вот return мы оптимизировать можем (RVO).

Вот такая вот интересная загогулина...

Из интересного, немного по-разному выглядит порядок деструкторов в MSVC и gcc/clang:

MSVC:
int-ctor
move-ctor
dtor
move-ctor
dtor
dtor

gcc:
int-ctor
move-ctor
move-ctor
dtor
dtor
dtor

clang:
int-ctor
move-ctor
move-ctor
dtor
dtor
dtor

Но ситуация еще забавнее. В предыдущий пост в комменты прилетело объявление move-конструктора с ключевым словом explicit.

Обычно я так не объявляю, но давайте поиграемся с этим.
explicit простыми словами запрещает использовать конструктор без явного его вызова.

struct S {
    int value_;
    explicit S(int i) : value_(i) { puts("int-ctor"); }
    explicit S(S&&) noexcept { puts("move-ctor"); }
    explicit S(S const &) noexcept { puts("cpy-ctor"); }
    ~S() { puts("dtor"); };
};


S id(S x) { return x; }
S id_cpy(const S& x) { return x; }

Вот так делать при этом нельзя:

 error: class "S" has no suitable copy constructor

Что происходит. Это очень старая штука - компилятор сначала подставляет конструктор копирования, а уже потом применяет оптимизации (RVO, copy-ellision и т.п.), и тогда копирование уходит.

Мы можем в этом случае объявить функцию немного иначе:

S id(S x) { return S(x); }
S idm(S x) { return S(std::move(x)); }

В первом случае вызывается явно конструктор копирования, во втором - move конструктор.
При этом MSVC такие штуки в страшных муках вообще перестает компилировать.

gcc и clang компилируют, но не могут оптимизировать конструкторы по тем же самым причинам.

int-ctor
move-ctor
move-ctor
dtor
dtor
dtor

Но в таком примере, по любимой традиции, выпендрился icc. У него конструкторов 3, а деструкторов - 8.

int-ctor
move-ctor
dtor
move-ctor
dtor
dtor
dtor
dtor
dtor
dtor
dtor

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

Я знаю много разных веселых реализаций TypeId - когда тебе надо по типу получить уникальный числовой идентефикатор.

Да что там, сам выступал с докладом, как такое сделать, и как мы это применили.

Но тут я нашел на еще одну реализацию, очень даже изящную (да, ты должен написать в комментарии, что Abseil это вообще-то классика жанра, а идея так вообще общеизвестна, и стыдно мне такое не знать)

Центральная идея проста. Пусть у нас есть вот такой класс:

namespace base_internal {
template <typename Type>
struct FastTypeTag {
  static constexpr char kDummyVar = 0;
};
} 

У нас есть шаблонный класс, в нем есть шаблонная константа. Для каждого типа Т, он объявит свою константу. Да, все константы будут равны нулю, но у каждой из них будет свой уникальный адрес (!)

А дальше дело техники - мы просто используем адрес в качестве идентефикатора.

template <typename Type>
constexpr FastTypeIdType FastTypeId() {
  return FastTypeIdType(&base_internal::FastTypeTag<Type>::kDummyVar);
}

Это очень просто и изящно!

Ну и как многие другие способы получения Id типа - этот ломается в случае динамических библиотек. В каждой dll будет свой адрес константы и Id между разными dll будут расходиться.

Но идею я записал.

А вот в C23 можно тип объявлять прямо в return типе.

#include <stdio.h>

struct{int a; float b;} test()
{
  return (typeof(test())){1337, 666.666};
}

int main()
{
  auto a = test();
  printf("%d %f\n", a.a, a.b);
  return 0;
}

А вот в С++ такого нельзя:

error: new types may not be defined in a return type

Товарищи из комитета, отстаете. Где эти безусловно нужные всем языковые фичи?

Товарищи, а вы откуда в таком количестве подписываетесь сегодня? Кого благодарить за ссылку?

Сегодня у нас поиски глубинного смысла в С++ на основе примеров, которые подсказывают подписчики.

В чем цимес. Лично мне в С++ не всегда понятно, что должно быть "нормальным поведением по-умолчанию", а что "нужно прописать явно".

Давайте посмотрим вот сюда:

#include <iostream>

struct Good {
  int i;
  bool operator==(const Good&) const = default; 
};

int main() {

  Good good1{1}, good2{2};
  std::cout << (good1 == good2) << std::endl;

  return 0;
}

Мы создали структуру, прописали, что ее можно сравнивать (по дефолту), и сравнили.

А теперь давайте унаследуем такую же структуру от пустой структуры

#include <iostream>

struct Empty {
  // bool operator==(const Empty&) const = default; 
};
struct Bad : Empty {
  int i;
  bool operator==(const Bad&) const = default;
  /* error:
  constexpr bool Bad::operator==(const Bad&) const' 
    is implicitly deleted because the default 
    definition would be ill-formed
  */
};

static_assert(sizeof(Good) == sizeof(Bad));

int main() {

  Bad bad1{{}, 1}, bad2{{}, 2};
  std::cout << (bad1 == bad2) << std::endl;

  return 0;
}

Мы не можем скомпилировать этот код, потому что оператор сравнения "по-умолчанию" не создается, пока мы не объявим явным образом оператор сравнения для пустой структуры.

Другими словами, нам надо явно писать что-то такое:

struct Empty {
  bool operator==(const Empty&) const {
    return true;
  }
};

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

И снова спасибо подписчикам за отборный контент.

Оказывается, в С++ можно объявить оператор каста к... void.

struct X {
  // warning: Conversion function converting 'X' to 'void' will never be used
  operator void() { std::cerr << "void\n"; }
};

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

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

#include <iostream>

struct X {
  // warning: Conversion function converting 'X' to 'void' will never be used
  operator void() { std::cerr << "void\n"; }
};

int main(int argc, char *argv[]) {
  X x;

  (void)x;              // no
  static_cast<void>(x); // no
  x.operator void();    // YES!!!

  return 0;
}

И вот это уже вообще взрыв мозга! 🤯

Этот пост был в очереди где-то уже на май, но чет у меня настроение лирическое, публикую сейчас.

Мне тут мой дорогой друг присоветовал (подписывайтесь на его boosty !)
подрезать из одного доклада примерчики для этого канала. И был абсолютно прав!

Я еще не досмотрел доклад, но в нем даже классические и всем известные примеры можно показать каким-то новым способом, который выглядит нелепо и комично:

int main() {
    static_assert((double)(0.3) == 0.29999999999999998);
    static_assert((double)(0.3) != ((double)(0.1) + (double)(0.2)));
}

Думаю, что на тот момент, когда вы это читаете, я уже доклад досмотрел, и поставил в отложку еще некоторое количество примеров. Поэтому если вам не терпится, и хочется спойлеров - смотрите доклад из сообщения.

Сегодня разбираем вот такой рабочий пример. (Рабочий в том смысле, что найден на работе).

Берем вот такой код:

// hpp

#include <unordered_map>

struct Foo {
    int x;
    int y;
};

struct Bar{
    std::unordered_map<std::string, Foo> xx;

    Foo& ForY(const std::string& v);
};

// cpp

#include <string>

Foo& Bar::ForY(const std::string& v) {
    return xx[v];
}

int main() {}

Внимательно на него смотрим. Потом смотрим еще внимательнее.
Не видим проблемы.

Смотрим еще раз, и опять не видим проблемы.

А потом отправляем его на компиляцию, и получаем ошибку:

/cefs/aa/aad5f6fdba80b622f643f9a5_clang-trunk-20260313/bin/../include/c++/v1/unordered_map:657:74: error: type 'const std::hash<std::string>' does not provide a call operator
  657 |   _LIBCPP_HIDE_FROM_ABI size_t operator()(const _Cp& __x) const { return __hash_(__x.first); }

У нас нет инстанса хеша для строки.

😣😣😣😣😣😣


Как это исправляется? Правильно, заголовок строки надо обязательно ставить выше заголовка мапы:

// hpp

#include <string>
#include <unordered_map>

struct Foo {
    int x;
    int y;
};

struct Bar{
    std::unordered_map<std::string, Foo> xx;

    Foo& ForY(const std::string& v);
};

// cpp


Foo& Bar::ForY(const std::string& v) {
    return xx[v];
}

int main() {}

Точнее на самом деле, разумеется, важен не порядок заголовков (хотя там отдельный геморой. И в большинстве codestyle-ах порядок заголовков указывается, хотя на моей памяти "правильный" порядок поменялся ровно на противоположный).

Нужно чтобы string была указана до объявления мапы.

Скомпилируется:

#include <string>
struct Bar{
    std::unordered_map<std::string, Foo> xx;

    Foo& ForY(const std::string& v);
};

Не скомпилируется:

struct Bar{
    std::unordered_map<std::string, Foo> xx;

    Foo& ForY(const std::string& v);
};
#include <string>

Скомпилируется:

struct Bar{
    std::unordered_map<std::string, Foo> xx;

    Foo& ForY(const std::string& v);
};
#include <string>

// Foo& Bar::ForY(const std::string& v) {
//     return xx[v];
// }

Скомпилируется:

struct Bar{
    std::unordered_map<std::string, Foo> xx;

    Foo& ForY(const std::string& v);
};

#include <string>

Foo& Bar::ForY(const std::string& ) {
    return xx.begin()->second;
}

И это какая-то лютая хрень, которую не найти не исправить.

Как вообще оно так вышло?

Некоторые вещи о С++ я знаю натурально против своей воли.

Давайте возьмем вот такие флаги компиляции

--std=c++2c -O2 -pedantic -Wall -Wextra -fsanitize=address -fsanitize=undefined

Для icc сделаем -std=c++20, потому что 2c он не знает.

Стартовый пример, который хотел показать.

Ни одного ворнинга на компиляторах не выдает.

Что в этом примере:

void foo() {            // never called
  if constexpr(false) { // never true
    if (false) {        // never true
        constexpr auto call = [](auto arg) {
            std::printf("called %d", arg);
        };
        void(B<A<tag>, decltype(call)>{});
    }
  }
}

Самая обычная функция, которая нигде в коде не вызывается. Внутри функции if constexpr (false) который какбы тоже не должен никогда вызваться. Я бы вообще ожидал что блок внутри выкенется из компиляции. Внутри этого блока if (false). Внутри котого лямбда (причем с аргументом и локальной переменной).

Внимание, вопрос! А можно ли как-то вызвать эту лямбду?

Оказывается да, и нам в этом помогает вот такая строчка:

        void(B<A<tag>, decltype(call)>{});

Что за классы такие А и В? А вот как они объявляются:

class tag;

template<class>
struct A { 
    template<class>
    friend constexpr auto get(A); 
};

template<class K, class V>
struct B { 
    template<class>
    friend constexpr auto get(K) { return V{}; } 
};

И вуаля, теперь мы можем вызвать эту функцию вот таким кодом:

int main() {
    get<tag>(A<tag>{})(42);
}

Много раз повторив добьемся того же эффекта. И ни одного ворнинга.


Да, объявив лямбду вот так:

        constexpr auto call = [&](auto arg) {
            std::printf("called %d", arg);
        };

Получим веселую ошибку компиляции:

note: a lambda closure type has a deleted default constructor

(Да, я просто добавил `[&]`).


И я изначально, встретив нечно похожее, шел по пути усложнения кода. Потому что хотел избавиться от всех ворнингов, а, например, закомментрируем template в объявлении функции get, и хотябы gcc начнет сыпать хоть какими-то ворнингами:

template<class>
struct A { 
    // template<class>
    friend constexpr auto get(A); 
};

template<class K, class V>
struct B { 
    // template<class>
    friend constexpr auto get(K) { return V{}; } 
};

warning: friend declaration 'constexpr auto get(A< <template-parameter-1-1> >)' declares a non-template function

А icc так вообще перестанет собирать код:

internal error: assertion failed at: "func_def.c", line 1915 in scan_function_body

      get(A<tag>{})(42);

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

#include <cstdio>

struct A { 
    friend auto get(A); 
};

template<class V>
struct B { 
    friend auto get(A) { return V{}; } 
};

void foo() {            // never called
  if constexpr(false) { // never true
    if (false) {        // never true
        constexpr auto call = [](auto arg) {
            std::printf("called %d", arg);
        };
        void(B<decltype(call)>{});
    }
  }
}

int main() {
    get(A{})(42);
}

тоже прекрасно работает.

Вот ей богу, я эту грязь знать не хотел. 🤢

Итак, у нас, согласно cppreference, c 11-ого стандарта есть набор целочисленных типов типа:

int8_t
int16_t
int32_t
int64_t
   
signed integer type with width of exactly 8, 16, 32 and 64 bits respectively
with no padding bits and using 2's complement for negative values
(provided if and only if the implementation directly supports the type)

Ну давайте поиграемся.

Что будет выведено вот на это:

    std::cout << "int16_t: \n" 
              << static_cast<int16_t>(00) << '\n'
              << static_cast<int16_t>(48) << '\n'
              << static_cast<int16_t>(65) << '\n'
              << std::endl;

Правильный ответ:

```
int16_t:
0
48
65
```

А вот на это?

    std::cout << "int64_t: \n" 
              << static_cast<int64_t>(00) << '\n'
              << static_cast<int64_t>(48) << '\n'
              << static_cast<int64_t>(65) << '\n'
              << std::endl;

Правильный ответ:

```
int64_t:
0
48
65
```

А вот на это?

    std::cout << "int8_t: \n" 
              << static_cast<int8_t>(00) << '\n'
              << static_cast<int8_t>(48) << '\n'
              << static_cast<int8_t>(65) << '\n'
              << std::endl;

Правильный ответ:

```
int8_t:
0
A
```

А все почему?

Потому что идите все нахер, int8_t - это char.


Особенно это приятно, когда у вас из логов пропадает что-то такое:

enum class Direction : int8_t {
    LEFT, RIGHT, UP, DOWN
};

// ... 



    std::cout << static_cast<int8_t>(Direction::LEFT) 
              << std::endl;
    
    using Int = std::underlying_type_t<Direction>;
    std::cout << static_cast<Int>(Direction::LEFT) 
              << std::endl;

Ну вот и нахрен так жить?

Прекрасный и интуитивный auto.


Давайте возьмем вот такой код для старта.

int main() {
    const int x = 42;
    auto a = x;
    auto& b = x;
}

Давайте попробуем угадать, какого типа будут переменные a и b?

decltype(a)
decltype(b)

Это прекрасное:

    static_assert(std::is_same_v<decltype(a), int>);
    static_assert(std::is_same_v<decltype(b), const int&>);

Тоесть при копии у нас теряется константность. А при получении ссылки не теряется.

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

А что делать, если мы хотим что-то менее логичное, но более интуитивное?

А что-то такое:

#include <iostream>
#include <type_traits>

int main() {
    const int x = 42;
    decltype(auto) a = x;
    auto& b = x;
    // ...
}

Маленька классика на этой неделе.

Что выведет вот этот код?

#include <iostream>

int main() {
    int x = 42;
    std::cout << sizeof(++x) << '\n';
    std::cout << x << '\n';
}

Да, все верно:

```
4
42
```

Тут все просто: sizeof не вычисляет выражение. Вообще никак.

То есть ++x написан,
вы его видите,
компилятор его видит,
Бог его видит,
но реально инкремента не происходит.

Только clang немного поплюется warning-ами

Ну чтож... всего лишь еще один повод угодить в дурку.

Пример из того самого доклада.


Это просто прекрасное. Я где-то слышал утверждение, что лямбы имеют zero cost, что должны соптимизироваться во что-то такое же, как и исхордный код.

Ну так вот для такого кода:

int main() {
    auto div = [](double a, double b) { return a / b; };
    double a = 0.5;
    double b = 0.01;

    std::cout << (int)(a / b) << std::endl;
    std::cout << (int)div(a, b) << std::endl;
}

У меня сработало в трех случаях из четырех. В четвертом вышло

49
50

Счастливого дебага с*****.

Есть вот такая шляпа:

struct Buffer {
    std::vector<int> data{1, 2, 3};

    const std::vector<int>& Items() const {
        return data;
    }
};

Buffer MakeBuffer() {
    return {};
}

int main() {
    for (int x : MakeBuffer().Items()) {
        std::cout << x << ' ';
    }
    std::cout << '\n';
}

Что будет выведено?

Если запускать gcc/clang с

 -fsanitize=address -fsanitize=undefined

То они взворвуться всякими ошибками на доступ к памяти.

==1==ERROR: AddressSanitizer: stack-use-after-scope on address 0x6cc5bdef0060 at pc 0x5806274e084a bp 0x7ffc913eefb0 sp 0x7ffc913eefa8
READ of size 8 at 0x6cc5bdef0060 thread T0
    #0 0x5806274e0849 in __gnu_cxx::__normal_iterator<int const*, std::vector<int, std::allocator<int>>>::__normal_iterator(int const* const&) /opt/compiler-explorer/gcc-snapshot/lib/gcc/x86_64-linux-gnu/16.0.1/../../../../include/c++/16.0.1/bits/stl_iterator.h:1059:20

Без них

clang выводит:

692359176 -2055096448 -2055096448

icc выводит:

163141 0 -143200117

gcc и msvc не выводит ничего....


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

А под капотом - так называемый "13-летний баг", историю которого можно отследить вот по этим ссылкам:
https://cplusplus.github.io/CWG/issues/900.html
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2021/p2012r2.pdf
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p2644r1.pdf
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p2718r0.html

Какие выводы мы можем сделать по итогу этих ссылок? Что в С++23 починили таки эту проблему.

Содержательно fix такой: в [class.temporary] добавили четвёртый специальный контекст, в котором временный объект живёт дольше обычного — если он создан в for-range-initializer range-based for, то его lifetime продлевается на жизнь скрытой ссылки, то есть фактически на весь цикл.

The fourth context is when a temporary object other than a function parameter object is created in the for-range-initializer of a range-based for statement. If such a temporary object would otherwise be destroyed at the end of the for-range-initializer full-expression, the object persists for the lifetime of the reference initialized by the for-range-initializer.

И оно поддержано уже в gcc/clang (но не других компиляторах).

Пример с теми же санитайзерами выводит:

1 2 3 

Приятно, что всего через 13 лет один из самых болезненных багов из С++ ушел...

Посмеемся?

#include <iostream>
#include <string_view>

struct Base {
    void Set(std::string_view) { std::cout << "string\n"; }
    void Set(int)              { std::cout << "int\n"; }
};

struct Derived : Base {
    void Set(bool)             { std::cout << "bool\n"; }
};

int main() {
    Derived d;
    d.Set("hello");
}

Что выведет?

Ответ конечно `bool`:


Почему так?

Потому что перегрузки из Base в Derived скрываются целиком, если в наследнике появился метод с тем же именем.

И дальше d.Set("hello") уже ищет только среди перегрузок Derived.
А const char* в bool конвертируется просто замечательно.

И по нашей любимой традиции - ни одного ворнинга ни в одном из компиляторов.