По правде, это не "проблема", а "ограничение" данной концепции. Так будет правильнее, чтобы не создавать негативную коннотацию при использовании штампа "проблема".
Проблема возникает, когда концепцию с подобными ограничениями начинают продвигать как универсальную замену на все случаи жизни, а в случае невозможности реализации конкретного алгоритма, предлагается переделывать архитектуру системы, из-за наличия подобных ограничений в исходной концепции языка.
По хорошему, и это тоже не стоит называть "проблемой". Просто нужно иметь ввиду, что у каждого языка программирвания есть ограничения и не стараться использовать PHP или JavaScript во встраиваемых решениях для микроконтроллеров или, как в данном случае, просто нужно помнить, что в Раст статическая проверка "владения и заимствования" не работает для циклических графов. Только рантайм, аналогичный реализованному в С++ :-)
описанием доказательства математической корректности модели управления памятью или на худой конец список проверок и/или ограничений, которые сделаны в компиляторе Rust для её реализации
А вы мне опять подсовываете частный случай оптимизации при доступе к памяти:
We give formal proofs (mechanized in Coq) showing that this rules out enough programs to enable optimizations that reorder memory accesses around unknown code and function calls, based solely on intraprocedural reasoning.
Может быть тогда вы напишите ту самую правильную ссылку с описанием доказательства математической корректности модели управления памятью или на худой конец список проверок и/или ограничений, которые сделаны в компиляторе Rust для её реализации?
Множественное владение может быть требованием задачи (как в текущем случае), и если язык не может это реализовать, то это проблема дизайна языка программирования.
Так что я лучше деньги отдам тому кто нормально сделает, пускай закрыто.
Ну а раз вы команде платить не хотите, а платите конкурентам, то откуда у вас возникают претензии к свободному их продукту? Почему они должны делать то, что нужно вам, тогда как непосредственных разработчиков все устраивает?
И те из них, кто конкуренцию не выдерживает, уходит с рынка.
Вот только почему-то по после ухода мало кто набирается смелости открыть исходники продуктов, например как Netscape. Но дело даже не в этом, а в том, что законы лоббируются корпорациями и пишутся под их дудку и с этим ничего сделать нельзя :-(
Так поправь сам, или оплати работу программиста если сам не в состоянии. Или ты отдашь деньги корпорасту за ПО с зондами, но сам будешь орать, что халявы не дают?
Вы попутали свободное и бесплатное ПО. Свободное ПО вовсе не значит бесплатное, но у неге есть особенности бизнес модели, которые принципиально отличаются от обычного проприетарного софта.
Проприетарный софт проще коммерциализировать, так как его бизнес-ценность защищена в силу закрытости исходников, из-за чего пользователю можно втюхать любую фигню, которую он безропотно скушает из-за отсутствия альтернативы, тогда как у свободного ПО есть альтернатива в виде возможности самостоятельной сборки из исходников с исправлением (или удалением) встроенной условной фигни.
Владелец автомобиля будет признан виновным, если нарушил руководство по эксплуатации
То есть производитель пишет в руководстве, что пользователь (водитель) должен быть готов перехватить управление в случае опасности и это чудесным образом делает его не виновным в любых авариях, если водитель не успел :-)
А там разве нет унитаза? :-)
По правде, это не "проблема", а "ограничение" данной концепции. Так будет правильнее, чтобы не создавать негативную коннотацию при использовании штампа "проблема".
Проблема возникает, когда концепцию с подобными ограничениями начинают продвигать как универсальную замену на все случаи жизни, а в случае невозможности реализации конкретного алгоритма, предлагается переделывать архитектуру системы, из-за наличия подобных ограничений в исходной концепции языка.
По хорошему, и это тоже не стоит называть "проблемой". Просто нужно иметь ввиду, что у каждого языка программирвания есть ограничения и не стараться использовать PHP или JavaScript во встраиваемых решениях для микроконтроллеров или, как в данном случае, просто нужно помнить, что в Раст статическая проверка "владения и заимствования" не работает для циклических графов. Только рантайм, аналогичный реализованному в С++ :-)
Вы издеваетесь? Мне хочется найти
А вы мне опять подсовываете частный случай оптимизации при доступе к памяти:
Конечно, я не туда посмотрел или не так понял.
Может быть тогда вы напишите ту самую правильную ссылку с описанием доказательства математической корректности модели управления памятью или на худой конец список проверок и/или ограничений, которые сделаны в компиляторе Rust для её реализации?
Может быть вы тогда обратите внимание и на ответы к упомянутым вами комментариям?
Ага, много слов и никакой конкретики по заданным вопросам. Так же как и ваш комментарий.
Низкоуровневая реализация тут не причем, так как у Rust есть проблемы с доказательством самой модели безопасной работы с памятью.
Та и не писал бы. Все равно не понятно, к чему относится ваш комментарий, либо вы отвечаете не тому человеку.
Множественное владение может быть требованием задачи (как в текущем случае), и если язык не может это реализовать, то это проблема дизайна языка программирования.
Живите теперь с этим :--)
Ваш хваленый Rust не решает проблему циклический зависимостей и множественного владения.
Пока.
А скажут, что виноваты во всем северокорейские хакеры
Я его и имел ввиду
Ну а раз вы команде платить не хотите, а платите конкурентам, то откуда у вас возникают претензии к свободному их продукту? Почему они должны делать то, что нужно вам, тогда как непосредственных разработчиков все устраивает?
Вы забили уточнить "Rust дает некоторую надежность и безопасность", так как некоторые аспекты безопасности он все же решить не в силах.
Вот только почему-то по после ухода мало кто набирается смелости открыть исходники продуктов, например как Netscape. Но дело даже не в этом, а в том, что законы лоббируются корпорациями и пишутся под их дудку и с этим ничего сделать нельзя :-(
Так поправь сам, или оплати работу программиста если сам не в состоянии. Или ты отдашь деньги корпорасту за ПО с зондами, но сам будешь орать, что халявы не дают?
Вы попутали свободное и бесплатное ПО. Свободное ПО вовсе не значит бесплатное, но у неге есть особенности бизнес модели, которые принципиально отличаются от обычного проприетарного софта.
Проприетарный софт проще коммерциализировать, так как его бизнес-ценность защищена в силу закрытости исходников, из-за чего пользователю можно втюхать любую фигню, которую он безропотно скушает из-за отсутствия альтернативы, тогда как у свободного ПО есть альтернатива в виде возможности самостоятельной сборки из исходников с исправлением (или удалением) встроенной условной фигни.
Во первых функции не С++, а С, а во вторых куда делись С++ исключения?
То есть производитель пишет в руководстве, что пользователь (водитель) должен быть готов перехватить управление в случае опасности и это чудесным образом делает его не виновным в любых авариях, если водитель не успел :-)
Ну так работает ли устройство как задумывалось или это такой наброс с картинками?