Rust обогнал Сишечку по скорости распаковки

А он типа маленький?

Что делать со всякими strcat? Делать по штуке на каждую комбинацию указателей?

что в зависимости от реализации у указателей могут быть дополнительные параметры, влияющие на размер

Сколько разных видов указателей может быть у реализации. Как сделать strcat, чтобы работал со всеми видами?

Если strcat работает только с одним видом, то дополнительные указатели в стандарте не нужны, это просто некие структуры, которые позволяют хранить данные где-то ещё и получать их оттуда.

Единственное место, где она инициализируется Do = EraseAll

Однако,

10 If an object that has automatic storage duration is not initialized explicitly, its value is indeterminate. If an object that has static storage duration is not initialized explicitly, then:

— if it has pointer type, it is initialized to a null pointer;

— if it has arithmetic type, it is initialized to (positive or unsigned) zero;

— if it is an aggregate, every member is initialized (recursively) according to these rules;

— if it is a union, the first named member is initialized (recursively) according to these rules.

То есть объявление без явного инициализатора означает инициализацию null, а в функции NeverCalled это уже изменение начального значения. Вот здесь меня интуиция подводит.

Слушайте, я не пойму.

В раст есть наследование логики класса - трейтов, более того, можно множественное наследование (например яве нельзя). Данные тоже технически можно наследовать.

Есть инкапсуляция, есть композиция, полиморфизм.

Но при этом в раст ООП нету, потому что мы его так не называем и делается он чуть иначе, чем в С++, а в яве при этом есть, потому что мы его так называем?

Или я просто не понимаю каких то основ?

Быть null в момент использования она не может, так как было бы разыменование null указателя.

Согласен, UB всё таки делает невозможное. Но с точки зрения оптимизатора, всё разумно. Там или null или EraseAll. Если null, значит UB, значит можно не учитывать этот вариант и считать константой.

Да. Классическое ООП наследует данные. В трейтах и интерфейсах явы данных нет, поэтому если мы ограничиваем наследование реализацией интерфейсов, то это уже не ООП.

Хорошо, в раст не ООП, потому что наследование данных нужно «эмулировать» через макросы или Enums - это допольнительные действия. Ок.

Но тогда что не так с ООП в луа? В луа тоже считается, что нет ООП, хотя есть ну вообще все, включая наследование данных, наример.

Меня не покидает смутное ощущение, что сами вот эти формулировки и принципы в целом условны. И это просто подходы, способы работы с кодом, чем законченные концепции цельные.

А он типа маленький?

Что делать со всякими strcat? Делать по штуке на каждую комбинацию указателей?

Добавить касты. Вообще проблемы нет.

Но UB позволяет добиться даже одновременноp == qи*p != *q.

UB позволяет добиться вообще чего угодно. Это буквально значит, что компилятор свободен высрать тебе абсолютно любое говно вместо кода или завернуть твой код в залупу и послать тебя в лес, напечатав тебе простыню сообщений об ошибках. Я не могу понять, почему многие сишники продолжают отрицать эту особенность их любимого язычка.

Так тогда у нас один тип указателей (в который кастуем для strcat) и несколько типов структур, которые можно преобразовывать в указатели. Зачем менять стандарт?

В луа тоже считается, что нет ООП, хотя есть ну вообще все, включая наследование данных, наример.

Какой синтаксической конструкцией? Насколько я знаю, готового нет, но можно сделать.

Зачем менять стандарт?

Кто говорил про «менять»? Я написал, что изначально стандарт составлен жопой и его авторы писали его будучи обдолбанными ослиной мочой, потому что в него всунута куча мусора (как, например, UB с кавычками) и в нём нет кучи полезных и уже существовавших вещей.

Сегодня его не надо менять, сегодня его надо выкинуть вместе с языком, который он описывает.

Как в любой стандарт под UB загнали всё, что в разных реализациях было по-разному.

Разные типы указатели в рамках одной программы не полезная вещь.

nsFld = {}
nsFld.__index = nsFld
setmetatable(nsFld, { __index = NsDb })

Ну вот я наследую от класса NsDb в класс nsFld. Получаю все методы и данные родительского класса.

Чем это отличается от «настоящего ООП»?

Чем это отличается от «настоящего ООП»?

Тем, что вместо nsFld = class { parent = NsDb } происходит какая-то магия после создания.

Также как в схеме «нет ООП, но можно сделать». Потому что вместо явного указания класса и его родителя приходится писать магию на замыканиях (которую можно макросом замести под ковёр и сделать реализацию ООП библиотекой).

А вот в Rust сделать ООП библиотекой не получится. Семантика не позволяет (нет операции «сделать объекту А поля объекта Б»).

Кажись до меня дошло.

В классическом ООП есть спец-команда для того же наследования.

В луа вручную реализуем наследование метатаблицами (по сути сторонней фичей, но суть получаем ту же), однако это не спец-команда для наследования.

В раст то же самое реализуем макросами или Enums.

То есть, приходится делать дополнительные действия различной степени нудности вместо встроенной родной реализации.

