Здравствуйте, T4r4sB, Вы писали:
TB>Да хоть на 10. Я использовал знаковые размеры в других языках — жить стало лишь легче. Доменная ориентированность оказалась ненужным словом, чисто чтоб хипсторам порадоваться
А у нас вон один <censored> сделал LBA знаковым и насрал нам кучу геморроя сделав ну очень геморройным использование старшего бита.
Потому что этот мудак дане не потрудился подумать своим межушным ганглием ну хоть чуточку вперёд. Ай похрен на то, что LBA отрицательным не бывает, "мне так удобнее будет".
TB>Да нет никакой далеко растущей проблемы
Это у тебя нет, потому что ты её просто ещё пока не видишь.
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, vsb, Вы писали:
vsb>И в чём проблема кернелу жить в других адресах?
Пусть все вокруг всё переделают только чтоб тебе было "удобнее", да?
Сразу нафиг!
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, CreatorCray, Вы писали:
CC>А у нас вон один <censored> сделал LBA знаковым и насрал нам кучу геморроя сделав ну очень геморройным использование старшего бита.
А что сложного в использовании старшего бита у знакового числа?
Нет такой подлости и мерзости, на которую бы не пошёл gcc ради бессмысленных 5% скорости в никому не нужном синтетическом тесте
Здравствуйте, T4r4sB, Вы писали:
TB>Кстати, как это помогает, когда 4 була подряд? Типа позволяет выдать аргументам имена в точке вызова, типа не просто
TB>foo(true, true, false, true)
TB>а
TB>foo(Big{true}, Black{true}, Long{false}, Strong{true})?
Типа того. Но еще полезнее это когда есть проброс параметров из одной функции в другую. Если все параметры типизированные, то случайно перепутать значения не получится.
Здравствуйте, T4r4sB, Вы писали:
CC>>А у нас вон один <censored> сделал LBA знаковым и насрал нам кучу геморроя сделав ну очень геморройным использование старшего бита.
TB>А что сложного в использовании старшего бита у знакового числа?
Он совершенно случайно оказывается нужен для представления обычных, не негативных адресов.
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, no_ise, Вы писали:
_>Все это хорошо про "зависимые типы", Lof Type Theory, но, получается парадокс. _>Т.е. внизу у нас Тюринг-комплит система, скажем, C или там С++, и сверху мы начинаем _>сильной типизацией городить Тюринг-комплит метауровень.
А что, компилятор — не программа, чоль? На него не распространяется проблема останова, чоль?
Тем более, что вычисления времени компиляции — уже в абстрактном С++ являются тьюринг-полными.
А в голых сях оптимизирующий компилятор тоже может внутри себя поиграть в зависимые типы и уйти в глубокую задумчивость.
(Но обычно для этого принимаются противомеры — отсечка по длине-глубине вычислений).
_>Для хардкорного доказательства теорем это может быть круто. А для сложения-умножения точек _>в каком-нибудь GDI кажется будет перебором.
Для какого-нибудь критичного железа, может, и не будет перебором.
А то история знает ряд дурацких багов в авиации и космонавтике, которые могли быть пойманы сильной типизацией и анализом покрытия кода.
Здравствуйте, CreatorCray, Вы писали:
CC>Здравствуйте, T4r4sB, Вы писали:
CC>>>А у нас вон один <censored> сделал LBA знаковым и насрал нам кучу геморроя сделав ну очень геморройным использование старшего бита.
TB>>А что сложного в использовании старшего бита у знакового числа? CC>Он совершенно случайно оказывается нужен для представления обычных, не негативных адресов.
То есть проблема не в наличии знака и не в старшем бите, а в том, что реальные значения адреса бывают и от 2 лярдов до 4 лярдов?
Нет такой подлости и мерзости, на которую бы не пошёл gcc ради бессмысленных 5% скорости в никому не нужном синтетическом тесте
Здравствуйте, T4r4sB, Вы писали:
К>>Почему компилятор должен догадываться, что вот здесь u8+u8 = u8, а вот здесь уже = u9? А последующий u9-u8 — это u8, u9 или i10?
TB>Ну ок, компилятор не должен догадываться. Пусть будет результат u8. А я возьму инт и не буду про это думать? Можно? Нет, нельзя.
В конкретном месте приводи к int и работай с ним, если ты прямо вот уверен, что никогда не выбежишь из разрядной сетки или не схватишь знаковый разряд как обычный.
К>>Если в русте договорились, что тип результата не продвигается без явных указаний, — ну, делай указания.
TB>Проблема в том что в раст коммьюнити считается нормой изнасиловать разработчика этой необходимостью делать указания. И по надежности при этом никакого профита по сравнению с простым хранением интов.
Когда в большом плюсовом проекте включили варнинг компилятора о числовых преобразованиях, — ух, сколько аннотаций пришлось расставить, ты бы знал.
Особенно, когда у тебя, например, две библиотеки геометрии, делающие почти одно и то же, но одна оперирует float (чтобы экономить сетевой и дисковый трафик), а другая double (чтобы гарантированно не терять точность — которая, в общем-то, и нафиг не нужна).
Или одна библиотека использует размеры и индексы типа int (и очень рассчитывает, что там не будет больше 2 миллиардов байтов), а все остальные — size_t (потому что 2 миллиарда байтов вполне встречаются, хоть и не всюду).
Но всякие глупости при этом были пойманы.
И всякое необоснованное смешивание нескольких библиотек было убрано (потому что надоедает аннотировать, проще содержательно вылизать код).
Хотя на первом этапе это и казалось изнасилованием.
К>>Если есть сущность "смещения только в пределах шахматной доски", то — возможно, автору библиотеки или тебе лично, — придётся завести и сущность "расширенные смещения без гарантии, что они влезли в доску".
TB>Да можно. Только эти хипстеры забыли что не надо плодить сущности без необходимости. А необходимости нет — на простых интах жилось ьы намного проще.
К>>Опять же, разрядность этих смещений — "мамой клянусь, i32 мне за глаза и за уши", а вдруг "возьму-ка я float64"?
TB>Переход на плавающие числа это уже радикальное изменение которое требует переписать почти все.
Не всегда.
Например, то же время — можно хранить в наносекундах с начала эпохи, а можно в секундах с микросекундами в дробной части (плавающая точка). А можно — в секундах и наносекундах (фиксированная точка).
И промышленные библиотеки в одном проекте используют все три представления.
К>>А по факту, i128 в большинстве случаев люто избыточно. К>>Если наносекунды с начала эпохи влезают в i64, а ты будешь буферные 64 бита всюду таскать и складывать нули с нулями.
TB>А я не знаю, влезают ли в i64? Там запаса почти нет вродь. Ну если и его хватит то можно и его. Зато голову морочить не надо.
Да, фигня какая, вдвое больше места и вчетверо медленнее вычисления.
К>>Все эти универсальное время, системное, монотонное... это всё разные сущности. Физически разные. К>>std::chrono прямо заставляет тебя сдать экзамен по метрологии, прежде чем ты пойдёшь кодить, — это правда.
TB>Когда я пользовалсяGetTickCount(), time(), rdtsc() и QueryPerformanceCounter() то как то обходился без экзамена. Правда один раз огреб с GetTickCount когда у компа аптайм превысил ограничения типа
Мало огрёб, если не понял, зачем нужен экзамен по метрологии.
Потом откроешь для себя високосные секунды и немонотонное время, и ещё разок огребёшь.
Сильная типизация не спасёт от скачков времени, но будет изолировать куски программы, работающие по разным законам.
К>>А какая физическая природа у суммы двух точек? К>>И как к ней, например, аффинные преобразования применять?
TB>Сумма это промежуточный результвт операции "полусумма" у которой есть смысл. TB>Конечно можно записать это в виде a+(b-a)*0.5, но не всегда. Например тебе надо миллион точек прополусуммировать с данной. Тогда заранее вычислить a*0.5 было бы проще.
Аха, то есть, координаты для промежуточных вычислений (а не только перед финальным округлением) у нас уже полуцелые. Кто тут говорил, что int хватит?
TB>А пользы от данной идеи не вижу. Защииа он неверных значений не имеющих физического смысла типа (a+b)*0.6? Ну так если я напишу a+(b-a)*0.6, то мне станет не легче от того что результат сиал гдето примерно посередине a и b
Почему точка ровно посередине отрезка AB имеет физический смысл, а шестая по счёту точка на гребёнке из десяти засечек — не имеет физический смысл?
Разница между точкой и вектором — в том, что аффинные преобразования с ними делаются по-разному.
Параллельный перенос изменяет точки, но не трогает векторы.
Если у тебя есть аффинный оператор (масштаб*поворот + смещение), то в библиотеке геометрии
— либо ты явно используешь две разные функции оператор_над_точкой(A,P), оператор_над_вектором(A,V)
— либо потрошишь оператор и явно используешь его недра — (A.M*P + A.S), (A.M*V)
— либо же назначаешь точке и вектору разные типы и неявно пользуешься перегрузкой — A*P, A*V
Я вот тоже думал "нафига ввели точку, есть же вектор" — до того момента, как не полез в "промышленную" геометрию.
Так что все эти вещи — выстраданные.
Но никто не мешает в целях оптимизации вообще массив точек распедалить на три массива x, y, z координат и делать всякие векторные вычисления с каждой колонкой независимо.
Просто держишь в голове, что эти три гигантских вектора (или один гигантский тензор) имеет вот такую физическую природу, а потом перегоняешь обратно в естественное представление — россыпь точек.
Здравствуйте, T4r4sB, Вы писали:
TB>То есть проблема не в наличии знака и не в старшем бите, а в том, что реальные значения адреса бывают и от 2 лярдов до 4 лярдов?
Реальные девайсы могут использовать все 64 бита адреса, объявленные в стандарте на протокол.
Реальные адреса в памяти могут находится в сааааамом конце 64битного пространства.
Потому вся эта детская отсебятина с сделаем то, что не бывает отрицательным всё равно signed, чтоб было "удобнее" для меня звучит примерно как "сделаем сердечник электромагнита из дерева для облегчения веса изделия".
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, Кодт, Вы писали:
К>Здравствуйте, no_ise, Вы писали:
К>А что, компилятор — не программа, чоль? На него не распространяется проблема останова, чоль? К>Тем более, что вычисления времени компиляции — уже в абстрактном С++ являются тьюринг-полными. К>А в голых сях оптимизирующий компилятор тоже может внутри себя поиграть в зависимые типы и уйти в глубокую задумчивость. К>(Но обычно для этого принимаются противомеры — отсечка по длине-глубине вычислений).
Программа, распространяется, да
Параблемы те же самые, что на уровне что на метауровне, однако.
К>Для какого-нибудь критичного железа, может, и не будет перебором. К>А то история знает ряд дурацких багов в авиации и космонавтике, которые могли быть пойманы сильной типизацией и анализом покрытия кода.
Вот и получается, что где-то много метауровня это хорошо, а где-то Вася за пузырь лучше сделает.
Вопрос в балансе. Сколько и чего вытаскивать на метауровень в разных случаях.
Ну, а если собрать стартап с пресидом 20 лямов, который на айфоне будет показывать какую задачу
лучше с сильной типизацией и анализом покрытия кода делать, а какую Васе делегировать, то там
такая же проблема откроется.
Здравствуйте, no_ise, Вы писали:
_>Ну, а если собрать стартап с пресидом 20 лямов, который на айфоне будет показывать какую задачу _>лучше с сильной типизацией и анализом покрытия кода делать, а какую Васе делегировать, то там _>такая же проблема откроется.
Это и есть проблема останова: что будет, если натравить анализатор на анализатор? (И что будет, если Васю с бутылкой заставить верифицировать код Васи с бутылкой)?
Очевидно, что без двух бутылок тут в любом случае не разберёшься!
Здравствуйте, Кодт, Вы писали:
К>Здравствуйте, no_ise, Вы писали:
_>>Ну, а если собрать стартап с пресидом 20 лямов, который на айфоне будет показывать какую задачу _>>лучше с сильной типизацией и анализом покрытия кода делать, а какую Васе делегировать, то там _>>такая же проблема откроется.
К>Это и есть проблема останова: что будет, если натравить анализатор на анализатор? (И что будет, если Васю с бутылкой заставить верифицировать код Васи с бутылкой)?
К>Очевидно, что без двух бутылок тут в любом случае не разберёшься!
Здравствуйте, Кодт, Вы писали:
К>В конкретном месте приводи к int и работай с ним, если ты прямо вот уверен, что никогда не выбежишь из разрядной сетки или не схватишь знаковый разряд как обычный.
Понимаешь, в чём проблема. Если я забуду привести к инту при сложении u8+u8, то я получу падающий код. И компилятор ничего мне на это не скажет. То есть эти ограниченные Strong Types сами порождают грабли, хотя по задумке якобы должны от них защищать. И что самое хреновое — правильный код выглядит грязнее и хуже, чем неправильный но компилирующийся.
К>Когда в большом плюсовом проекте включили варнинг компилятора о числовых преобразованиях, — ух, сколько аннотаций пришлось расставить, ты бы знал.
Я не про то, что неявные преобразования зло. Я про то, что не надо плодить слишком много типов, и боже упаси ограничивать диапазон этих типов.
К>Да, фигня какая, вдвое больше места и вчетверо медленнее вычисления.
Отбрось лишние биты (старшие или младшие — в зависимости от задачи) и будет быстрое время.
К>Аха, то есть, координаты для промежуточных вычислений (а не только перед финальным округлением) у нас уже полуцелые. Кто тут говорил, что int хватит?
Очевидно, что пример с шахматной доской это не тот же пример, что с векторами-точками.
К>Почему точка ровно посередине отрезка AB имеет физический смысл, а шестая по счёту точка на гребёнке из десяти засечек — не имеет физический смысл?
Потому что мне нужен корректный код. Если я опечатался и написал a+(b-a)*0.6, то мне от этого ничуть не легче, чем если бы я написал (a+b)*0.6. Результат в обоих случаях неверен.
Можно поспекулировать на тему, что во втором случае я замечу, что поведение системы меняется в зависимости от расстояния до нуля и поэтому быстрее найду причину бага, но это спекуляции, потому что в разных случаях может быть по-разному.
К>Я вот тоже думал "нафига ввели точку, есть же вектор" — до того момента, как не полез в "промышленную" геометрию. К>Так что все эти вещи — выстраданные.
Что такое "промышленная геометрия"? В популярных библиотеках нет этой шизы.
Если же ты про библиотеки, предназначенные для сверх-надёжного кода для прошивок ядерных реакторов, то надеюсь, что тебе очевидно, что методы, применяемые в этой сфере, категорически не подходят в тех случаях, когда цена ошибки — это максимум потеря правок за последнюю минуту?
И раз уж мы вспомнили про прошивки ядерных реакторов, то давай вернёмся к моему примеру про сложение u8+u8, которое компилятор не отловит. Ну и тогда уж, чтоб намёк про "надёжность" ограниченных типов был понятнее — давай заменим ядерный реактор на ракету Ариан-5
Нет такой подлости и мерзости, на которую бы не пошёл gcc ради бессмысленных 5% скорости в никому не нужном синтетическом тесте
Здравствуйте, CreatorCray, Вы писали:
CC>Реальные девайсы могут использовать все 64 бита адреса, объявленные в стандарте на протокол. CC>Реальные адреса в памяти могут находится в сааааамом конце 64битного пространства.
Блин, причём тут знак тогда?! У нас тут для хранения значения используется тип, у которого тупо диапазона не хватает для представления всех значений, причина вообще в другом.
В случае с размером вектора — он не может быть больше чем 2**63-1
Нет такой подлости и мерзости, на которую бы не пошёл gcc ради бессмысленных 5% скорости в никому не нужном синтетическом тесте
Здравствуйте, T4r4sB, Вы писали:
TB>Ну короче тут наверное многие знают, и любой может нагуглить, что такое Primitive Obsession — это когда везде используются инты и строки, и из-за этого иногда случается фигня, когда секунды складываются с килограммами, а в емейл записывается заведомо невалидная строка. TB>А как называется противоположный антипаттерн? Это когда некий долбаный хипстер везде нагородил сраную овертипизацию, из-за которой даже нельзя блин сложить два вектора, потому что складывать можно только вектор и точку, а если таки надо сложить два вектора, то надо после получаса попыток заставить компилятор собрать код таки узнать, что надо использовать my_vector_lib::my_vector::point_cast<my_vector_lib::my_vector::point<std::ratio<1, 1000000000>>> на одном из них? Причём даже если для этой абракадабры есть простой алиас типа my_vector_lib::my_vector::millimeter_cast, то из сообщений компилятора это узнать невозможно, и это надо обязательно зазубрить.
А как называется феномен когда программист принципиально не читает документацию? Узнавать о возможностях библиотеки надо из документации, а не из сообщений компилятора.
Если у библиотеки нет/плохая документация — то за это можно и нужно ее поругать. Так же можно поругать того кто решил такую библиотеку использовать в проекте.
А пытаться изучать библиотеку по ошибкам компилятора... Ну такое.
Перекуём баги на фичи!
