чтобы точно скастило

в google coding guidelines вроде написано, не используйте преобразования типов из C++, они все говно ) используйте сишные

если мне не изменяет память

правильно. и void * хорошо.

правильно. и void * хорошо.

смотря где и зачем

Use C++-style casts like static_cast<float>(double_value), or brace initialization for conversion of arithmetic types like int64 y = int64{1} << 42. Do not use cast formats like int y = (int)x or int y = int(x) (but the latter is okay when invoking a constructor of a class type).

https://google.github.io/styleguide/cppguide.html раздел Casting.

хехе ровно наоборот )

т.е. память таки подвела

либо это новая ревизия

т.к. уже всякая новая херня типа int64{x} есть

аргументы за просто убийственные =)

The problem with C casts is the ambiguity of the operation; sometimes you are doing a conversion (e.g., (int)3.5) and sometimes you are doing a cast (e.g., (int)"hello"). Brace initialization and C++ casts can often help avoid this ambiguity. Additionally, C++ casts are more visible when searching for them.

кстати у них там и cout << теперь рекомендуется вместо printf

засранцы )

The problem with C casts is the ambiguity of the operation; sometimes you are doing a conversion (e.g., (int)3.5) and sometimes you are doing a cast (e.g., (int)"hello"). Brace initialization and C++ casts can often help avoid this ambiguity. Additionally, C++ casts are more visible when searching for them.

ну сишные касты они же для всего например ты не всегда хочешь убирать const qualifier (иначе на кой хрен он вообще нужен), а сишный каст успешно это делает

ну сишные касты они же для всего например ты не всегда хочешь убирать const qualifier (иначе на кой хрен он вообще нужен), а сишный каст успешно это делает

а не очевидно когда тип был с const а стал без, что я убираю его?

Если более приземленно: (Type1)(obj) - работает по разному, в зависимости от Type1 и obj static_cast/reinterpret_cast/const_cast - явно определяют, что хочется

т.е static_cast<Type1>(obj1) вполне может тебя послать, если не имеет смысла

а не очевидно когда тип был с const а стал без, что я убираю его?

я гляжу и в правду очень много целых ног

:)

ну это всё какие-то мелочные костылики

и без того 1000 способов выстрелить в ногу есть, если не понимаешь, что делаешь

явное лучше неявного, мой пусть и небольшой опыт это подтверждает

как к этому относится auto?

например auto i = 5; :)

кстати у них там и cout << теперь рекомендуется вместо printf

fmt::print надо)

fmt::print надо)

это printf в C++22 завезли? ;)

это printf в C++22 завезли? ;)

fmtlib ещё не приняли в стандарт если правильно помню

например auto i = 5; :)

auto i = int{5};

гыгы

почему не int i = 5;?

не модно?

почему не int i = 5;?

потому что int i = 5.5; успешно скомпилируется

лол

а что в этом плохого?

можно ещё int i{5};

или какой-нибудь unsigned int i = -1; тоже скомпилируется

а unsigned int i{-1}; не скомпилируется?

а unsigned int i{-1}; не скомпилируется?

почему?

а unsigned int i{-1}; не скомпилируется?

нет

и правда

зато clang подсказывает как можно всё-таки убедить компилятор что тебе надо выстрелить себе в ногу

1.cc:3:17: error: constant expression evaluates to -1 which cannot be narrowed to type 'unsigned int' [-Wc++11-narrowing] unsigned int i{-1}; ^~ 1.cc:3:17: note: insert an explicit cast to silence this issue unsigned int i{-1}; ^~ static_cast<unsigned int>( )

:D

ой боги, кто придумал стандарт

т.е. сферический дурачок в вакууме напишет static_cast<unsigned int>(-1) и будет по-старому

можно ещё auto i = 5_int;

