Rust vs C++

@ReYalp · Регистрация: 27.12.2017

Студворк — интернет-сервис помощи студентам

Кто-то писал на Rust? Стоит ли начинать учить? Насколько Rust хуже/лучше С++?

@Fulcrum_013 · 14.07.2020, 23:31

Сообщение от COKPOWEHEU

"гигантский удар по производительности" возникает только когда процесс пытается проломить изоляцию.

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

Добавлено через 1 минуту

Сообщение от Curry

Упомянутый в названии этой темы rust имеет годную для управления ресурсами автоматику.

Но не имеет годных средств для прикручивания к ней управления взаимосвязями. Так же как и годного ООП, отсутсвие которого и является одной из основных причин отставания веб-гуя и средств проекции БД в клиента от десктопа, где есть и дуплекс и годное ООП.

@Curry · 14.07.2020, 23:37

Сообщение от Fulcrum_013

Но не имеет годной для управления взаимосвязями.

Какая такая специфическая автоматика управления взаимосвязями встроена в С++?

@Fulcrum_013 · 15.07.2020, 04:03

Сообщение от Curry

Какая такая специфическая автоматика управления взаимосвязями встроена в С++?

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

Добавлено через 10 минут
Вообще как видим раст пытается лечить недопонимание базовых для ООП конценций, к примеру композиции и агрегации используемые для взаимосвязей между активными объектами, и сути их отличия от владения пассивными буферами (именно это и пытвется делать борровинг а не что то еще, при этом получая в результате сплошные сапоги в смятку), концепции наследования и т.д. Т.е родился в результате изнасилования моска явой, а не в результате достижения каких то границ возможностей плюсов. Ну и как результат мертворожден в принципе, ибо рубит в результате как минимум то для чего ООП предназначено - упрощение реализации моделей сущностей предметной области.

Добавлено через 3 часа 5 минут

Сообщение от COKPOWEHEU

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

И опять абсолютный бред. РАзница между языками она именно в их синтаксисе и семантике а не в том во что в результате скомпилится. Именно в том скока надо моски покомпостировать чтобы получить код решающий задачу. На плюсах это гораздо гораздо проще за счет годной автоматики и средств создания высокоуровневых абстракций которых все остальное лишено напрочь.
Т.е. и тут уровень вашей компетентности ниже плинтуса.

@COKPOWEHEU · 15.07.2020, 07:55

Сообщение от Fulcrum_013

Т.е. опять вы в вопросе абсолютно некомпитентны от слова совсем. Только повторяете крики безсовестных/безмозглых евангелистов.
Т.е. и тут уровень вашей компетентности ниже плинтуса.

Может хватит уже этой мантры? От того, что вы свой бред повторите еще 500 раз, он правдой не станет.

Сообщение от Fulcrum_013

Он не обеспечивает автоматику управления жизненным циклом...

Я спрашивал не об этом. Вот никому он не мешает (если не надо - не пользуются), только у вас постоянно какая-то неадекватная реакция со словонедержанием. Такое ощущение, что вы чего-то от него ожидали, а потом он вас подвел.

Сообщение от Fulcrum_013

Гигантский удар по производительности возникает в результате необходимости синхронизации каждого доступа к переменным

Ах да, у вас же проблемы не то что с синхронизацией и обменом данными между потоками (или процессами, разница невелика), но даже с пониманием зачем это нужно.

Сообщение от Fulcrum_013

Именно в том скока надо моски покомпостировать чтобы получить код решающий задачу. На плюсах это гораздо гораздо проще

Именно для этого придумали высокоуровневые языки. При прочих равных для решения задачи на каком-нибудь Питоне потребуется на порядок меньше кода. Это мы уже обсуждали.

Сообщение от Fulcrum_013

Ну найдите для начала апи контролов в линухе. Именно в апи линухи а не какого то стороннего десктопа, при этом универсальное для всех десктопов. А потом апи работы со звуком. А потом апи работы с HTTP. Ну и т.д.
А то что впихнули в XP в резульате чего и произошел такой рост в размерах - .Net ну это действительно мусор

Да, и еще вопрос: почему каждый раз, когда я задаю прямой вопрос о размере дистрибутива винды или ее ядра, вы старательно переводите тему на графику, сеть и прочий функционал, не имеющий отношения ни к тому, ни к другому?
Ну и в продолжение вопроса: почему функционал "искоробочного" дистрибутива винды настолько отстает от аналогичного линукса по функционалу, но превосходит по объему?

@vantfiles · 15.07.2020, 11:56

Сообщение от Fulcrum_013

именно в их синтаксисе и семантике

А не в парадигме?
Не хотите обсудить синтаксис и семантику языка Forth?

@Curry · 15.07.2020, 17:31

Сообщение от Fulcrum_013

Там встроен автоматический запуск любого пользовательского кода при выходе объекта из скопа.

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

Сообщение от Fulcrum_013

недопонимание базовых для ООП конценций

Вы правда думаете что разработчики rust-а скрптобыдлокодеры которые ООП не освоили?

Сообщение от Fulcrum_013

именно это и пытвется делать борровинг

Из вашего предложения (откуда цитата) невозможно ничего понять. Borrowing - средство определения времени жизни переменной во время компиляции. В плюсах ничего подобного нет.

Сообщение от Fulcrum_013

Т.е родился в результате изнасилования моска явой

