Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Вообще, Вы с ним демонстрируете не инженерный, а чисто математический подход: "вот здесь может появиться бесконечность, а значит, что решение ни к черту не годится". И по барабану, что та бесконечность может появиться лишь при достаточно редком сочетании условий, а для большинства повседневных задач решение отлично подходит.
Инженеры должны уметь в вычислительную математику.
Если "вот здесь может появиться бесконечность", то здесь могут появиться гигантские нестабильности, шумы и ошибки.
Значит, надо поставить оградку, — что эта формула хорошо работает только в повседневных условиях.
Либо всё-таки переписать формулу.
Вон тут вчера прикалывались, что в кадастре есть земельные участки с отрицательной площадью.
Какой-то программист тоже, видимо, решил, что простая формула хорошо работает в простых случаях, и не стал ни валидировать входные данные, ни корректно обобщать формулу для случая произвольных входных данных.
Ладно, там попались откровенно неправильные результаты, а сколько земельных участков с положительной площадью посчитано неверно?
Или вот такая история. Программа интерполирует движение робота по траектории. Там несложные аффинные преобразования, всё ок... Вот только в этих преобразованиях фигурируют обратные матрицы (из одной системы координат в другую — и обратно).
Стоило вынести точку нуля координат на сотню километров (расстояние между гаражом и полигоном), матрица ещё не выродилась, но была близка к тому. И при обращении вылезли ошибки, интерполяция отрезка длиной в один метр превратилась в дугу радиусом сто метров. Вживую робот едет прямо, а в телеметрии его шарахает по всему полигону.
А вот нефиг было с обратными матрицами работать, взяли в качестве основной другую систему координат, в формуле остались только прямые матрицы.
Здравствуйте, B0FEE664, Вы писали:
BFE>·>У тебя тоже линейная запись. Но в двух местах параллельно. Насчёт "проверять каждое отдельное значение" — не понял. А как ещё? BFE>Функция GetObjectProps проверяет наличие всех значений внутри себя.
Круто, но зачем? Цель-то какая?
BFE>·>Не очень понял. Вот есть код const auto itFrequency = GetObjectPropAsDouble(..). Где что ты тут перегрузишь? В лучшем случае зашаблонить GetObjectProp<double>(..). BFE>GetValue(FromType, double& rToHere); BFE>GetValue(FromType, int& rToHere); BFE>... BFE>Короче, ровно так же, как сделано для std::from_chars
Это же неюзабельно. Напиши код, испольующий это, и станет очевидно.
А ещё потом тебе захочется дефолтные значения, на случай отсутствия проперти в json.
auto type = json.asString(s_name_Type, "default");
auto frequency = json.asDouble(s_name_Frequency, 440);
BFE>·>В json все значения — строки. Взять оттуда значение в виде числа — нужен парсинг. BFE>В Json строки и числа имеют разный формат записи. При этом, конечно, число можно записать в виде строки, но тогда проблемы Json заменяются проблемами проверки, что строка это именно число, а не нечто, похожее на число. Поэтому, например, у меня две разные функции asInt и toInt.
Угу. Но парсеры обычно не различают "42" и 42. JS, по большому счёту, тоже не различает.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ·, Вы писали:
BFE>>Функция GetObjectProps проверяет наличие всех значений внутри себя. ·>Круто, но зачем? Цель-то какая?
Отбросить неполные данные.
BFE>>·>Не очень понял. Вот есть код const auto itFrequency = GetObjectPropAsDouble(..). Где что ты тут перегрузишь? В лучшем случае зашаблонить GetObjectProp<double>(..). BFE>>GetValue(FromType, double& rToHere); BFE>>GetValue(FromType, int& rToHere); BFE>>... BFE>>Короче, ровно так же, как сделано для std::from_chars ·>Это же неюзабельно. Напиши код, испольующий это, и станет очевидно.
Собственно, коду уже написан и работает.
BFE>>В Json строки и числа имеют разный формат записи. При этом, конечно, число можно записать в виде строки, но тогда проблемы Json заменяются проблемами проверки, что строка это именно число, а не нечто, похожее на число. Поэтому, например, у меня две разные функции asInt и toInt. ·>Угу. Но парсеры обычно не различают "42" и 42.
Ещё как различают! А вот скажем, "4\u0032" и "42" различают не все.
·>JS, по большому счёту, тоже не различает.
Причём тут JS?
Здравствуйте, B0FEE664, Вы писали:
BFE>>>Функция GetObjectProps проверяет наличие всех значений внутри себя. BFE>·>Круто, но зачем? Цель-то какая? BFE>Отбросить неполные данные.
Зачем нужна вся пачка сразу? Можно проверять поштучно.
BFE>>>В Json строки и числа имеют разный формат записи. При этом, конечно, число можно записать в виде строки, но тогда проблемы Json заменяются проблемами проверки, что строка это именно число, а не нечто, похожее на число. Поэтому, например, у меня две разные функции asInt и toInt. BFE>·>Угу. Но парсеры обычно не различают "42" и 42. BFE>Ещё как различают! А вот скажем, "4\u0032" и "42" различают не все.
Ну может быть функция проверки, но, как правило, есть методы конверсии.
BFE>·>JS, по большому счёту, тоже не различает. BFE>Причём тут JS?
JS Object Notation
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, B0FEE664, Вы писали:
B>>Так возвращаемые функцией элементы всегда связаны между собой — это же результат ее работы. Другое дело, что некоторые (включая стандарт) ленятся заводить под результат структуры, в результате получая безликие ".first" и "get<1>".
BFE>Иногда заводить отдельные структуры под результат — это засорять код ненужными структурами. Вот недавно была задача: из распарсенного json-объекта вытащить значения некоторых полей. Оказалось удобно использовать вариадик функцию возвращающую переменное количество значений для переменного числа параметров:
JSON-объект — далеко не то же самое, что возвращаемое значение функции. В вашем случае, конечно, удобно использовать tuple и инициализацию по переменным.
Проект Ребенок8020 — пошаговый гайд как сделать, вырастить и воспитать ребенка.
Здравствуйте, netch80, Вы писали:
N>Вот это — реальное "достижение" (нет) авторов GCC и Clang в области их супероптимизаций, которое важнее того, что они очередным хаком над стандартом получили ещё 1-2% в каком-то тесте.
Проблема ж в определении самого языка, а не в компияторе, не?
Вот как раз добрые разработчики компилятора оставили лазейку в виде -O0 для тех, кому язык оказался непосилен (т.е., чуть менее, чем для всех)
Здравствуйте, Pzz, Вы писали:
N>>Вот это — реальное "достижение" (нет) авторов GCC и Clang в области их супероптимизаций, которое важнее того, что они очередным хаком над стандартом получили ещё 1-2% в каком-то тесте.
Pzz>Проблема ж в определении самого языка, а не в компияторе, не?
Скорее да.
Pzz>Вот как раз добрые разработчики компилятора оставили лазейку в виде -O0 для тех, кому язык оказался непосилен (т.е., чуть менее, чем для всех)
Ага, ну очень добрые — сначала изнасиловали, потом позволили остаться живым. Мне реально где-то такое сравнение приходит на ум, потому что если без оптимизаций то код реально страшный, а если с оптимизациями то начинаешь бояться.
Здравствуйте, Кодт, Вы писали:
N>>Вот это — реальное "достижение" (нет) авторов GCC и Clang в области их супероптимизаций, которое важнее того, что они очередным хаком над стандартом получили ещё 1-2% в каком-то тесте.
К>Это как-то намекает на качество кода и качество тестирования.
Да. Но это чистейшая корпоративная реальность.
Я не говорю, что они правильно делают — я описываю наблюдаемый факт.
На проекте вполне толковые разработчики, но их оценивают по другим параметрам: как прочитать спецификацию какого-то стандарта, сделать для него реализацию и отработать всё это во взаимодействии с конкретным железом. Они понимают, как запрограммировать железку, что в какие регистры класть (и потому C++ или даже C), но им не хочется думать о том, что оставив случайно p->q раньше чем if(p!=nullptr), они вместо понятного кордампа сделали то, что код совершенно не будет соответствовать тому, что они видят.
К>Почему у других людей толстые проекты компилируются на максимальной оптимизации?
А почему по статистике ~40% C++ проектов разрабатываются с запретом исключений?
Где-то у людей хватило силы продавить контроль за кодом чтобы не прибегать к таким крайним мерам, где-то — нет.
На предыдущем очень похожем по сути проекте было -O3 по умолчанию (перегиб в другую сторону, там это нафиг не было нужно кроме пары файлов), а на этом -O0.
Я смотрю на уровень проблемы в среднем, а он реально высок. Конкуренты в диапазоне от Ada до C# и Rust имеют подобных проблем в разы меньше. Значит, можно сделать, чтобы не выжирать кровь у целых поколений разработчиков?
К>Статические анализаторы тоже не всесильны, наверняка есть способ писать код так, чтобы облегчить либо усложнить им жизнь. Это культура написания кода.
Это "мышки, станьте ёжиками".
Инструмент должен помогать, а не нагромождать проблемы, вызванные самим инструментом.
К>Опять же, толстый проект предполагает толстый набор тестов, от юнитов до интеграционных. Если ошибка выплывает, то её можно воспроизводить и локализовывать, — начиная с какого коммита она стала вылезать, например.
Тесты есть.
Цена воспроизведения и потом поиска ошибки — выше, чем, считается, можно себе позволить.
И, повторюсь, все эти супероптимизационные возможности нафиг не нужны этому коду. Тот, где реально нужны, в идеале ограждены флажками.
К>Не глядя на проект, конечно, нельзя сказать, — что же там с самого начала пошло не так.
Можешь не смотреть, ничего особенного. Повторюсь, больше половины это, например, как полученную из сети конфигурацию отрендерить в форму, которая загружается в целевой чип, и наоборот — как собранные из него данные передать аплинку.
Здравствуйте, ·, Вы писали:
·>Здравствуйте, netch80, Вы писали:
N>>мои заказчики ставят -O0 ·>Это уже днище какое-то, имхо. Вы просто не тот яп выбрали. Даже если это на javascript переписать в котором с UB проблем практически нет, и то быстрее заработает, там хоть jit есть.
На javascript есть доступ к регистрам встроенного ASIC?
Где такие реализации водятся и как на них посмотреть?
Здравствуйте, Pzz, Вы писали:
Pzz>тех, кому язык оказался непосилен (т.е., чуть менее, чем для всех)
Дико извиняюсь за офтопик, но мне интересно: а вам не надоело выплескивать свою желчь в адрес C++?
Мне вот очень не нравятся ни Java, ни Python, ни Go. На мой взгляд, эти языки были сделаны для того, чтобы умственно отсталые персонажи могли бы хоть что-то хоть как-то программировать. Но это мое личное мнение, никому его не навязываю. И, тем более, не бегаю по форумам про Java/Python/Go и не пытаюсь уныло троллить обитающих там пользователей этих языков.
Вы же, вроде, не молоды уже, гормональные выбросы вроде как уже должны были перестать влиять на умственные способности, да и какой-то жизненный опыт должен был бы поднакопиться, чтобы понимать, что не все так однозначно в этом мире. Но херней упорно страдаете.
Вам, как и Артёмке, C++ лет 20 назад нанес такую же неизгладимую травму, которая до сих пор дает о себе знать?
Здравствуйте, so5team, Вы писали:
Pzz>>тех, кому язык оказался непосилен (т.е., чуть менее, чем для всех)
S>Дико извиняюсь за офтопик, но мне интересно: а вам не надоело выплескивать свою желчь в адрес C++?
А почему ты решил, что это "желчь"?
Я вот считаю, что это капанье на мозги в сторону, чтобы в следующем стандарте что-то поменять хоть как-то в сторону улучшения наиболее критичных вещей и заодно самопроверки тезисов в эту сторону. Чтобы дальше хоть в чём-то, но было лучше.
Прогресс идёт в 10-20 раз медленнее, чем должен был бы, но идёт.
Вот я вижу решение описанных проблем в виде:
1. Определить основные критичные области UB и задать для них контекстную регулировку атрибутами.
2. Сделать умолчанием, чтобы максимально соответствовало исходному коду, даже если там есть подозрительные места.
3. Сделать средства для отдельных особых операций там, где это нужно.
Вот, например, в GCC сделали overflow builtins — роскошно, теперь их протащить (пусть со сменой названий, очевидно) на уровень стандарта. Или добавляют новые функции, работающие с stdio, но сам stdio уже лет 30 ждёт замыканий в стиле fopencookie() — аналогично.
Да, стандартизаторов напрямую тут нет, и у меня нет времени+вдохновения самому лезть в это, но чем чаще и конструктивнее обсуждается, тем лучше.
А ты воспринимаешь как-то критически неадекватно — "желчь" и всё такое. Почему ты так воспринимаешь?
Почему ты не хочешь понять, что если люди ещё критикуют, то они отя бы заинтересованы в средстве? Те, кто не заинтересован, ушли на другие языки.
S>Мне вот очень не нравятся ни Java, ни Python, ни Go. На мой взгляд, эти языки были сделаны для того, чтобы умственно отсталые персонажи могли бы хоть что-то хоть как-то программировать. Но это мое личное мнение, никому его не навязываю. И, тем более, не бегаю по форумам про Java/Python/Go и не пытаюсь уныло троллить обитающих там пользователей этих языков.
Будешь писать на них — можешь точно так же "троллить", а на самом деле, обсуждать недостатки и пути их обхода и устранения. Почему нет?
Ещё раз: мы на них реально пишем и именно поэтому недовольны тем, что с ними происходит.
S>Вы же, вроде, не молоды уже, гормональные выбросы вроде как уже должны были перестать влиять на умственные способности, да и какой-то жизненный опыт должен был бы поднакопиться, чтобы понимать, что не все так однозначно в этом мире. Но херней упорно страдаете.
Ну вот пока ты думаешь, что это херня, и не поймёшь. Перечитай что я пишу в данном сообщении.
S>Вам, как и Артёмке, C++ лет 20 назад нанес такую же неизгладимую травму, которая до сих пор дает о себе знать?
Артёмка на нём пишет или нет?
Если регулярно это делает — то надо хотя бы иногда его слушать.
Здравствуйте, so5team, Вы писали:
Pzz>>тех, кому язык оказался непосилен (т.е., чуть менее, чем для всех)
S>Дико извиняюсь за офтопик, но мне интересно: а вам не надоело выплескивать свою желчь в адрес C++?
Здравствуйте, Pzz, Вы писали:
S>>Дико извиняюсь за офтопик, но мне интересно: а вам не надоело выплескивать свою желчь в адрес C++?
Pzz>Да нет у меня никакой желчи, не парься.
Ах, простите, это не желчь, это говно. Не сразу в сортах разобрался.
Я бы не парился, если бы не приходилось здесь читать пустые высеры, которые никак не помогают решать проблемы C++ тем, кто продолжает (по тем или иным причинам) C++ пользовался. Но вы с завидной регулярностью приходите сюда (и не только) изложить свое веское (нет) мнение. Отсюда и вопрос: "а нафига?"
Здравствуйте, netch80, Вы писали:
Pzz>>>тех, кому язык оказался непосилен (т.е., чуть менее, чем для всех)
S>>Дико извиняюсь за офтопик, но мне интересно: а вам не надоело выплескивать свою желчь в адрес C++?
N>А почему ты решил, что это "желчь"?
Потому что ошибся, это была не желчь, это говно, которое, имхо, следовало бы держать при себе и не выставлять на всеобщее обозрение.
За то, что это говно, говорит, как минимум, две простые вещи:
a) утверждение "язык оказался непосилен" противоречит окружающей меня действительности. Т.к. софт на C++ есть и он работает не хуже, чем софт, реализованный на других языках программирования;
b) данное утверждение не несет никакого конструктива.
Предложение сменить язык актуально и известно уже лет 25, минимум, кто хотел, тот воспользовался. У тех, кто остался в C++, есть причины здесь оставаться. И высказывания "да говно этот ваш C++, пользоваться им никто не умеет, а улучшить его невозможно" ничуть не помогают писать хороший и работающий код на C++ (повторю в N-й раз: писать код на C++ все еще нужно).
N>Я вот считаю, что это капанье на мозги в сторону, чтобы в следующем стандарте что-то поменять хоть как-то в сторону улучшения наиболее критичных вещей и заодно самопроверки тезисов в эту сторону. Чтобы дальше хоть в чём-то, но было лучше.
Практика показывает, что капать на мозги нужно не изливанием желчи (и не откладыванием кучек известной субстанции), а подготовкой предложений и/или участием в их обсуждении.
Ничего подобного регулярные выпады от Pzz не напоминают.
N>А ты воспринимаешь как-то критически неадекватно — "желчь" и всё такое. Почему ты так воспринимаешь?
См. выше.
N>Почему ты не хочешь понять, что если люди ещё критикуют, то они отя бы заинтересованы в средстве?
Конкретно Pzz многократно заявлял, что он C++ не использует, а программирует на C и Go.
N>Будешь писать на них — можешь точно так же "троллить", а на самом деле, обсуждать недостатки и пути их обхода и устранения. Почему нет?
Ну вот когда буду, тогда у меня будет хоть что-то напоминающее "моральное право".
Но даже когда я писал на Java (а сейчас временами пользуюсь Python) просто огульные "да говно это ваше..." хороши разве что в качестве шутки юмора и очень в меру.
N>Ну вот пока ты думаешь, что это херня, и не поймёшь.
Ну-ну, ну-ну.
S>>Вам, как и Артёмке, C++ лет 20 назад нанес такую же неизгладимую травму, которая до сих пор дает о себе знать?
N>Артёмка на нём пишет или нет?
Уже нет. Лет 10 как. Но всегда готов отпустить шпильку в адрес C++ и C++ников (при этом демонстрируя явное непонимание предмета).
N>Если регулярно это делает — то надо хотя бы иногда его слушать.
А поехавших крышей и утверждающих, что соседи их через розетку облучают, тоже нужно хотя бы иногда слушать?
Здравствуйте, night beast, Вы писали:
N>>А ты воспринимаешь как-то критически неадекватно — "желчь" и всё такое. Почему ты так воспринимаешь?
NB>а как ты воспринимаешь? NB>
NB>Поэтому нет, не нужна, и сам c++ не нужен. Его не исправишь, добавляя новые функции.
Это Артёмка писал? Я за него не отвечаю и сильно не слежу.
И в этой теме его не было.
Здравствуйте, so5team, Вы писали:
S>Конкретно Pzz многократно заявлял, что он C++ не использует, а программирует на C и Go.
Почти всё обсуждаемое в активно-флеймовой части этой темы одинаково относится к обоим C|C++.
Алиасинг, выкидывание проверок указателя на !=null, эффекты переполнений, ещё что-то.
S>За то, что это говно, говорит, как минимум, две простые вещи:
S>a) утверждение "язык оказался непосилен" противоречит окружающей меня действительности. Т.к. софт на C++ есть и он работает не хуже, чем софт, реализованный на других языках программирования;
А если подсчитать трудозатраты для всего выше уровня ОС/железа — окажется, что вот те упомянутые тобой Java/Go/etc. забрали большинство задач. Поэтому "не хуже" — ложь. Хуже, иначе бы с него не убегали.
S>Предложение сменить язык актуально и известно уже лет 25, минимум, кто хотел, тот воспользовался. У тех, кто остался в C++, есть причины здесь оставаться.
В большинстве случаев причина — нет другого языка, который бы был распространён в домене ManualMM + прямой доступ к памяти (где надо). C|C++ угробили всех конкурентов, при этом не отличаясь идеальными характеристиками (мягко говоря).
Если бы такой был, то, что я сейчас пишу, давно было бы на нём.
S> И высказывания "да говно этот ваш C++, пользоваться им никто не умеет, а улучшить его невозможно" ничуть не помогают писать хороший и работающий код на C++ (повторю в N-й раз: писать код на C++ все еще нужно).
К сожалению, это так.
N>>Если регулярно это делает — то надо хотя бы иногда его слушать.
S>А поехавших крышей и утверждающих, что соседи их через розетку облучают, тоже нужно хотя бы иногда слушать?
Ой не знаю. Это ж у вас история была...
(пардоньте, это не через розетку. но близко к тому)
Здравствуйте, netch80, Вы писали:
S>>Конкретно Pzz многократно заявлял, что он C++ не использует, а программирует на C и Go.
N>Почти всё обсуждаемое в активно-флеймовой части этой темы одинаково относится к обоим C|C++. N>Алиасинг, выкидывание проверок указателя на !=null, эффекты переполнений, ещё что-то.
Если бы Pzz говорил, что C не нужен, то вопрос о причинах излияния желчи все равно бы остался.
N>А если подсчитать трудозатраты для всего выше уровня ОС/железа — окажется, что вот те упомянутые тобой Java/Go/etc. забрали большинство задач. Поэтому "не хуже" — ложь. Хуже, иначе бы с него не убегали.
"Не хуже" -- это относилось к тому, что программы работают, падают и портят что-то не сильно больше, чем разработки на той же Java. Что говорит (мне по крайней мере), что язык осваивают вполне себе успешно.
Причин для убегания много (впрочем, с той же Java тоже убегают, и с Go на Rust убегают), сложности с освоением в списке причин есть, но вряд ли на первых местах.
N>В большинстве случаев причина — нет другого языка, который бы был распространён в домене ManualMM + прямой доступ к памяти (где надо). C|C++ угробили всех конкурентов, при этом не отличаясь идеальными характеристиками (мягко говоря).
Уж что есть, тем и пользуемся. Отсюда и интерес к тому, как пользоваться тем что есть с большей безопасностью и удобством.
А вот интереса обосрать посильнее у многих здесь нет, но с попытками сделать это почему-то регулярно приходится иметь дело.
N>Ой не знаю. Это ж у вас история была... N>(пардоньте, это не через розетку. но близко к тому)
Перекуём баги на фичи!