struct A { explicit A(int) {} }; void foo() { A x{1}; A y = 1; //строже }

только надо литерал написать

кароч всякая такая хуета только затрудняет чтение кода как по мне

а обойти это всё и сделать ошибку всё равно можно

как по мне, я нихуя не понял, почему unsigned int x{-1} строже, чем unsigned int x = -1

почему не наоборот?

потому что первый делает проверку

struct A { explicit A(int) {} }; void foo() { A x{1}; A y = 1; //строже }

второй вариант не будет работать же, т.к. в нём "неявное приведение"

дополнительную

потому что первый делает проверку

вопрос почему не второй делает проверку

struct A { explicit A(int) {} }; void foo() { A x{1}; A y = 1; //строже }

почему замена A на unsigned int вообще меняет проверки?

вопрос почему не второй делает проверку

так повелось

потому что раньше считалось что программист думает иногда головой

теперь неочень

так повелось

"так повелось" это эвфемизм для "неудачное техническое решение приняли"?

да не

это даже специально сделали

умные дядьки )

специально сделали парадоксальный синтаксис?

ну вот в инициализаторы вставили дополнительные проверки

потому что кто-то подумал, что так получше будет )

а компиляторы один хер советуют как эти проверки обойти )

ну вот в инициализаторы вставили дополнительные проверки

вопрос в другом

ну unsigned int = -1; используется на практике, самое большое число получить, хотя это непереносимый код

это не ответ

почему синтаксис {} не единообразен?

почему синтаксис {} не единообразен?

ещё раз сформулируй вопрос с примером кода, пожалуйста, я не очень понял тебя

всё норм, сделают static_initializer{} и cast_initializer{} в C++30 ;))

struct A { explicit A(int) {} }; //using Z = unsigned int; //#1 //using Z = A; //#2 void foo() { Z x{-1}; Z y = -1; }

в случае #1 первое ошибка, второе ОК

ну unsigned int = -1; используется на практике, самое большое число получить, хотя это непереносимый код

разве не переносимый?

в случае #2 второе ошибка, первое ОК

разве не переносимый?

надо смотреть, что там в стандарте

в случае #2 второе ошибка, первое ОК

в случае #2 второе ошибка, потому что там получается неявный каст, который explicit запрещает первое ОК, потому что как и ожидалось передаётся int, мб ты хотел написать там unsigned int?

в случае #2 второе ошибка, потому что там получается неявный каст, который explicit запрещает первое ОК, потому что как и ожидалось передаётся int, мб ты хотел написать там unsigned int?

в двух случаях поведение строго противоположно

чего вообще непонятного? почему это плохо?

в двух случаях поведение строго противоположно

если explicit A(unsigned int) {} тогда у и первого и второго будет ошибка

если explicit A(unsigned int) {} тогда у и первого и второго будет ошибка

если написать в начало "hello, world" тоже

надо смотреть, что там в стандарте

https://stackoverflow.com/questions/4975340/int-to-unsigned-int-conversion

почему-то поведение этих синтаксических конструкций инвертируется в зависимости от фазы луны^W^W вопроса, является ли Z user-defined типом или нет

я понимаю такие правила для драконьего покера)

почему-то поведение этих синтаксических конструкций инвертируется в зависимости от фазы луны^W^W вопроса, является ли Z user-defined типом или нет

там всё логично (во втором случае), но я так и не понял, почему у тебя в конструкторе аргумент с типом int, а не с типом unsigned int

там всё логично (во втором случае), но я так и не понял, почему у тебя в конструкторе аргумент с типом int, а не с типом unsigned int

логично что? синтаксис Z x{-1} соответствует implicit cast или explicit? синтаксис Z x = -1 соответствует implicit cast или explicit?

в первом грехи совместимости вполне себе проявляются

логично что? синтаксис Z x{-1} соответствует implicit cast или explicit? синтаксис Z x = -1 соответствует implicit cast или explicit?

Z x{-1} это explicit, Z x = -1 это implicit

Z x{-1} это explicit, Z x = -1 это implicit

тогда почему если Z это unsigned int то первое не компилируется, а второе компилируется?

тогда почему если Z это unsigned int то первое не компилируется, а второе компилируется?

Z это int же

тогда почему если Z это unsigned int то первое не компилируется, а второе компилируется?

первое: потому что -1 это int, а не unsigned int

преобразование -1 в unsigned int это explicit, не допускающее implicit?

https://stackoverflow.com/questions/4975340/int-to-unsigned-int-conversion

там стандарт даже цитируют "If the destination type is unsigned, the resulting value is the least unsigned integer congruent to the source integer (modulo 2^n where n is the number of bits used to represent the unsigned type)." congruent... что бля

))