Нет. Тогда бы там GC был. А rust и создавали что бы уйти от GC, но сделать более безопасной работу с памятью чем в С++.

@Fulcrum_013 · 15.07.2020, 23:28

Сообщение от Curry

Соответственно, автоматики там не меньше чем в плюсах.

Не совсем правильный вывод. Возможности запуска автоматики те же. А вот возможности ее кастомизации пропорциональны возможностям языка в плане ООП и метапрограммирования. В расте оные возможности порублены по самые немогу.

Сообщение от Curry

Вы правда думаете что разработчики rust-а скрптобыдлокодеры которые ООП не освоили?

Если бы они его осилили они бы глупостей про опасность наследования не писали бы. И не ломали бы его. Точно так же как не было бы никаких криков про опасность множественного наследования - это инструмент решения проблемы хрупкого базового класса.

Сообщение от Curry

Нет. Тогда бы там GC был.

Не обязательно. То что моск в изнасиловали явой никак не мешает при правильном подходе к обучению в универе понять почему GC юселесс.

Сообщение от Curry

А rust и создавали что бы уйти от GC, но сделать более безопасной работу с памятью чем в С++.

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

Сообщение от Curry

Из вашего предложения (откуда цитата) невозможно ничего понять. Borrowing - средство определения времени жизни переменной во время компиляции. В плюсах ничего подобного нет.

А ничего подобного и не нужно и даже вредно. Т.е. существует концепция владения - т.е. ресурс существует пока на него есть ссылка.
Есть концепция композиции - ресурс безоговорочно уничтожается при разрыве конкретной ссылки, но это далеко не единственная из возможных причин уничтожения. Есть концепция агрегации - т.е. ресурс взят в пользование и может точно так же помереть в любой момент. Все что должны в этом случае ресурсы - оповестить тех кто на них ссылается, а те кто ссылается должны быть готовы к тому что ресурсы помрут. Это растет из того что для объектов критерии их уничтожения концептуально изветсны только им самим, все остальное - оптимизации реализации этих концепций. При этом очевидно что в компайлтайме никакую из этих концепций реализовать не удастся.
Какую из этих концепций моделирует борровинг? Вот в том то и дело что никакую. В результате неизбежно получаются сапоги в смятку которые ни к селу ни к городу.
А обеспечить безопасность работы со указателями способно только соблюдение правил взаимосвязей.

@Curry · 16.07.2020, 00:19

Сообщение от Fulcrum_013

и метапрограммирования.

Это вы про то что в rust не нужно писать ключевое слово template ? Так и без него ясно, если есть уголковые скобки.
А, так то там возможностей то побольше. И с учётом, как быстро он развивается, то будет ещё больше.
Отдельного внимания заслуживают макросы rust-а. Типобезопасные, а не простая текстовая замена идущая из 80ых.

Сообщение от Fulcrum_013

Безопасность она в понимании концепций оной работы, а не в том что компилятор отслеживает там чего то что он знать не может в принципе.

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

Сообщение от Fulcrum_013

Т.е. существует концепция владения - т.е. ресурс существует пока на него есть ссылка.

Да, да. В учебнике по rust так и написано : владение, заимствование, время жизни.
Создатели rust, как раз учли мировой накопленный опыт программирования на плюсах и ввели заимствование.

Сообщение от Fulcrum_013

Есть концепция композиции - ресурс безоговорочно уничтожается при разрыве конкретной ссылки

Это не встроено ни в С++, ни в Rust, и решается смартпоинтерами.

Сообщение от Fulcrum_013

Все что должны в этом случае ресурсы - оповестить тех кто на них ссылается, а те кто ссылается должны быть готовы к тому что ресурсы помрут.

Это более высокий уровень, не встроенный в язык. Т.к. автоматика вызова кода перед уничтожением переменной есть, то на rust это реализуется не хуже.

Сообщение от Fulcrum_013

При этом очевидно что в компайлтайме никакую из этих концепций реализовать не удастся.

Композиции, биндинги всякие, это и не реализуется на уровне компилятора.

Сообщение от Fulcrum_013

Какую из этих концепций моделирует борровинг?

Никаких биндингов он не реализует. Он позволяет отследить время жизни данных более тонко чем сишный простой выход из скопа.

Сообщение от Fulcrum_013

А обеспечить безопасность работы со указателями способно только соблюдение правил взаимосвязей.

С указателями ("сишными") в Rust можно работать только в блоках unsafe, что подчёркивает что к отладке этих блоков нужно подойти более тщательно с одной стороны, и предполагает требование минимизации таких блоков с другой.
А сишный код, считай, весь в блоке unsafe.

@Fulcrum_013 · 16.07.2020, 01:39

Сообщение от Curry

Это вы про то что в rust не нужно писать ключевое слово template ?

template template где? нонтайп аргументы где? специализация где? возможность наследования от аргумента шаблона где? Зависимые типы где? Т.е. по сути тот же заменитель void* что и дженерики а не полноценные шаблоны.

Добавлено через 3 минуты

Сообщение от Curry

Отдельного внимания заслуживают макросы rust-а. Типобезопасные, а не простая текстовая замена идущая из 80ых.

Неограниченные макросы зло но зло неизбежное. Другого варианта вынести из под капота компилятора хотя бы какую то часть функциональности code rewrite не существует. как бы не были развиты возможности шаблонов и т.д. но они всегда будут ограниченны по сравнению с полноценным code rewrite живущим под капотом у компилятора.

