Есть такая книжка из жанра альтернативной истории "Миссионеры" (авторы Евгений и Любовь Лукины).
Сюжет про то, как могли бы индейцы подготовиться к приходу европейцев.
Там вместо приветствия используется фраза "Когда будет произнесено имя истинного врага".
Так вот про миссионеров.
Миссионеры бывают не только религиозные, миссионеры бывают так же и компьютерные.
И чаще всего они пропагандируют какую-нибудь дурь. (Я имею в виду не только христиан).
Ну вот например, они пропагандируют... ну например контроль типов.
Да, в своё время контроль типов произвёл революцию в программировании.
Если Вы раньше писали на Фортране, а потом перешли на Си, то должны помнить,
что Си требует описания переменных, а Фортран пытается угадать тип переменных по её имени.
И если вы очепятались в имени переменной, то можете несколько суток искать ошибку.
Да, раньше программировали на перфокартах, и прогон мог занимать много времени.
Вот и теперь некоторые несознательные граждане хотят быть святее папы римского,
и предлагают везде писать модификатор const и даже... делать разные типы для разных int,
"чтобы яблоки с апельсинами не складывать".
Да, конечно, хорошо бы чтобы компилятор подсказывал, когда ты пытаешься метры с килограммами сложить.
Но у всего есть цена. Так давайте посмотрим на цену.
Допустим у нас есть несколько (ну допустим пять) величин: метры, килограммы, секунды, ньютоны и джоули.
Да, их нельзя складывать с друг с другом. Но их можно(нужно) умножать и делить.
Таким образом, чтобы написать формулу, которая содержит три величины, нам нужно иметь 3*(5+1)*(5+1) типов данных.
То есть 36 типов для результатов умножения (килограмм*метр),
И 2*36 типов для деления килограмм/метр и метр/килограмм.
То есть, что-то около сотни типов. (Точная цифра =108)
И чтобы над всем этим великолепием можно было выполнять действия, нужно 100*100 — десять тысяч функций.
Ну... вот так одним лёгким движением Вы обеспечиваете себя работой до пенсии.
Конечно, какие-то операции будут бессмысленными, и не должны быть реализованными,
но и тех, что должны быть реализованы, Вам хватит, чтобы работа встала навсегда.
Миссионеры конечно скажут, что для таких ситуаций у них есть шаблоны,
на что я скажу, что я хочу ЭТО видеть. Как вы будете трахаться с шаблонами.
В этом месте миссионер скажет, а зато Вам компилятор подскажет, когда Вы вставите в формулу не ту переменную.
На что я отвечу, что да, раз в год я могу вставить в формулу не ту переменную.
Но я это делаю не чаще раза в год, и за пять минут найду такую ошибку.
А весь остальной год мне придётся бороться против компилятора,
и на этом будет потеряно гораздо, гораздо, ГОРАЗДО больше времени.
А зачем же тогда они это пропагандируют? На этот вопрос ответа нет.
Поэтому, я говорю: не слушайте миссионеров. Миссионеры — это враги.
В данном случае я опять не христиан имею в виду.
Ну, у меня же и основная работа есть. Поэтому я могу забыть про дискуссию или потерять к ней интерес.
Пищу для размышлений я дал, а дальше сами. Спор ради спора я вести не буду. Так что терпите.
Вот в Вашем напримере какого рода ответ Вы ожидаете получить? Смысл Вашего вопроса какой?
Здравствуйте, alpha21264, Вы писали:
A>Поэтому, я говорю: не слушайте миссионеров. Миссионеры — это враги. A>В данном случае я опять не христиан имею в виду.
Знаешь, что ты сейчас сказал?
Ты сказал, что если к вам придёт человек и научит вас варить сахар, то надо сварить его самого заживо в котле для сахара, потому что сахар-то он научил готовить, а торты — нет.
A>Да, конечно, хорошо бы чтобы компилятор подсказывал, когда ты пытаешься метры с килограммами сложить. A>Но у всего есть цена. Так давайте посмотрим на цену.
Давай.
У европейцев спутник "Ариан-5" упал когда-то, с типом данных не угадали. Стоит ли работы программиста?
Или сбой навигации у самолётов над Мёртвым морем, когда высота была отрицательной.
Есть области, где стоит платить такую цену.
A>Есть такая книжка из жанра альтернативной истории "Миссионеры" (авторы Евгений и Любовь Лукины). A>Сюжет про то, как могли бы индейцы подготовиться к приходу европейцев. A>Там вместо приветствия используется фраза "Когда будет произнесено имя истинного врага".
A>Так вот про миссионеров. A>Миссионеры бывают не только религиозные, миссионеры бывают так же и компьютерные. A>И чаще всего они пропагандируют какую-нибудь дурь. (Я имею в виду не только христиан).
Да разрабатывали как люди в машинных кодах, а потом пришли эти жертвы егэ т.е. миссионеры и все испортили.
Здравствуйте, Pzz, Вы писали:
A>>Поэтому, я говорю: не слушайте миссионеров. Миссионеры — это враги. A>>В данном случае я опять не христиан имею в виду.
Pzz>Знаешь, что ты сейчас сказал?
Pzz>Ты сказал, что если к вам придёт человек и научит вас варить сахар, то надо сварить его самого заживо в котле для сахара, потому что сахар-то он научил готовить, а торты — нет.
В данном случае будет уместно сказать "учу читать".
Если пользоваться твоей аналогией про сахар, то это будет звучать так:
сахара получается мало, а затрат на него много, в результате начинает не хватать на хлеб.
Здравствуйте, Nuzhny, Вы писали:
A>>Да, конечно, хорошо бы чтобы компилятор подсказывал, когда ты пытаешься метры с килограммами сложить. A>>Но у всего есть цена. Так давайте посмотрим на цену.
N>Давай. N>У европейцев спутник "Ариан-5" упал когда-то, с типом данных не угадали. Стоит ли работы программиста?
Ариан-5 упал не из-за этого.
Он упал как раз из-за избыточного контроля.
Ракета летела совершенно нормально.
Но кому-то почудилось, что величина вышла из диапазона.
Вот так из-за чьей-то паранойи ракета и грохнулась.
Здравствуйте, Qulac, Вы писали:
A>>Так вот про миссионеров. A>>Миссионеры бывают не только религиозные, миссионеры бывают так же и компьютерные. A>>И чаще всего они пропагандируют какую-нибудь дурь. (Я имею в виду не только христиан).
Q>Да разрабатывали как люди в машинных кодах, а потом пришли эти жертвы егэ т.е. миссионеры и все испортили.
Тебе не кажется, что твоя реплика похожа на кривляние?
A>Вот и теперь некоторые несознательные граждане хотят быть святее папы римского,
Нет
A>и предлагают везде писать модификатор const
Я пишу, и мне это абсолютно не мешает, а вполне даже помогает
A>и даже... делать разные типы для разных int, A>"чтобы яблоки с апельсинами не складывать".
Тоже хорошее дело, жаль только, что в плюсах нет
A>Да, конечно, хорошо бы чтобы компилятор подсказывал, когда ты пытаешься метры с килограммами сложить. A>Но у всего есть цена. Так давайте посмотрим на цену.
A>Допустим у нас есть несколько (ну допустим пять) величин: метры, килограммы, секунды, ньютоны и джоули. A>Да, их нельзя складывать с друг с другом. Но их можно(нужно) умножать и делить. A>Таким образом, чтобы написать формулу, которая содержит три величины, нам нужно иметь 3*(5+1)*(5+1) типов данных. A>То есть 36 типов для результатов умножения (килограмм*метр), A>И 2*36 типов для деления килограмм/метр и метр/килограмм. A>То есть, что-то около сотни типов. (Точная цифра =108)
A>И чтобы над всем этим великолепием можно было выполнять действия, нужно 100*100 — десять тысяч функций. A>Ну... вот так одним лёгким движением Вы обеспечиваете себя работой до пенсии.
До какой пенсии? Это пишется за пару дней. Там же ничего не будет, кроме явных кастов-разрешений сделать требуемую операцию.
Но и сразу тебе это никто делать не предлагает. Собрался ты делить километры на секунды, компилятор тебе дал по рукам, ты пошел проверил: "да, я всё правильно делаю, просто пока нет такого метода", и сделал метод, который позволяет делить расстояние на время и возвращает скорость. Всё. Делов на три секунды.
По хорошему, подобное уже должно было бы быть в стандартной библиотеке, или в бусте, как минимум.
Просто из-за того, что в плюсах нет нормального сильного typedef, поэтому такой библиотеки до сих пор нет.
A>Конечно, какие-то операции будут бессмысленными, и не должны быть реализованными, A>но и тех, что должны быть реализованы, Вам хватит, чтобы работа встала навсегда.
Нет конечно
A>Миссионеры конечно скажут, что для таких ситуаций у них есть шаблоны, A>на что я скажу, что я хочу ЭТО видеть. Как вы будете трахаться с шаблонами.
А что с ними трахаться? Для подобного если шаблоны и надо применять, то это будет элементарно. Даже если и захочешь потрахатся, не с чем будет.
A>В этом месте миссионер скажет, а зато Вам компилятор подскажет, когда Вы вставите в формулу не ту переменную. A>На что я отвечу, что да, раз в год я могу вставить в формулу не ту переменную. A>Но я это делаю не чаще раза в год, и за пять минут найду такую ошибку.
Ты лучше скажи, какой софт ты пилишь, чтобы я его стороной обходил
A>А весь остальной год мне придётся бороться против компилятора, A>и на этом будет потеряно гораздо, гораздо, ГОРАЗДО больше времени.
Да нет, на подобное время уходило тогда, когда я забивал на предупреждения компилятора. Как стал собирать всё с -Wall -Werror, и поправил свои либы (на что ушла где-то неделя, вдумчивого разбирательства с каждым из кейсов), такой проблемы просто нет.
A>А зачем же тогда они это пропагандируют? На этот вопрос ответа нет.
Упрощаем жизнь себе, и рекомендуем это другим.
A>Поэтому, я говорю: не слушайте миссионеров. Миссионеры — это враги. A>В данном случае я опять не христиан имею в виду.
Были такие товарищи — луддиты. Вот ты на них очень похож
Здравствуйте, alpha21264, Вы писали:
A>Ракета летела совершенно нормально. A>Но кому-то почудилось, что величина вышла из диапазона. A>Вот так из-за чьей-то паранойи ракета и грохнулась.
Если мне не изменяет склероз, то на Ариан-5 переиспользовали часть кода из Ариан-4. И старый код не был расчитан на параметры взлета Ариан-5. Поэтому-то снимаемые телеметрией величины вышли за диапазон, на который был расчитан код Ариан-4. И смог бы переиспользованный из Ариан-4 код корректно обработать эти величины дальше, если бы не было жесткого контроля на уровне преобразований типов, это еще вопрос.
Так что это не из-за параноии, а из-за излишнего доверия к коду, который работает.
Здравствуйте, alpha21264, Вы писали:
A>Ну, у меня же и основная работа есть. Поэтому я могу забыть про дискуссию или потерять к ней интерес.
Ну да когда обосрамшись, то интерес действительно быстро теряется
A>Пищу для размышлений я дал, а дальше сами. Спор ради спора я вести не буду. Так что терпите.
Да вот ещё, терпеть тебя. Нам просто на тебя наплевать. Просто мы теперь многое о тебе узнали, как и о качестве твоего софта. Ну и стало ясно, что твоё мнение немногого стоит, ты можешь лютую дичь нести с важным видом.
A>Вот в Вашем напримере какого рода ответ Вы ожидаете получить? Смысл Вашего вопроса какой?
A>>Пищу для размышлений я дал, а дальше сами.
S>Тупой наброс теперь так называется? Ну OK.
Похоже, что Вы сам немного...
Когда я написал про illegal instruction, я написал что :
1) Новый gcc вставляет в код illegal instruction, о чём его никто не просил.
2) Полезные сообщения тонут в тоннах бесполезных.
И что к этому нужно быть готовым.
Далее на эту тему можно рассуждать до бесконечности.
Ваша точка зрения, которую Вы защищаете —
давайте нам ещё больше тонн бесполезных варнингов.
Вот что я дальше должен обсуждать?
A>>Вот в Вашем напримере какого рода ответ Вы ожидаете получить?
S>Честный желательно. Используете ли вы в своем коде классы? S>Если используете, то есть ли в ваших классах const-методы?
Классы использую.
const-методы не использую, потому что не знаю, зачем они нужны.
У меня есть get-методы, но по моему это не одно и то же.
Самое главное — я не понимаю, какое это имеет отношение к обсуждаемой теме.
У меня такое впечатление, что Вы слишком много внимания уделяете инструменту и слишком мало задаче.
Такое бывает, когда Вам не дают больших и интересных задач.
A>>Смысл Вашего вопроса какой?
S>Вы на вопросы сперва ответьте.
Ну вот ответил. Я думаю, что Вам не полегчало. Потому что мы существа из разных миров.
Здравствуйте, Marty, Вы писали:
M>Да вот ещё, терпеть тебя. Нам просто на тебя наплевать. Просто мы теперь многое о тебе узнали, как и о качестве твоего софта. Ну и стало ясно, что твоё мнение немногого стоит, ты можешь лютую дичь нести с важным видом.
Да ладно вам, может человек всю жизнь какую-то специфическую математику в какой-то узкой специфической области считает. Например, в области радиолокации или спутниковой связи.
Если программы по 10KLOC и кроме автора никто в них никогда не заглядывает, то и проблем никаких нет.
Здравствуйте, alpha21264, Вы писали:
A>Ваша точка зрения, которую Вы защищаете -
Внесем ясность: это не моя точка зрения, это то, что вы думаете про мою точку зрения.
A>давайте нам ещё больше тонн бесполезных варнингов.
Не-а, мне бы хотелось больше полезных варнингов.
A>Классы использую. A>const-методы не использую, потому что не знаю, зачем они нужны.
Ну вот это я и хотел услышать.
A>Самое главное — я не понимаю, какое это имеет отношение к обсуждаемой теме.
Самое прямое.
const -- это контроль компилятора за тем, что вы делаете.
Например, у меня в при программировании многопоточности часто используется принцип -- если в некий тред отдается const-ссылка на объект, то значит этот тред имеет возможность вызывать const-методы объекта в любой момент. Типа того, что "чтение всегда безопасно".
И при таком подхоже компилятор сам бьет меня по рукам если я пытаюсь по const-ссылке вызвать мутабельный метод.
Это такая помощь от компилятора, которую сложно переоценить.
A>У меня такое впечатление, что Вы слишком много внимания уделяете инструменту и слишком мало задаче.
У меня задачи специфические, похожие на задачи слесаря-инструментальщика на заводе. Делаю инструменты, которые затем позволяют другим людям проще и быстрее решать их задачи.
A>Такое бывает, когда Вам не дают больших
Давайте конкретнее: "большие" -- это сколько в строках?
A>интересных задач.
Тут есть парадокс: чем интереснее задача, тем меньше шансов, что за нее заплатят
Из совсем свежего: версионированный контейнер для использования в многопоточном коде. Типа того, что если кто-то взял этот контейнер как "читатель", то он работает со старой версией содержимого и не видит изменений, которые в контейнер сейчас вносят "писатели".
Такая задача по вашей классификации пойдет как "интересная" или нет?
A>Ну вот ответил. Я думаю, что Вам не полегчало.
Здравствуйте, Marty, Вы писали:
A>>Ну, у меня же и основная работа есть. Поэтому я могу забыть про дискуссию или потерять к ней интерес.
M>Ну да когда обосрамшись, то интерес действительно быстро теряется
Хамло. (тут мне нужен смайлик с воздушным поцелуем)
A>>Пищу для размышлений я дал, а дальше сами. Спор ради спора я вести не буду. Так что терпите.
M>Да вот ещё, терпеть тебя. Нам просто на тебя наплевать. Просто мы теперь многое о тебе узнали, как и о качестве твоего софта. Ну и стало ясно, что твоё мнение немногого стоит, ты можешь лютую дичь нести с важным видом.
И твой процессор и твоя материнка сделаны с помощью моих программ. Поэтому у меня длиннее. Ну вот так жизнь сложилась. Прими это.
PS модератору.
Мы во флейме, значит можем себе позволить некоторые вольности в выражениях братской любви. Прошу понимать без пошлости.
Здравствуйте, alpha21264, Вы писали:
A>В данном случае будет уместно сказать "учу читать".
A>Если пользоваться твоей аналогией про сахар, то это будет звучать так: A>сахара получается мало, а затрат на него много, в результате начинает не хватать на хлеб.
Соотношение сахара и затрат зависит от контекста. Скажем, если у тебя дешевое сырьё, делать сахар уместно. В противном случае — нет.
Предлагаю отделить для начала рассмотрение самой технологии от рассмотрения границ ее применимости.
Здравствуйте, alpha21264, в целом согласен, но скорее вижу проблемы не в конкретной проблеме типа Primitive Obsession vs Type-safe domain modeling, а когда какому-то подходу или методу придается слишком большое или универсальное значение в ущерб другим важным аспектам проекта. Так, например, 90% менеджеров 90% времени начинают говорить и думать, например, о Скраме, при этом проект проваливается, потому что успех определялся комплексом параметров — уровнем хардов команды, инженерной культурой, архитектурой, процессом развертывания, соответствия продукта рынку и и т.п. и т.д.
Тогда можно сказать, что миссионеры — это сторонники одной серебряной пули, которой, как правило, нет. Но время и комплексный поход могут быть уже упущены к тому моменту, когда закончатся деньги на продукт или компанию.
N>У европейцев спутник "Ариан-5" упал когда-то, с типом данных не угадали. Стоит ли работы программиста? N>Или сбой навигации у самолётов над Мёртвым морем, когда высота была отрицательной.
Там контроль типов не помог бы
Ну написал ты
uint8_t a=42;
uint8_t b=69;
uint8_t c=a-b;
Как тебя контроль типов спасёт?
По части const тс конечно ересь втирает, но по части "свой тип на свой домен" тут я во многом его понимаю, потому что это всего лишь порождает код засранный принудительными кастами к одниму числовому наиболее общему типу
Нет такой подлости и мерзости, на которую бы не пошёл gcc ради бессмысленных 5% скорости в никому не нужном синтетическом тесте
Здравствуйте, Быдлокодер, Вы писали:
Б>Интересно, а кто на практике использовал strongly typed domain modeling в реальном проекте? Какие результаты и выводы?
Я каждый раз когда подключаю std::chporno для замеров времени. Я эту парашу без гугла в жисть не повторю. С сишными функциями проще было. Да, баги вида "сложил секунды и милисекунды" возможны, но зато их легко обнаружить и пофиксить, чем каждый раз изучать доку на тему какой метод тут нужен для преобразования. Еще и какие-то систем клок, стеди клок, чё
Да и чисто психилогически мне поиск несоответствия в результате вывода комфортнее чем гуглинг и ковыряние в документации.
Короче я за примитив обсешшон. Доменный фанатизм фтопку
Нет такой подлости и мерзости, на которую бы не пошёл gcc ради бессмысленных 5% скорости в никому не нужном синтетическом тесте
Здравствуйте, T4r4sB, Вы писали:
TB>Я каждый раз когда подключаю std::chporno для замеров времени. Я эту парашу без гугла в жисть не повторю. С сишными функциями проще было.
Счастливый ты человек. Ты никогда не сталкивался с точным измерением времени, синхронизацией, календарями, таймзонами, и т.п.
И да, C++ тут не при чём.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ·, Вы писали:
·>Счастливый ты человек. Ты никогда не сталкивался с точным измерением времени, синхронизацией, календарями, таймзонами, и т.п. ·>И да, C++ тут не при чём.
Насколько точным? Мне struct timeval с микросекундами как-то хватало всегда
Нет такой подлости и мерзости, на которую бы не пошёл gcc ради бессмысленных 5% скорости в никому не нужном синтетическом тесте
Здравствуйте, alpha21264, Вы писали:
A>Здравствуйте, so5team, Вы писали:
A>Когда я написал про illegal instruction, я написал что : A>1) Новый gcc вставляет в код illegal instruction, о чём его никто не просил.
Это вообще надо было сделать сразу. Но лучше позндо, чем никогда. Кстати, весьма вероятно, что у них есть ключик, чтобы вернуть старое поведение.
A>2) Полезные сообщения тонут в тоннах бесполезных.
Все сообщения полезны, и сигнализируют о том, что ты, скорее всего, делаешь что-то подозрительное. Проект должен собираться с ключиками -Wall -Werror
A>Ваша точка зрения, которую Вы защищаете - A>давайте нам ещё больше тонн бесполезных варнингов.
Это ты, привыкнув говнокодить, считаешь, что они бесполезны
S>>Честный желательно. Используете ли вы в своем коде классы? S>>Если используете, то есть ли в ваших классах const-методы?
A>Классы использую. A>const-методы не использую, потому что не знаю, зачем они нужны.
Их используют для того, чтобы компилятор мог определять возможность их вызова для константных объектов
A>У меня есть get-методы, но по моему это не одно и то же.
Твои get-методы могут поменять объект, но никто этого не заметит. Сколько чудных граблей ты раскладываешь в своём коде
A>Самое главное — я не понимаю, какое это имеет отношение к обсуждаемой теме.
Это твоя проблема
A>У меня такое впечатление, что Вы слишком много внимания уделяете инструменту и слишком мало задаче. A>Такое бывает, когда Вам не дают больших и интересных задач.
А ты не уделяешь внимания инструменту от слова вообще. Тебе микроскоп дадут, а ты им гвозди будешь забивать, потому что забивание гвоздей — это для тебя большая интересная задача.
Здравствуйте, T4r4sB, Вы писали:
TB>Как тебя контроль типов спасёт? TB>По части const тс конечно ересь втирает, но по части "свой тип на свой домен" тут я во многом его понимаю, потому что это всего лишь порождает код засранный принудительными кастами к одниму числовому наиболее общему типу
По-хорошему, разрешенные касты должны быть описаны, и не должно быть никаких принудительных кастов в прикладном коде
Здравствуйте, alpha21264, Вы писали:
Q>>Да разрабатывали как люди в машинных кодах, а потом пришли эти жертвы егэ т.е. миссионеры и все испортили.
A>Тебе не кажется, что твоя реплика похожа на кривляние?
Здравствуйте, Marty, Вы писали:
Q>>>Да разрабатывали как люди в машинных кодах, а потом пришли эти жертвы егэ т.е. миссионеры и все испортили.
A>>Тебе не кажется, что твоя реплика похожа на кривляние?
M>Не больше, чем твоя тема
Marty, сегодня ты не смешной.
Вообще, rsdn — это сайт, который крутится на компьютере Влада.
Я думаю, что не надо забивать его бессодержательными репликами.
Здравствуйте, alpha21264, Вы писали:
A>Допустим у нас есть несколько (ну допустим пять) величин: метры, килограммы, секунды, ньютоны и джоули. A>Да, их нельзя складывать с друг с другом. Но их можно(нужно) умножать и делить. A>Таким образом, чтобы написать формулу, которая содержит три величины, нам нужно иметь 3*(5+1)*(5+1) типов данных. A>То есть 36 типов для результатов умножения (килограмм*метр), A>И 2*36 типов для деления килограмм/метр и метр/килограмм. A>То есть, что-то около сотни типов. (Точная цифра =108) A>И чтобы над всем этим великолепием можно было выполнять действия, нужно 100*100 — десять тысяч функций.
Нужно, что бы компилятор умел
1. уметь поддержку единиц измерений
2. выводить типы из выражения
3. проверять соответсвие типов — уже умеет
В этом случае,
все типы он выведет сам, и будет делать это по месту переменной
никаких десять тысяч функций не нужно — вы пишете по одной, под конкретную формулу, а компилятор с остальным справляется сам
В этом случае вы не сможете силу передать как массу или энергию, а вот произведение ускорения на массу — с да, сможете
Здравствуйте, Marty, Вы писали:
M>По-хорошему, разрешенные касты должны быть описаны, и не должно быть никаких принудительных кастов в прикладном коде
Вот у тебя одна либа генерирует изображение в котором выдает координаты u64 а другая которая сохраняет принимает координаты в u32. В русте такой шизы очень много. Я спрашивал типа сделайте int64 для всех и не трахайте голову, а мне втирают что это примитив обсешшон и он приведет к проблемам. Ну пока что проблемы с тем что приходится принудительно писать касты и разбирать отдельно случай вычитания большего из меньшего
Нет такой подлости и мерзости, на которую бы не пошёл gcc ради бессмысленных 5% скорости в никому не нужном синтетическом тесте
Здравствуйте, T4r4sB, Вы писали:
M>>По-хорошему, разрешенные касты должны быть описаны, и не должно быть никаких принудительных кастов в прикладном коде
TB>Вот у тебя одна либа генерирует изображение в котором выдает координаты u64 а другая которая сохраняет принимает координаты в u32. В русте такой шизы очень много. Я спрашивал типа сделайте int64 для всех и не трахайте голову, а мне втирают что это примитив обсешшон и он приведет к проблемам. Ну пока что проблемы с тем что приходится принудительно писать касты и разбирать отдельно случай вычитания большего из меньшего
Тебе не кажется, что это несколько другая ситуация?
Здравствуйте, Быдлокодер, Вы писали:
Б>Интересно, а кто на практике использовал strongly typed domain modeling в реальном проекте? Какие результаты и выводы?
Я использую, но у меня не физика, нет необходимости складывать/делить и исполнять прочую арифметику.
Зато есть объекты, для которых есть целочисленные идентификаторы (uintXX_t в основном).
И у одного и того же объекта может быть больше одного идентификатора, в зависимости от того, кому он передаётся.
вот и есть у меня:
using session_id_t = StrongTypedef<..., uint32_t>;
using nsapi_t = StrongTypedef<..., uint8_t>;
using teid_t = StrongTypedef<..., uint32_t>;
using eps_bearer_id_t = StrongTypedef<..., uint32_t>;
using qci_t = StrongTypedef<..., uint8_t>;
using nsapi_t = StrongTypedef<..., uint8_t>;
using qdisc_id_t = StrongTypedef<..., uint32_t>;
// ну и ещё с десяток-полтора подобного
Результат — код лучше, ловил несоответствие формальных и фактических параметров ф-ций по типу не раз. Прямо во время написания кода редактор показывает, что такой вызов не получится.
Лучше всего проявляло себя во время рефакторингов модели. Без использования StrongTypedef я бы просто боялся делать изменения тех масштабов, которые я делал.
Кроме того, упрощаются некоторые виды анализов кода. Например, я легко могу найти все API, работающие с данным типом, да и вообще все места его использования.
Для каких-то типов я вводил специальные форматтеры для записи в журнал. Например, если Wireshark показывает тип как шестнатиричное 8-хциферное число с ведущими нулями, то мне в журнале удобно его видеть ровно так же, и я переопределяю желаемый формат в одном месте, затем просто использую `{}` где нужно, и в выводе программы я увижу "0000beda", без необходимости выписывать форматную строку в каждом месте. До того, как я ввёл строгие типы, одни и те же значения печатались то как десятичные, то как шестнадцатиричные.
Было такое, что для решения одной проблемы, когда мне нужно было анализировать много выхлопа программы, я оборачивал вывод в декоратор типа `---0000beda---` для более простого парсинга скриптом, и добавлял в журнал коды для выделения этих значений цветом, для более удобного поиска глазами. И то, и другое делалось в одном месте. Если бы нужно было найти и попатчить все места использования этого типа, я бы просто этого делать не стал.
Я понимаю, что это не то же самое, что моделирование физики, где нужно комбинировать величины разных размерностей, что ведёт к комбинаторике. Была бы задача с физикой — обязательно бы попробовал с сильной типизацией. Не факт, что понравилось бы, нет такого опыта.
Здравствуйте, Marty, Вы писали:
M>Тебе не кажется, что это несколько другая ситуация?
Нет. Это бред с разным числовым типом на каждый чих — именно то, что мне обосновывали как "доменно-ориентированный тип". И как следствие — на стыке домена и своего кода ехал каст через каст
Нет такой подлости и мерзости, на которую бы не пошёл gcc ради бессмысленных 5% скорости в никому не нужном синтетическом тесте
M>>Тебе не кажется, что это несколько другая ситуация?
TB>Нет. Это бред с разным числовым типом на каждый чих — именно то, что мне обосновывали как "доменно-ориентированный тип". И как следствие — на стыке домена и своего кода ехал каст через каст
Хернёй люди занимаются. Нет смысла в отсутствие нормального strong typedef'а
Здравствуйте, T4r4sB, Вы писали:
TB>Насколько точным? Мне struct timeval с микросекундами как-то хватало всегда
Слишком много ликбеза. Мне лень писать подробно. Но пара хинтов:
TB>Я каждый раз когда подключаю std::chporno для замеров времени.
И читаем: https://blog.habets.se/2010/09/gettimeofday-should-never-be-used-to-measure-time.html
TB>Еще и какие-то систем клок, стеди клок, чё
Это сисколлы, а не причуда std::chrono как тебе кажется: "kernel support the following clocks:" https://linux.die.net/man/3/clock_gettime
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, alpha21264, Вы писали:
A>Вообще, rsdn — это сайт, который крутится на компьютере Влада. A>Я думаю, что не надо забивать его бессодержательными репликами.
У современного диска быстрее кончается срок, когда на надёжность этого диска не страшно рассчитывать, чем место на нём...
Здравствуйте, Marty, Вы писали:
M>Да вот ещё, терпеть тебя. Нам просто на тебя наплевать. Просто мы теперь многое о тебе узнали, как и о качестве твоего софта. Ну и стало ясно, что твоё мнение немногого стоит, ты можешь лютую дичь нести с важным видом.
Знаешь, мне приходилось встречать людей, которые рассуждают, как Альфа, но при этом в состоянии надёжно работать. У них какие-то свои методы обеспечения надёжности, отличные от общепринятых.
В принципе, людям нашего с Альфой поколения это простительно: мы сложились, как профессионалы, раньше, чем это методы стали общепринятыми (ну и вообще, то, что сейчас считается общепринятым, во многом формировалось на наших глазах, и во многих точках вполне могло пойти по другой траектории).
Так что представления о качестве его софта из его слов не выведешь.
Здравствуйте, Pzz, Вы писали:
Pzz>Так что представления о качестве его софта из его слов не выведешь.
Проблема не в том, что кто-то пишет код с использованием ненадёжных, небезопасных подходов и практик.
Проблема — когда такие подходы продвигаются, как правильные, а сторонники практик, облегчающих написание надёжного кода, объявляются "истинными врагами". А человек, заявляющий "у меня длиннее", уж наверняка будет навязывать своё видение в команде.
Я знаю специалистов, на голову, а то и не одну выше меня, при этом defensive programming, эти все ассёрты, санитайзеры, юнит-тесты, повышенные уровни предупреждений, const-correctness, [nodiscard]], RAII, отказ от using-директив и пр. им "мешают творить".
Могу ли уважать такого человека, может, даже в чём-то и восхищаться? Да.
Захочу ли я с ним работать? Нет. Это будет боль или для него, или для меня, или для обоих. Я не настолько умён, чтобы отказываться от помощи инструментов. И большинство программистов — тоже.
Здравствуйте, serg_joker, Вы писали:
Pzz>>Так что представления о качестве его софта из его слов не выведешь. _>Проблема не в том, что кто-то пишет код с использованием ненадёжных, небезопасных подходов и практик. _>Проблема — когда такие подходы продвигаются, как правильные, а сторонники практик, облегчающих написание надёжного кода, объявляются "истинными врагами". А человек, заявляющий "у меня длиннее", уж наверняка будет навязывать своё видение в команде.
А кто в этой дискуссии не категоричен?
_>Я знаю специалистов, на голову, а то и не одну выше меня, при этом defensive programming, эти все ассёрты, санитайзеры, юнит-тесты, повышенные уровни предупреждений, const-correctness, [nodiscard]], RAII, отказ от using-директив и пр. им "мешают творить".
Наше ремесло обрасло неимоверным количеством ритуалов, в которые все верят, будто их Моисей на каменных скрижалях написал.
При всём при том, многие из них родились совсем недавно. И до их появления как-то же люди умудрялись программы писать.
Например, к тому времени, когда придумали code review, я написал уже не один десяток тысяч строк вполне работоспособного софта. А сейчас код без ревью считается говнокодом.
Самое смешное, что многие программы, написанные по корпоративным стандартам, содержат хренову кучу опенсорсного кода. Который запросто может быть написан, следуя совсем другим процессам. И никого это не парит, когда речь идет о внешнем коде, но вот внутренний — будьте добры все ритуалы соблюсти.
Пойми меня правильно, я не против code review и т.п. Но мне странно видеть, как соблюдение ритуалов ставится выше здравого смысла.
При этом я не хочу быть услышан, как человек, который выступает за полную анархию в разработке. Правила нужны, особенно в командной игре. Но надо понимать, что можно договориться, с учётом реалий конкретной команды, о правилах "не по учебнику", и это будет прекрасно работать.
_>Могу ли уважать такого человека, может, даже в чём-то и восхищаться? Да. _>Захочу ли я с ним работать? Нет. Это будет боль или для него, или для меня, или для обоих. Я не настолько умён, чтобы отказываться от помощи инструментов. И большинство программистов — тоже.
Я так понимаю, у Альфы в проекте куча предупреждений сыпется. Вряд ли все евонные, иначе он бы просто подстроил опции компилятора под себя. Похоже, там и без него изрядный бартак стоит.
В общем и целом, если из кода лезут предупреждения изо всех мест, какой смысл их держать в компиляторе разрешенными, если их никто не чинит?
Здравствуйте, Pzz, Вы писали:
M>>Да вот ещё, терпеть тебя. Нам просто на тебя наплевать. Просто мы теперь многое о тебе узнали, как и о качестве твоего софта. Ну и стало ясно, что твоё мнение немногого стоит, ты можешь лютую дичь нести с важным видом.
Pzz>Знаешь, мне приходилось встречать людей, которые рассуждают, как Альфа, но при этом в состоянии надёжно работать. У них какие-то свои методы обеспечения надёжности, отличные от общепринятых.
Весьма возможно, что он пишет очень-очень мало кода. Не, его код может быть очень нужным и важным, и никто другой его не напишет, так как он, но тем не менее, это очень специфично, и хорошо, если работает в 1% случаев.
Pzz>В принципе, людям нашего с Альфой поколения это простительно: мы сложились, как профессионалы, раньше, чем это методы стали общепринятыми (ну и вообще, то, что сейчас считается общепринятым, во многом формировалось на наших глазах, и во многих точках вполне могло пойти по другой траектории).
В сишечке const был всегда (ну почти):
Ключевое слово const появилось в языке C в версии ANSI C (C89), которая была стандартизирована в 1989 году.
Что-то мне не кажется, что вы настолько древние, что успели сформироваться как профессионалы, до 89го года.
Pzz>Так что представления о качестве его софта из его слов не выведешь.
Весьма вероятно, что 99% "его" софта написано не им, а он только отвечает за какие-то компоненты, и его не трогают, пока оно вроде как работает и вроде не особо глючит
Здравствуйте, Marty, Вы писали:
Pzz>>Знаешь, мне приходилось встречать людей, которые рассуждают, как Альфа, но при этом в состоянии надёжно работать. У них какие-то свои методы обеспечения надёжности, отличные от общепринятых.
M>Весьма возможно, что он пишет очень-очень мало кода. Не, его код может быть очень нужным и важным, и никто другой его не напишет, так как он, но тем не менее, это очень специфично, и хорошо, если работает в 1% случаев.
А может вовсе и не мало кода. С его слов это никак не следует.
Pzz>>В принципе, людям нашего с Альфой поколения это простительно: мы сложились, как профессионалы, раньше, чем это методы стали общепринятыми (ну и вообще, то, что сейчас считается общепринятым, во многом формировалось на наших глазах, и во многих точках вполне могло пойти по другой траектории).
M>В сишечке const был всегда (ну почти):
Я люблю const. Не надо меня агитировать за const. В гошечке я скучаю по сишному const. Не понимаю, почему он туда не попал.
M>
M>Ключевое слово const появилось в языке C в версии ANSI C (C89), которая была стандартизирована в 1989 году.
И до сих пор используется не всегда последовательно. Например, strerror, getenv возвращают неконстантную строку. Функции типа strtol берут константную строку, но указатель на место, после которого не получилось распарсить — char **.
Не то, чтобы таких мест много, но время от времени на них натышаешься. В компиляторах времен начала 90-х таких "подарков" было больше.
Pzz>>Так что представления о качестве его софта из его слов не выведешь.
M>Весьма вероятно, что 99% "его" софта написано не им, а он только отвечает за какие-то компоненты, и его не трогают, пока оно вроде как работает и вроде не особо глючит
Можно долго гадать, чего он там и в каком количестве пишет
Pzz>А может вовсе и не мало кода. С его слов это никак не следует.
С таким подходом сложно написать крупную систему. Не ну может он конечно уникум.
M>>В сишечке const был всегда (ну почти):
Pzz>Я люблю const. Не надо меня агитировать за const. В гошечке я скучаю по сишному const. Не понимаю, почему он туда не попал.
Да я вроде и не особо агитирую, я просто констатирую факт, что если культура писать без const привилась у человека, то это очень древний человек
M>>
M>>Ключевое слово const появилось в языке C в версии ANSI C (C89), которая была стандартизирована в 1989 году.
Pzz>И до сих пор используется не всегда последовательно. Например, strerror, getenv возвращают неконстантную строку. Функции типа strtol берут константную строку, но указатель на место, после которого не получилось распарсить — char **.
Тяжелое наследие:
В 1969—1973 годы на основе Би был разработан компилируемый язык, получивший название Си.
В 1973 году вышла третья редакция Unix со встроенным компилятором языка Си.
Подозреваю, K&R тоже про const не особо сначала подумали, а потом наелись говна и решили добавить, и спустя 15 лет оно вошло в стандарт.
Unix изначально был однозадачный, и, возможно, создатели что-то знали о размерах буфера strerror, getenv, и могли его использовать. Потом фичу порезали, но для совместимости с говнокодом сигнатуры остались как есть.
strtol — весьма вероятно, что предполагалась возможность модифицировать буфер, если знаешь, что передал туда неконстантную строку. char* кастится к const char без предупреждений, обратно — не так. А товарищи не любили явно кастить
Pzz>Не то, чтобы таких мест много, но время от времени на них натышаешься. В компиляторах времен начала 90-х таких "подарков" было больше.
Ну, перечисленное — это изначально были юниксовые сисколы, а не просто какой-то компилятор
M>>Весьма вероятно, что 99% "его" софта написано не им, а он только отвечает за какие-то компоненты, и его не трогают, пока оно вроде как работает и вроде не особо глючит
Pzz>Можно долго гадать, чего он там и в каком количестве пишет
С таким подходом много и качественно очень сложно сделать
Здравствуйте, Pzz, Вы писали:
Pzz>И до их появления как-то же люди умудрялись программы писать.
Я на асме Z-80 не одну тетрадку 96 листов всяких подпрограмм и библиотечек написал, только вот в продукт оно так и не выросло
Pzz>Самое смешное, что многие программы, написанные по корпоративным стандартам, содержат хренову кучу опенсорсного кода. Который запросто может быть написан, следуя совсем другим процессам. И никого это не парит, когда речь идет о внешнем коде, но вот внутренний — будьте добры все ритуалы соблюсти.
В этом ничего смешного. Опенсорсный считается протестированным сообществом, и потому достаточно качественным, а также — это чисто внешняя зависимость, и никто её развивать не будет. А свой код таки предполагается, что будет развиваться. Так что подход вполне логичный.
Pzz>Я так понимаю, у Альфы в проекте куча предупреждений сыпется. Вряд ли все евонные, иначе он бы просто подстроил опции компилятора под себя. Похоже, там и без него изрядный бартак стоит.
Я без проблем решал эту проблему
Pzz>В общем и целом, если из кода лезут предупреждения изо всех мест, какой смысл их держать в компиляторе разрешенными, если их никто не чинит?
Здравствуйте, Marty, Вы писали:
Pzz>>А может вовсе и не мало кода. С его слов это никак не следует.
M>С таким подходом сложно написать крупную систему. Не ну может он конечно уникум.
Ну а как люди пишут крупные системы на JS или Питоне? Там с проверками еще сильно хуже.
M>Подозреваю, K&R тоже про const не особо сначала подумали, а потом наелись говна и решили добавить, и спустя 15 лет оно вошло в стандарт.
Мне кажется, там уж комитет подключился.
Вообще, лет 20 назад в UNIX было полно программ, написанных на K&R C. Т.е., никаких тебе const, никаких прототипов функций...
M>Unix изначально был однозадачный, и, возможно, создатели что-то знали о размерах буфера strerror, getenv, и могли его использовать. Потом фичу порезали, но для совместимости с говнокодом сигнатуры остались как есть.
В каком смысле он был однозадачный? В том, что решал одну задачу: создавал предлог Ричи и Томпсону заныкать стоявшую в конторе "ничейную" PDP-ку и невозбранно играть на ней в Startrack?
Вообще-то, насколько я в курсе, он с самого начала был многопользовательский/многозадачный. Вот нити, да, появились в унихе довольно поздно.
M>strtol — весьма вероятно, что предполагалась возможность модифицировать буфер, если знаешь, что передал туда неконстантную строку. char* кастится к const char без предупреждений, обратно — не так. А товарищи не любили явно кастить
У товарищей ps работал путём чтения ядерной памяти из /dev/kmem. Народ тогда был не то, что ныне
Здравствуйте, Marty, Вы писали:
Pzz>>Самое смешное, что многие программы, написанные по корпоративным стандартам, содержат хренову кучу опенсорсного кода. Который запросто может быть написан, следуя совсем другим процессам. И никого это не парит, когда речь идет о внешнем коде, но вот внутренний — будьте добры все ритуалы соблюсти.
M>В этом ничего смешного. Опенсорсный считается протестированным сообществом, и потому достаточно качественным, а также — это чисто внешняя зависимость, и никто её развивать не будет. А свой код таки предполагается, что будет развиваться. Так что подход вполне логичный.
Качество там ОЧЕНЬ разное.
Например, libtiff, написанный в одни руки Самуилом Лёфлером, соавтором ядра BSD UNIX и совершенно замечательной книжки про это ядро — это лютый треш (а ядро, кстати, вполне ничего, не считая местами ну очень уж тонких игр с синхронизацией там, где можно было бы сделать по-простому, не пожалев нескольких тактов процессора на явное использование какого-нибудь уместного примитива синхронизации).
Pzz>>Я так понимаю, у Альфы в проекте куча предупреждений сыпется. Вряд ли все евонные, иначе он бы просто подстроил опции компилятора под себя. Похоже, там и без него изрядный бартак стоит.
M>Я без проблем решал эту проблему
Это — организационная проблема. Она не всегда решается тем, что ты создаешь патч, который решает техническую часть проблемы.
Pzz>>В общем и целом, если из кода лезут предупреждения изо всех мест, какой смысл их держать в компиляторе разрешенными, если их никто не чинит?
M>Смысл есть сделать это хотя бы для своего кода
Здравствуйте, Pzz, Вы писали:
Pzz>А кто в этой дискуссии не категоричен?
Я! и не спорь!
Pzz>При всём при том, многие из них родились совсем недавно. И до их появления как-то же люди умудрялись программы писать. Pzz>Например, к тому времени, когда придумали code review, я написал уже не один десяток тысяч строк вполне работоспособного софта. А сейчас код без ревью считается говнокодом.
Количество кода и программистов выросло, а качество программистов — наоборот, это нужно учитывать в практиках.
Pzz>Самое смешное, что многие программы, написанные по корпоративным стандартам, содержат хренову кучу опенсорсного кода. Который запросто может быть написан, следуя совсем другим процессам. И никого это не парит, когда речь идет о внешнем коде, но вот внутренний — будьте добры все ритуалы соблюсти.
Тот опенсорс, который я тащу в проект — это обычно что-то сильно более протестированное в силу пользовательской базы, чем моё (буст, к примеру, или fmtlib). Себе я доверяю меньше, поэтому предпочитаю, чтобы мой код коллеги смотрели, не ради ритуала, а чтобы поймать мою невнимательность, да и познакомиться с тем, что изменилось. При этом я вполне могу позволить себе пушнуть в мастер без ревью, и, обожемой, даже переписать историю уже пушнутой ветки (и даже мастер)! Ща меня заплюют, наверное
Pzz>Пойми меня правильно, я не против code review и т.п. Но мне странно видеть, как соблюдение ритуалов ставится выше здравого смысла.
Я тут полностью с тобой. Туда же отнесу разновсяческие Clean Code и прочие Solid, если они исполняются ритуально и догматично.
Pzz>При этом я не хочу быть услышан, как человек, который выступает за полную анархию в разработке. Правила нужны, особенно в командной игре. Но надо понимать, что можно договориться, с учётом реалий конкретной команды, о правилах "не по учебнику", и это будет прекрасно работать.
+. Но от Альфы я увидел скорее "мне не нужны правила, у меня длинней" (и в разрезе толерантности к предупреждениям, и по поводу const, и что-то ещё, общее ощущение вот такое).
Pzz>Я так понимаю, у Альфы в проекте куча предупреждений сыпется. Вряд ли все евонные, иначе он бы просто подстроил опции компилятора под себя. Похоже, там и без него изрядный бартак стоит.
Я воспринимаю мнение Альфы так (пусть поправит, если ошибочно): "у нас в проекте куча предупреждений, поэтому мы не видим среди мусора нужное, но меня это устраивает". Ну вот не увидел я в его текстах сожаления о том, что оно так. Мне это непонятно.
Pzz>В общем и целом, если из кода лезут предупреждения изо всех мест, какой смысл их держать в компиляторе разрешенными, если их никто не чинит?
Согласен. Вот даже если полностью забить на предупреждения (как, видимо, у них и происходит), то чисто с прагматической точки зрения стоит сделать так, чтобы их не было вовсе, тогда сообщения об ошибках будут идти подряд, а не в перемешку с мусором.
Если утилита каждый запуск пишет простыни в stderr, но тебе этот вывод неинтересен — перенаправь его в /dev/null, зачем на него глядеть-то?
Здравствуйте, Pzz, Вы писали:
M>>В этом ничего смешного. Опенсорсный считается протестированным сообществом, и потому достаточно качественным, а также — это чисто внешняя зависимость, и никто её развивать не будет. А свой код таки предполагается, что будет развиваться. Так что подход вполне логичный.
Pzz>Качество там ОЧЕНЬ разное.
Pzz>Например, libtiff, написанный в одни руки Самуилом Лёфлером, соавтором ядра BSD UNIX и совершенно замечательной книжки про это ядро — это лютый треш (а ядро, кстати, вполне ничего, не считая местами ну очень уж тонких игр с синхронизацией там, где можно было бы сделать по-простому, не пожалев нескольких тактов процессора на явное использование какого-нибудь уместного примитива синхронизации).
Даже если это не так, как возможно, в твоём примере, всё равно никто этот условный libtiff ни чинить, ни развивать не будет
Pzz>>>Я так понимаю, у Альфы в проекте куча предупреждений сыпется. Вряд ли все евонные, иначе он бы просто подстроил опции компилятора под себя. Похоже, там и без него изрядный бартак стоит.
M>>Я без проблем решал эту проблему
Pzz>Это — организационная проблема. Она не всегда решается тем, что ты создаешь патч, который решает техническую часть проблемы.
Причем тут патч, когда это решается разными настройками компилятора для разных частей проекта?
Pzz>>>В общем и целом, если из кода лезут предупреждения изо всех мест, какой смысл их держать в компиляторе разрешенными, если их никто не чинит?
M>>Смысл есть сделать это хотя бы для своего кода
Pzz>Есть. Если говно из заголовков не лезет.
Это тоже решается. Я в основном использую хидер-онли библиотеки, в тч и чужие такие же, и у меня всё компилируется без единого варнинга
Здравствуйте, serg_joker, Вы писали:
Pzz>>При всём при том, многие из них родились совсем недавно. И до их появления как-то же люди умудрялись программы писать. Pzz>>Например, к тому времени, когда придумали code review, я написал уже не один десяток тысяч строк вполне работоспособного софта. А сейчас код без ревью считается говнокодом. _>Количество кода и программистов выросло, а качество программистов — наоборот, это нужно учитывать в практиках.
Боюсь, что эти сложившиеся практики способствуют снижению качества программистов. Не попасть бы нам в замкнутый круг, когда практики будут подстраиваться под плохих программистов, еще больше снижая их качество и т.д.
Pzz>>Самое смешное, что многие программы, написанные по корпоративным стандартам, содержат хренову кучу опенсорсного кода. Который запросто может быть написан, следуя совсем другим процессам. И никого это не парит, когда речь идет о внешнем коде, но вот внутренний — будьте добры все ритуалы соблюсти. _>Тот опенсорс, который я тащу в проект — это обычно что-то сильно более протестированное в силу пользовательской базы, чем моё (буст, к примеру, или fmtlib). Себе я доверяю меньше, поэтому предпочитаю, чтобы мой код коллеги смотрели, не ради ритуала, а чтобы поймать мою невнимательность, да и познакомиться с тем, что изменилось. При этом я вполне могу позволить себе пушнуть в мастер без ревью, и, обожемой, даже переписать историю уже пушнутой ветки (и даже мастер)! Ща меня заплюют, наверное
Опенсорс бывает разный. У libtiff огромная пользовательская база, и написан он вполне приличным и уважаемым человеком. А код там такой, что хочется его развидеть, пока глаза не отвалились.
Pzz>>При этом я не хочу быть услышан, как человек, который выступает за полную анархию в разработке. Правила нужны, особенно в командной игре. Но надо понимать, что можно договориться, с учётом реалий конкретной команды, о правилах "не по учебнику", и это будет прекрасно работать. _>+. Но от Альфы я увидел скорее "мне не нужны правила, у меня длинней" (и в разрезе толерантности к предупреждениям, и по поводу const, и что-то ещё, общее ощущение вот такое).
Ну, может человек прищемил на бегу дверью чувствительный и важный орган, и теперь у него действительно длиннее. Нам-то откуда знать?
Pzz>>Я так понимаю, у Альфы в проекте куча предупреждений сыпется. Вряд ли все евонные, иначе он бы просто подстроил опции компилятора под себя. Похоже, там и без него изрядный бартак стоит. _>Я воспринимаю мнение Альфы так (пусть поправит, если ошибочно): "у нас в проекте куча предупреждений, поэтому мы не видим среди мусора нужное, но меня это устраивает". Ну вот не увидел я в его текстах сожаления о том, что оно так. Мне это непонятно.
Ну, я тоже примерно так услышал. Ну или не "устраивает", а "приходится с этим как-то уживаться". Организационно может быть трудно навести там порядок, мы ж не знаем его обстоятельств.
Здравствуйте, Marty, Вы писали:
M>Даже если это не так, как возможно, в твоём примере, всё равно никто этот условный libtiff ни чинить, ни развивать не будет
Проблема в том, что он важен для печати, факсов и PDF. И у него нет альтернативы. А чинить да, никто не будет.
Здравствуйте, Pzz, Вы писали:
M>>Даже если это не так, как возможно, в твоём примере, всё равно никто этот условный libtiff ни чинить, ни развивать не будет
Pzz>Проблема в том, что он важен для печати, факсов и PDF. И у него нет альтернативы. А чинить да, никто не будет.
Так и в чем проблема? Работает, и ладно.
Насрать, в каком стиле там всё сделано, почему тот стиль должен как-то влиять на основной проект?
A>Ну вот например, они пропагандируют... ну например контроль типов.
Что-то не пойму я, кто тебе что пропагандирует. Это ведь ты темы создаешь. Тебе просто высказывают мнение по поднятым тобой вопросам. А если это мнение не совпадает с твоим, значит, враги. Так что, тут ещё вопрос, кто и что пропагандирует.
--
Справедливость выше закона. А человечность выше справедливости.
Здравствуйте, Pzz, Вы писали:
Pzz>Боюсь, что эти сложившиеся практики способствуют снижению качества программистов. Не попасть бы нам в замкнутый круг, когда практики будут подстраиваться под плохих программистов, еще больше снижая их качество и т.д.
Мне так не кажется. К примеру, плохой программист напишет плохой код как и продуктового куска, так и юнит-теста, но всё-таки шансы, что он случайно юнит тест напишет такой, что поймает ошибку реализации или регрессию в будущем, есть.
Какие "модные" практики ты видишь такие, что ухудшают качество программистов? Именно практики как таковые, а не их догматическое и чисто формальное использование. Вот так, чтоб практику отменить — и программисты стали лучше.
Pzz>Опенсорс бывает разный. У libtiff огромная пользовательская база, и написан он вполне приличным и уважаемым человеком. А код там такой, что хочется его развидеть, пока глаза не отвалились.
Ну вот я его заверну аккуратно, чтобы ворнингами не сыпало, и буду пользоваться. Большая пользовательская база такой низкоуровневой хрени — это уже некая гарантия качества (на уровне предоставляемого функционала). Что там внутри меня мало интересует до тех пор, пока мне не нужно будет колупаться в исходниках.
Pzz>Ну, я тоже примерно так услышал. Ну или не "устраивает", а "приходится с этим как-то уживаться". Организационно может быть трудно навести там порядок, мы ж не знаем его обстоятельств.
Ну вот если бы хоть намёк на "приходится". Пока что я видел только аргументы в пользу "бусть будет, как было, мне норм".
Здравствуйте, rg45, Вы писали:
R>А если это мнение не совпадает с твоим, значит, враги.
Более того, этот персонаж любить обрывать разговор на полуслове. Типа мне стало скучно, а вопросов ваших я в силу специфичности своего опыта не понимаю, поэтому "давай, до свиданья!"
Пытаешься выяснить у человека обстоятельства, а он тупо отморозился и все. Остаешься в недоумении: а тему-то зачем открывать, если затем сходу в кусты и не отсвечиваешь?
Здравствуйте, Pzz, Вы писали:
Pzz>Ну а как люди пишут крупные системы на JS или Питоне? Там с проверками еще сильно хуже.
С какими именно проверками?
Так-то JS и Python -- это языки со строгой типизацией, в отличии от C или C++.
В них по ошибке строку невозможно выдать за double.
А именно крупные системы пишут с трудом и за счет тотального тестирования. Не зря же сама мода на unit-тестирование в индустрию пришла из extreme programming, который возник из опыта разработки большого проекта на динамически-типизированном SmallTalk.
Плюс к тому, в чисто-динамические в прошлом языки либо добавляют опциональные аннотации типов (как в Python), либо делают ответвления в сторону (как в TypeScript).
Здравствуйте, serg_joker, Вы писали:
Pzz>>При всём при том, многие из них родились совсем недавно. И до их появления как-то же люди умудрялись программы писать. Pzz>>Например, к тому времени, когда придумали code review, я написал уже не один десяток тысяч строк вполне работоспособного софта. А сейчас код без ревью считается говнокодом. _>Количество кода и программистов выросло, а качество программистов — наоборот, это нужно учитывать в практиках.
Я бы добавил еще несколько факторов:
— в 1970-х и 1980-х количество кода, приходящегося на одного разработчика в проекте, было сильно поменьше нынешнего, да и сами проекты очень сильно выросли в объемах с тех пор;
— сейчас уровень переиспользования кода и объем использованных в проекте сторонних зависимостей кардинально увеличился. Грубо говоря и ты сам полагаешься на код, в который даже не заглядываешь никогда, и точно так же полагаются на твой код. Причем когда чужой код переиспользуется, то нередно он переиспользуется так, как автору и не снилось;
— за последние 40 лет было сильно размыто понятие "владелец" кода. Еще в начале-середине 1990-х, особенно на обломках СССР, нормальным было явление, когда за каждым членом команды был закреплен свой кусок кода, в который никто больше не заглядывал, то сейчас ситуация принципиально иная. Ты написал какой-то модуль, через неделю в нем уже куча правок от десятка коллег, а через месяц его куски растащили по другим местам проекта, а оставшуюся часть основательно переделали;
— программисты стали гораздо чаще менять места работы и переходить из одной предметной области в другую. Сегодня ты склеиваешь картинки и наносишь на них водяные знаки, завтра пишешь бэкенд для Интернет-магазина, послезавтра сапортишь in-memory database.
Все это ведет к тому, что в 1989-ом можно было спокойно написать набор специализированных подпрограмм для расчета разводки печатных плат, в которые никто не заглядывал, и которые использовались только тобой и еще парой-тройкой таких же как ты узких специалистов. Сейчас уже сильно не так.
PS. Все перечисленное в дополнение к вашим доводам, а не попытка с вами поспорить.
Здравствуйте, so5team, Вы писали:
S>Более того, этот персонаж любить обрывать разговор на полуслове. Типа мне стало скучно, а вопросов ваших я в силу специфичности своего опыта не понимаю, поэтому "давай, до свиданья!"
S>Пытаешься выяснить у человека обстоятельства, а он тупо отморозился и все. Остаешься в недоумении: а тему-то зачем открывать, если затем сходу в кусты и не отсвечиваешь?
Только поулучается: "Мне стало скучно, поэтому пойду подниму эту же тему в другом месте".
--
Справедливость выше закона. А человечность выше справедливости.
Здравствуйте, alpha21264, Вы писали:
A>Миссионеры бывают не только религиозные, миссионеры бывают так же и компьютерные. A>И чаще всего они пропагандируют какую-нибудь дурь. (Я имею в виду не только христиан).
A>Ну вот например, они пропагандируют...
Из разговра с вами стало понятно, что ряд нововведений в С++ вы считаете бесполезными.
А вот каково ваше отношение к [[nodiscard]]?
Можно предположить, что "нормальные программисты" (tm) никогда не игнорируют возвращаемые функциями/методами значения. И посему [[nodiscard]] -- всего лишь бесполезный "синтаксический оверхэд" (c)
Здравствуйте, so5team, Вы писали:
S>А вот каково ваше отношение к [[nodiscard]]?
Так очевидно же. nodiscard же только генерирует предупреждения в случае чего, а предупреждения "мы" игнорируем.
Здравствуйте, serg_joker, Вы писали:
S>>А вот каково ваше отношение к [[nodiscard]]? _>Так очевидно же. nodiscard же только генерирует предупреждения в случае чего, а предупреждения "мы" игнорируем.
Чего-то подобного я и ожидаю, но хотелось бы все-таки послушать начальника транспортного цеха...
PS. Сам уже не понимаю как мы до C++17 без этого атрибута жили. Благо компиляторы позволяли его использовать даже в рамках C++11 и C++14.
Здравствуйте, serg_joker, Вы писали:
_>Какие "модные" практики ты видишь такие, что ухудшают качество программистов? Именно практики как таковые, а не их догматическое и чисто формальное использование. Вот так, чтоб практику отменить — и программисты стали лучше.
Ну, например, сейчас больше принято полагаться на тестовое покрытие как критерий корректности кода, чем на какое-либо умственное обоснование. Что приводит к утрате умения рассуждать о корректности кода головой (и заодно снижает степень понимания кода, как своего, так и чужого, и степень понимания используемого API).
Повсеместная практика code review двояка по последствиям. С одной стороны, это хорошо, если код посмотрит другая пара глаз (хотя зачастую ревьювер смотрит код весьма формально, у него и своей работы полно). С другой, это задерживает путь прохождения изменений в репозиторий. Автор коммита вынужден, в ожидании ревью, переключаться на другие задачи. Это рассеивает внимание.
Ну и т.д. Я описал общее ощущение, к серьёзной дискуссии на эту тему я не готов.
Pzz>>Опенсорс бывает разный. У libtiff огромная пользовательская база, и написан он вполне приличным и уважаемым человеком. А код там такой, что хочется его развидеть, пока глаза не отвалились. _>Ну вот я его заверну аккуратно, чтобы ворнингами не сыпало, и буду пользоваться. Большая пользовательская база такой низкоуровневой хрени — это уже некая гарантия качества (на уровне предоставляемого функционала). Что там внутри меня мало интересует до тех пор, пока мне не нужно будет колупаться в исходниках.
Его кормят снаружи данными в весьма сложном и нетривиальном формате. Тебе его придется в контейнер обернуть, чтобы быть уверенным, что он в тебя не выстрелит.
Здравствуйте, so5team, Вы писали:
Pzz>>Ну а как люди пишут крупные системы на JS или Питоне? Там с проверками еще сильно хуже.
S>С какими именно проверками? S>Так-то JS и Python -- это языки со строгой типизацией, в отличии от C или C++. S>В них по ошибке строку невозможно выдать за double.
JS-то, как раз, без проблем даст сложить строку с числом
Питон да, не даст.
Но оба языка дадут положить в массив или словарь значение неподходящего типа (например, по ошибке, не поле какого-то объекта, а ведь объект целиком). И выстрелит это в момент использования.
S>А именно крупные системы пишут с трудом и за счет тотального тестирования. Не зря же сама мода на unit-тестирование в индустрию пришла из extreme programming, который возник из опыта разработки большого проекта на динамически-типизированном SmallTalk.
Мой тезис: отсутствие проверок усложняет разработку, но не делает её невозможной.
Я к тому, что всяческие статические проверки — это хорошо. Но не надо по их поводу истерику устраивать.
Кстати, моё личное мнение: динамически типизованные языки плохо подходят для первоначального обучения программированию. Статическая типизация не только следит за руками, но еще и приучает систематически думать наперёд. Если начинать с динамически типизованного языка, в котором "всё можно", этот навык не развивается.
A>Допустим у нас есть несколько (ну допустим пять) величин: метры, килограммы, секунды, ньютоны и джоули. A>Да, их нельзя складывать с друг с другом. Но их можно(нужно) умножать и делить. A>Таким образом, чтобы написать формулу, которая содержит три величины, нам нужно иметь 3*(5+1)*(5+1) типов данных. A>То есть 36 типов для результатов умножения (килограмм*метр), A>И 2*36 типов для деления килограмм/метр и метр/килограмм. A>То есть, что-то около сотни типов. (Точная цифра =108)
Возможности:
1. Независимые типы данных, такие как mass и length. Присвоить один другому нельзя — будет ошибка компиляции.
2. Автоматическое конвертирование величин одной и той же размерности из одной системы единиц в другую. К примеру, присвоив килограммам один грамм, в результирующей переменной (si::mass) обнаружим 0.001. Вычисление коэффициентов преобразования производится в compile time.
3. Контроль за корректностью формул со стороны компилятора. Так, если ускорению попытаться присвоить результат деления длины на время, возникнет ошибка компиляции. С моей точки зрения, это наиболее важное свойство моего кода. Особенно это заметно на трехэтажных формулах, где очень легко потерять из виду, какая же в результате получается размерность. В случае использования моего кода подобного рода ошибки полностью исключаются.
Здравствуйте, so5team, Вы писали:
Pzz>>как критерий корректности кода, чем на какое-либо умственное обоснование
S>А это вообще как?
S>Некто alpha21264 или Pzz порассуждал, начирикал что-то на бумажке и заключил "код корректен"?
Давай так. Или ты не будешь хамить. Или я не буду с тобой разговаривать.
Мне интересен разговор с коллегами в формате обмена знаниями, мнениями и опытом, а не в формате кунания друг друга головой в чан с говном.
S>Или же это "умственное обоснование" должно быть как-то формально быть записано, да еще и так, чтобы проходить хоть какую-то верификацию.
Мне как-то помнится пришлось начальника припрячь оторваться от его начальничьих дел и выслушать моё формальное доказательство сложного куска кода. Но это хорошо, что под рукой был человек с математическим образованием, способный поддерживать разговор на таком уровне.
Здравствуйте, Pzz, Вы писали:
Pzz>Ну и т.д. Я описал общее ощущение, к серьёзной дискуссии на эту тему я не готов.
Да я тоже.
Ну вот мне кажется, что всё-таки многие практики, будучи приложены к абизянам, безопасность не ухудшают.
Не-абизяны на то и не-абизяны, чтобы думать, где чего применять, а где нет. Ну и стараться не работать там, где практики применяются бездумно и формально.
Pzz>Его кормят снаружи данными в весьма сложном и нетривиальном формате. Тебе его придется в контейнер обернуть, чтобы быть уверенным, что он в тебя не выстрелит.
Убедил, всеми силами буду стараться держаться от него подальше
Здравствуйте, Pzz, Вы писали:
S>>Так-то JS и Python -- это языки со строгой типизацией, в отличии от C или C++. S>>В них по ошибке строку невозможно выдать за double.
Pzz>JS-то, как раз, без проблем даст сложить строку с числом
Я вообще не о том говорил. В C и C++ вы можете скастовать void* к double* и начать работать с double, хотя по факту за void* был спрятан char*.
Pzz>Но оба языка дадут положить в массив или словарь значение неподходящего типа (например, по ошибке, не поле какого-то объекта, а ведь объект целиком). И выстрелит это в момент использования.
Поэтому нормальный проект на языке с динамической типизацией невозможен без плотного покрытия тестами.
И, что характерно, именно это и делают.
Pzz>Мой тезис: отсутствие проверок усложняет разработку, но не делает её невозможной.
Pzz>Я к тому, что всяческие статические проверки — это хорошо. Но не надо по их поводу истерику устраивать.
"Истерику", как вы выразились, устраивают не по поводу отсутствия статических проверок, а по поводу сознательного отказа некоторых индивидов от их применения.
Казалось бы, в твоем распоряжении инструмент, который позволяет забесплатно и автоматически снять с тебя нехилый кусок головной боли.
Но ты от этого отказываешься, да еще и кичишься этим.
Что уже странно, по меньшей мере.
Еще более странно, что не расказывают а чем же компенсируют отсутствие такого контроля.
Моя версия, которую, к сожалению, не представляется возможным проверить -- это работа alpha21264 над небольшой и стабильной кодовой базой в небольшой команде. Да еще и, вероятно, в условиях, когда сама прикладная задача достаточно старая и хорошо изученная. И в которой, могу предположить, математика и физика на пару порядков важнее чем код, в который превращаются итоговые формулы.
Здравствуйте, serg_joker, Вы писали:
Pzz>>Ну и т.д. Я описал общее ощущение, к серьёзной дискуссии на эту тему я не готов. _>Да я тоже. _>Ну вот мне кажется, что всё-таки многие практики, будучи приложены к абизянам, безопасность не ухудшают. _>Не-абизяны на то и не-абизяны, чтобы думать, где чего применять, а где нет. Ну и стараться не работать там, где практики применяются бездумно и формально.
Проблема в том, что человек — существо высокосоциальное. И если он будет работать в команде, состоящей в основном из обезьян, с соответствующими практиками, ну, в конце концов он и сам превратится в обезьяну.
Pzz>>Его кормят снаружи данными в весьма сложном и нетривиальном формате. Тебе его придется в контейнер обернуть, чтобы быть уверенным, что он в тебя не выстрелит. _>Убедил, всеми силами буду стараться держаться от него подальше
А куда ты денешься, PDF использует евонные кодеки.
Здравствуйте, so5team, Вы писали:
S>Из разговра с вами стало понятно, что ряд нововведений в С++ вы считаете бесполезными.
Большую часть того, что появилось после 2010 года.
Если уже даже сам Страуструп говорит, что он знает С++ только на 80%...
Керниган говорил Ричи, когда тот предлагал внести в язык очередную фичу, — если тебе нужен PL/1 ты знаешь, где его взять.
Сейчас современный С++ намного превосходит тот самый монстрообразный PL/1.
Это неправильно. Язык должен быть простым, чтобы программист думал не над языком, а над задачей.
S>А вот каково ваше отношение к [[nodiscard]]?
S>Можно предположить, что "нормальные программисты" (tm) никогда не игнорируют возвращаемые функциями/методами значения. И посему [[nodiscard]] -- всего лишь бесполезный "синтаксический оверхэд" (c)
Ну в общем да. Один раз в жизни это предупредит меня об ошибке, а всё остальное время это будет засирать код.
Слова "один раз в жизни" достаточно ярко выделены?
И что мне делать, если мне действительно не нужно возвращаемое значение? Заводить неиспользуемую переменную?
Или есть какое-то специальное слово "мне действительно не нужно возвращаемое значение"?
Писать вот так?
(void)ваша_дурацкая_функция();
А кроме того, это просто уродливо. Скажите, ну вот зачем тут [[nodiscard]] сразу двое квадратных скобок?!
Здравствуйте, Pzz, Вы писали:
S>>Некто alpha21264 или Pzz порассуждал, начирикал что-то на бумажке и заключил "код корректен"?
Pzz>Давай так. Или ты не будешь хамить.
Или вы перестанете выискивать черную кошку в черной комнате.
S>>Или же это "умственное обоснование" должно быть как-то формально быть записано, да еще и так, чтобы проходить хоть какую-то верификацию.
Pzz>Мне как-то помнится пришлось начальника припрячь оторваться от его начальничьих дел и выслушать моё формальное доказательство сложного куска кода. Но это хорошо, что под рукой был человек с математическим образованием, способный поддерживать разговор на таком уровне.
Давайте переведем вашу историю в более содержательное русло.
Вы с помощью некого формального аппарата вывели доказательство корректности кода.
Далее вы устным образом рассказали это доказательство и оно было принято.
Пока все верно?
Если да, то было ли это доказательство зафиксированно в неком виде, позволяющем провести формальную верификацию посредством программных инструментов?
Здравствуйте, so5team, Вы писали:
S>Давайте переведем вашу историю в более содержательное русло.
Давайте.
S>Если да, то было ли это доказательство зафиксированно в неком виде, позволяющем провести формальную верификацию посредством программных инструментов?
Здравствуйте, alpha21264, Вы писали:
A>Это неправильно. Язык должен быть простым, чтобы программист думал не над языком, а над задачей.
При этом есть мнение, что сложность инструмента должна быть сопоставима со сложностью решаемой задачи, иначе образуется слишком большой семантический разрыв.
A>Ну в общем да. Один раз в жизни это предупредит меня об ошибке, а всё остальное время это будет засирать код. A>Слова "один раз в жизни" достаточно ярко выделены?
Да.
A>И что мне делать, если мне действительно не нужно возвращаемое значение?
В стиле современного C++ это должно записываться так:
std::ignore = some_func();
Однако, было бы интересно узнать, а в каких-таких ситуациях можно игнорировать помеченное как [[nodiscard]] значение?
Я сходу могу назвать всего две:
1. Когда кто-то бездумно расставил [[nodiscard]]. По принципу "прикажи дураку богу молиться, он и лоб расшибет".
2. В unit-тестах, когда на возникающие ошибки реально пофиг.
В продакшен коде, наверное, вспоминаются разве что отдельные noexcept-контексты, вроде деструкторов или секций catch, в которых нужно сделать очистку ресурсов или откат ранее выполненных операций. И тогда, т.к. мы не можем бросать исключения, приходится игнорировать коды возврата у вызываемых функций/методов.
Но тогда std::ignore как раз указывает, что мы поступаем так намеренно.
Здравствуйте, Pzz, Вы писали:
S>>Если да, то было ли это доказательство зафиксированно в неком виде, позволяющем провести формальную верификацию посредством программных инструментов?
Pzz>Нет.
А теперь вопрос: через какое-то время после вас этот код был модифицирован Васей Пупкиным. Что поможет Васе понять, что он ничего не поломал?
Упарывание юнит-тестами имеет свои негативные стороны, но оно хотя бы решает проблему подобных проверок без привлечения механизмов автоматической формальной верификации.
Здравствуйте, so5team, Вы писали:
Pzz>>JS-то, как раз, без проблем даст сложить строку с числом
S>Я вообще не о том говорил. В C и C++ вы можете скастовать void* к double* и начать работать с double, хотя по факту за void* был спрятан char*.
Не, ну это всё же специально стараться надо. Случайно так не ляпнешь.
Кстати, union — более удобный инструмент, чтобы так насвистеть, чем кастирование через void*
S>Казалось бы, в твоем распоряжении инструмент, который позволяет забесплатно и автоматически снять с тебя нехилый кусок головной боли. S>Но ты от этого отказываешься, да еще и кичишься этим.
Сколько лет ушло у линуксячего ядра, чтобы наконец вычистить предупреждения? (да и то я не уверен, что их вычистили целиком).
S>Моя версия, которую, к сожалению, не представляется возможным проверить -- это работа alpha21264 над небольшой и стабильной кодовой базой в небольшой команде. Да еще и, вероятно, в условиях, когда сама прикладная задача достаточно старая и хорошо изученная. И в которой, могу предположить, математика и физика на пару порядков важнее чем код, в который превращаются итоговые формулы.
Можно чуть-чуть обобщить.
Есть класс задач, в которых именно прикладной уровень обладает высокой степенью сложности. Например, из-за сложной физики-математики, как в вашем примере. Или из-за алгоритмической сложности. Например, задача написания оптимизирующего компилятора. Заметим, в ней именно "математика" сложна.
В таких задачах люди типа даже не Альфы (про него, живого, мы мало чего знаем), а описанной вами чуть выше модели альфы вполне могут работать.
gcc внутри, кстати, примерно так и написан. Но назвать его говнокодом у меня как-то язык не поворачивается. Все-таки, большая часть мировой кодовой базы вполне успешно через него проходит и выдаёт на выходе вполне работоспособный машинный код.
Здравствуйте, so5team, Вы писали:
S>А теперь вопрос: через какое-то время после вас этот код был модифицирован Васей Пупкиным. Что поможет Васе понять, что он ничего не поломал?
Да, это болезненный вопрос. К тому же, я имею тенденцию сочетать алгоритмическую сложность с аккуратным оформлением кода. Это наводит Васю Пупкина на (ложную) мысль, что он в этом коде способен разобраться.
Даже рантайм-проверки не помогают. Вася их убирает, когда они срабатывают, скотина такая.
S>Упарывание юнит-тестами имеет свои негативные стороны, но оно хотя бы решает проблему подобных проверок без привлечения механизмов автоматической формальной верификации.
Говорят, когда в машинах массво появились ремни безопасности, люди не стали реже гибнуть на дорогах. Люди стали быстрее ездить.
Я не против тестов. Но к ним что-то еще должно прилагаться.
Здравствуйте, Pzz, Вы писали:
_>>Не-абизяны на то и не-абизяны, чтобы думать, где чего применять, а где нет. Ну и стараться не работать там, где практики применяются бездумно и формально.
Pzz>Проблема в том, что человек — существо высокосоциальное. И если он будет работать в команде, состоящей в основном из обезьян, с соответствующими практиками, ну, в конце концов он и сам превратится в обезьяну.
В целом согласен (с оговорками про высокосоциальность прям каждого индивидума), поэтому выделенная часть. Ну и вообще выбор коллектива — это очень важно. Если есть такая возможность, то с неумными людьми лучше не работать, жизнь слишком коротка для этого. И уж точно не работать, если неумные люди будут активно влиять на то, как придётся тебе. В том числе, и особенно, если неумные люди — начальство.
_>>Убедил, всеми силами буду стараться держаться от него подальше Pzz>А куда ты денешься, PDF использует евонные кодеки.
Я имел ввиду работу с библиотекой как программист.
Здравствуйте, Pzz, Вы писали:
S>>Я вообще не о том говорил. В C и C++ вы можете скастовать void* к double* и начать работать с double, хотя по факту за void* был спрятан char*.
Pzz>Не, ну это всё же специально стараться надо. Случайно так не ляпнешь.
Да сколько угодно как только народ начинает пропихивать информацию через void*.
Например, если есть callback-и с дополнительным параметром userData, который как раз void* обычно и является.
S>>Казалось бы, в твоем распоряжении инструмент, который позволяет забесплатно и автоматически снять с тебя нехилый кусок головной боли. S>>Но ты от этого отказываешься, да еще и кичишься этим.
Pzz>Сколько лет ушло у линуксячего ядра, чтобы наконец вычистить предупреждения? (да и то я не уверен, что их вычистили целиком).
Меня не интересует ядро Linux-а, тем более, что это пример проекта без дедлайнов и с неограниченными ресурсами.
Pzz>В таких задачах люди типа даже не Альфы (про него, живого, мы мало чего знаем), а описанной вами чуть выше модели альфы вполне могут работать.
Могут. Только если в таких задачах намечается тенденция к росту кодовой базы, то взгляды персонажей вроде Альфы очень быстро приводят ее в состояние говнокода.
Здравствуйте, serg_joker, Вы писали:
_>>>Убедил, всеми силами буду стараться держаться от него подальше Pzz>>А куда ты денешься, PDF использует евонные кодеки. _>Я имел ввиду работу с библиотекой как программист.
Других для C/C++ нет. Если понадобиться об TIFF мараться, придётся с этой.
Здравствуйте, so5team, Вы писали:
Pzz>>Не, ну это всё же специально стараться надо. Случайно так не ляпнешь.
S>Да сколько угодно как только народ начинает пропихивать информацию через void*. S>Например, если есть callback-и с дополнительным параметром userData, который как раз void* обычно и является.
Хех. Вы не застали времена, когда в UNIX было принято пропихивать информацию через unsigned int.
На VAX-е то он был 32 бита, как и указатель.
Я в те времена писал под MS-DOS. Unsigned int для меня был 16-битным, а указатель, в large модели — 32-битным.
Здравствуйте, 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. Если в заголовках языка объявлено что кг*м/(с*с) — это сила и она имеет собственную букву, ну окей, компилятор узнаёт и 'алиас' и что под ним. Но если нет обозначения — пусть так и таскает из формулы в формулу циферку и её размерности. Авось где что посокращается. Техническая реализация таких алиасов так-то не проблема, проблема то, что создатели языков и думать не хотят про какие-то типы, кроме тех что нужны для создания компилятора
Тут главное чтобы язык не дай бог не получил "стандартную библиотеку физических типов", а позволял гибко объявлять это всё внутри проекта. Потому что в разных областях физики или химии одинаковые буквы могут значить ну очень разное.
Здравствуйте, alpha21264, Вы писали:
A>6) so5team! Ты прочитал фразу (в другом сообщении), что поскольку в реальных программах большинство параметров const, A>то слово const лучше убрать, а использовать не-const. Тогда контроль за параметрами останется, а мусор исчезнет.
Это верное замечание, кстате.
Из-за этого существуют языки, где по умолчанию const, а mutable надо прописывать явно.
A>Мне не нужны модификаторы const, потому что я не делаю такого рода ошибок. Мне костыль не нужен.
Лично мне const помогает реже совершать описку "=" вместо "==". ))
Здравствуйте, vdimas, Вы писали:
V>Это верное замечание, кстате.
Разговор шел конкретно в контексте языка C++.
Если кто-то может в очередном стандарте поменять так, что в C++ все ссылки и указатели в параметрах автоматически станут ссылками/указателями на const, то я буду очень и очень удивлен такому развитию событий.
Здравствуйте, vdimas, Вы писали:
A>>Мне не нужны модификаторы const, потому что я не делаю такого рода ошибок. Мне костыль не нужен.
V>Лично мне const помогает реже совершать описку "=" вместо "==". ))
Я для таких случаев константу пишу слева, а переменную справа.
Здравствуйте, vdimas, Вы писали:
A>>Мне не нужны модификаторы const, потому что я не делаю такого рода ошибок. Мне костыль не нужен.
V>Лично мне const помогает реже совершать описку "=" вместо "==". ))
Для этого в gcc существует отдельное предупреждение.
Я в Go пошли еще дальше. В этом языке "=" не является оператором (его нельзя использовать в выражениях) а условие if-а и цикла обязано быть bool (int не является bool и к bool не приводится).
Здравствуйте, alpha21264, Вы писали:
A>5) so5team! Ты прочитал фразу (в другом сообщении), что из-за бесполезных варнингов теряются полезные?
Эта фраза вызывает удивление и непонимание.
Потому, что в тех проектах, в которых я устанавливаю правила (или способен влиять на установленные правила), количество бесполезных варнингов равно нулю. Поэтому все оставшиеся — полезные.
Полагаю, другие участники дискуссии имеют схожий опыт.
А ты почему-то не такой, как все. Этот факт вызывает удивление и беспокойство.
Здравствуйте, alpha21264, Вы писали:
V>>Лично мне const помогает реже совершать описку "=" вместо "==". )) A>Я для таких случаев константу пишу слева, а переменную справа.
Не всегда сравниваются константы.
И да, константа не сильно отличается по семантике от const-переменной, особенно в инлайных ф-ях при распространении констант вдоль иерархии вызовов. ))
Здравствуйте, Pzz, Вы писали:
V>>Лично мне const помогает реже совершать описку "=" вместо "==". )) Pzz>Для этого в gcc существует отдельное предупреждение.
Согласен. Достаточно взять в двойные скобки if((a=b)) чтобы использовать присвоение как bool-выражение.
Pzz>Я в Go пошли еще дальше. В этом языке "=" не является оператором (его нельзя использовать в выражениях) а условие if-а и цикла обязано быть bool (int не является bool и к bool не приводится).
У этой медали две стороны. ))
Особенно учитывая возможность переопределения операторов в С++.
Здравствуйте, vdimas, Вы писали:
V>У этой медали две стороны. )) V>Особенно учитывая возможность переопределения операторов в С++.
Если бы директором был я, я бы сильно ограничил возможности переопределения операторов. В частности, я бы требовал, чтобы операторы сравнения, как и операторы || и && всегда возвращали bool. И, вероятно, разрешил бы только переопределять операторы <, <= и ==, считая, что > — это отрицание <= и т.п. (если честно, я бы пошел и дальше, и ограничился бы только переопределением < и ==, с автовыводом <=, но ведь в C++ нельзя напрасно терять и такта процессора...).
Здравствуйте, vdimas, Вы писали:
V>>>Лично мне const помогает реже совершать описку "=" вместо "==". )) A>>Я для таких случаев константу пишу слева, а переменную справа.
V>Не всегда сравниваются константы.
Здравствуйте, Pzz, Вы писали:
Pzz>Если бы директором был я, я бы сильно ограничил возможности переопределения операторов. В частности, я бы требовал, чтобы операторы сравнения, как и операторы || и && всегда возвращали bool. И, вероятно, разрешил бы только переопределять операторы <, <= и ==, считая, что > — это отрицание <= и т.п. (если честно, я бы пошел и дальше, и ограничился бы только переопределением < и ==, с автовыводом <=, но ведь в C++ нельзя напрасно терять и такта процессора...).
В С++ можно терять такты процессора, если задача позволяет.
Но если задача не позволяет, то должен быть способ выразить всё то же самое, но эффективно. Предложенное тобой ограничение по операторам может очевидным образом этому препятствовать.
Здравствуйте, serg_joker, Вы писали:
_>В С++ можно терять такты процессора, если задача позволяет. _>Но если задача не позволяет, то должен быть способ выразить всё то же самое, но эффективно. Предложенное тобой ограничение по операторам может очевидным образом этому препятствовать.
Может препятствовать.
Я хочу сказать, что очень бы было желательно, чтобы операции сравнения были алгебраичны. В том смысле, что a < b равносильно b > a и равносильно !(a >= b). И из a < b && b < c следует, что a < c.
И это важнее, чем несколько тактов процессора.
Очень редко бывает так, чтобы требования быстроты и сложности применялись к коду одновременно. И там, где есть требование быстроты, можно поднапрячься и обойтись без перегрузки операторов — скорее всего, речь идёт о небольшой доле кода.
А вот в сложном коде язык должен помогать, а не усложнять жизнь. И ради этого можно пожертвовать несколькими тактами процессора.
Здравствуйте, hi_octane, Вы писали:
_>Тут главное чтобы язык не дай бог не получил "стандартную библиотеку физических типов", а позволял гибко объявлять это всё внутри проекта. Потому что в разных областях физики или химии одинаковые буквы могут значить ну очень разное.
Здравствуйте, Pzz, Вы писали:
Pzz>Очень редко бывает так, чтобы требования быстроты и сложности применялись к коду одновременно. И там, где есть требование быстроты, можно поднапрячься и обойтись без перегрузки операторов — скорее всего, речь идёт о небольшой доле кода.
Ну вот возьмём простой класс — std::string, хочу я его во всяких контейнерах держать, сравнивать и вообще не церимониться.
и есть у меня код:
if (s1 > s2) { ... }
вот ты бы хотел, чтобы условие разворачивалось в (!(s1 < s2 ) || (s1 == s2)) с удвоением сложности?
или чтобы нужно было писать gteaterthan(s1,s2) ?
С моей точки зрения, код не выглядит слишком уж экзотичным. Во вполне прикладном и высокоуровневом коде сравниваются строки, контейнеры, кортежи, варианты, опшналы и много чего другого, я бы не хотел, чтобы мне вместо читабельных математических символов пришлось использовать что-то другое.
Но и плата за !((v1 < v2) || (v1 == v2)) — это не несколько тактов.
Здравствуйте, serg_joker, Вы писали:
_>вот ты бы хотел, чтобы условие разворачивалось в (!(s1 < s2 ) || (s1 == s2)) с удвоением сложности?
Удобно когда есть дефолты. Т.е. для типичной структуры с набором полей это не требуется. А там где есть экономия — там делаем более оптимальные имплементации.
Кстати, этот самый <=> как раз это и делает, как я понял.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ·, Вы писали:
·>Удобно когда есть дефолты. Т.е. для типичной структуры с набором полей это не требуется. А там где есть экономия — там делаем более оптимальные имплементации.
Тут вопрос что такое "типично". Если структура содержит ту же самую std::string, то вся аргументация про удвоение сложности остаётся в силе. А современная "типичная" структура зачастую содержит что-то такое тяжёлое.
Как по мне, очень опасное с т.з. производительности поведение по умолчанию.
·>Кстати, этот самый <=> как раз это и делает, как я понял. <=> относится к этой же проблематике, но делает не совсем это. Для вычисления любого из синтезированных операторов требуется один вызов <=>.
Здравствуйте, ·, Вы писали:
·>Удобно когда есть дефолты. Т.е. для типичной структуры с набором полей это не требуется. А там где есть экономия — там делаем более оптимальные имплементации. ·>Кстати, этот самый <=> как раз это и делает, как я понял.
Именно так.
Поэтому, в случае недефолта иногда выгоднее по старинке расписать отдельно операции <, > и т.д., т.к. сравнение на простое меньше иногда в 2-3 раза дешевле полноценного <=>.
Здравствуйте, Marty, Вы писали:
_>>Тут главное чтобы язык не дай бог не получил "стандартную библиотеку физических типов", а позволял гибко объявлять это всё внутри проекта. Потому что в разных областях физики или химии одинаковые буквы могут значить ну очень разное.
M>А namespace'ы на что?
Здравствуйте, alpha21264, Вы писали:
_>>>Тут главное чтобы язык не дай бог не получил "стандартную библиотеку физических типов", а позволял гибко объявлять это всё внутри проекта. Потому что в разных областях физики или химии одинаковые буквы могут значить ну очень разное.
M>>А namespace'ы на что?
A>Чтобы запутать себя и других.
команды по тяге двигателя в программном обеспечении Mars Climate Orbiter использовали единицу измерения силы ньютон (международная система единиц (СИ)), в то время как программное обеспечение на Земле, которое создавало эти команды, использовало британскую единицу измерения (фунт-сила)[1].
Если не ошибаюсь, там ошиблись примерно из-за того, что "все учли": Британцы учли, что пишут для американцев, поэтому перевели числа в американские единицы измерения. А американцы учли, что для них писали британцы, и решили, что они в британских единицах.
И еще. Уже 21 век, но по-прежнему происходят косяки в ПО, из-за путаницы в кодировках текстовых файлов. И попадаются видеофайлы с неправильным aspect ratio (сплющенные).
Хоть, к статической типизации это уже не имеет отношения. Но здесь есть нерешенные проблемы. Хотя здесь последствия от багов не большие.
Здравствуйте, serg_joker, Вы писали:
_>вот ты бы хотел, чтобы условие разворачивалось в (!(s1 < s2 ) || (s1 == s2)) с удвоением сложности? _>или чтобы нужно было писать gteaterthan(s1,s2) ?
Нет. Я ведь ясно написал , я не хочу, чтобы операции сравнения стали вдвое дороже. Я хочу, чтобы они были алгебраичны. И чтобы на это мог рассчитывать в первую очередь человек, но и компилятор тоже.
Как это технически реализовать, я не знаю. Возможно, C++ way — это добавить операцию сравнения с тремя вариантами ответа (пресловутую <=>), из коториой компилятор бы вывел все остальные. Смущает в этом подходе то, что C++ старается наделить глубоким смыслом все возможные сочетания непечатных символов, напоминающих шум из модема при отсутствии error correction.
Здравствуйте, Marty, Вы писали:
M>>>А namespace'ы на что?
A>>Чтобы запутать себя и других.
M>Яс но. Вопросов больше не имею
Ну ты вообще слегка недогадлив.
И склонен к впаданию в ступор, если встретился немного нестандартный контекст.
Пересечение namespace'ов — это как раз на эту тему.
Здравствуйте, Nuzhny, Вы писали:
A>>Но у всего есть цена. Так давайте посмотрим на цену.
N>У европейцев спутник "Ариан-5" упал когда-то, с типом данных не угадали. Стоит ли работы программиста? N>Или сбой навигации у самолётов над Мёртвым морем, когда высота была отрицательной. N>Есть области, где стоит платить такую цену.
А есть области, где не стоит.
В данном случае это был видеоредактор для роликов Ю-туба.
Здравствуйте, alpha21264, Вы писали:
A>А есть области, где не стоит.
Ой ли?
Один из самых запоминающихся кранчей по поиску бага был связан с тем, что в типа "бизнес-приложении" на Java имя пользователя и пароль пользователя для доступа к БД задавались обычными String-ами. Команда из 6 человек потратила полдня на поиск совершенно тупой ошибки, когда username и password перепутали местами.
Этой ошибки не было бы в принципе, если бы:
* язык программирования поддерживал strong typedef из коробки. Ну или хотя бы предоставлял возможности для дешевой реализации strong typedef своими руками (вот Java в прошлом этой возможности не предоставляла, а может и до сих пор);
* у программистов была привычка пользоваться strong typedef-ами. У подавляющего большинства из виденных мной такой привычки нет.
Если добавить сюда, например, то, что в C++ и в Си есть автоматическое и неявное преобразование между типами, то такие бездны открываюся, что просто ахтунг. Встречался код, в котором у людей double неявно к std::size_t приводился. И, типа, норм...
Здравствуйте, serg_joker, Вы писали:
_>и есть у меня код: _>
_>if (s1 > s2) { ... }
_>
_>вот ты бы хотел, чтобы условие разворачивалось в (!(s1 < s2 ) || (s1 == s2)) с удвоением сложности? _>или чтобы нужно было писать gteaterthan(s1,s2) ?
Зачем? Имея два оператора: == и <, остальной набор операторов компилятор мог бы сгенерировать автоматически безо всякого удвоения сложности:
bool operator != (const T& a, const T& b) { return !(a == b);}
bool operator > (const T& a, const T& b) { return b < a;}
bool operator <= (const T& a, const T& b) { return !(b < a);}
bool operator >= (const T& a, const T& b) { return !(a < b);}
по крайней мере, для total и weak ordering.
--
Справедливость выше закона. А человечность выше справедливости.
Здравствуйте, rg45, Вы писали:
R>Зачем? Имея два оператора: == и <, остальной набор операторов компилятор мог бы сгенерировать автоматически безо всякого удвоения сложности:
Здравствуйте, so5team, Вы писали:
A>>А есть области, где не стоит.
S>Ой ли?
S>Один из самых запоминающихся кранчей по поиску бага был связан с тем, что в типа "бизнес-приложении" на Java имя пользователя и пароль пользователя для доступа к БД задавались обычными String-ами. Команда из 6 человек потратила полдня на поиск совершенно тупой ошибки, когда username и password перепутали местами.
Вот этот пример какое имеет отношение к обсуждаемой теме?
Если для поиска такой тупой ошибки нужно 6 человек и полдня, то тут дело не в языке программирования.
Мне кажется, что у кого-то руки из жопы.
S>Этой ошибки не было бы в принципе, если бы...
Я подозреваю, что абсолютно в любой системе имя пользователя и пароль будут стрингами.
Не, если в команде заведётся какой-нибудь миссионер...
А вот есть такие ошибки, когда путают плюс и минус. Или икс и игрек.
Нет ли какого-нибудь продвинутого костыля для таких случаев?
Ну вот чтобы в формуле программист плюс и минус не перепутал.
Мне очень надо. Ну пожалуйста!
S>Если добавить сюда, например, то, что в C++ и в Си есть автоматическое и неявное преобразование между типами, то такие бездны открываюся, что просто ахтунг. Встречался код, в котором у людей double неявно к std::size_t приводился. И, типа, норм...
Не понимаю, что тебя расстроило. Плавающая точка всегда приводилась к целому.
Всегда — это с 60-х годов, когда плавающая точка вообще появилась.
Здравствуйте, alpha21264, Вы писали:
S>>Один из самых запоминающихся кранчей по поиску бага был связан с тем, что в типа "бизнес-приложении" на Java имя пользователя и пароль пользователя для доступа к БД задавались обычными String-ами. Команда из 6 человек потратила полдня на поиск совершенно тупой ошибки, когда username и password перепутали местами.
A>Вот этот пример какое имеет отношение к обсуждаемой теме?
Самое прямое. Это все вариации на тему strong typedef, его отсутствия и (не) желания его использовать.
A>Если для поиска такой тупой ошибки нужно 6 человек и полдня, то тут дело не в языке программирования.
Эту-то ошибку хотя бы нашли. А вот разработчикам Mars Climate Orbiter не повезло.
A>Мне кажется, что у кого-то руки из жопы.
Они таковы у 99.9(9)% разработчиков. Поскольку я лично не видел еще ни одного (может быть кроме вас) кто бы не совершал ошибок, в том числе и совершенно дурацких, когда по невнимательности путают аргументы местами.
S>>Этой ошибки не было бы в принципе, если бы...
A>Я подозреваю, что абсолютно в любой системе имя пользователя и пароль будут стрингами. A>Не, если в команде заведётся какой-нибудь миссионер...
То они стрингами, к счастью, не будут.
A>А вот есть такие ошибки, когда путают плюс и минус. Или икс и игрек. A>Нет ли какого-нибудь продвинутого костыля для таких случаев?
Strong typedef rules them all!
A>Ну вот чтобы в формуле программист плюс и минус не перепутал.
Полагаю, все типы ошибок ловятся тестами.
Но если использование строгой типизации в коде позволяет совсем исключить какой их процент, то зачем от этого отказываться?
A>Не понимаю
Это не удивительно. У меня есть сомнения, что вы вообще в программировании что-то понимаете.
A>Плавающая точка всегда приводилась к целому.
Округление в какую сторону при неявных преобразованиях double в size_t идет?
Актуально ли это для конкретной задачи или правильно делать округление в большую сторону? Или к ближайшему целому?
Вот какие вопросы должны волновать разработчика когда он вычисляет что-то в double, а затем неявно преобразует результат в size_t. И сам факт того, что эти преобразования делаются неявно в 99% случаев говорит о том, что разработчик об этом даже не задумывался.
Здравствуйте, so5team, Вы писали:
S>Один из самых запоминающихся кранчей по поиску бага был связан с тем, что в типа "бизнес-приложении" на Java имя пользователя и пароль пользователя для доступа к БД задавались обычными String-ами. Команда из 6 человек потратила полдня на поиск совершенно тупой ошибки, когда username и password перепутали местами.
Видел жавовые "приложения", представляю о чём речь. Дело там совсем не в стрингах.
Будь у них там стронг-тайпед дефс, то суммарные потери времени были бы куда больше. Ты смотришь только на эти 6 человеко-дней, а нужно смотреть на всю стоимость написания и поддержки системы. Так вот, там где перемудрили с тимпами, поддержка куда дороже чем в прямом си-стайл коде, особенно когда переборщили IoC. Там такие дебри бывают, что тупо полдня ищещешь, куда же искомая строчка в итоге отправляется. После такого кода плохеет от одного только слова "спринг". А спринг-бут чётко ассоциируется со словом "ПИДАРАС!".
Оверинженеринг, он такой!
зы: извините за крепкие выражения.
Всё сказанное выше — личное мнение, если не указано обратное.
Здравствуйте, so5team, Вы писали:
S>Один из самых запоминающихся кранчей по поиску бага был связан с тем, что в типа "бизнес-приложении" на Java имя пользователя и пароль пользователя для доступа к БД задавались обычными String-ами. Команда из 6 человек потратила полдня на поиск совершенно тупой ошибки, когда username и password перепутали местами.
Звучит как очень простой баг. Нарвался — быстро нашёл — покрыл тестом. Был бы специальный тип для логина и пароля — мудохался бы с преобразованиями весь срок жизни проекта
Нет такой подлости и мерзости, на которую бы не пошёл gcc ради бессмысленных 5% скорости в никому не нужном синтетическом тесте
Здравствуйте, T4r4sB, Вы писали:
TB>Звучит как очень простой баг. Нарвался — быстро нашёл — покрыл тестом. Был бы специальный тип для логина и пароля — мудохался бы с преобразованиями весь срок жизни проекта
Не мудохался бы. Если у вас очень частые преобразования между типами Username/Password и String, значит что-то делается не так.
И да, я помню ваши стоны о том, что в Rust-е вы запарились с библиотеками обработки изображений у которых разные int-ы. Не самый убедительный пример, который говорит, скорее, о выразительных возможностях Rust-а.
S>И да, я помню ваши стоны о том, что в Rust-е вы запарились с библиотеками обработки изображений у которых разные int-ы. Не самый убедительный пример, который говорит, скорее, о выразительных возможностях Rust-а.
не знаю как в Расте, но это вообще много где геморойное дело, т.к. в языке как правило есть дефолтный целочисленный тип, и он шире одной цветовой компоненты пиксела, и неявное расширение до него немного похоже на минное поле
Здравствуйте, koenig, Вы писали:
S>>И да, я помню ваши стоны о том, что в Rust-е вы запарились с библиотеками обработки изображений у которых разные int-ы. Не самый убедительный пример, который говорит, скорее, о выразительных возможностях Rust-а.
K>не знаю как в Расте, но это вообще много где геморойное дело, т.к. в языке как правило есть дефолтный целочисленный тип, и он шире одной цветовой компоненты пиксела, и неявное расширение до него немного похоже на минное поле
Без подробностей предметной области сложно рассуждать, но есть ощущение, что в достаточно выразительном языке можно было бы делать "универсальный" тип с условным i64 внутри, с автоматической конвертацией в этот тип из исходных u64 и u32 со всеми нужными проверками внутри. И, если так уж хочется, с автоматической конвертацией к u64/u32 (опять же с нужными проверками).
Тогда бы получилось что в самой прикладной логике все делается с "универсальным" типом, а операции конвертации присутствуют только в местах использования сторонних библиотек.
Прямая аналогия -- это как сейчас в C++ с std::chrono. Очень часто достаточно использовать условный std::chrono::steady_clock::duration и все. Мест же, где этот самый duration получается из исходных единиц (секунд, миллисекунд) или преобразуется в целевые единицы (секунды, миллисекунды) оказывается сильно меньше и все они отлично видны в коде.
Правда, T4r4sB от std::chrono плюётся, но это, возможно, уже и не лечится.
Здравствуйте, so5team, Вы писали:
S>И да, я помню ваши стоны о том, что в Rust-е вы запарились с библиотеками обработки изображений у которых разные int-ы. Не самый убедительный пример, который говорит, скорее, о выразительных возможностях Rust-а.
Который говорит о том, что надо головой думать, а не пытаться пихать эти доменно-ориентированные типы в каждую щель, произнося "доменный" с религиозным придыханием.
Нет такой подлости и мерзости, на которую бы не пошёл gcc ради бессмысленных 5% скорости в никому не нужном синтетическом тесте
Здравствуйте, koenig, Вы писали:
S>>И да, я помню ваши стоны о том, что в Rust-е вы запарились с библиотеками обработки изображений у которых разные int-ы. Не самый убедительный пример, который говорит, скорее, о выразительных возможностях Rust-а.
K>не знаю как в Расте, но это вообще много где геморойное дело, т.к. в языке как правило есть дефолтный целочисленный тип, и он шире одной цветовой компоненты пиксела, и неявное расширение до него немного похоже на минное поле
В Русте нет неявного расширения, поэтому если автор библиотеки не дружит с головой и применил как ему кажется более подходящий u32 вместо наиболее широкого и удобного i64, то при работе с библиотекой ты будешь постоянно писать "ехал каст через каст". Самое дикое что там на уровне языка размер массива (метод len) это usize, а значит даже просто написать v.len()-1 нельзя, это потенциально опасная операция. Повышает это читаемость, удобство отладки? Нет, конечно. Зато слабоумные евангелисты считают что использовать беззнаковый тип для размера это круто потому что сразу показывает что размер не может быть отрицательным, а если тебе надо вычитать из размера единичку, то в их зумерской жизни такого ни разу не надо было, значит ты тоже что-то делаешь не так.
Нет такой подлости и мерзости, на которую бы не пошёл gcc ради бессмысленных 5% скорости в никому не нужном синтетическом тесте
Здравствуйте, T4r4sB, Вы писали:
TB>Который говорит о том, что надо головой думать, а не пытаться пихать эти доменно-ориентированные типы в каждую щель, произнося "доменный" с религиозным придыханием.
Пихать тоже нужно уметь, для этого думать нужно еще больше, чем рассказывать страшилки про то, как плохо иметь размер контейнера в виде беззнакового.
TB> то при работе с библиотекой ты будешь постоянно писать "ехал каст через каст".
хотя бы будешь писать
а не иметь загадочный баг неизвестно где — надо еще догадаться, что проблема в касте, а потом его найти при том что в сорцах его нет, а потенциально он может быть много где.
Здравствуйте, koenig, Вы писали:
TB>> то при работе с библиотекой ты будешь постоянно писать "ехал каст через каст".
K>хотя бы будешь писать K>а не иметь загадочный баг неизвестно где — надо еще догадаться, что проблема в касте, а потом его найти при том что в сорцах его нет, а потенциально он может быть много где.
1. Я написал v.len()-1, компилятор даже слова не скажет что так бывает нельзя
2. Я написал (v.len() as isize — 1) as usize, аналогично
3. try_into().unwrap() пишут только шизы свихнувшиеся на идеологической корректности
Нет такой подлости и мерзости, на которую бы не пошёл gcc ради бессмысленных 5% скорости в никому не нужном синтетическом тесте
Здравствуйте, T4r4sB, Вы писали:
TB>Самое дикое что там на уровне языка размер массива (метод len) это usize, а значит даже просто написать v.len()-1 нельзя, это потенциально опасная операция.
И как в Расте выглядит уменьшение размера массива на 1?
Здравствуйте, T4r4sB, Вы писали:
TB>Вот у тебя одна либа генерирует изображение в котором выдает координаты u64 а другая которая сохраняет принимает координаты в u32. В русте такой шизы очень много. Я спрашивал типа сделайте int64 для всех и не трахайте голову, а мне втирают что это примитив обсешшон и он приведет к проблемам. Ну пока что проблемы с тем что приходится принудительно писать касты и разбирать отдельно случай вычитания большего из меньшего
Тут есть та тонкость, что в JPEG-е, например, на размер изображения отведено всего лишь 16 бит, и практические размеры при высоких (но вполне достижимых) разрешениях очень близко подходят к этой черте.
Поэтому тут надо аккуратно выплясывать, а не просто конвертнуть в подходящий универсально-широкий тип.
Здравствуйте, Pzz, Вы писали:
Pzz>Здравствуйте, T4r4sB, Вы писали:
TB>>Самое дикое что там на уровне языка размер массива (метод len) это usize, а значит даже просто написать v.len()-1 нельзя, это потенциально опасная операция.
Pzz>И как в Расте выглядит уменьшение размера массива на 1?
Уменьшение или вычисление в котором промежуточный результат это размер минус единица?
Если ты уверен что массив не пустой то просто v.len()-1. А если нет то дальше начинаются неприятные краевые случаи которые на нормальных знаковых типах разруливаются сами собой а на беззнаковых выстреливают в рантайме
Нет такой подлости и мерзости, на которую бы не пошёл gcc ради бессмысленных 5% скорости в никому не нужном синтетическом тесте
