Здравствуйте, alpha21264, Вы писали:
A>Ну... вот так одним лёгким движением Вы обеспечиваете себя работой до пенсии.
всё уже украдено написано до нас: Boost.Units. На других языках (особенно модных молодёжных) это работает почти из коробки.
Хотя идея обеспечить себя работой до пенсии конечно заманчива. Недавно вот прочитал, что люди переписали код сервиса на Rust и их уволили. А чё держать? Багов нет, ничего поддерживать не надо.
A>Но я это делаю не чаще раза в год, и за пять минут найду такую ошибку.
у меня на практике был случай что для Id какого-то объекта я стал использовать enum class. В итоге нашёл несколько довольно неприятных багов (когда условно id сессии сравнивался с id объекта). Такой баг можно и не обнаружить "за 5 минут". Ну записался другой id, нет проблемы, скорее всего в обоих таблицах такое значение есть. Это даже не UB, который скорее всего как-то себя проявит в рантайме. Такой баг будет сидеть тихо и ждать.
Здравствуйте, alpha21264, Вы писали:
A>Ну в общем да. Один раз в жизни это предупредит меня об ошибке, а всё остальное время это будет засирать код. A>Слова "один раз в жизни" достаточно ярко выделены?
Выделены-то они достаточно ярко, но не соответствуют рельности.
В реальности же [[nodiscard]] "засирает" только объявление функции — в одном месте.
А предупреждать будет каждый раз, когда важный возврат функции будет проигнорирован.
Здравствуйте, Pzz, Вы писали:
Pzz>Я в те времена писал под MS-DOS. Unsigned int для меня был 16-битным, а указатель, в large модели — 32-битным.
Я сам прошел от 16-бит MS-DOS к 32-битовым OS/2, Windows NT и Linux, а потом и к 64-битовым. В том числе и через 16-битовый Windows.
void* привел в пример потому, что даже в современном C++ это актуально когда приходится иметь дело с чисто-Си-шными либами или старыми C++ными библиотеками, использующими механизм callback-ов.
При этом в современном C++ актуальность проблем с union-ом заметно синизилась за счет std::variant.
А std::variant вряд ли бы появился, если бы C++ не усложняли вещами, против которых протестует ТС.
Здравствуйте, sergii.p, Вы писали:
SP>у меня на практике был случай что для Id какого-то объекта я стал использовать enum class. В итоге нашёл несколько довольно неприятных багов (когда условно id сессии сравнивался с id объекта). Такой баг можно и не обнаружить "за 5 минут". Ну записался другой id, нет проблемы, скорее всего в обоих таблицах такое значение есть. Это даже не UB, который скорее всего как-то себя проявит в рантайме. Такой баг будет сидеть тихо и ждать.
Таких историй, думаю, просто вагон и маленькая тележка.
Например, некоторые люди очень любят подряд идущие аргументы типа bool:
void do_something(const data & d, mode m,
bool use_hard_checks,
bool use_strict_format,
bool verbose)
{
...
}
Стоит ввести enum class-ы и поменять типы булевых аргументов на них, так сразу выясняется, что часть флагов во вложенных вызовах тупо меняются местами.
_>Возможности:
_>1. Независимые типы данных, такие как mass и length. Присвоить один другому нельзя — будет ошибка компиляции.
_>2. Автоматическое конвертирование величин одной и той же размерности из одной системы единиц в другую. К примеру, присвоив килограммам один грамм, в результирующей переменной (si::mass) обнаружим 0.001. Вычисление коэффициентов преобразования производится в compile time.
_>3. Контроль за корректностью формул со стороны компилятора. Так, если ускорению попытаться присвоить результат деления длины на время, возникнет ошибка компиляции. С моей точки зрения, это наиболее важное свойство моего кода. Особенно это заметно на трехэтажных формулах, где очень легко потерять из виду, какая же в результате получается размерность. В случае использования моего кода подобного рода ошибки полностью исключаются.
Ну, честь и хвала этому достойному человеку.
Жаль только, что для использования этих возможностей нужно переходить на другой (не С++) язык.
Так же хотелось бы иметь возможность создавать свои типы (или даже систему типов).
По идее это должно быть не так сложно, нужно лишь задать матрицу "при перемножении таких-то типов получается такой-то тип".
Можно оформить как предложение в следующий стандарт С++.
Здравствуйте, alpha21264, Вы писали:
A>Так же хотелось бы иметь возможность создавать свои типы (или даже систему типов). A>По идее это должно быть не так сложно, нужно лишь задать матрицу "при перемножении таких-то типов получается такой-то тип".
A>Можно оформить как предложение в следующий стандарт С++.
Как вы там любите...? Свобода — это осознанная необходимость?
Так вот, использование const в С++ — это осознанная необходимость. Без const проконтролировать работу 10 программистов за день не успеете. Просто не успеете прочитать код.
И — да, складывать яблоки с апельсинами можно, если нужен компот. Вот у вас компот опять и получился, вы смешали вместе const и контроль типов.
Теперь о цене. Вас останавливает жалкие 100*100=10'000 однострочных функций ?!
Впрочем..., понятно — большие проекты без константности и контроля типов работать не будут, поэтому вы с такими, видимо, и не сталкиваетесь.
Но главный пункт не в этом, а в том, что в подавляющем большинстве прикладных программ никакого взаимодействия между разными типами вообще не происходит, кроме как их складывание в одну структуру. Если у вас есть ID пользователя, то его не надо складывать ни с ID продукта, ни с фамилией продавца, ни делить на время оформления. Это всё бессмысленные действия. А вот не перепутать ID посетителя, скажем, с ID билета может быть важно.
Впрочем, я давно пессимист в том, что смогу убедить таких как вы в правильности строго подхода. Вы же не отличаете набора констант, от перечисления, перечисление от битовых флагов, битовые флаги от множества, множество от набора констант.
Здравствуйте, Marty, Вы писали: M>В этом ничего смешного. Опенсорсный считается протестированным сообществом, и потому достаточно качественным, а также — это чисто внешняя зависимость, и никто её развивать не будет. А свой код таки предполагается, что будет развиваться. Так что подход вполне логичный.
Считается
Я видел его использование — зависимость часто не на конкретную версию, а как-то так:
go get porno.git.hub.com/gorillaz/ClintEastwood
Т.е. сегодня это вполне годная библиотечка, которая по роковому стечению обстоятельств делает то, что надо и не больше, через пару месяцев она же вдруг становится проблемой. Т.е. даже не она становится проблемой, а вдруг вылезает какая-то непонятная фигня, в результате которой ты осознаёшь: у нас проблема. Очень любопытная ситуёвина получается, когда поды валятся только на проде в моменты пиковой нагрузки.
Ы!
Всё сказанное выше — личное мнение, если не указано обратное.
Здравствуйте, Философ, Вы писали:
M>>В этом ничего смешного. Опенсорсный считается протестированным сообществом, и потому достаточно качественным, а также — это чисто внешняя зависимость, и никто её развивать не будет. А свой код таки предполагается, что будет развиваться. Так что подход вполне логичный.
Ф>Считается Ф>Я видел его использование — зависимость часто не на конкретную версию, а как-то так: Ф>
Ф>go get porno.git.hub.com/gorillaz/ClintEastwood
Ф>
Ф>Т.е. сегодня это вполне годная библиотечка, которая по роковому стечению обстоятельств делает то, что надо и не больше, через пару месяцев она же вдруг становится проблемой. Т.е. даже не она становится проблемой, а вдруг вылезает какая-то непонятная фигня, в результате которой ты осознаёшь: у нас проблема. Очень любопытная ситуёвина получается, когда поды валятся только на проде в моменты пиковой нагрузки.
И что? Это повод все процессы/стили приводить используемому в библиотеке? Кстати, какой, если в проекте сторонних либ больше одной?
Pzz>Есть класс задач, в которых именно прикладной уровень обладает высокой степенью сложности. Например, из-за сложной физики-математики, как в вашем примере. Или из-за алгоритмической сложности. Например, задача написания оптимизирующего компилятора. Заметим, в ней именно "математика" сложна.
Pzz>В таких задачах люди типа даже не Альфы (про него, живого, мы мало чего знаем), а описанной вами чуть выше модели альфы вполне могут работать.
Clang, кстати, хотя в целом стиль мне не нравится, написан вполне неплохо, и наоборот, использует все фичи плюсов.
Pzz>gcc внутри, кстати, примерно так и написан. Но назвать его говнокодом у меня как-то язык не поворачивается. Все-таки, большая часть мировой кодовой базы вполне успешно через него проходит и выдаёт на выходе вполне работоспособный машинный код.
Да, я слышал, что GCC внутри — это кусок говна (по крайней мере, был). Но, говорят, его чуть ли не на плюсах уже давно переписали.
И, кстати, в давние времена (2.95, например), когда он точно был на сишечке, он мог и упасть, и сгенерить хрень. Имхо, MSVC, Borland, Watcom — были покачественнее (но об их внутреннем устройстве ничего не знаю)
Здравствуйте, alpha21264, Вы писали:
A>Сейчас современный С++ намного превосходит тот самый монстрообразный PL/1. A>Это неправильно. Язык должен быть простым, чтобы программист думал не над языком, а над задачей.
C++ вполне прост, и на нём можно писать просто.
S>>А вот каково ваше отношение к [[nodiscard]]?
S>>Можно предположить, что "нормальные программисты" (tm) никогда не игнорируют возвращаемые функциями/методами значения. И посему [[nodiscard]] -- всего лишь бесполезный "синтаксический оверхэд" (c)
A>Ну в общем да. Один раз в жизни это предупредит меня об ошибке, а всё остальное время это будет засирать код. A>Слова "один раз в жизни" достаточно ярко выделены?
Значит, ты просто неправильно употребил этот атрибут
A>И что мне делать, если мне действительно не нужно возвращаемое значение? Заводить неиспользуемую переменную? A>Или есть какое-то специальное слово "мне действительно не нужно возвращаемое значение"? A>Писать вот так?
A>
A> (void)ваша_дурацкая_функция();
A>
Этот атрибут обычно ставят там, где возвращаемое значение достаточно важно. Например:
Возвращаемое значение никогда нельзя игнорировать, это приведёт к утечке памяти.
Плохо, что ты не понимаешь таких простых вещей.
В принципе, его могут ставить и в случаях, когда редко-редко, но возвращаемое значение можно проигнорировать. Не вижу проблем на сотни вызовов такой функции один раз явно указать, что возвращаемое значение игнорируется.
A>А кроме того, это просто уродливо. Скажите, ну вот зачем тут [[nodiscard]] сразу двое квадратных скобок?!
Предложи более изящный синтаксис для атрибутов, который бы не конфликтовал ни с чем.
Здравствуйте, Marty, Вы писали:
Pzz>>gcc внутри, кстати, примерно так и написан. Но назвать его говнокодом у меня как-то язык не поворачивается. Все-таки, большая часть мировой кодовой базы вполне успешно через него проходит и выдаёт на выходе вполне работоспособный машинный код.
M>Да, я слышал, что GCC внутри — это кусок говна (по крайней мере, был). Но, говорят, его чуть ли не на плюсах уже давно переписали.
Я заглянул из любопытства. Да, лежат какие-то .cc файлы. Внутри — процедуры и функции, как на Си. Но местами используются классы. Но подробно не смотрел, впечатление очень поверхностное.
M>И, кстати, в давние времена (2.95, например), когда он точно был на сишечке, он мог и упасть, и сгенерить хрень. Имхо, MSVC, Borland, Watcom — были покачественнее (но об их внутреннем устройстве ничего не знаю)
Все они могли и упасть и сгенерить хрень. В целом, gcc был довольно надёжный. Он был в состоянии собрать делый дистр линуха, это дохрена разнообразного кода.
Я когда-то очень любил TurboC 2.0. Он был быстрый, как пулемет, ошибок в нём было штуки три, и все, кому надо, про них знали. Конечно, оптимизирующим компилятором его было трудно назвать. У меня с него осталась привычка не звать memcpy от 0 байт, потому что евонная библиотека в таком случае глючила, и хрен его знает, какие еще стандартные библиотеки от каких платформ в таком случае сглючат.
У ваткома, кстати, была забавная особенность. Под досом, если памяти не хватало, он мог снизить уровень оптимизации, чтобы хоть как-то, да скомпилировать.
ИМХО, это скорее недостаток, когда результат кодогенерации зависит от того, на какой машине идёт сборка.
Здравствуйте, Философ, Вы писали:
Ф>Считается Ф>Я видел его использование — зависимость часто не на конкретную версию, а как-то так: Ф>
Ф>go get porno.git.hub.com/gorillaz/ClintEastwood
Ф>
Чивой-то я не понял. При стандартном использовании go, внешний импорт привязан к конкретной версии библиотеки, и никакие изменения на стороне еёйной репы сами себе, автоматически, без ручной команды в сборку не попадут.
Здравствуйте, Pzz, Вы писали:
Pzz>>>gcc внутри, кстати, примерно так и написан. Но назвать его говнокодом у меня как-то язык не поворачивается. Все-таки, большая часть мировой кодовой базы вполне успешно через него проходит и выдаёт на выходе вполне работоспособный машинный код.
M>>Да, я слышал, что GCC внутри — это кусок говна (по крайней мере, был). Но, говорят, его чуть ли не на плюсах уже давно переписали.
Pzz>Я заглянул из любопытства. Да, лежат какие-то .cc файлы. Внутри — процедуры и функции, как на Си. Но местами используются классы. Но подробно не смотрел, впечатление очень поверхностное.
Скорее всего, они по минимуму переделывали, не трогая слишком архитектуру. Заюзали разные вкусняшки от плюсов, типа RAII, например, или интерфейсы с виртуальными функциями и реализации интерфейсов, возможно — исключения, вместо рукопашного сишного их аналога, и тд и тп, вместо сишечного говна
M>>И, кстати, в давние времена (2.95, например), когда он точно был на сишечке, он мог и упасть, и сгенерить хрень. Имхо, MSVC, Borland, Watcom — были покачественнее (но об их внутреннем устройстве ничего не знаю)
Pzz>Все они могли и упасть и сгенерить хрень. В целом, gcc был довольно надёжный. Он был в состоянии собрать делый дистр линуха, это дохрена разнообразного кода.
Уверен, там были воркэраунды вокруг косяков GCC
Pzz>Я когда-то очень любил TurboC 2.0. Он был быстрый, как пулемет, ошибок в нём было штуки три, и все, кому надо, про них знали. Конечно, оптимизирующим компилятором его было трудно назвать. У меня с него осталась привычка не звать memcpy от 0 байт, потому что евонная библиотека в таком случае глючила, и хрен его знает, какие еще стандартные библиотеки от каких платформ в таком случае сглючат.
Хз, не помню такого, на TurboC 2.0 я прогал только первый семестр, и никогда не было идеи выделять кусок памяти нулевого размера. А потом на BC++3.1 пересел.
Pzz>У ваткома, кстати, была забавная особенность. Под досом, если памяти не хватало, он мог снизить уровень оптимизации, чтобы хоть как-то, да скомпилировать.
Pzz>ИМХО, это скорее недостаток, когда результат кодогенерации зависит от того, на какой машине идёт сборка.
Хз, я на Watcom пересел, он уже вроде то ли 9ый, то ли вообще 10ый был, и он вроде уже использовал 32 бита в ДОСе, и вряд ли ему было мало даже 4х метров памяти, хотя у меня на первом компе было 16
Здравствуйте, so5team, Вы писали:
S>Более того, этот персонаж любить обрывать разговор на полуслове. Типа мне стало скучно, а вопросов ваших я в силу специфичности своего опыта не понимаю, поэтому "давай, до свиданья!"
S>Пытаешься выяснить у человека обстоятельства, а он тупо отморозился и все. Остаешься в недоумении: а тему-то зачем открывать, если затем сходу в кусты и не отсвечиваешь?
Есть некий предел бестолковости собеседника, после которого я совершенно теряю интерес к разговору.
Например если персонаж не умеет читать.
Вот как например в данном случае. Я в стартовом сообщении написал следующее:
Да, в своё время контроль типов произвёл революцию в программировании.
Вот и теперь некоторые несознательные граждане хотят быть святее папы римского,
Да, конечно, хорошо бы чтобы компилятор подсказывал, когда ты пытаешься метры с килограммами сложить.
Но у всего есть цена. Так давайте посмотрим на цену.
И вот как я должен с тобой разговаривать?
Что я должен тебе сказать? Я должен как в детском саду тебя спросить:
1) so5team! Ты прочитал фразу, что "контроль типов произвёл революцию в программировании"?
Это фраза обозначает, что Альфа в принципе за контроль типов и считает его полезным.
2) so5team! Ты прочитал фразу, что "несознательные граждане хотят быть святее папы римского"?
Это фраза обозначает, что Альфа считает, что иногда излишнее усердие является вредным.
Поскольку ты читать не умеешь, обращаю твоё внимание, что в этой фразе присутствует слово "иногда".
3) so5team! Ты прочитал фразу, что "хорошо бы чтобы компилятор подсказывал, когда ты пытаешься метры с килограммами сложить"?
Это фраза означает, что Альфа не против, чтобы компилятор подсказывал подсказки.
4) so5team! Ты прочитал фразу, что "у всего есть цена"?
Это фраза означает, что Альфа сейчас будет рассуждать о том, не является ли цена больше приносимой пользы.
И вообще бывают ситуации, когда цена больше пользы.
5) so5team! Ты прочитал фразу (в другом сообщении), что из-за бесполезных варнингов теряются полезные?
6) so5team! Ты прочитал фразу (в другом сообщении), что поскольку в реальных программах большинство параметров const,
то слово const лучше убрать, а использовать не-const. Тогда контроль за параметрами останется, а мусор исчезнет.
so5team!
Вот ты настолько читать не умеешь, что ты в моём достаточно коротком сообщении пропустил 75% его содержания.
И программу ты читаешь скорее всего точно так же. Тебе необходимы костыли и протезы, потому что сам ты не справляешься.
Мне не нужны модификаторы const, потому что я не делаю такого рода ошибок. Мне костыль не нужен.
А тебе нужен. Почему нужен? Потому что ты читать не умеешь.
Из-за того, что ты читать не умеешь, информация должна быть много раз дублирована, следовательно текст становится длиннее.
Это относится и к программному тексту и к обычному тексту, которым мы переписываемся в конфе.
Текст становится длиннее, ты его ещё менее внимательно читаешь — читаешь не каждое второе слово, а каждое десятое.
И так далее — возникает порочный круг, который всё раскручивается и раскручивается.
Программы начинают уже занимать гигабайты. При этом смысл у них даже на мегабайты не тянет.
И мне действительно лень повторять тебе по несколько раз то, что я уже написал в самом первом сообщении.
Ну так может быть ты научишься читать? Умение читать — это универсальный навык. Он нужен не только в программировании.
Я мог бы научить тебя читать, но я не собираюсь учить тебя бесплатно.
Час моей работы как психолога стоит пять тыщщ рублей.
Здравствуйте, alpha21264, Вы писали:
S>>Более того, этот персонаж любить обрывать разговор на полуслове. Типа мне стало скучно, а вопросов ваших я в силу специфичности своего опыта не понимаю, поэтому "давай, до свиданья!"
S>>Пытаешься выяснить у человека обстоятельства, а он тупо отморозился и все. Остаешься в недоумении: а тему-то зачем открывать, если затем сходу в кусты и не отсвечиваешь?
A>Есть некий предел бестолковости собеседника, после которого я совершенно теряю интерес к разговору.
A>Например если персонаж не умеет читать. A>Вот как например в данном случае. Я в стартовом сообщении написал следующее:
А теперь покажите мне, пожалуйста, где бы я разбирал или хотя бы как-то комментировал то, что вы написали в стартовом сообщении.
Да я даже никакой оценки вашему стартовому сообщению не поставил.
Единственный мой ответ на ваше стартовое сообщение был вот таким:
У вас есть плохая привычка сперва сказать "A", а потом молча слиться, когда вам задают вопросы (например).
И все.
Я вам всего лишь намекнул на то, что вести с вами конструктивную беседу тяжело, т.к. как только пытаешься что-то выяснить у вас, как вы исчезаете прикинувшись ветошью.
А теперь вы еще и накатали телегу в которой навесили на меня собак, к которым я не имею никакого отношения.
Фу таким быть.
Хотите нормальной конструктивной дискуссии? Пожалуйста, отвечайте на вопросы и не домысливайте за собеседника (как вы это только что сделали).
Здравствуйте, so5team, Вы писали:
S>А вот каково ваше отношение к [[nodiscard]]?
даже я [nodiscard]] считаю лишним, хотя к большинству новых фич отношусь положительно. Слишком много слов. Если вам нужно отлавливать такие вещи, натравите санитайзер какой-нибудь. А так реально захламление кода. Примерно такое же отношение к noexcept — компилятор должен это делать. Хотя у последнего хотя бы есть какой-то полезный эффект.
[[nodiscard]] bool isActive() const noexcept;
Не кажется ли это перебором, для такой простой функции писать столько обвязки?
Здравствуйте, sergii.p, Вы писали:
SP>Не кажется ли это перебором, для такой простой функции писать столько обвязки?
Я не вел подсчета, но с тех пор как стал пользоваться [[nodiscard]] счет выловленных компилятором косяков уже измеряется десятками.
Да, с точки зрения эргономики оказывается перегруженным. Удобнее было бы, напротив, иметь nodiscard по умолчанию. А те результаты, которые можно игнорировать, чтобы явно помечались как [[maybe_unused]]. Но из-за соображений совместимости это, увы, невозможно.
Вокруг есть множество проектов, в которых никакие санитайзеры и анализаторы не используются. И вряд ли будут.
А вот [[nodiscard]] работает даже в них. Проверено
Здравствуйте, alpha21264, Вы писали:
A>Мне не нужны модификаторы const, потому что я не делаю такого рода ошибок. Мне костыль не нужен.
Видимо, у тебя такая кодовая база, что ты всю держишь её в голове. И работаешь один. Это достаточно редкое явление.
const в прототипе функции/метода говорит, что ссылочный/указательный параметр не меняется внутри функции, метода он говорит, что метод не меняет состояние объекта.
Это экономит массу времени, даже когда ты работаешь со своим старым кодом, и не помнишь всех деталей. И уж тем более это экономит время при командной работе.
A>А тебе нужен. Почему нужен? Потому что ты читать не умеешь.
A>По идее это должно быть не так сложно, нужно лишь задать матрицу "при перемножении таких-то типов получается такой-то тип".
Эээ, зачем матрицу? Вот допустим проскочило у нас некое m*a. Если в заголовках языка объявлено что кг*м/(с*с) — это сила и она имеет собственную букву, ну окей, компилятор узнаёт и 'алиас' и что под ним. Но если нет обозначения — пусть так и таскает из формулы в формулу циферку и её размерности. Авось где что посокращается. Техническая реализация таких алиасов так-то не проблема, проблема то, что создатели языков и думать не хотят про какие-то типы, кроме тех что нужны для создания компилятора
Тут главное чтобы язык не дай бог не получил "стандартную библиотеку физических типов", а позволял гибко объявлять это всё внутри проекта. Потому что в разных областях физики или химии одинаковые буквы могут значить ну очень разное.