Добавлено через 3 минуты

Сообщение от Curry

Да, да. В учебнике по rust так и написано : владение, заимствование, время жизни.

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

Добавлено через 7 минут

Сообщение от Curry

С указателями ("сишными") в Rust можно работать только в блоках unsafe, что подчёркивает что к отладке этих блоков нужно подойти более тщательно с одной стороны, и предполагает требование минимизации таких блоков с другой

Что только затруднит все тем кто понимает что делает и никак не ограничит тех кто не понимает - указатель он лепит из затого что считает что понимает что делает, поэтому точно так же прилепит unsafe. При этом если типа арифметика указателей унсафе то с каких дел сафе стала арифметика индексов массивов в том числе ассоциативных? Это точно такие же указатели. О каком непониамнии работы с указателями и одновременном понимании работы с массивами вообще может идти речь? На самом деле сафе/унсафе бывают разработчики, а не какой то один из видов указателей.
Т.е. все эти унсафе - точно так же самые обычные сапоги в смятку.

Добавлено через 1 минуту

Сообщение от Curry

Композиции, биндинги всякие, это и не реализуется на уровне компилятора.

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

Добавлено через 3 минуты

Сообщение от Curry

Это не встроено ни в С++, ни в Rust, и решается смартпоинтерами.

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

Добавлено через 4 минуты

Сообщение от Curry

Он позволяет отследить время жизни данных более тонко чем сишный простой выход из скопа.

При выходе из скопа объект на стеке безоговорочно уничтожается - т.е. используется композиция. А соответственно те кто на него ссылаются априори должны использовать агрегацию - т.е. быть готовыми к тому что он умрет своей смертью, и на их работоспособность то что он помер никак влиять не должно. Что в этом плане дает борровинг? В том то и дело что ничего. Это в принципе нельзя реализовать без рантаймовых оповещений. Кстати вот это - непонимание того что уничтожение объекта по выходу из скопа на самом деле ни что иное как композиция, и есть результат изнасилования моска явой - там композиции как таковой нет, есть только нелепые попытки скостылить ее на основании владения/совладения. Отсюда и все эти "ужасные проблемы" плюсов - из непонимания концепции композиции.

Добавлено через 8 минут

Сообщение от Curry

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

А логики которую можно отследить в компалтайме не существует в принципе.

Сообщение от Curry

Вот и borrowing для защиты от ошибок.

Каких ошибок? Непонимания того, какую концепцию взаимосвязи используют для той или иной ссылки? Никакой компилятор не в состоянии защитить от недопонимания задачи.
Мало того - вырвиглазий синтаксис в сочетании с костылентем ООП - это гигантский источник труднообнаруживаемых ошибок, как в алгоритмах так и в архитектуре. Для того чтобы С или процедурный паскаль оказались неюзабельными для подавляющего большинства задач еще в 80-х хватило только второго.

Добавлено через 37 минут

Сообщение от Curry

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

Для того чтобы это реализовалось не хуже нужны указатели на члены класса, нонтайп агрументы и template-template как минимум. Иначе вместо унивресальной параметризируемой реализации будете лепить весь механизм вручную на каждую ссылку.

@Curry · 16.07.2020, 23:09

Сообщение от Fulcrum_013

template template где?

higher-kinded polymorphism ? Кажется, ещё не завезли. Хотя обещают. Rust развивается.

Сообщение от Fulcrum_013

нонтайп аргументы где? специализация где? Зависимые типы где?

Это есть.

Сообщение от Fulcrum_013

Неограниченные макросы зло

Зло. Только в плюсах их не стоит считать неограниченными, у них возможностей почти нет, зато очень не безопасные.

Сообщение от Fulcrum_013

Другого варианта вынести из под капота компилятора хотя бы какую то часть функциональности code rewrite не существует.

Существует в других языках. И везде возможна генерация исходников отдельной программой - классика метапрограммирования.
В общем, макросы rust-а продвинутей сишных, хотя, тоже не универсальные.

Сообщение от Fulcrum_013

Т.е. получается борровинг

Из того что вы пишите, следует что вы не поняли что такое borrowing. Есть учебник по rust, есть примеры.

Сообщение от Fulcrum_013

Что только затруднит все тем кто понимает что делает

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

Сообщение от Fulcrum_013

никак не ограничит тех кто не понимает - указатель он лепит из затого что считает что понимает что делает, поэтому точно так же прилепит unsafe.

Если ему объяснить как переводится unsafe, и выработать у него ассоциацию, что unsafe, это как стоять возле прокатного стана в халате с развивающимися полами, то не будет.
На плюсах ведь как: хочет начинающий что то сделать, находит статью отсканированную с книжки 80ых, привыкает к арифметики указателей. А про rust во всех статьях unsafe и предупреждения.

Почему, вы думаете, распространены языки с GC? У этих языков порог входа низкий. Самый-самый начальный порог. В этом легко убедиться посмотрев в разделе "плюсы для начинающих" какие ошибки в работе с памятью совершают новички.
Самый простой способ их от этого избавить - ввести GC. Новички же ещё не создают системы из связанных объектов, ресурсами кроме памяти не рулят. И им с GC проще. Видимо, первая задача обучения программирования "ан масс" состоит в том что бы не бросили учиться на первых порах. А когда научаться хоть чему то, то уже и привыкли к GC.

