Здравствуйте, T4r4sB, Вы писали:
TB>Если тебе нужен контейнер, то логика инкапсулируется в unsafe
Ну так и в нормальном использовании С++ такая же фигня. Всё голое одевается в врапперы/контейнеры и снаружи в голом виде никогда не высовывается.
На этих примитивах уже пишется бизнес логика.
TB>Если это твой код то можно эмулировать индексами в векторе вместо указателей
List реализовывать через вектор это конечно сильно...
Здравствуйте, netch80, Вы писали:
N>И это работает только потому, что количество элементов вектора гарантированно влезает в знаковый ssize_t.
Это твой код будет работать только с размерами контейнера влазящими в ssize_t.
N>Если бы таким же образом ты пытался обойти, как ты тут рядом рассказывал, сектора диска при допустимом LBA равном ~0, у тебя бы ограничительное условие не сработало.
if (v.size() == MAX_UINT64) то при i == MAX_UINT64 — 1, т.е. i + 1 == MAX_UINT64 будет останов, т.к. MAX_UINT64 < MAX_UINT64 == false
Так что всё прекрасно работает.
N>Переполнение в "i--" на последней операции, которое проходит только потому, что формализована семантика неотрицательных вычетов по модулю.
Внезапно (tm) так и работают беззнаковые. Это кольцо.
N> По сути — грязный хак, хоть и по стандарту.
Ты определись, таки хак или таки по стандарту?
N>Там вообще-то была ссылка, которую тебе лучше бы прочитать.
Ну прочитал я её, и что? Меня давно перестало интересовать мнение теоретиков, практика сильно вносит коррективы в "стройную теорию", так что я уж лучше и дальше практическим опытом буду руководствоваться.
N> Ну, если хочешь таки чего-то нового узнать
Там не было ничего для меня нового. Всё тот же слон.
Здравствуйте, T4r4sB, Вы писали:
TB>С обычного. Начальное значение, конечное значение, приращение.
И чем же мои примеры отличаются от "Начальное значение, конечное значение, приращение"?
TB>Незачот, Страуструп сам признал что это был фейл.
Вот так всегда с теоретиками, сначала они делают что то для практического применения а потом отрываются от земли и начинают что то додумывать где то там, в облаках, потеряв связь с реальностью.
С++ это всё таки близкий к железу язык, так что все красивые теории математиков надо обрезать прокрустовым ложем суровых реалий имплементации.
А реалии таковы что signed очень сильно мешает, особенно в kernel, где ядро сидит в самых верхних адресах и все указатели по сути будут отрицательными.
Здравствуйте, CreatorCray, Вы писали:
CC>Здравствуйте, flаt, Вы писали:
F>>Базовой и азбучной список стал на заре компьютеров, как только появилась возможность работать с указателями. Это для ассемблера и Си (ака высокоуровневый ассемблер) связанный список — базовая структура. CC>Rust пропихивают как системный язык, так что будьте бобры.
Здравствуйте, CreatorCray, Вы писали:
CC>>>Не, там дело в std который позволяет делать поток из лямбды. Это конечно бывает удобно, но вызывающий должен понимать что он делает. S>>Опечатки случаются даже у тех, кто понимает. CC>Там сама идея error prone.
Там простая, очевидная и удобная идея. А вот как сделать иначе, похоже, известно не только лишь всем.
S>>Собственно, это и есть главный selling point для Rust CC>Для меня это скорее повод на него не смотреть совсем. Ибо выглядит как "овчинка выделки не стоит".
Каждый сам для себя решает нужен ему Rust или нет. Но поскольку пипл хавает, то хотелось бы понимать, что за этим стоит и стоит ли оно того.
CC>Дык не будет же. Чудес в природе не бывает. Потому что придётся бороться с языком чтоб написать нужную бизнес логику, делая ошибки уже в логике, пытаясь её вывихнуть под заморочки языка.
К сожалению, пока в тусовке Rust-оманов преобладают агрессивные плюсохейтеры (некоторые из тех, с кем доводилось сраться на форумах, плюсами не очень-то и владели), поэтому сложно судить. Но, говорят, что на практике не так уж сильно приходится бороться. Говорят. Сам пока не проверял, т.к. было пару шансов вписать в Rust-о-проекты за последние два года, но в обоих случаях это был блокчейн/крипта.
CC>>>Свою реализацию таки можно заставить принимать только конкретные обёртки, которые будут заниматься вопросами владения. CC>>>Не идеально но всё же получше. S>>И как это будет выглядеть? CC>Лень сюда код писать, звиняй.
Здравствуйте, CreatorCray, Вы писали:
S>>Невладеющие указатели/ссылки вы предлагаете пустить в топку? CC>Ну в rust жеж их по сути в топку и пустили, не?
В Rust-е сумели сделать так, что язык допускает наличие нескольких иммутабельных ссылок или всего одной мутабельной ссылки. Плюс еще и в статике пытается за этим следить. Причем делает это на удивление хорошо.
Если кто-то считает, что в C++ можно как-то приблизится к этому уровню, то очень бы хотелось узнать как.
Здравствуйте, CreatorCray, Вы писали:
CC>С++ это всё таки близкий к железу язык, так что все красивые теории математиков надо обрезать прокрустовым ложем суровых реалий имплементации. CC>А реалии таковы что signed очень сильно мешает, особенно в kernel, где ядро сидит в самых верхних адресах и все указатели по сути будут отрицательными.
Какое значение имеет "знаковость" указателя к знаковости разности указателей?
Или даже если ты его сконвертировал в целое и обратно, какое кому дело до знаковости числа, представляющего указатель?
Здравствуйте, _NN_, Вы писали:
_NN>И что такого? _NN>В C рантайме есть код и на ассемблере, в Python есть код на C.
Ну это примерно как в С писать на ассемблере и говорить что это написано на С. На асме пишется то, что невозможно написать на самом языке. Так что использование unsafe это фактическая расписка в том, что на самом языке этот алгоритм реализовать таки нельзя.
Вопрос, напомню, был про возможность реализовывать алгоритмы на чистом языке, без принудительного выключения тех самых его фич, которые были объявлены как киллер фичи.
Потому как выглядит это несколько странно: вот у нас есть такие классные фичи, но их надо выключать если вы таки хотите писать полноценный код.
Здравствуйте, CreatorCray, Вы писали:
CC>Вопрос, напомню, был про возможность реализовывать алгоритмы на чистом языке, без принудительного выключения тех самых его фич, которые были объявлены как киллер фичи. CC>Потому как выглядит это несколько странно: вот у нас есть такие классные фичи, но их надо выключать если вы таки хотите писать полноценный код.
Я особо не следил тут за ходом событий.
Но как компетентному собеседнику могу сказать, что утверждать будь то прямо всё можно без unsafe глупо.
Любая статическая система имеет ограничения, это выходит из самого определения.
Мне непонятно почему это так всех беспокоит
Вполне возможно в будущем сделают по типу в .NET, помечать библиотеки либо как доверенные (где есть unsafe) либо как безопасные (где нет unsafe).
Правда в .NET и от этого похоже отказались.
Здравствуйте, CreatorCray, Вы писали:
CC>И чем же мои примеры отличаются от "Начальное значение, конечное значение, приращение"?
В первом ты сравниваешь не с конечным значением v.size()-1, ты перенёс единицу в другую часть. С точки зрения математики это не должно влиять, но грёбаная беззнаковость требует извращаться.
Во втором вместо нормального сравнения с нулём сравниваешь с размером вектора с другой стороны, с точки зрения математики это полнейший изврат, но грёбаная беззнаковость требует извращаться.
Понимаешь, я умею обходить эти ловушки в каждом конкретном случае, я могу весь код изуродовать кастами туда-сюда, но зачем, ради чего это?
CC>С++ это всё таки близкий к железу язык, так что все красивые теории математиков надо обрезать прокрустовым ложем суровых реалий имплементации.
Боже, школьные мамкины хакеры сразу вспомнились. "близость к железу кококо".
CC>А реалии таковы что signed очень сильно мешает, особенно в kernel, где ядро сидит в самых верхних адресах и все указатели по сути будут отрицательными.
Здравствуйте, CreatorCray, Вы писали:
CC>Здравствуйте, T4r4sB, Вы писали:
TB>>Дык контейнеры и в С++ пишутся с unsafe CC>В С++ нет понятия unsafe
К unsafe в С++ я отношу прямые обращения к аллокатору и ручные вызовы конструкторов и деструкторов.
Я даже написал про это в сообщении, которое ты цитируешь.
Это полный аналог растового unsafe: неприемлемо в пользовательском коде, но необходимо в контейнерах.
Здравствуйте, CreatorCray, Вы писали:
CC>Ну это примерно как в С писать на ассемблере и говорить что это написано на С. На асме пишется то, что невозможно написать на самом языке. Так что использование unsafe это фактическая расписка в том, что на самом языке этот алгоритм реализовать таки нельзя.
Нет, с чего это?
Ок, я тоже так могу:
ниабхадимасть вызовать диструктары вручную это фактическая расписка в том, что RAII в С++ ниработаит11111!!!1111))))00000
Здравствуйте, _NN_, Вы писали:
_NN>утверждать будь то прямо всё можно без unsafe глупо.
Угу. Концепция одного указателя с одной стороны, в теории, выглядит интересно но с другой стороны, на практике, регулярно будет мешаться под ногами и заставлять искать обходные пути просто потому что.
_NN>Мне непонятно почему это так всех беспокоит
Потому что всем надо не шашечки а ехать?
Здравствуйте, T4r4sB, Вы писали:
TB>грёбаная беззнаковость требует извращаться.
Ну капец какие извращения, арифметика начальной школы
TB>с точки зрения математики это полнейший изврат
Понятие кольца это всё ещё математика, так что мимо.
TB>Понимаешь, я умею обходить эти ловушки в каждом конкретном случае, я могу весь код изуродовать кастами туда-сюда
Не весь код а только пару мест где реально надо разница между беззнаковыми.
TB>но зачем, ради чего это?
Чтобы не извращаться со знаковостью в других местах.
Здравствуйте, CreatorCray, Вы писали:
CC>Здравствуйте, _NN_, Вы писали:
_NN>>утверждать будь то прямо всё можно без unsafe глупо. CC>Угу. Концепция одного указателя с одной стороны, в теории, выглядит интересно но с другой стороны, на практике, регулярно будет мешаться под ногами и заставлять искать обходные пути просто потому что.
Это из вашей практики написания кода на Rust?
В простейшем варианте мы используем Rc/Arc с RefCell и переносим все проверки в рантайм.
А далее «усложняем» код с простановкой времени жизни.
К тому же с каждой версией компилятор становится умнее, и, возможно, в будущем нужно будет описывать гораздо меньше руками.
_NN>>Мне непонятно почему это так всех беспокоит CC>Потому что всем надо не шашечки а ехать?
Как мне кажется все просто ищут примеры где на Rust сделать сложно, а в C/C++ просто.
На практике код бизнес логики будет примерно выглядеть также.
Создай объект, выполни действия, объект удаляется и освобождает ресурсы.
Зато Rust решил проблему пакетов одной системой, а в C/C++ каждый должен решать самостоятельно.
Здравствуйте, T4r4sB, Вы писали:
F>>Открой для себя ассист.
TB>А теперь попробуй с помощью отсосиста найти ошибку компиляции в гугл-тесте, образанном многоэтажными рекурсивными макросами.
