Здравствуйте, Miroff, Вы писали:
M>Практический смысл преизрядный: такому типу даже теоретически невозможно присвоить значение, выходящее за пределы диапазона.
Хм, и каким же образом это обеспечивается?
Вот давай
let index = a - b;
Какой механизм языка не даст мне даже теоретически сделать a<b?
А никакой.
Тогда что же будет вместо? А будут в лучшем случае рантаймовые проверки на КАЖДУЮ промежуточную операцию! Да, в таком случае они есть и для знаковых типов тоже, но всё что я получу на беззнаковых — программа упадёт при попытке вычислить промежуточный результат, а мне это нахрен не сдалось. Тогда какой в этом практический смысл? Что я на этом сэкономлю по сравнению с вариантом "посчитать всё в наиболее удобном для вычислений типе, который очень даже знаковый, а потом в самом конце проверить, но это валидный индекс"? Вместо проверки на каждой операции будет только одна проверка в конце, ну и хорошо.
>А еще можно таким способом сделать нецельночисленные индексы, разреженные индексы, бесконечные индексы для генераторов и т.п.
О, давай введём индекс, который может быть только 0,1,3,42. И вот давай попытаемся что-то посчитать
if let Some(element) = element.get(a+2) ...
(get — это метод, который проверяет валидность индекса и возвращает либо элемент по индексу, либо None)
Но у нас так вышло, что даже теоретическая возможность вычислить 2+2 запрещена так любимым современными хипстерами "ОГРАНИЧЕНИЕМ НА УРОВНЕ СИСТЕМЫ ТИПОВ". (Ещё хипстер может добавить "Благодаря этому ограничению мы сумели выкинуть проверку из get и всегда возвращать элемент, тем самым мы ускорили get, мы такие классные") То есть прога завалится до попытки проверить валидность индекса. А какой толк тогда в этом ограничении, если оно обеспечивается только через проверки в рантайме, да ещё и дико усложняет примерно все операции, в который индекс это не просто уникальный ойдишник, но и число, над которым делается математика?
Здравствуйте, T4r4sB, Вы писали:
TB>Здравствуйте, Miroff, Вы писали:
M>>Практический смысл преизрядный: такому типу даже теоретически невозможно присвоить значение, выходящее за пределы диапазона.
TB>Хм, и каким же образом это обеспечивается?
Системой типов. Твоя беда что ты до сих пор мыслишь на С++ тридцатилетней давности с его адресной арифметикой. Тебе на самом деле не нужна семантика a-b, а ту семанику, которая тебе на самом деле нужна можно выразить через типы.
>>А еще можно таким способом сделать нецельночисленные индексы, разреженные индексы, бесконечные индексы для генераторов и т.п.
TB>О, давай введём индекс, который может быть только 0,1,3,42. И вот давай попытаемся что-то посчитать TB>
TB>if let Some(element) = element.get(a+2) ...
TB>
Если ты вводишь такой индекс, будь добр определи что такое для него операция плюс. Иначе не скомпилируется.
TB>Но у нас так вышло, что даже теоретическая возможность вычислить 2+2 запрещена так любимым современными хипстерами "ОГРАНИЧЕНИЕМ НА УРОВНЕ СИСТЕМЫ ТИПОВ". (Ещё хипстер может добавить "Благодаря этому ограничению мы сумели выкинуть проверку из get и всегда возвращать элемент, тем самым мы ускорили get, мы такие классные") То есть прога завалится до попытки проверить валидность индекса. А какой толк тогда в этом ограничении, если оно обеспечивается только через проверки в рантайме, да ещё и дико усложняет примерно все операции, в который индекс это не просто уникальный ойдишник, но и число, над которым делается математика?
В первую очередь это упрощает код избавляя его от миллиардов проверок на каждый чих чтобы на дай бог не выстрелить себе в ногу. В Си ты хотя бы получал сегфолт, а вот в питоне, где отрицательные индексы есть, ты вообще получишь некорректный результат и никогда об это не узнаешь. И вовсе не обязательно это делать в рантайме. Корректность алгоритмов можно и нужно доказывать в компайл тайме вынося в рантайм только те проверки, для которых вывод не дал однозначного результата.
Здравствуйте, Miroff, Вы писали:
M>Системой типов. Твоя беда что ты до сих пор мыслишь на С++ тридцатилетней давности с его адресной арифметикой. Тебе на самом деле не нужна семантика a-b, а ту семанику, которая тебе на самом деле нужна можно выразить через типы.
Видишь ли, я при работе использую std::vector 30-летней выдержки. А при программировании на Rust я использую вектор, основанный на идее 30-летный выдержки.
TB>>О, давай введём индекс, который может быть только 0,1,3,42. И вот давай попытаемся что-то посчитать
M>Если ты вводишь такой индекс, будь добр определи что такое для него операция плюс. Иначе не скомпилируется.
Ну в кишках можно определить как "кастануть к инту, сложить, упасть если результат не попал в допустимое множество, кастануть в наш офигенный тип". Можно ещё до каста определить, что результат не поместится в допустимое множество, чество перечислив все 16 вариантов слагаемых. В любом случае это не будет работать как магия, которая волшебными оптимизациями на уровне компилятора автоматом даст "правильный" результат. Нет, правильность обеспечивает рантайм, лол.
M>В первую очередь это упрощает код избавляя его от миллиардов проверок на каждый чих чтобы на дай бог не выстрелить себе в ногу.
Я тебе только что привёл пример, как "ограничения на уровне системы типов" (произносить саркастическим голосом) реализуются именно через рантаймовые проверки на каждый чих! Так что нахрен не впёрлись такие ограничения, нет в них никакой практической полезности. Отрицательное число не должно валить программу до тех пор, пока мы не попытаемся действительно взять элемент по такому индексу.
M>В Си ты хотя бы получал сегфолт,
На знаковых индексах я получал бы абсолютно валидную рабочую программу, обрабатывая индекс при помощи функции my_vector.is_index_valid(i), которая успешно принимала и отрицательные числа.
M>а вот в питоне, где отрицательные индексы есть, ты вообще получишь некорректный результат и никогда об это не узнаешь.
В Питоне лажа полная. Разумеется, отрицательный индекс должен считаться инвалидным.
M>И вовсе не обязательно это делать в рантайме. Корректность алгоритмов можно и нужно доказывать в компайл тайме вынося в рантайм только те проверки, для которых вывод не дал однозначного результата.
А ещё надо писать красивые программы, которые никогда не глючат.
А в реальном мире есть миллион ситуаций, когда тебе блин НУЖНО вычитать индексы, или когда тебе НУЖНО знаковое смещение от индекса элемента. И постоянно помнить, что даже банальное "i<v.size()-1" таит в себе бомбу — это просто сложность, не обоснованная ни-чем, кроме хипстерских размахиваний руками.
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, Privalov, Вы писали:
P>>Меня больше напрягает термин виртуальная функция.
V>Это беда многих жаргонизмов. V>Русское слово "виртуальный" и английское "virtual" имеют в разных контекстах разный смысл. V>
V>В русском "виртуальный" значает только "мнимый", "не существующий" и т.д. V>В ООП "virtual" означает "фактический".
Да нет там значения "фактический".
Есть "почти тот самый, но не совсем".
Обычно virtually переводят как "практически", а "virtual" — это существительное с похожим значением.
Ну и "виртуальный" если подумать имеет тот же самый смысл с немного отличающимся оттенком.
А вы тут придумали какую-то ересь.
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, Privalov, Вы писали:
P>>Ладно, допустим что virtual в английском языке означает фактический.
V>Я обратил прошлый раз внимание, что "фактический" имеет несколько смыслов даже в русском. V>Перечислил не все оттенки, разумеется, вот пример, где по смыслу подходит наречие "почти": V>
V>The angry peasants were a virtual army as they attacked the castle.
V>Разгневанные крестьяне представляли собой фактически армию, напавшую на замок. V>... практически армию V>... чуть ли не армию V>и т.д.
Угу, "практически" в смысле "не совсем армию, но почти".
"Фактически" — это немного другое, в нем нет необходимого оттенка того, что это не совсем то.
Здравствуйте, VladiCh, Вы писали:
VC>Угу, "практически" в смысле "не совсем армию, но почти". VC>"Фактически" — это немного другое, в нем нет необходимого оттенка того, что это не совсем то.
Это в русском. ))
В английском virtual приобретает смысловой оттенок в зависимости от контекста.
Здравствуйте, VladiCh, Вы писали:
VC>Ну и "виртуальный" если подумать имеет тот же самый смысл с немного отличающимся оттенком. VC>А вы тут придумали какую-то ересь.
Здравствуйте, T4r4sB, Вы писали:
V>>Давай-ка я тебя и тут выпорю. )) V>> auto ptr = begin(vec); V>> ptr++; V>> auto x = ptr[-1]; TB>Ты сам себя выпорол. Никто так с векторами не работает.
ОК, продолжаем порку:
Итераторы произвольного доступа
Итераторами произвольного доступа называются двунаправленные итераторы, поддерживающие прямой доступ к элементам. Для этого в них определяются вычисления с итераторами (по аналогии с математическими вычислениями с обычными указателями) — вы можете складывать и вычитать смещения, обрабатывать разности...
Итераторы произвольного доступа удобны именно для относительной адресации.
Новомодная идиома ranges когда-то зародилась и выросла именно из такого обращения с итераторами, будучи обобщённой затем на произвольные итераторы.
В т.ч.: https://en.cppreference.com/w/cpp/ranges/view_interface/operator_at
The default implementation of operator[] member function obtains the element at the specified offset relative to the beginning iterator, reusing the operator[] of the iterator type.
V>>Ты сам задал тон общения с тобой. TB>Ты изначально взял снисходительный тон
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, VladiCh, Вы писали:
VC>>Ну и "виртуальный" если подумать имеет тот же самый смысл с немного отличающимся оттенком. VC>>А вы тут придумали какую-то ересь.
V>Учите матчасть, как грится. V>
V>Понятно, что профессиональная деформация, что жаргонизмы IT въелись в кровь, но всё же...
Жаргонизмы тут ни при чем. я говорю о том, как это слово реально используется вне IT контекста, и откуда взялся собственно смысл в IT-контексте.
И о том что оно не переводится как "фактический" нигде, смысл его "похожий, но не совсем тот",
все указанные выше синонимы удовлетворяют этому смыслу.
Здравствуйте, LaptevVV, Вы писали: LVV>1. Я читал все книжки Вирта еще в Советском Союзе... LVV>2. И еще тогда понял, что он таки да — ОЧЕНЬ умный дядька.
а мне повезло на его лекции быть в универе где он рассказывал про дизайн Оберона и прикалывался над С++
однако, Оберон помер..
Здравствуйте, Privalov, Вы писали:
P>Здравствуйте, vdimas, Вы писали:
V>>Ну или в смысле "почти что функция" ))
P>То есть virtual — это функция, а не virtual — почти функция? А что такое почти функция в языках программирования? Мне приходит в голову только ENTRY из Фортнана. Это оно?
Наоборот, здесь vdimas все запутал. Не virtual — обычная функция, а virtual — "почти функция". Почему так — ну потому что то что стоит за этой "функцией" четко не определено, зависит от VMT.
То есть это не совсем функция, а некий редирект на функцию, я думаю в этом был изначальный смысл.
Здравствуйте, VladiCh, Вы писали:
VC>Наоборот, здесь vdimas все запутал. Не virtual — обычная функция, а virtual — "почти функция". Почему так — ну потому что то что стоит за этой "функцией" четко не определено, зависит от VMT. VC>То есть это не совсем функция, а некий редирект на функцию, я думаю в этом был изначальный смысл.
Дак я, собственно, об этом же. Виртуальной можно назвать функцию, которая определена где-то в интерфейсе, у которой нет тела. Но кто-то ее вызывает и получает результат. Что там на самом деле отрабатывает, неважно.
А к функции, которая и сама может вернуть результат, определение "виртуальная" не подходит. Она какая-нибудь перекрываемая.
LVV>>1. Я читал все книжки Вирта еще в Советском Союзе... LVV>>2. И еще тогда понял, что он таки да — ОЧЕНЬ умный дядька. __>а мне повезло на его лекции быть в универе где он рассказывал про дизайн Оберона и прикалывался над С++ __>однако, Оберон помер..
Нифига он не помер.
1. Наши атомщики сварганили себе компилятор Оберона — Мультиоберон.
Чтобы писать на нем встроенные системы для Росатома.
2. В 2018 или 2019 году в Россию на День Оберона (который ежегодно происходит в Москве и Орле) приехал Гуткнехт.
Рассказывал, что они там у себя придумали.
В ниши Оберон ушел — туда, где требуется надежность
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, T4r4sB, Вы писали:
V>>Итераторы произвольного доступа TB>А это-то вообще к чему? XD
К еще одному утверждению, не соответствующему действительности:
Никто так с векторами не работает.
Только не с векторами, а с итераторами.
Итератор произвольного доступа можно не только от вектора получить, т.е. надо накручивать функциональность вокруг итератора, а не вектора, ес-но.
В общем, если бы с итераторами так не работали, не возникла бы библиотека ranges сначала в рамках Boost, затем в стандарте.
Она именно так и работает, по крайней мере для итераторов произвольного доступа, убирая последние отличия итераторов от указателей через систему хелперов, в т.ч. через хелперы, получающие итераторы от встроенных и библиотечных типов. В т.ч. через открытость такой системы, где к юзверским типам можно доопределять соотв. хелперы.
(с оговоркой, что для более ограниченных итераторов — в рамках их ограничений, ес-но)
Здравствуйте, Marty, Вы писали:
M>Беззнаковые в C++ — размеры, обычно используют для этого size_t. В операторе []/at() тоже используется беззнаковый
Ну да, вектор гарантирует, что у него нет данных по отрицательному смещению, индекс vector::operator[] имеет тип size_type.
M>А отрицательные индексы так-то значения не имеют. Потому что индекс всегда в диапазоне [0,N). И в библиотеке идёт одна проверка — на превышение размера (который size_t), вместо двух проверок.
+1
Но в сигнатуре итератора вектора iterator::operator[] индекс имеет тип difference_type.
size_type Unsigned integer type (usually std::size_t)
difference_type Signed integer type (usually std::ptrdiff_t)
Здравствуйте, T4r4sB, Вы писали:
TB>Задание: напиши проверку (index >= 0 && index < size) для знакового типа так, чтоб оно скомпилировалось в один бранч
Здесь UB:
int32_t i = get_some_value();
uint64_t n = i; // (uint64_t)i; uint64_t(i)
TB>Вот я хочу перебрать элементы с конца TB>
TB>for (auto i = vec.size() - 1; i >=0; --i)
TB>
TB>Ну я вот записал цикл самым естественным образом. И подорвался на мине.
Чтобы не подорваться:
for (auto const& e : ranges::view::reverse(vec))
TB>А ещё я хочу перебрать все элементы, кроме последнего
Здравствуйте, VladiCh, Вы писали:
VC>Не virtual — обычная функция, а virtual — "почти функция". Почему так — ну потому что то что стоит за этой "функцией" четко не определено, зависит от VMT. VC>То есть это не совсем функция, а некий редирект на функцию, я думаю в этом был изначальный смысл.
Потенциальных смыслов в английском здесь сразу несколько:
— подразумеваемая функция
— выбираемая по-факту функция
вполне может быть так, что изначальные авторы термина повелись на всю эту "красоту" из мешанин смыслов.
Оно ж такое, люди любят загадочность, смысловое двойное дно и прочее))
Для меня основное значение всегда было второе.
Вдогонку, pure virtual однозначно отсылает к первому.
Ну понимаешь, да, можно применять крутые модные клёвые итераторы вместо отсталых пенсионерских винтажных индексов, правде не во всех случаях. Только всё это лишний слой абстракции, который на самом деле был бы нахрен не нужен, если бы индексы и размеры были знаковые.
V>Сейчас хелперы навроде std::ssize(vec) служат для гладкого сопряжения с адаптерами из ranges:
Да, я знаю, ssize это выход. Опомнились и осознали, когда уже Страуструп прямо сказал, что не надо использовать ансигнеды всуе.
Ждём когда Растаманы допрут до того же.
Здравствуйте, Shmj, Вы писали:
S>↑ — сложение. S>↓ — вычитание.
Как у обычных векторов на 2D плоскости.
S>↑↑ — умножение.
В "привычной" алгебре при векторном умножении 2D векторов получаем перпендикулярный вектор в 3D.
В алгебре комплексных чисел эта операция складывает углы в полярной системе координат.
S>↓↓ — деление
сводится к умножению обоих частей дроби на комплексно-сопряжённый делитель.
S>↑↑↑ — возведение в степень.
Как и умножение, в полярной системе координат тривиально.
Да нет там значения "фактический".