Rust, впрочем, никак не назвать языком с низким порогом вхождения. Правда, начинающий на rust-е будет в значительно большей степени застревать на этапе компиляции и читать сообщения компилятора, а на плюсах он быстро добирается до неинформативных "программа выполнила недопустимую операцию ...". Есть разница.

@Fulcrum_013 · 17.07.2020, 04:00

Сообщение от Curry

зато очень не безопасные.

Еще раз - безопасными/небезопасными бывают кодеры а не инструментыю.

Сообщение от Curry

Существует в других языках.

НЕ существует. Суть как раз в возможности замены производного кода в произвольном месте.
Очевидно что вот такого никакими ограниченными макросами сделать не удатся, придется копипастить

C++
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
#define BinOps Op(+) Op(-) Op(*) Op(/) Op(%) 
#define BitOps Op(^) Op(|) Op(&) Op(>>) Op(<<)
#define LogicOps Op(&&) Op(||) 
#define AssignBinOps Op(+=) Op(-=) Op(*=) Op(/=) 
#define AssignBitOps Op(|=) Op(%=) Op(&=) Op(^=) Op(<<=) Op(>>=)
#define CmpOps Op(<) Op(>) Op(>=) Op(<=) Op(==) Op(!=)
#define ConstOps BinOps  BitOps  CmpOps  LogicOps
#define AssignOps AssignBitOps AssignBinOps  
#define AllOps ConstOps AssignOps
//-------
#define Op(op) template <class RS> decltype(Val<TConstValue>() op Val<typename RS::TConstValue>()) operator op  (const TProperty<RS>& r) const { return Get() op (typename RS::TConstValue)(r); };
        ConstOps //Op(=)
#undef Op
#define Op(op) template <class RS> decltype(Val<TValue>() op Val<typename RS::TConstValue>()) operator op  (const TProperty<RS>& r)  { return Get() op (typename RS::TConstValue)(r); };
        ConstOps //Op(=)
#undef Op
#define Op(op)  template <class RT> Where<!IsProperty<UnRef<RT>>, decltype(Val<TConstValue>() op Val<RT>())> operator op (RT&& r) const {\
            return (Get() op std::forward<RT>(r));\
        };
        ConstOps 
#undef Op
#define Op(op)  template <class RT> Where<!IsProperty<UnRef<RT>>, decltype(Val<TValue>() op Val<RT>())> operator op (RT&& r)  {\
            return (Get() op std::forward<RT>(r));\
        };
        ConstOps
#undef Op
#define Op(op) template <class LT> friend  Where<!IsProperty<UnRef<LT>>, decltype(Val<LT>() op  Val<TConstValue>())>  operator op (LT&& l, const TProperty& r) { return l op r.Get(); };
        AllOps
#undef Op
#define Op(op) template <class LT> friend  Where<!IsProperty<UnRef<LT>>, decltype(Val<LT>() op  Val<TValue>())>  operator op (LT&& l,       TProperty& r) { return l op r.Get(); };
        AllOps
#undef Op

Добавлено через 2 минуты

Сообщение от Curry

Из того что вы пишите, следует что вы не поняли что такое borrowing.

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

Добавлено через 1 минуту

Сообщение от Curry

Лучше самому себя обезопасить

Чем оно может обезопасить то?

Добавлено через 31 минуту

Сообщение от Curry

В этом легко убедиться посмотрев в разделе "плюсы для начинающих" какие ошибки в работе с памятью совершают новички.

На то они и новички чтобы ошибки совершать. Пусть учатся - в конце концов не поняв что указатеь это тензор программистом не стать. Плюсы, матан, линейная алгебра, теория реляционных БД и основы информатики (именно в виде науки об алгоритмах и т.д.)- порог вхождение в обучение специальности. О каком вхождении в более-менее серьезные задачи можно вообще без этого говорить?
Еще раз - порог вхождения выдвигают задачи а не языки.

Сообщение от Curry

Самый простой способ их от этого избавить - ввести GC.

Да вот нифига подобного. Использование искоробочных смартпоинтеров STL к примеру абсолютно аналогичны вызову GC.Collect после каждого изменения ссылки - их спецом такими делали для облегчения перехода с явы, а для чего то более-менее серьезного они не пригодны в принципе - те же сапоги в смятку вместо композиции. При этом отмазка про то что типа нужно думать где вики расставить не канает - без них GC течет точно так же, с той лишь разницей что вики у STL отрабатывают корректно, в отличии от толп зомбаков у GC.
Самый простой способ избавить их от ошибок - научить понимать что они делают. Все эти беды от недопонимания задачи. И от языка это не зависит. Точно так же напортачат с арифметикой индексов массивов - это точно такие же указатели.
При этом работе с памятью учатся очень быстро. Не помню чтобы видел утечки после первого курса. Да и на первом курсе они были далеко не у всех. И это при тупо ручных new/delete как это было принято в середине 90-х. Потому что банально сначала объяснили что такое память как она устроена и т.дить когда . а потом уже сказали юзать динамическое распределение в лабах. С хотя бы STL-скими контейнерами и смартами утечь память - ну это настолько тупыми и упертыми надо быть что GC не просто течь, сифонить будет.
Опять же с точки зрения корректности работы модели для ООП утечки как то фиолетовы. А вот несвоевременная деинициализация объектов - это просто катастрофа в плане корректности. И определить когда рассогласование превышает допустимый предел чтобы в ручную вызвать GC.Collect практически нереально, а тем более для новичков.
Так что в этом плане языки с GC не дают абсолютно никаких преимуществ, окромя сплошных недоствтков - деинициализацию объектов и разрыв взаимосвязей нужно поизводить вручную иначе потечет - критерии ненужности в ООП и в GC кардинально противоположны, без ручного обрыва взаимосвязей ненужных по правилам модели объектов GC их мусором не посчитает. Это уже неоднократно показывалось. Точно так же как и беда-беда с ресурсами которая опять же решается только ручной деинициализацикй - т.е. ничем не отличается от ручных вызовов delete.
Так что про порог вхождения - это сказки. Ничего большего чем написание хеллоуверда таким вошедшим доверить нельзя все равно, да и то исключительно под присмотром 3-х квалифицированных спецов на каждого.