В итоге всетаки «сделать объекту А поля объекта Б» технически мы можем, но для этого нет спец-команды конкретно именно для этой задачи.

В смысле? В расте если функция ожидает структуру типа A, то нельзя сделать тип B и передать в эту функцию.

А насчет луа и схемы суть а том, что когда ООП на уровне языка как в Яве, Си++ или Объектном Си, то система классов у всех одинаковая, а в Луа один сделал классы с прототипированием, пара других с наследованием, но по-разному и эти классы плохо работают друг с другом.

Все, понял. Это именно композиция в раст - включение структуры. Теперь точно дошло. А в луа вместо встроенной команды эмуляция через метатаблицы.

Короче, суть я понял, спасибо.

Как в любой стандарт под UB загнали всё, что в разных реализациях было по-разному.

Что значит «как в любой стандарт»? Покажи мне другой язык программирования с такой же клоунадой вокруг UB, как это сделано в C и C++. Их просто нет, это вообще уникальный прецедент.

Экономия на спичках. На асме, я бы наверное обменял через дополнительный регистр какой-нибудь. tmp можно в регистр сохранить. Команда mov чуть ли не самая частая и распространенная и поэтому хорошо оптимизирована внутри процессора.

Выигрывают все-равно алгоритмы, а не эти спички. Ерунда это.

Современные компиляторы многое умеют, разворачивать циклы, использовать 128-битные регистры расширений типа SSE или MMX. Но алгоритм за тебя они не напишут.

Грубо говоря сравнивать строку с тысячей строк посимвольно или найти ее в хеш-таблице или хотя бы в дереве – разные вещи разного порядка. Уже на сотне строк дадут плюс в 10 раз. Но компилятор не сможет написать алгоритм за тебя.

А эти все спички, ерунда.

Не надо допускать к программированию особо одаренных и все будет нормально, никаких UB.

Покажи мне

показываю -

https://doc.rust-lang.org/reference/behavior-considered-undefined.html

Покажи мне

показываю -

https://doc.rust-lang.org/reference/behavior-considered-undefined.html

Немного разные трактовки термина. Компилятор Rust не выкинет тебе кривой кусок говна вместо кода при всём при этом. И для всех этих штук требуется unsafe{}.

Не надо допускать к программированию особо одаренных и все будет нормально, никаких UB.

Думаешь, если 90% сишников сжечь на костре, оно из стандартов C и C++ магическим образом само исчезнет? Я не прочь попробовать, так-то.

В трейтах

В трейтах на PHP данные есть

Компилятор Rust не выкинет тебе кривой кусок говна вместо кода при всём при этом

а где это утверждается? может не выкинет. может сейчас не выкинет, зато потом выкинет.

UB у них есть? есть. вопрос, как далеко они зайдут в эксплуатации UB в оптимизации кода.

Потому что в реальности они могут просто вписать -O0, -fno-string-alias, -ansi, и продолжить игнорировать эти правила. Многие считают что комитет только вредит, поэтому просто отказываются соглашаться на (стандарт == С).

В документации к Flang есть очень схожее описание:

Несмотря на соответствие стандартам, программисты Fortran обычно ожидают, что код, который успешно компилировался в прошлом, будет продолжать компилироваться и работать бесконечно. Стандарты иногда обозначают функции как устаревшие, устаревшие или даже удаленные, но это можно понимать только как препятствующее их использованию в новом коде — они, вероятно, всегда будут работать в любой серьезной реализации.

Видимо поэтому и нет компилятора где есть strict aliasing без -fno-strict-aliasing.

а где это утверждается? может не выкинет. может сейчас не выкинет, зато потом выкинет.

Все так, Страуструп об этом давно писал. Пусть появится хотя бы альтернативный компилятор типа gccrs: https://godbolt.org/z/WT16v5vfM

Зачем всё это?

Если это будет неполная поддержка слов для работы с сегментами, значит придется все равно использовать расширения компилятора. Получается практически бесполезное включение в стандарт, и как с __far в стандарте, так и без него, с сегментами без расширений не поработаешь.

Покажи мне другой язык программирования с такой же клоунадой вокруг UB, как это сделано в C и C++.

ANSI Common Lisp. В неопределённое стандартом попадает доступ к элементу массива, если позиция не «valid array indices for the array».

Или декларация типа «consequences are undefined if the value of the declared variable is not of the declared type».

Компилятор Rust не выкинет тебе кривой кусок говна вместо кода при всём при этом.

https://godbolt.org/z/xMWcGnK9E

В массиве из 10 элементов найдено 20 разных чисел :-).

Ты взял unsafe, прочитал за пределами массива и радуешься. Это какой-то гигатупняк просто.

Это контрпример к утверждению:

Компилятор Rust не выкинет тебе кривой кусок говна вместо кода при всём при этом.

Компилятор Rust при наличии unsafe оптимизирует также, как компилятор C.

Да, без unsafe не может быть UB. Но без unsafe некоторые алгоритмы просто невозможны.

ООП это про контекст внутри объекта а не про вложение структур друг в друга и вызов функций о которых вы размусоливаете.

ООП это и подход в том числе и контекст внутри объекта. И метод всетаки не функция.