现已上线！2025 年 Telegram 研究 — 年度关键洞察 
C++: Хроники Дурки🚑
前往频道在 Telegram
Очень люблю C++, но это скорее уже стокгольмский синдром. Постоянно нахожу способы стрельнуть себе в ногу.
显示更多839
订阅者
+624 小时
+697 天
+37330 天
帖子存档
Я знаю много разных веселых реализаций 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);
}
Ответ: два раза.
А все почему? А вот почему:
У нас есть конкретные правила, когда copy-ellision разрешен, и когда явно запрещен. И там один абзац, и в абзаце этом черт ногу сломит. Нас интересует вот это
в страшных муках вообще перестает компилировать.
gcc и clang компилируют, но не могут оптимизировать конструкторы по тем же самым причинам.
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)); }
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 - закрываю ноут и перестаю копать дальше....
Небольшой опрос про мою любимую тему - сраный move....
Есть у нас вот такой код:
template<class T>
inline constexpr T id(T x) { return x; }
int main() {
S y = id(id(S(42)));
}
Сегодня у нас поиски глубинного смысла в С++ на основе примеров, которые подсказывают подписчики.
В чем цимес. В С++ есть некоторые проблемы с тем, что должно быть "нормальным поведением по-умолчанию", а что "нужно прописать явно".
Давайте посмотрим вот сюда:
#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;
}
};
Пример честно украденный отсюда.
Но я периодически возвращаюсь к нему, чтобы вновь попытаться понять, почему я до сих пор не бросил эти несчастные кресты.
Пример выглядит следующим образом:
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, а остальные по-разному врут...
Я ему верю, но код на всякий перекрещу, и святой водой ноутбук побрызгаю...Если вы очень любите питон, у меня для вас выход:
#include <iostream>
#include <stdio.h>
#include <fcntl.h>
#include <string>
#define print(data) cout<<data<<endl;
#define ord(data) int(data[0])
#define str(data) char(data)
#define open fopen
#define write(f, data) fputc(data, f)
using namespace std;
string input()
{
string s;
cin>>s;
return s;
};
FILE* f;
int chr;
int main() {
print("Enter:");
f = open("code.txt", "w");
chr = ord(input());
print(chr);
write(f, str(chr));
return 0;
}Обычно когда спрашивают, что такое nullptr, получают в ответ, что это указатель равный нулю.
Более продвинутые говорят, что это зависит от имплементации, и приводят в пример какие-то embedded сценарии архитектур, до которых среднему программисту дела нет. Поэтому первая часть людей продолжает говорить, что в практическом поле nullptr - это ноль.
Но есть красивый пример, иллюстрирующий что это не так.
Природа заблуждения растет, как мне кажется, из проверки подстановкой указателя в if.
struct S {
char a;
char b;
int c;
int d;
};
int main()
{
auto s = S{'1', '2', 3, 4};
S* pS = nullptr;
if (!pS) {
std::cout << "pS" << std::endl;
std::cout << std::hex << "ptr: "<< *(int*)(&pS) << std::endl;
}
pS = &s;
if (pS) {
std::cout << "pS" << std::endl;
std::cout << std::hex << "ptr: "<< *(int*)(&pS) << std::endl;
}
}pS
ptr: 0
pS
ptr: 7ede1034if (var) - это проверка на ноль, как мы и привыкли.
Но помимо указателя на объект в С++ есть еще указатель на члены класса.
char S::* pSm = nullptr;
pSm = &S::a;
if (pSm) {
std::cout << "pS.a" << std::endl;
std::cout << std::dec << "value: " << s.*pSm << std::endl;
std::cout << std::hex << "ptr: "<< *(int*)(&pSm) << std::endl;
}
pSm = &S::b;
if (pSm) {
std::cout << "pS.b" << std::endl;
std::cout << std::dec << "value: " << s.*pSm << std::endl;
std::cout << std::hex << "ptr: "<< *(int*)(&pSm) << std::endl;
}pS.a
value: 1
ptr: 0
pS.b
value: 2
ptr: 1if (pSm) для нуля. Потому что это валидное и даже ожидаемое значение, а в бинарном коде эта проверка выглядит так:
cmp rax, -1 pSm = nullptr;
if (!pSm) {
std::cout << "pS.nullptr" << std::endl;
std::cout << std::dec << "value: " << s.*pSm << std::endl;
std::cout << std::hex << "ptr: "<< *(int*)(&pSm) << std::endl;
}
if (pSm) {
std::cout << "Unreacheable" << std::endl;
}
pS.nullptr
value:
ptr: ffffffff
значение nullptr - это минус один. И это без всяких эзотерических архитектур, в рамках одной и той же программы у нас есть два разных значения для nullptr.
Весело в С++ однако.....Тут в комментах к этом посту прислали восхитительный пример. Хорошо я сидел, когда это увидел.
Вот такое:
struct Empty {};
struct Good : Empty {
int i;
char c;
};
struct Bad {
int i;
char c;
};
template <typename T>
struct S : T {
char c;
};
static_assert(sizeof(S<Good>) < sizeof(S<Bad>));
int main() {
return 0;
}
Сегодняшнее интересное меганаблюдение посвящено выбору стандартной библиотеки.
К примеру, мы можем скомпилировать программу с помощью clang двумя командами:
clang++ -O2 -std=c++20 -stdlib=libstdc++
clang++ -O2 -std=c++20 -stdlib=libc++struct A {
int i;
bool operator<(const A& other) const {
return i < other.i;
}
};
struct B {
int i;
bool operator<(const B& other) const {
return i < other.i;
}
};
int main() {
const auto first = std::make_tuple(A{1}, B{4});
const auto second = std::make_tuple(A{2}, B{3});
std::cout << ((first < second) ? "less" : "more") << std::endl;
std::cout << ((std::get<0>(first) < std::get<0>(second)) ? "less" : "more") << std::endl;
less lessНо если мы попробуем забуриться во внутреннее устройство, например, глянуть в каком порядке хранятся структурки внутри тупла:
const int* const pf = reinterpret_cast<const int* const> (&first);
const int* const ps = reinterpret_cast<const int* const> (&second);
std::cout << pf[0] << ' ' << pf[1] << std::endl;
std::cout << ps[0] << ' ' << ps[1] << std::endl;
std::cout << (pf[0] < ps[0] ? "less" : "more") << std::endl; 4 1 3 2 moreНа libc++
1 4 2 3 lessТоесть libstdc++ хранит реальные значения в обратном порядке... Хотя get<0> вычисляет так, как мы того и ожидаем. И это может иметь всякие неожиданные последствия для, например, производительности. Однако, см предыдущий пост, это как минимум не должно сказаться на размере структур данных. Потому что разворотом порядка членов padding не меняется.
Есть задачка, абсолютно практическая на самом деле.
Все знают про padding:
#include <iostream>
struct Foo {
char a; // 1
int b; // 4
double c; // 8
};
struct Bar {
char a; // 1
double c; // 8
int b; // 4
};
int main() {
std::cout << sizeof(Foo) << '\n'; // 16
std::cout << sizeof(Bar) << '\n'; // 24
}Размер структуры невозможно поменять, переставив переменные в ней В ОБРАТНОМ ПОРЯДКЕЗадача - доказать что утверждение верно или привести контрпример. Как я сказал, задача на самом деле практическая, подробности в следующем посте.
Что бы вы сказали, найдя в коде вот такой кусок?
if(0){}else
if (0) {}
#if GCC
else if (gcc_comparison())
{
gcc_action();
}
#endif
#if CLANG
else if (clang_comparison())
{
claing_action();
}
#endif
Note: Since Qt 5.7, the use of this macro is discouraged. Use C++11 range-based for, possibly with std::as_const(), as needed.
#define Q_FOREACH(variable, container) \
if (0) else
for (const QForeachContainerBase &_container_ = qForeachContainerNew(container); \
qForeachContainer(&_container_, true ? 0 : qForeachPointer(container))->condition(); \
++qForeachContainer(&_container_, true ? 0 : qForeachPointer(container))->i) \
for (variable = *qForeachContainer(&_container_, true ? 0 : qForeachPointer(container))->i; \
qForeachContainer(&_container_, true ? 0 : qForeachPointer(container))->brk; \
--qForeachContainer(&_container_, true ? 0 : qForeachPointer(container))->brk)
int main() {
for (int i = 0; i < 3; ++i) {
std::cout << i << std::endl;
}
std::cout << i << std::endl;
return 0;
}
if(true) ? А потому что тогда бы сработало
Q_FOREACH(a, b)
else {
// ...
}
qForeachContainer(&_container_, true ? 0 : qForeachPointer(container))->condition();Ну, к разного рода наркомании, что
std::cout << a[42] << std::endl;
std::cout << 42[a] << std::endl;
static constexpr int a[] = { [0 ... 9] = 1, [10 ... 99] = 2, [100] = 3 };
int whitespace[256] =
{
[' '] = 1, ['\t'] = 1,
['\f'] = 1, ['\n'] = 1,
['\r'] = 1
};
#include <iostream>
int main() {
static constexpr int a[] = { [0 ... 9] = 1, [10 ... 99] = 2, [100] = 3 };
std::cout << a[42] << std::endl;
std::cout << 42[a] << std::endl;
int whitespace[256] =
{
[' '] = 1, ['\t'] = 1,
['\f'] = 1, ['\n'] = 1,
['\r'] = 1
};
return 0;
}
g++ --std=gnu++23 main.cppВот какие-то такие развлечения....
Разберем вот такой вот пример. Что в нем не так?
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// 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; AnotherScheduler ash;
auto af = []() -> void {};
ash.Add(std::ref(af)); // moved here inside function
af(); // UBПричины, по которым этот канал называется "дурка".
Вот такой вот метод:
void Suicide() {
delete this;
}
#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 <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));
}Еще одна абсолютно бесполезная, но унаследнованная штука в С++. Заголовок может заинклюдить сам себя.
Например вот такой заголовок:
// 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 дефайнов, и для каждого определить функцию? Было бы... Забавно?...
Иногда нам приходится использовать самое страшное и отвратительное что досталось С++ по наследству: препроцессор.
По разным причинам - или средствами языка нельзя что-то емко выразить (как в либах 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)