Добавлено через 2 минуты

Сообщение от Curry

это как стоять возле прокатного стана в халате с развивающимися полами, то не будет.

Не поверите но именно так там и загорают. Ото на мостиках для перехода через линию прокатки. Аккурат от проходящих слябов ИК шибет метров с двух - и не шибко жарко и загораешь. А к опасному оборудованию залелть там ой как постараться надо. Оно просто настолько не маленькое - к примеру когда обслуживают главный привод (ну эт такой маторчик постоянного тока) в нем открывают дверь в корпусе и туда заходит бригада человек 20, ну прям как более-менее сурьезная задача, к которой с оными мусоросборниками и скриптами тоже никак не подлезешь от слова совсем.

Добавлено через 10 минут

Сообщение от Curry

На плюсах ведь как: хочет начинающий что то сделать, находит статью отсканированную с книжки 80ых, привыкает к арифметики указателей. А про rust во всех статьях unsafe и предупреждения.

А типа основы информатики он параллельно не изучает где ему рассказывают что это и с чем это едят? О каком тогда вообще вхождении куда то окромя как в море глюков может идти речь, даже при арифметике индексов массивов - это точно такие же указатели.
А вот если изучает - то надо таки это пощупать на практике обязательно. А то хоть мульен унсафоф придумай накосячит если не с указателями то с индексами массивов и ассоциативными ключами - это точно такие же указатели. Как кстати и итераторы, которые в купе со смартами ничто иное как средство разделения указателей на две категории - владеющие и имеющие мутабельную арифметику.

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

Добавлено через 26 минут

Сообщение от Curry

Почему, вы думаете, распространены языки с GC?

Исключительно по причине нехватки квалифицированных специалистов. Конторы которым их не хватает набирают людей фактически с улицы (переход на жабу с паскалей и васиков за бугром во всех школах завершился 2000-му, так что с тем чтобы найтить желающих проблем нет). Потом для того чтобы разгрести что они набыдлокодили нанимают еще быдлокодеров с той же улицы ну и по кругу (отсюдова и такой процент типа их популярности - те же программитсы 2000 только в гораздо более крупном масштабе). Долго, дорого, глючно, результат в эксплуатации неэффективен и не удобен. если вообще до экскплуатации дело доходит, но в свете того что квалифицированных спецов даже гуглам и эпплам не хватает катастрофически - лучше чем никак.

Добавлено через 37 минут

Сообщение от Curry

Предполагается что unsafe используются на низком уровне, в библиотеках многократно используемых, а не в коде конечного приложения (по возможности).

Арифметика итераторов/индексов массивов и т.д. - это точно такая же арифметика указателей. Индекс массива - точно такой же указатель. От смены правил разыменования и точки отсчета в адресном пространстве его суть не меняется - указатель есть тензор. Точно так же как и для ассоицативных массивов. Не говоря уже про оффсеты в файлах и т.д. Т.е. по вашему вcе это тоже нужно унсафе помечать и нигде кроме как под капотом у либ не использовать? А либы по вашему тоже с Луны прилетают или с Беттельгейзе?

Добавлено через 6 минут
При этом похерить принудительное удаление объектов == сделать язык абсолютно непригодным для ООП - критерии ненужности объектов в ООП определяются критериями возможности/невозможности продолжения их существования по правилам конкретно взятой предметной области, которым на наличие ссылок сугубо паралельно, так же как и композиции. При этом и кастомизацию автоматики автогенерация/автовызов деструкторов дает только в сочетании с ручным управлением памятью.

Добавлено через 6 минут
При этом похерить принудительное удаление объектов == сделать язык абсолютно непригодным для ООП - критерии ненужности объектов в ООП определяются критериями возможности/невозможности продолжения их существования по правилам конкретно взятой предметной области, которым на наличие ссылок сугубо паралельно, так же как и композиции. При этом и кастомизацию автоматики автогенерация/автовызов деструкторов дает только в сочетании с ручным управлением памятью. А делает GC не нужным как известно не какая та супер-дупер автоматика языка, а соблюдение правил работы взаимосвязей принятых в ООП, автовызов деструкторов в сочетании с ручным управлением временем жизни объектов на куче дает только возможность ее реализовать для нее автоматику под разные схемы. Задаче же управления памятью - это вообще из другой области - а именно найти кусок памяти под буфер требуемого размера. Либо решение этой задачи подстраивается под паттерн распределения каждого конкретно взятого экземпляра структур данных, либо никакой скорости не будет в принципе.

Добавлено через 2 часа 29 минут

Сообщение от Curry

Правда, начинающий на rust-е будет в значительно большей степени застревать на этапе компиляции и читать сообщения компилятора,

банальный пример

