Здравствуйте, sergey2b, Вы писали:
S>Коллега китаец проработавший в Амазоне несколько лет
Китаец из Китая, китаец из Гонконга, или же китаец выросший уже здесь?
Это три большие разницы
Здравствуйте, sergey2b, Вы писали:
S>Дополню твой список S>Китаец и Тайваня, китаец из Сингапура и китаец из Малайзии
Это уже тайванец, сингапурец и малайзиец
Слишком давно разделение произошло, культуры уже сильно разные.
Если правда не использовать "китаец" в смысле "азиат, но откуда именно — сходу не понятно"
Здравствуйте, Doom100500, Вы писали:
Аё>>Наверное это недокументированная фича
D>В моём детстве в школе училки говорили в подобных случаях "Услышал звон, да не знаю где он".
А ты шо, знаток OpenCV? Я то с ним имел секас работать.
Аё>>PS перекличка сипипи фаперов произведена .
D>А не это: "смотрю в книгу — вижу фигу".
Здравствуйте, CreatorCray, Вы писали:
S>>Я, я, я... В жопу себе свое самомнение засуньте CC>Порвался таки, а как дышал...
Как дышал, так и дышу: я вам говорю объективные вещи о том, что у макросов в качестве констант есть врожденные недостатки, которых нет у нормальных C++ных констант. Вы же в своем духе упоротого самодура вещаете "А у меня все работает! Да у меня такие проекты за плечами!"
S>>Кроме этого есть и случаи, когда код пишут вчерашние студенты, да еще и под руководством 20-летних сеньоров CC>И? Как это влияет на людей с опытом, которые знают как оно устроено, как оно работает, и которым не надо ритуальные подгузники чтобы писать нормальный код.
На упорышей, вроде вас, полагаю, никак. Остальные могли бы подумать о том, что защита от элементарных опечаток и для них тоже будет работать.
CC>В серьёзных проектах никто в здравом уме не станет подпускать маппетов к коду
Кроме "серьёзных" проектов есть куча и всяких других. А CreatorCray такой один единственный и всю работу не сделает. Поэтому можно, мягко говоря, забить на то, что о себе думает CreatorCray и поизучать безопасные практики, которые в C++ уже не одно десятилетие рекомендуют "лучшие собаководы".
S>>И если вы не видите в своих проектах чего-то вроде: S>>
?
CC>А я говорил про строковые константы, инициализация которых даже через constexpr не выразима.
Ну так разбейте инициализацию и представление. Пока в C++ в compile-time генерация строк делается через Ж, эту самую генерацию приходится делать через макросы, но хранить результат уже давно можно и не в виде макро-подстановки.
S>>Пример того, как это используется. CC>#define FOO_FILEPATH "/blah/bar/foo" CC>#define FOO_FILEPATH_W L"" FOO_FILEPATH CC>
Тю, а разговоров-то было.
Если бы мне пришлось иметь что-то такое, то в современном C++ сделал бы что-то вроде:
CC>Если уровень пониже на порядок — таких просто не берём, ибо вреда от них больше чем пользы. CC>Если просто слегка пониже то это либо достаточно быстро дотягивается до достаточного, либо досвидульки.
О том и речь. Но как быть всем остальным, кто не так крут, как CreatorCray? Послать рекомендации Страуструпа, Мейерса, Саттера и прочих в сад и набивать шишики самостоятельно?
Вопрос риторический.
S>>Хотя бы затем, чтобы было меньше неявных преобразований типов и неявного смешения разных типов в одном выражении. CC>Эк ты заморачиваешься на ровном месте.
Когда твой код люди компилируют с -Wall -Wextra -Werror (и даже -Weverything), то приходится.
S>>У вас будет такой же литерал типа int. И, повторюсь, для многих это будет неожиданно. CC>Ты хочешь сказать что если тебе надо в коде что то перемножить на 3 то ты вместо foo *= 3; будешь заводить отдельную константу с явно прописанным типом и потом умножать на неё?
Нет, только если 3 повторяется более одного раза. И, скорее всего, придется думать о суффиксе.
S>> Как, например, для многих неожиданно, что "abc" -- это const char[4]. CC>А также const char*, и чо?
Таки не const char*.
Как и 0.1 -- это double, а не float, как иногда думают.
S>>Я лично немного видел define-ов, которые бы выглядели вот так: S>>
S>>#define SIZE 100u
S>>
S>>или так: S>>
S>>#define LONG_SIZE 100ull
S>>
CC>Потому что в подавляющем колве случаев такие заморочки нафиг не нужны.
Это до тех пор, пока ошибка компиляции не возникнет. Как, например, здесь:
#include <vector>
#define msize 1000
//constexpr std::size_t msize{ 1000 };template<typename T>
T selector(T a, T b) { return a < b ? a : b; }
bool get_result(const std::vector<int> & a) {
const auto limit = selector(a.size() / 2, msize);
return a.size() < limit;
}
int main()
{
std::vector<int> arr{1, 2, 3, 4, 5};
return get_result(arr);
}
S>>И если уж заставлять людей выписывать тип, то зачем зазубривать особенности define-ов, если можно сделать: S>>
S>>constexpr unsigned size{ 100 };
S>>constexpr unsigned long long long_size{ 100 };
S>>
CC>Не надо замусоривать код. Тип для константы выписывается там, где он реально нужен.
Так он и указывается там, где он нужен. Причем всего один раз.
S>>И лучше их заставлять находиться в жестких рамках, чем позволять пользоваться небезопасными возможностями. CC>Студней — да, пока не осознают.
Ага, человек учится на constexpr, затем обретает дзен и начинает херачить константы в виде define. Самому не смешно?
CC>Спецы знают как оно работает, сам себя ограничивают где это приносит максимальную пользу, но детские памперсы им только мешают.
Магические спецы уровня CreatorCray, ага, ага. Тормоза, технику безопасности и изоляцию на проводах придумали трусы, настоящие спецы в этом всем не нуждаются.
Здравствуйте, sergey2b, Вы писали:
S>да заставляют
В каждой команде должна быть веточная стратегия, она должна быть известна всем, кто коммитит, и если ты её не нарушаешь, всем должно быть пофиг, какой инструмент ты используешь (если он не нарушает некие корпоративные ИТ стандарты). Раз используются инструменты ревью кода, скорее всего, наиболее опасные операции (прямой пуш в "основную" ветку) запрещены технически. Но особенность git в том, что принципиально он проще иных проприетарных систем, т.к. меньше сущностей (файл, индекс), и потому он ближе к unix-way, и работа из командной строки обычное дело.
Здравствуйте, so5team, Вы писали:
S>я вам говорю объективные вещи о том, что у макросов в качестве констант есть врожденные недостатки, которых нет у нормальных C++ных констант.
Ты пока не показал ничего что можно было бы считать недостатком.
S> Вы же в своем духе упоротого самодура S> На упорышей, вроде вас S> Пилять, lavrov.jpg
Юг вооон там, горячий вьюноша.
CC>>В серьёзных проектах никто в здравом уме не станет подпускать маппетов к коду S>Кроме "серьёзных" проектов есть куча и всяких других.
Ты сам то понял что сказал?
S>Ага. А есть ли он здесь:
Тут ты скобки поставил
S>Тю, а разговоров-то было.
Ну наконец то до тебя этот элементарнейший пример дошёл.
S>Если бы мне пришлось иметь что-то такое, то в современном C++ сделал бы что-то вроде: S>#define
А как же твои крики про недопустимость #define?
S>Но как быть всем остальным
Учиться!
S>Когда твой код люди компилируют с -Wall -Wextra -Werror (и даже -Weverything), то приходится.
-Werror я лично считаю обязательным, весь мой код пишется именно с ним.
S>если 3 повторяется более одного раза. И, скорее всего, придется думать о суффиксе.
S>Как и 0.1 -- это double
А вода — мокрая!
CC>>Потому что в подавляющем колве случаев такие заморочки нафиг не нужны. S>Это до тех пор, пока ошибка компиляции не возникнет.
Она там возникает исключительно из-за за уши притянутого template.
И это как раз редкий случай в котором просто дописывается ull
Всяко короче чем твой вариант.
S>Так он и указывается там, где он нужен. Причем всего один раз.
Суффикс в #define 1000ull тоже указывается там, где он нужен, и тоже всего один раз.
S>Ага, человек учится на constexpr, затем обретает дзен и начинает херачить константы в виде define. Самому не смешно?
Поживёт в реальном мире — станет.
S>Тормоза, технику безопасности и изоляцию на проводах придумали трусы, настоящие спецы в этом всем не нуждаются.
Ох дитятко...
Хм... а в каком месте оно деалоцируется? Меня в первую очередь этот вопрос будет волновать, хоть я и не знаю Куду.
C++ник должен иметь навык писать нормально сразу. Даже с таким навыком со временем код превращается в говно, а без оного он таким оказывается сразу. Безопасные языки наплевательское отношение к качеству исходников до какой-то степени прощают, а вот C++ -- нет.
Код, очевидно, не почищен, и выложен "как есть", но придирки в основном "к шашечкам". C++ никогда не избавится от наследия C.
Это один из.
CC>>>В серьёзных проектах никто в здравом уме не станет подпускать маппетов к коду S>>Кроме "серьёзных" проектов есть куча и всяких других. CC>Ты сам то понял что сказал?
Я-то понял, мне не только в "серьезные" приходится заглядывать.
S>>Ага. А есть ли он здесь: CC>Тут ты скобки поставил
Во-первых, матчасть про фигурные скобки при инициализации подучите.
Во-вторых, перепишите без скобок и попробуйте найти там такой же недостаток, как и в макросах.
S>>Если бы мне пришлось иметь что-то такое, то в современном C++ сделал бы что-то вроде: S>>#define CC>А как же твои крики про недопустимость #define?
Вообще-то речь шла о недопустимости #define для обозначения констант. За нитью разговора следите, плз:
Начиная с C++98 оставалось не так много мест, для define были бы удобны для задания констант, а начиная с С++17 таких мест, вроде бы, вообще не осталось.
Если не писать заголовочные файлы, которые могут использоваться как в чистом Си, так и в C++ (т.е. если выйти за рамки Си-шного подмножества), то надобности в define для констант в C++ уже нет.
S>>Но как быть всем остальным CC>Учиться!
Ну вот пусть и учатся сразу хорошему, а #define пусть оставят для матерых профи, вроде CreatorCray.
CC>>>Потому что в подавляющем колве случаев такие заморочки нафиг не нужны. S>>Это до тех пор, пока ошибка компиляции не возникнет. CC>Она там возникает исключительно из-за за уши притянутого template.
Там вообще весь пример из пальца чтобы показать ветеранам ынтырпрайзного софтострителя как оно бывает в дикой природе.
CC>И это как раз редкий случай в котором просто дописывается ull
А если пользоваться C++ными константами, то и ull не придется дописывать. Кстати говоря, ull -- это не тот суффикс, который должен использоваться для значений std::size_t. А корректный суффикс появится только в C++23, который не всем доступен, а кому-то может быть недоступен еще долго.
S>>Так он и указывается там, где он нужен. Причем всего один раз. CC>Суффикс в #define 1000ull тоже указывается там, где он нужен, и тоже всего один раз.
Только вот ull (даже не смотря на то, что он не для std::size_t) опционален и его легко забыть. Как и скобки вокруг значений в #define.
CC>Ох дитятко...
Адрес куда вам следует засунуть свое самомнение уже был указан.
__>Хм... а в каком месте оно деалоцируется? Меня в первую очередь этот вопрос будет волновать, хоть я и не знаю Куду.
В таких примерах "на выброс" не заморачиваются ни проверкой на ошибки, ни деаллокациями. Так что и я не стал.
__>
__>C++ник должен иметь навык писать нормально сразу. Даже с таким навыком со временем код превращается в говно, а без оного он таким оказывается сразу. Безопасные языки наплевательское отношение к качеству исходников до какой-то степени прощают, а вот C++ -- нет.
__>Код, очевидно, не почищен, и выложен "как есть", но придирки в основном "к шашечкам".
Эти самые шашечки зачастую оказываются очень точными "лакмусовыми бумажками".
__>C++ никогда не избавится от наследия C.
Что не значит, что нужно это наследие эксплуатировать при наличии более безопасных альтернатив из C++.
А почему не constexpr???
Ну мимоходом к прошлогоднему срачу, где ты картинно закатывал глаза про префикс m_, тоже выяснилось что в твоём sobjectizer он повсеместно используется.
Прошёлся по моим ответам тебе — там такие же твои пуристические истерики.
Здравствуйте, so5team, Вы писали:
S>Это один из.
Тут скорее вопиющая неопытность аффтара. Классический пример "верхнее но без среднего".
Препроцессор работает по простым принципам, которые просто позорно не знать.
S>Я-то понял, мне не только в "серьезные" приходится заглядывать.
Не ты один, и?
S>Во-первых, матчасть про фигурные скобки при инициализации подучите. S>Во-вторых, перепишите без скобок и попробуйте найти там такой же недостаток, как и в макросах.
Отпусти сову.
S>Вообще-то речь шла о недопустимости #define для обозначения констант. Да что ты говоришь!
S>надобности в define для констант в C++ уже нет.
То, что появились дополнительные возможности со своими бонусами никак не мешает выбирать наиболее удобный для решения конкретной задачи инструмент.
S>Ну вот пусть и учатся сразу хорошему
Дык я и не против
S>А если пользоваться C++ными константами, то и ull не придется дописывать
Придётся дописывать аж полный тип
S>и его легко забыть
Дык он в подавляющем колве случаев нафиг не нужен.
S> Как и скобки вокруг значений в #define.
Это примерно как трусы забыть надеть при выходе из дома.
Называется профнепригодность
S>Адрес куда вам следует засунуть свое самомнение уже был указан.
Так уж и быть, раз так просишь, наклоняйся — засуну.
Здравствуйте, CreatorCray, Вы писали:
S>>Цитату можно? CC>Я в той теме тоже ответил, посмотри у себя в ответах тебе.
Доказывать что-либо должен тот, кто тезис выдвинул. Так что вперед, за цитатой. Мне даже интересно, что я про префикс m_ говорил, если я использую его чуть ли не с 2000-го года.
Здравствуйте, CreatorCray, Вы писали:
S>>Это один из. CC>Тут скорее вопиющая неопытность аффтара.
Повторяющаяся с завидным постоянством.
Итого: есть такой факт в макросах? Есть.
Есть такой факт в C++ных константах? Нет.
Вопрос закрыт.
По поводу того, что литерал в define может иметь неожиданный для пользователя тип уже говорилось выше. Такой же факт.
Но вы матерый ынтырпрайзный спец, я уверен, что вы способны с фактами успешно поспорить.
CC>То, что появились дополнительные возможности со своими бонусами никак не мешает выбирать наиболее удобный для решения конкретной задачи инструмент.
Вы видите удобство, но не желаете замечать рисков.
S>>А если пользоваться C++ными константами, то и ull не придется дописывать CC>Придётся дописывать аж полный тип
И это всяко лучше, чем полагаться на неявные правила вывода. В C++ и так слишком много неявных преобразований.
Здравствуйте, so5team, Вы писали:
S>Мне даже интересно, что я про префикс m_ говорил, если я использую его чуть ли не с 2000-го года.
CC>Я просто оставил имена как есть, поправив только совсем уж угробищное _ в конце имени.
S>Еще хуже объяснять умудренному опытом (но не гибкостью мышления и способностью смирится с тем, что его мнение нифига не единственно правильное) ветерану с 25-летним опытом, что префикс m_ многими воспринимается как такое же говно, как и суффикс _.
CC>Префикс лучше чем суффикс банально потому, что он стоит В НАЧАЛЕ и сразу бросается в глаза для любого, кто читает слева направо.
CC>Потому что это позволяет легко сузить scope для intellisense подсказок при наборе имени переменной, в саааамом начале набора её имени.