Здравствуйте, T4r4sB, Вы писали:
TB>Каст знакового в беззнаковое однозначно определён.
Зато обратный каст нет.
И вот у тебя знаковый тип-индекс, а под ним беззнаковое выражение...
TB>Ну понимаешь, да, можно применять крутые модные клёвые итераторы вместо отсталых пенсионерских винтажных индексов, правде не во всех случаях. Только всё это лишний слой абстракции
Для векторов, массивов, строк и т.д. слой бесплатный.
TB>который на самом деле был бы нахрен не нужен, если бы индексы и размеры были знаковые.
Знаковые размеры неудобны.
В дотнете сильно раздражают.
Знаковые индексы тоже не всегда удобны.
V>>Сейчас хелперы навроде std::ssize(vec) служат для гладкого сопряжения с адаптерами из ranges: TB>Да, я знаю, ssize это выход. Опомнились и осознали, когда уже Страуструп прямо сказал, что не надо использовать ансигнеды всуе. TB>Ждём когда Растаманы допрут до того же.
Тебе уже отвечали тут несколько раз — вектор не имеет данных по отрицательному смещению.
Зато итератор может иметь.
Ну да, для большого класса алгоритмов глубоко до фени подробности вектора, для этих алгоритмов и навертели ranges::view.
Здравствуйте, VladiCh, Вы писали:
VC>Жаргонизмы тут ни при чем. я говорю о том, как это слово реально используется вне IT контекста, и откуда взялся собственно смысл в IT-контексте. VC>И о том что оно не переводится как "фактический" нигде
В переводах всегда используется жаргонизм "виртуальная", т.е. это уже термин, не требующий перевода.
VC>смысл его "похожий, но не совсем тот"
Смысл его — фактически выбираемая.
=================
Меня немного улыбает, что ты и Привалов считаете оттенки "подразумеваемый"/"возможный" и "фактический" противоположными.
Это близкие значения в случае, когда нечто "возможное" непременно будет однажды "фактическим", просто в некий момент еще неизвестно каким именно.
Т.е. в контексте IT у этих оттенков разный не смысл, а время действия. ))
В момент написания программы — "возможное".
В момент работы этой же программы — "фактическое".
Английское "virtual" просто удачно охватывает оба смысла.
А я обращал внимание, что в русском языке слово "виртуальный" имеет совсем другой оттенок, чем в английском.
В русском "виртуальный" означает, скорее, "надуманный".
Типа как "виртуальные частицы".
Этот термин в русском однозначно говорит, что никаких "виртуальных частиц" в реальности не существует.
Однако, в английском про виртуальные частицы довольно часто встречаются пояснения, что это никакие нафик не частицы, что это просто флуктуации или возмущения полей и т.д.
Потому что в английском оно же выглядит, скорее, как "возможные частицы".
И регулярно встречаются предложения придумать для этого понятия другой термин, т.е. в английском языке термин многими видится неудовлетворительным.
Здравствуйте, vdimas, Вы писали:
V>Меня немного улыбает, что ты и Привалов считаете оттенки "подразумеваемый"/"возможный" и "фактический" противоположными.
Загляни в словарь. Фактический — действительный, состоявшийся. Возможный — такой, который может произойти. Разницу объяснять надо?
V>Это близкие значения в случае, когда нечто "возможное" непременно будет однажды "фактическим", просто в некий момент еще неизвестно каким именно.
С какого перепугу возможное непременно станет фактическим?
V>В момент написания программы — "возможное". V>В момент работы этой же программы — "фактическое".
В момент написания программы я знаю, что в определенном месте будет вызван метод. Мне известно, как он выглядит, но неизвестно, откуда он вызовется.Только при выполнении это станет ясно. То есть он за счет чего-то реального моделируется. Как и все виртуальное.
V>Английское "virtual" просто удачно охватывает оба смысла.
V>В русском "виртуальный" означает, скорее, "надуманный". V>Типа как "виртуальные частицы".
Нам ближе виртуальные машины. Вот помню, на ЕС 1036 стояла у нас СВМ ЕС. На ней создавалась виртуальная машина с БОС 7.3 (дальнейшее ращвитие ОС ЕС).
Мне нужно выполнить на ней некое задание. Для этого сначала я запускаю ридер на устройство чтения с перфокарт. Если кто не знает, ридер (RDR) — это программа системного ввода. Да, так вот. Ридер ждет, когда ему придет пакет перфокарт.
А пакет этот в виде перфокарт не существует. Он лежит где-то на другой виртуальной машине с ПДО. Я как-то указываю ридеру, что этот пакет нужно прочитать. Деталей не помню, давно это было. Но ни перфокарт, ни устройства ввода физически не существует. Однако ридер спокойно отрабатывает, задание запускается и работает. И видит он пакет перфокарт как таковой. Он не знает, что пакет этот не существует. Как не знает, что и устройства ввода не существует.
И так все. Виртуальное устройство физически не существует. Оно как-то моделируется.
Ровно то же с виртуальными функциями. Но. В C++ то, что называется виртуальной функцией, может существовать физически. И значит, к такой функции термин "виртуальная" неприменим.
Здравствуйте, LaptevVV, Вы писали: LVV>2. В 2018 или 2019 году в Россию на День Оберона (который ежегодно происходит в Москве и Орле) приехал Гуткнехт.
поискал кто это такой, гугл такие картинки интересные выдает
LVV>Рассказывал, что они там у себя придумали. LVV>В ниши Оберон ушел — туда, где требуется надежность
интересно, не знал
LVV>>2. В 2018 или 2019 году в Россию на День Оберона (который ежегодно происходит в Москве и Орле) приехал Гуткнехт. __>поискал кто это такой, гугл такие картинки интересные выдает
Гуткнехт — это соратник Вирта по проекту Оберон (см. сайт Project Oberon 2013)
Два мужика (одному лет 50, второму порядка овер 40) в свободное от работы время сварганили
а) Язык Оберон
б) компилятор
в) операционную систему на Обероне.
Эта система представляла собой рабочее место программиста.
Через несколько лет ученики Вирта вырезали из этой системы редактор и компилятор и создали IDE BlackBox Componen Builder
Клеменс Шиперски написал книгу Beyond OOP
За что его пригласили в Микрософт Ресёч.
Не знаю, работает ли сейчас.
Другой ученик Михаэль Франц — разработал виртуальную машину для Компонентного паскаля и защитил диссер у Вирта.
В википедии написано:
Его докторская диссертация, озаглавленная «Генерация кода на лету: ключ к переносимому программному обеспечению», предлагала сделать программное обеспечение переносимым среди различных целевых компьютерных архитектур путем использования компиляции на лету из сжатая промежуточная структура данных во время загрузки. Двумя годами позже были запущены язык программирования и система Java, которые приняли эту идею как мейнстрим, хотя и использовали термин «своевременная компиляция» вместо термина «компиляция на лету», который использовал Франц.
Только его там называют "американским" ученым, хотя родился он в Гамбурге, а учился в Швейцарии.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, vdimas, Вы писали:
V>Знаковые размеры неудобны. V>В дотнете сильно раздражают. V>Знаковые индексы тоже не всегда удобны.
Ну-ка, пример приведи.
То, как беззнаковые индексы превращают валидный код в инвалидный, я привёл уже.
V>Тебе уже отвечали тут несколько раз — вектор не имеет данных по отрицательному смещению.
Ичо. Это не значит, что индекс не может участвовать в выражениях, дающих отрицательный результат.
Здравствуйте, T4r4sB, Вы писали:
TB>То, как беззнаковые индексы превращают валидный код в инвалидный, я привёл уже.
Это глупый программист превращает, бо в стандарте оговорено каким образом знаковые сравниваются с беззнаковыми.
V>>Тебе уже отвечали тут несколько раз — вектор не имеет данных по отрицательному смещению. TB>Ичо. Это не значит, что индекс не может участвовать в выражениях, дающих отрицательный результат.
Еще раз медленно — в случае дополнительного двоичного кода глубоко пофик, вся арифметика сохраняется с точностью до бит.
Ты не там проблему ищешь.
Плясать надо всегда от сценариев.
Где удобны беззнаковые — используем беззнаковые.
Наоборот — наоборот.
Но приводить одни сценарии для "доказательства" чего-то там относительно других — бессмыслица. ))
Здравствуйте, Privalov, Вы писали:
V>>Меня немного улыбает, что ты и Привалов считаете оттенки "подразумеваемый"/"возможный" и "фактический" противоположными. P>Загляни в словарь. Фактический — действительный, состоявшийся. Возможный — такой, который может произойти. Разницу объяснять надо?
Мне?
Я вижу, что собеседники увлеклись и не обратили внимания, к чему именно относится прилагательное.
На пальцах:
Вот у нас чёрный ящик, в нём достоверно 3 яблока, но 3-х разных цветов, выбираем одно.
Так что именно здесь виртуальное? ))
В английском языке цвет (или экземпляр) выбранного яблока будет virtual (потенциально-возможным) как до выбора, так и после выбора тоже virtual (фактический, установленный по факту и т.д.)
Путаница возникает потому что вы сами яблоки называете виртуальными.
Но виртуальные там не яблоки, а результат их выбора.
Это ж участь такая у любой терминологии — искажать первоначальные смыслы слов в угоду краткости.
В описанном сценарии некий введенный термин "виртуальное яблоко" в гражданском смысле означает "это такое яблоко, которое участвует в лотерее".
V>>Английское "virtual" просто удачно охватывает оба смысла. V>>В русском "виртуальный" означает, скорее, "надуманный". V>>Типа как "виртуальные частицы". P>Нам ближе виртуальные машины.
В этом контексте в русском противоречий нет — "подразумеваемая машина", а не реально-существующая.
P>А пакет этот в виде перфокарт не существует. Он лежит где-то на другой виртуальной машине с ПДО. Я как-то указываю ридеру, что этот пакет нужно прочитать. Деталей не помню, давно это было. Но ни перфокарт, ни устройства ввода физически не существует. Однако ридер спокойно отрабатывает, задание запускается и работает.
Это и в современных виртуалках так.
P>В C++ то, что называется виртуальной функцией, может существовать физически. И значит, к такой функции термин "виртуальная" неприменим.
Просто термин.
В комплексном числе тоже никаких мнимых частей нет, есть математическая абстракция из пары вещественных чисел.
Здравствуйте, vdimas, Вы писали:
V>Это глупый программист превращает, бо в стандарте оговорено каким образом знаковые сравниваются с беззнаковыми.
Ты пишешь как джун, который не понимает разницу между "запомнить правила" и "обходить все грабли", и который "я всегда всё контролирую в своём коде, в котором я уверен на 100%". Странно, что ты вообще пишешь на С++, писал бы на С, ведь это же так просто запомнить — у каждого маллока должен быть свой фри!
V>Еще раз медленно — в случае дополнительного двоичного кода глубоко пофик, вся арифметика сохраняется с точностью до бит.
Оператор сравнения по-разному работает, ничё?
Плюс есть новые языки, в которых есть проверка, что при вычитании случится "переполнение вниз".
Ах, да, тебе проверки не нужны.
V>Ты не там проблему ищешь. V>Плясать надо всегда от сценариев. V>Где удобны беззнаковые — используем беззнаковые. V>Наоборот — наоборот.
Логично. Так вот, для индексов и размеров удобны знаковые. Это проверено и об этом даже Страуструп говорит на видосах.
Здравствуйте, T4r4sB, Вы писали:
V>>Это глупый программист превращает, бо в стандарте оговорено каким образом знаковые сравниваются с беззнаковыми. TB>Ты пишешь как джун, который не понимает разницу между "запомнить правила" и "обходить все грабли"
Я отвечал на притянутые за уши примеры, бо обходить вектор принято через итераторы.
Здравствуйте, vdimas, Вы писали:
V>Я отвечал на притянутые за уши примеры, бо обходить вектор принято через итераторы.
Это только если тебе вектор нужен только целиком, просто пройтись по элементам в строго заданном порядке — самый банальный сценарий. К сожалению, большинство "программистов" никаких сценариев, кроме базового, никогда не видело. Покажи, как ты итераторами обойдёшь все элементы, кроме последнего?
Раньше никаких видосиков не делали. Учили математику на двумерной доске и читали двумерные книги. Это способствовало развитию абстрактного мышления, потому что мозг сам напрягался, пытаясь найти нужное ментальное представление задачи.
Здравствуйте, T4r4sB, Вы писали:
TB>Покажи, как ты итераторами обойдёшь все элементы, кроме последнего?
По классике примерно так:
vector<int> vec = { 1, 2, 3 };
for(auto i = vec.begin(), e = vec.end() - 1; i < e; ++i)
cout << *i << endl;
TB>Или как там?
Сейчас модно через range view, т.е. движение в сторону здравого смысла — отделение алгоритмов обхода коллекции от алгоритмов обработки элементов.
TB>Зачем мне помнить всю эту срань, если индексы работали 50 лет?
Итераторы появились вместе с векторами и сразу же через итераторы с вектором и работали.
TB>Я так понимаю, арифметику над индексами тебе делать не приходилось?
А потом опять будешь жаловаться? ))
Где требуется арифметика над индексами, там вектор обычно подходит плохо.
То размерность коллекции в единицы элементов, то требуется вставка/удаление из произвольных индексов.
Для обоих случаев есть более подходящие коллекции.
TB>И да, я всё ещё жду от тебя примера ситуации, в которой в сишарпе было неудобство со знаковыми индексами.
Арифметика сравнений проще в беззнаковом варианте.
V> vector<int> vec = { 1, 2, 3 };
V> for(auto i = vec.begin(), e = vec.end() - 1; i < e; ++i)
V> cout << *i << endl;
V>
Кажется, у нас тут UB) Причём такое же, как в цикле на беззнаковых индексах, оно тут на пустом векторе.
Крайне хреново, когда арифметика ограничивает тебя убогим диапазоном без запаса с обеих сторон, не так ли?
Кстати иногда таки нужен индекс внутри цикла. Само значение.
V>Итераторы появились вместе с векторами и сразу же через итераторы с вектором и работали.
Вектор это абстракция над массивами, массивы существовали задолго до векторов, и работали с ними через индексы.
Ну и до введения auto я чёто не помню любителей расписывать
(for std::vector<std::hash_table<std::string, std::vector<std::string> > >::iterator it = a.begin(); it < a.end(); ++it)
V>Где требуется арифметика над индексами, там вектор обычно подходит плохо. V>То размерность коллекции в единицы элементов, то требуется вставка/удаление из произвольных индексов. V>Для обоих случаев есть более подходящие коллекции.
Например?
V>Арифметика сравнений проще в беззнаковом варианте.
Здравствуйте, T4r4sB, Вы писали:
TB>Вектор это абстракция над массивами
Несвязанный набор слов.
Механизмом абстрагирования от типа контейнера является концепция итератора.
Адаптером конкретно массива под эту концепцию является тип std:array.
Помимо предоставление абстракции итератора, типы навроде std::array или новомодные ranges обладают еще одним важным преимуществом — не теряют информацию о своём размере при передаче в кач-ве параметров. Встроенные массивы же выхолащиваются до указателя (если только ф-ия не шаблонная, в которой размерность массива является параметром шаблона).
TB>Ну и до введения auto я чёто не помню любителей расписывать TB>
TB>(for std::vector<std::hash_table<std::string, std::vector<std::string> > >::iterator it = a.begin(); it < a.end(); ++it)
TB>
А их и не было.
В реальных проектах оно выглядело примерно так:
(for some_container_t::iterator it = a.begin(); it < a.end(); ++it)
Не знал про typedef?
V>>Где требуется арифметика над индексами, там вектор обычно подходит плохо. V>>То размерность коллекции в единицы элементов, то требуется вставка/удаление из произвольных индексов. V>>Для обоих случаев есть более подходящие коллекции. TB>Например?
Для заведомо маленьких коллекций размещение тела данных в динамической памяти является плохим решением.
А для произвольной вставки-удаления рулят деревоподобные структуры.
V>>Арифметика сравнений проще в беззнаковом варианте. TB>a<b? Вроде пишется одинаково...
Здравствуйте, vdimas, Вы писали:
V>Несвязанный набор слов.
Связанный, связанный.
V>Механизмом абстрагирования от типа контейнера является концепция итератора.
Только никто не пишет алгоритм, который универсален для векторов, листов и хеш-таблиц.
V>Адаптером конкретно массива под эту концепцию является тип std:array.
Ах, да, ещё std::array с той же проблемой с индексами.
V>Для заведомо маленьких коллекций размещение тела данных в динамической памяти является плохим решением. V>А для произвольной вставки-удаления рулят деревоподобные структуры.
Это не единственные примеры задач, где нужно обращение по индексу, причём индекс вычисляется.
V>>>Арифметика сравнений проще в беззнаковом варианте. TB>>a<b? Вроде пишется одинаково...
V>В беззнаковом варианте на одно сравнение меньше.
"a<b" пишется одинаково, и в асме число сравнений одинаковое.
А если ты про (a>=0 && a<b) ну это твои проблемы, что ты не смог это выделить в функцию и написать это так, чтоб это скомпилилось в одно сравнение...
Здравствуйте, T4r4sB, Вы писали:
V>>Несвязанный набор слов. TB>Связанный, связанный.
Курить "абстрагирование".
V>>Механизмом абстрагирования от типа контейнера является концепция итератора. TB>Только никто не пишет алгоритм, который универсален для векторов, листов и хеш-таблиц.
Этих алгоритмов и в стандартной библиотеке уже полно.
В Бусте еще больше.
И их именно так и пишут.
TB>Это не единственные примеры задач, где нужно обращение по индексу, причём индекс вычисляется.
Я на это уже отвечал — operator[] у итератора вектора, строки и прочих произвольного доступа имеет знаковый индекс.
И сдвиги самого итератора произвольного доступа так же дешевы, как оперирование указателями.
Вычисляй хоть обвычисляйся.
И сколько я не замерял — вычислять сразу указатель/итератор в цикле эффективнее, чем вычислять в том же цикле индекс, а потом по нему обращаться.
И да, оперирование итераторами более дешевое, чем ссылкой на std::vector<>, std::string и т.д. в случае передачи оных по ссылке.
Ты же видел сигнатуры стандартных алгоримов или алгоритмов Буста?
Такие сигнатуры не только абстрактны, но еще и эффективны, это ж плюсы, а не жабка какая-нить.
Еще пример, новомодный тип string_view — это операционный хелпер над парой итераторов, аналог абстрактного range_view с той разницей, что к типу привязали много операций, характерных для обработки строк.
Собсно уже устал агитировать открыть глаза на мейнстримовый уклон в обсуждаемых задачах.
Надо просто открыть глаза и задать себе однажды простой вопрос "а почему так?", всяко полезней будет, чем доставать своим упрямством коллег на весь интернет. ))
V>>В беззнаковом варианте на одно сравнение меньше. TB>"a<b" пишется одинаково, и в асме число сравнений одинаковое. TB>А если ты про (a>=0 && a<b) ну это твои проблемы, что ты не смог это выделить в функцию и написать это так, чтоб это скомпилилось в одно сравнение...
Оно коряво.
Сравнить:
if(a < b)
и
if(MyCoolComparer.IsLess(a, b))
Плюс для шарпа надо расписать комбинаторику сочетаний целочисленных типов в сигнатурах в конкретных типах.
Здравствуйте, vdimas, Вы писали:
V>Этих алгоритмов и в стандартной библиотеке уже полно. V>В Бусте еще больше. V>И их именно так и пишут.
Да, фигню написал.
Поправлюсь: никто не пишет программу так, чтоб можно было на 1 секунду поменять вектор на лист, обычно если применяют вектор, то значит уже так решили, что он тут лучше всего подойдёт.
Да, общие алгоритмы типа поиска выглядят универсально, но их реализация не всегда одинаковая для всех типов итераторов.
V>Я на это уже отвечал — operator[] у итератора вектора, строки и прочих произвольного доступа имеет знаковый индекс.
Никто не применяет [] к итератору, это тупо опасно, легко выскочить за диапазон.
V>Оно коряво. V>Сравнить: V>
V>if(a < b)
V>
V>и V>
V>if(MyCoolComparer.IsLess(a, b))
V>
Да, примерно так, только символов можно поменьше. Типа isBetween(a, 0, b);
Не вижу проблемы.
V>Плюс для шарпа надо расписать комбинаторику сочетаний целочисленных типов в сигнатурах в конкретных типах.
TB>Да, примерно так, только символов можно поменьше. Типа isBetween(a, 0, b);
Пока что использование статических классов как неймспейсов особо не прижилось, кроме известных стандартных классов, типа Console.
И это правильно, ИМХО, т.к. из-за легаси прошлых лет не сложилась система абстрактных/шаблонных свободных ф-ий и не устоялось их "стандартное" именование, как в плюсах.
Во многом из-за того, что вычисления/сравнение и т.д. над типами-числами нельзя было описывать естественным образом через генерики.
Теперь стало можно, но это вот только что.
Теперь должно пройти много лет, чтобы новые практики стали мейнстримом, обрастя по дороге новыми соглашениями и прочими правилами хорошего тона.
Ну и, реализация для случая 0, b может быть самой дешевой, т.е. надо как-то иначе называть, типа MyCoolComparer.CheckIndex(index, size);
V>>Плюс для шарпа надо расписать комбинаторику сочетаний целочисленных типов в сигнатурах в конкретных типах. TB>Не понял, поясни
Речь идёт о сравнении потенциально разных типов данных.
Соответственно, нужны сочетания сигнатур для знаковых/беззнаковых и для разной ширины бит, т.е. потребуется написать несколько перезагрузок ф-ии CheckIndex.
Теперь сравни с тем, что для "экосистемы" беззнаковых размеров, если опуститься на уровень встроенных массивов, то всё работает изкаробки.
На худой конец есть еще встроенные ср-ва — способ приведения знакового к беззнаковому описан в стандарте, и в аппаратуре ничего не стоит. Но обратное приведение специфировано лишь для неполного множества значений и его вообще рекомендуется избегать.
Это то, почему построить беззнаковую экосистему поверх навязанной знаковой гемморойно и вряд ли имеет смысл.
Зато если самому с 0-ля разработать под себя контейнеры, то всё выглядит вполне стройно.
Потому что вот так можно:
int[] arr = {1, 2, 3};
ulong i = 2; // uint i
Console.WriteLine (arr[i]);
А тут ошибка компиляции, требуется явное приведение к знаковому:
List<int> arr = new List<int> () {1, 2, 3};
ulong i = 2; // uint i
Console.WriteLine (arr[i]);
Понятно, что все приведенные контра относительно слабы и пахнут разве что небольшим геммороем, но зачем это для случая, скажем, когда я использую самописные контейнеры, выполненные как value-type, и оперирую в операциях чаще спанами, чем GC-ссылками на классы-контейнеры?
Плюс сам шарп представляет из себя такую экосистему, где можно и нужно избегать "синтаксического оверхеда" и прочего лишнего мусора/телодвижений в коде, иначе зачем он вообще? ))
Сегодня шарп даёт много для этого даже для случая расписывания собственной экосистемы эффективных контейнеров с 0-ля.
Например, даже если value-type контейнер необходимо передавать по ссылке, то последние версии шарпа и тут помогли:
Что тоже привносит хоть какую-то строгость в код — я могу распространять по цепочке вызовов константность ссылочных аргументов, типа как в С++.
А необходимость при вызове модифицирующих ф-ий подставлять ref я вообще приветствую — в плюсах мне чего-то подобного не хватает.
Такие модифицирующие ф-ии редки и должны обращать на себя внимание программиста.
Одно пока мест неудобно — для value-типов нельзя определить конструктор копирования, поэтому в коде надо следить, чтобы ненароком не скопировать такой контейнер в обычную переменную. Хотя, и в плюсах копирование контейнера чаще указывает на ошибку, но в плюсах хоть можно наследоваться/агрегировать и в своём типе уже запретить оператор и конструктор копирования... Но зато теперь как в плюсах можно копировать ссылку на свои value-типы, сверху в пол-тыка пишется маленькая обвязка для реализации std.move (оно именно так у меня и называется), в общем, на данном этапе развития шарпа жить уже хоть как-то можно. ))