C++
1
2
3
4
Instance* Foo(){
    int a =5;
    return CreateInstance(&a);
}

А теперь попробуйте определить насколько это корректно если оный CreateInstance который создает какой то объект живет в другом юните трансляции а то и в dll код которого в компайлтайме не доступен - банально абсолютно неизвестно что он там делает с этим указателем - захватывает в себя али так плюшками балуется. Ну вот в реальной жизни все будет именно так практически на каждом шагу. А соответственно сапоги в смятку ничем не помогут.

@Fulcrum_013 · 17.07.2020, 13:02

Сообщение от Curry

higher-kinded polymorphism ? Кажется, ещё не завезли. Хотя обещают. Rust развивается.

Да куда уж им там если nullptr завезти не осилили. Только одного этого достаточно для того чтобы язык был неюзабелен в ООП от слова совсем. Не говоря уже про возможность безопасной или вообще какой либо альтернативной реализации тех же контейнеров и т.д.

@COKPOWEHEU · 18.07.2020, 12:08

Сообщение от Fulcrum_013

Еще раз - безопасными/небезопасными бывают кодеры а не инструментыю.

Но язык может мешать или помогать обеспечивать безопасность. В лучшем случае бить кодера по рукам если тот творит что-то непотребное, но можно и по-тихому прибираться за ним.
Взять ту же работу с памятью - насколько проще получить утечку в С++ по сравнению с bash или lua.

Сообщение от Fulcrum_013

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

А если программировать приходится не-программисту. Админу допилить софт чтобы не падал, художнику прикрутить плагин, гейм-дизайнеру подправить коэффициенты или диалоги.
Не путайте предметную область, в которую свой порог входа с языком программирования, в котором свой. Физик-магнитчик может прекрасно знать как спин-орбитальное взаимодействие скажется на проводимости прибора, но сумеет ли он описать эту модель на С++? Да, кстати, для подобных задач ни динамическая память, ни вырвиглазные шаблоны не нужны.

Сообщение от Fulcrum_013

Исключительно по причине нехватки квалифицированных специалистов. Конторы которым их не хватает набирают людей фактически с улицы<...> Долго, дорого, глючно

И все равно это оказывается выгоднее, чем искать мега-хакеров, которые способны с машинном коде записать решение.

Сообщение от Fulcrum_013

в свете того что квалифицированных спецов даже гуглам и эпплам не хватает катастрофически - лучше чем никак.

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

Сообщение от Fulcrum_013

указатель есть тензор

Что вы понимаете под тензором? Обычное-то определение (матрица линейного преобразования из одного вектора в другой) тут явно не подходит.

@ReYalp · 18.07.2020, 13:22 **[ТС]**

COKPOWEHEU,

Сообщение от COKPOWEHEU

Что вы понимаете под тензором? Обычное-то определение (матрица линейного преобразования из одного вектора в другой) тут явно не подходит.

мне тоже интересно)

@Fulcrum_013 · 18.07.2020, 16:19

Сообщение от COKPOWEHEU

Взять ту же работу с памятью - насколько проще получить утечку в С++ по сравнению с bash или lua.

Пруф бкдет или как вегда повторять рекламные бредни будете?

Добавлено через 4 минуты

Сообщение от COKPOWEHEU

А если программировать приходится не-программисту. Админу допилить софт чтобы не падал, художнику прикрутить плагин, гейм-дизайнеру подправить коэффициенты или диалоги.
Не путайте предметную область, в которую свой порог входа с языком программирования, в котором свой. Физик-магнитчик может прекрасно знать как спин-орбитальное взаимодействие скажется на проводимости прибора, но сумеет ли он описать эту модель на С++? Да, кстати, для подобных задач ни динамическая память, ни вырвиглазные шаблоны не нужны.

Порог входа задеет именно предметная область. Квалификация в первую очередь означет умение адаптировать задачи из люой предметной области к машинному счету.
А соответсвенно если софт "допиливает" не квалифицированный программист то это самый обычный быдлокодинг по определению. В подавляющем случае это вызван тем что и саму исходную софтину делали быдлокодеры которые не предусмотрели нужных утилит подготовки данных. Особенно когда это такой фигни как "подправить диалоги" и т.д. касается.

Добавлено через 5 минут

Сообщение от COKPOWEHEU

Что вы понимаете под тензором?

То же что и везде - объект не зависимый от системы координат в которой его рассматривают. Т.е. от смены СК меняются только значения его компонентов и правила преобразования. Сама суть объекта остается неизменной.

Сообщение от COKPOWEHEU

Обычное-то определение (матрица линейного преобразования из одного вектора в другой) тут явно не подходит.

Как всегда слышали звон да не знаете где он. Матрица преобразования к тензору только тем боком что правила перевода тензора из одной СК в другую можно задавать в т.ч в виде матрицы.

@COKPOWEHEU · 18.07.2020, 16:46

Сообщение от Fulcrum_013

Пруф бкдет или как вегда повторять рекламные бредни будете?

Какой вам пруф если вы только рекламным бредням верите? Таких у меня нет, уж извините, я больше по реальному опыту говорю, чем как вы, по рекламкам.

Сообщение от Fulcrum_013

Порог входа задеет именно предметная область.

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

Сообщение от Fulcrum_013

А соответсвенно если софт "допиливает" не квалифицированный программист то это самый обычный быдлокодинг по определению.

Ну, зачастую именно так и получается. И тем не менее, задача языка (среды) в том, чтобы даже так код мог хоть криво-косо, но работать, а не сыпать сегфолтами по три раза на строчку кода.

Сообщение от Fulcrum_013

То же что и везде - объект не зависимый от системы координат в которой его рассматривают.

Эта штука называется инвариант.

Сообщение от Fulcrum_013

Как всегда слышали звон да не знаете где он. Матрица преобразования к тензору только тем боком что правила перевода тензора из одной СК в другую можно задавать в т.ч в виде матрицы.

Ну-ну, порадуйте физика, который буквально год назад занимался пересчетом тензора пьезокоэффициентов (матрица 3х6) по разным кристаллографическим направлениям (вот там да, умножение на матрицы 3х3). Где же это вы выкапаваете свои "определения" и "проценты", из какой конкретно рекламной брошюрки?

@Fulcrum_013 · 18.07.2020, 21:45

Сообщение от COKPOWEHEU

Какой вам пруф если вы только рекламным бредням верите? Таких у меня нет, уж извините, я больше по реальному опыту говорю, чем как вы, по рекламкам.

Т.е. уровень вашей компетентности в вопросе ниже нуля как всегда? GC никогда не предназначался для защиты от утечек и никогда как такое средство не позиционировался. Это средство эмуляции компьютера с бесконечной памятьтю. Т.е. он способен только находить буфера памяти доступные для повторного использования. Обязанность же своевременно деинициализировать объекты при этом точно так же лежит на программисте ( без этого утечка других видов ресурсов и косвенные утечки памяти в купе с некорректностью работы модели гарантированны), что кроме того что абсолютно аналогично ручным вызовам delete, еще попутно решает и задачу нахождения доступных для переиспользьзования буферов. Поэтому абсолютно никаких преимуществ перед языками с ручным управлением жизненным циклом GC не имеет, только сплошные пенальти. Это не говоря уже про языки с автоматическим управлением жизненным циклом, которые аккурат оные вызова и позволяют автоматизировать .
Вы как будто курс "компьютерное моделирование систем" не разу не проходили - там это все четко разжевываается при сравнении современных ООП языков с их далекими из далеких 60-х, померших именно по причине абсолютной бесполезности GC.

Сообщение от COKPOWEHEU

Эта штука называется инвариант.

Нет эта штука называется именно тензор. Инвариант имеет неизменное числовое значение во всех СК. Числовое же значение тензора для различных СК различно, неизменен только объект который он описывает. Т.е. опять вы даже близко не представляете о чем говорите.

Добавлено через 11 минут

Сообщение от COKPOWEHEU

Ну-ну, порадуйте физика, который буквально год назад занимался пересчетом тензора пьезокоэффициентов (матрица 3х6) по разным кристаллографическим направлениям (вот там да, умножение на матрицы 3х3).

Матрицы - один из вариантов задания правил преобразования тензоров в линейном пространстве. Адресное пространство компа напомню есть ни что иное как одномерное линейное пространтсво.
Поэтому к примеру разыменование индекса массива с типом элемента T описывается матрицей преобразования в однородном пространстве
$https://www.cyberforum.ru/cgi-bin/latex.cgi?\begin{vmatrix} sizeof(T) & 0\\ a & 1 \end{vmatrix} $
а нахождение к примеру индекса элемента по его адресу матрицей
$https://www.cyberforum.ru/cgi-bin/latex.cgi? \begin{vmatrix} 1/sizeof(t) & 0 \\ -a/sizeof(t) &1 \end{vmatrix} $
Т.е. самое обычное ковариантное и контрвариантное преобразование тензора.
По тем же самым принципам все это происходит и в дискретных адресных пространствах, только правила преобразования задаются уже другим способом.

Добавлено через 4 минуты

Сообщение от COKPOWEHEU

который буквально год назад занимался пересчетом тензора пьезокоэффициентов (матрица 3х6) по разным кристаллографическим направлениям (вот там да, умножение на матрицы 3х3).

Занимались вы как всегда бездумным былокодингом написанных кем то формул даже не вникая в суть расчета. Т.е. работу программиста как таковую вы никогда не выполняли.

Сообщение от COKPOWEHEU

Где же это вы выкапаваете свои "определения" и "проценты", из какой конкретно рекламной брошюрки

Из учебников по математике. А где вы берете ваш бред мало понятно.

@IamLost · 18.07.2020, 21:47

Сообщение от Fulcrum_013

А где вы берете ваш бред мало понятно.

Там же где вы взяли ваш про 25 млн строк кода линукса без учёта кода драйверов.

@Fulcrum_013 · 18.07.2020, 22:04

IamLost, То что в статистике по ним приведенной написано.

Добавлено через 11 минут

Сообщение от COKPOWEHEU

Но мы-то говорим еще и о пороге входа в язык

Язык есть нижней ступенькой порога вхождения в обучение умению вхождения в предметные области. Так что про вхождение в предметные области без вхождения в профессиональные языки, и основы информатики, которые и дают необходимые знания для работы с указателями (в т.ч. индексами массивов, ассоциативными ключами, смещениями в файлах и т.д. и т.п) - это из серии абсолютного бреда. Мало того, одной из первых ступенек в обучении является проектировние и реализация своего ЯП.
Так что про какое то осиливание порога вхождения в предметные области и не осиливание порога вхождения в профессиональные ЯП - это абсолютнейший бред никак не соответствующий реальной действительности. Реальная же действительность дает другое эмперическое наблюдение - человек не способный с полного нуля осилить плюсы за пол года программистом стать не способен в принципе. При этом получения навыка вхождения в предметные области и необходимые для этого теоритические знания быстрее чем за 5 лет получить нереально,

Добавлено через 3 минуты

Сообщение от COKPOWEHEU

Ну, зачастую именно так и получается. И тем не менее, задача языка (среды) в том,

Это абсолютно никак не говорит о большей пригодности рных быдлоскриптов к задачам которые пытаются таким способом решать. Говорит лишь о дефиците квалифицированных специалистов и том что все эти 90% горе-кодеров принципиально не могут решать более чем 1% задач индустрии. Они банально не способны войти в предметные области сложнее фоматирования ввода-вывода. Даже сортировку массивов им доверить нельзя.

Сообщение от COKPOWEHEU

чтобы даже так код мог хоть криво-косо, но работать, а не сыпать сегфолтами по три раза на строчку кода.

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

@COKPOWEHEU · 18.07.2020, 22:07

Сообщение от Fulcrum_013

Т.е. уровень вашей компетентности в вопросе ниже нуля как всегда?

Да, то есть ваш уровень компетенции на нуле, раз даже простейшие примеры не можете вообразить самостоятельно.

Lua
1
2
3
4
5
6
function func(filename)
  f = io.open(filename, "rt") -- здесь допущена ошибка: переменная должна быть локальной
  val = f.read()
  print(val)
  -- здесь вторая ошибка: файл не закрывается
end

Аналогичный код на том же С++ приведет к утечкам памяти.

Сообщение от Fulcrum_013

Числовое же значение тензора для различных СК различно

Что вы понимаете под числовым значением матрицы?

Сообщение от Fulcrum_013

Адресное пространство компа напомню есть ни что иное как одномерное линейное пространтсво.

Зачем для одномерных (кстати, это верно только для фон-неймановской архитектуры) интерпретировать число как тензор? Нет, формально-то можно, кто бы спорил. Просто смысла в этом никакого.

Сообщение от Fulcrum_013

Занимались вы как всегда бездумным былокодингом написанных кем то формул даже не вникая в суть расчета. Т.е. работу программиста как таковую вы никогда не выполняли.

Угу, сейчас неуч Fulcrum_013 будет мне рассказывать что же я делал и чего не делал.
Между прочим, наводку я дал - погуглите что такое "тензор пьезокоэффициентов". Это именно тензор - матрица 3х6.

Сообщение от Fulcrum_013

Из учебников по математике. А где вы берете ваш бред мало понятно.

Название учебника в студию. Просто чтобы не подходить к этому сборнику бреда и никому не рекомендовать.

Новые блоги и статьи Все статьи Все блоги /
Программа опроса у.з. расходомера SLS-720F Argus19 02.09.2026 Программа опроса у. з. расходомера SLS-720F Программа опрашивает один раз в минуту три ультразвуковых расходомера SLS-720F через интерфейс RS-485 по протоколу Modbus RTU. Опрашиваются регистры. . .	Hyper-V: Компьютер должен поддерживать доверенный платформенный модуль 2.0. Maks 31.08.2026 При установке Windows 11 на виртуальную машину Hyper-V 2-го поколения вылезла такая ошибка: Решение: в параметрах виртуальной машины, в разделе "Безопасность" (Security) активировать флаг. . .	Архитектура биовида Стива в Майнкрафте: Зачем бонобо кубический каннибализм anaschu 30.08.2026 Кубический Вагинокапитализм в Minecraft: Математический инвариант ОДУ и рок Стивов-бонобо Главная задача разработанной «Модели Всего» — наглядно продемонстрировать наличие системной «судьбы». . .	Оттачиваю умение писать js программы. russiannick 30.08.2026 Проектом выходного дня стало написание Книги шифров Виженера. Итогом стала версия 200, синий туман. Синий туман назван так, потому что замораживает текст под собой. Нажатие синих кнопок управляют. . .
мат медиц модель 30. презентация проекта anaschu 27.08.2026 хоп хоп хоп хидахоп, а я кладую))	Как у меня протекала болезнь zorxor 27.08.2026 Здравствуйте, друзья! Эта запись блога предназначена именно для вас - для моих дорогих друзей, которые знали меня лично. Чтобы ответить на вопрос - а что же со мной произошло на самом деле? Я учился. . .	Нашел вот забавное видео о измерениях. Лучшее что я видел на эту тему kumehtar 26.08.2026 ILETXiw9bMQ Основная суть и тезисы по измерениям: 0D (Нулевое измерение): точка, не имеющая длины, ширины, высоты или объема. Объект не может перемещаться в 0D. 1D (Первое измерение):. . .	[EasyBuilder Pro] Памятка по разработке для панелей Weintek ФедосеевПавел 26.08.2026 Памятка по разработке для панелей Weintek ВВЕДЕНИЕ Ранее, при реализации проектов основное внимание уделял разработке управляющей программы для контроллера, а панели оператора доставалось время. . .

@ReYalp 63 / 46 / 11 Регистрация: 27.12.2017 Сообщений: 1,484

	Rust vs C++ 26.06.2020, 16:10. Показов 48313. Ответов 660 Метки нет (Все метки) Кто-то писал на Rust? Стоит ли начинать учить? Насколько Rust хуже/лучше С++? 0