Ну, если не знать языка, то непростых вопросов при решении простой задачи в любом случае возникнет масса. Вон, выше я завалил простыми вопросами, на которые ответы не просты. Просто потому, что я не владею в полном объеме языком Rust :-)
В гуйне обычно есть несколько сущностей которые хранят в себе ссылки на гуй-компонентины. Простой пример — layout этот + диспетчер клавиатуры, которому нужно знать кому посылать сообщение в случае если пользователь клавишу вдавил. Подобных штук там довольно много разных.
Один и тот же виджет входит сразу в несколько иерархий и списков виджетов.
К счастью это давно возможно. Причем даже не на уровне компилятора, а на уровне операционки.
ulimit -s unlimited
Стек штука довольно вирутальная. У некоторых железок есть конечно железный стек, и там не забалуешь без сильных просадок в производительности. Но на персоналках ничего похожего нет.
А как это всё будет выглядеть если у меня два layout'a (или других подобных компонента) и в обоих нужен w1 (точнее ссылка на него)? В обоих местах естественно нужна возможность w1 модифицировать.
Просто так поперемещать, насколько я понимаю, уже не выйдет.
А можно пояснить что в последнем примере будет в плане размещения переменных/объектов в памяти? w1 и w2 будут на стеке? При приведении вида Box::new(w1) as Box значение w1 будет скопировано в кучу, таким образом, физически у нас станет на какой-то момент два w1?
Обычно в гуях какой-нибудь Layout держит в себе лишь указатели/ссылки/смартпоинтеры (в зависимости от ЯП) на виджеты, но не сами эти объекты.
Но на практика довольно редко приходится использовать типаж-объекты.
Хм. Интересно. А как в Rust статическим полиморфизмом обходится например такая задача, как написание GUI? Это вроде бы та область, где активно используется динамическая диспетчеризация/полиморфизм.
Похожего у них только то, что в сигнатуре виден тип возращаемой ошибки.
Ну, это и есть основное отличие checked от unchecked exceptions. И именно это вызывает в т.ч. кучу проблем в той же java.
Заабортить поток при исключении/ошибке можно и в жабах, да и вообще в общем то в любом ЯП. Это не проблема как раз.
Я прекрасно понимаю, что в Rust работа с ошибками в плане механизмов больше похожа на соответствующую монаду в Haskell нежели на исключения. Но расматриваем то, так сказать пользовательские характеристики, а не потроха. Кстати, какова эффективность (по сравнению с исключениями на современных архитектурах и компиляторов) у такого подхода? Накладных расходов на каждый успешных вызов функции нет?
Про checked exceptions пишут следующее:
«Checked exceptions are bad because programmers just abuse them by always catching them and dismissing them which leads to problems being hidden and ignored that would otherwise be presented to the user»
Кроме того, представьте себе, что вам например нужно добавить в самую общую, всеми используемую библиотеку еще один тип ошибок который она должна выбрасывать (возможно ранее какие-то функции вообще не выбрасывали ошибок, а теперь должны). Теперь в Rust и в java вам придется пройтись по ВСЕМУ коду (стандартному, стороннему, своему) и везде изменить сигнатуры функций. Ну и до кучи все перекомпилировать конечно.
Я правильно понимаю, что тип-суммы, это то, что в других ЯП называется алгебраическими типами данных?
Оверхед от типажей-объктов будет при каждом вызове функции, или только в тех случаях когда компилятор действительно не может определить на этапе компиляции какую функцию нужно дернуть (в С++ компиляторах эта оптимизация делается всегда когда возможно).
По моему, в Rust получилось нечто, что очень сильно напоминает checked exceptions в java со всеми их плюсами и минусами. А если учесть, что checked exceptions были признаны ошибкой…
Погодите, но ведь это же статический полиморфизм (то есть полиморфизм времени компиляции) продемонстрирован, разве нет? Это как type class в Haskell если без расширизмов от ghc (без existential types), ну и как это будет в C++ когда введут наконец концепты в стандарт.
Как на Rust будет динамический полиморфизм (времени исполнения)? И какой при этом будет оверхед?
А, ну да. Под iOS придется слинковать статически. Это проблема (если предполагается конечно в AppStore выкладывать, а это нужно при разработке под iOS далеко не всегда. Впрочем, когда софт используется только внутри конторы, то там и GPL сойдет — исходники в этом случае всё равно раскрывать не придется, GPL позволяет).
Да, Qt for Startups — интересно. Будем посмотреть.
Поддержка — понятно. А почему именно под iOS она желательна (ведь не обязательна же)?
Ну, до определенного размера собственного проекта, способствовать развитию Qt проще контрибьютом кода в Qt-компоненты. Уж больно ценник кусается у коммерческой версии Qt.
Да и в случае большого проекта иногда тоже так выгодней (скажем Qt Multimedia не умеет писать в файл в винде, а если твой мегапроприентарный и мегакоммерческий софт на Qt использует Qt Multimedia и нужно писать в файл видео в виндах, то имеет наверно смысл добавить такую поддержку и законтрибьютить в Qt вместо того, чтобы отдельно велосипед лепить в обход Qt именно для винды).
А вот скажите, какой смысл в коммерческой лицензии, если допустим в моей проприентарщине используются только опенсорсные компоненты Qt под лицензией LGPLv3 / LGPLv2.1? Ведь LGPL это не GPL, и не заставляет саму программу лицензировать под GPL/LGPL (если статические не слинковался с либой конечно).
Ну, непредвзятых выступлений на подобные темы я вообще не видел. Кроме того, всегда авторы подобных лекция-статей-книг имеют крайней не ровные знания в разных ЯП. То есть прямо видно, что часто автор не в теме.
Что же касается Зуева, у него, судя по этому видео, предвзятость сместилась в сторону Rust/Swift/Go :-) По крайней мере он именно их перечисляет в списке перспективных ЯП, у которых есть будущее.
Ну и понятное дело, что библиотеки пишут на всех ЯП, как жить вообще без библиотек, то есть без повторного использования кода на данном ЯП?
То есть, вы, например, захотели на Обероне написать сайт. А что такого, почему бы и нет? И начинается морока… Веб-сервер вы не можете поднять свой на Обероне, чтобы потестировать легонько, какие-нибудь библиотеки вы подключить не можете, потому что их на Обероне нет. И всё это через какие-то костыли делается, силы уходят, и в общем вы плюете и пишете на чистом Си свой сайт вместо Оберона.
Пример не совсем удачный к сожалению, ибо например есть вот это: www.o3-software.de/en/index.xhtml Ну и для Active Oberon веб-сервак тоже есть искаропки.
Да и дернуть сишную либу можно легко из любого в общем императивного языка (особенно из реализации которая компилируется в нативный бинарь). Без костылей.
Да и судя по архитектуре Swing — там подобное тоже имеется.
Один и тот же виджет входит сразу в несколько иерархий и списков виджетов.
Стек штука довольно вирутальная. У некоторых железок есть конечно железный стек, и там не забалуешь без сильных просадок в производительности. Но на персоналках ничего похожего нет.
А вот вам реализация на уровне компилятора: gcc.gnu.org/wiki/SplitStacks
Просто так поперемещать, насколько я понимаю, уже не выйдет.
А можно пояснить что в последнем примере будет в плане размещения переменных/объектов в памяти? w1 и w2 будут на стеке? При приведении вида Box::new(w1) as Box значение w1 будет скопировано в кучу, таким образом, физически у нас станет на какой-то момент два w1?
Обычно в гуях какой-нибудь Layout держит в себе лишь указатели/ссылки/смартпоинтеры (в зависимости от ЯП) на виджеты, но не сами эти объекты.
Хм. Интересно. А как в Rust статическим полиморфизмом обходится например такая задача, как написание GUI? Это вроде бы та область, где активно используется динамическая диспетчеризация/полиморфизм.
Примеры можно?
Ну, это и есть основное отличие checked от unchecked exceptions. И именно это вызывает в т.ч. кучу проблем в той же java.
Заабортить поток при исключении/ошибке можно и в жабах, да и вообще в общем то в любом ЯП. Это не проблема как раз.
Я прекрасно понимаю, что в Rust работа с ошибками в плане механизмов больше похожа на соответствующую монаду в Haskell нежели на исключения. Но расматриваем то, так сказать пользовательские характеристики, а не потроха. Кстати, какова эффективность (по сравнению с исключениями на современных архитектурах и компиляторов) у такого подхода? Накладных расходов на каждый успешных вызов функции нет?
Про checked exceptions пишут следующее:
Кроме того, представьте себе, что вам например нужно добавить в самую общую, всеми используемую библиотеку еще один тип ошибок который она должна выбрасывать (возможно ранее какие-то функции вообще не выбрасывали ошибок, а теперь должны). Теперь в Rust и в java вам придется пройтись по ВСЕМУ коду (стандартному, стороннему, своему) и везде изменить сигнатуры функций. Ну и до кучи все перекомпилировать конечно.
Это же Ад ломающий обратную совместимость.
Я правильно понимаю, что тип-суммы, это то, что в других ЯП называется алгебраическими типами данных?
Оверхед от типажей-объктов будет при каждом вызове функции, или только в тех случаях когда компилятор действительно не может определить на этапе компиляции какую функцию нужно дернуть (в С++ компиляторах эта оптимизация делается всегда когда возможно).
По моему, в Rust получилось нечто, что очень сильно напоминает checked exceptions в java со всеми их плюсами и минусами. А если учесть, что checked exceptions были признаны ошибкой…
Погодите, но ведь это же статический полиморфизм (то есть полиморфизм времени компиляции) продемонстрирован, разве нет? Это как type class в Haskell если без расширизмов от ghc (без existential types), ну и как это будет в C++ когда введут наконец концепты в стандарт.
Как на Rust будет динамический полиморфизм (времени исполнения)? И какой при этом будет оверхед?
Да, Qt for Startups — интересно. Будем посмотреть.
Ну, до определенного размера собственного проекта, способствовать развитию Qt проще контрибьютом кода в Qt-компоненты. Уж больно ценник кусается у коммерческой версии Qt.
Да и в случае большого проекта иногда тоже так выгодней (скажем Qt Multimedia не умеет писать в файл в винде, а если твой мегапроприентарный и мегакоммерческий софт на Qt использует Qt Multimedia и нужно писать в файл видео в виндах, то имеет наверно смысл добавить такую поддержку и законтрибьютить в Qt вместо того, чтобы отдельно велосипед лепить в обход Qt именно для винды).
в этой статье чего стоит…
Насколько Страуструп ассемблерист, настолько и С++ минималистичный ЯП.
:-)
Что же касается Зуева, у него, судя по этому видео, предвзятость сместилась в сторону Rust/Swift/Go :-) По крайней мере он именно их перечисляет в списке перспективных ЯП, у которых есть будущее.
Ну и понятное дело, что библиотеки пишут на всех ЯП, как жить вообще без библиотек, то есть без повторного использования кода на данном ЯП?
По моему тут лучше рассказано. Хотя и не без огрехов конечно.
Пример не совсем удачный к сожалению, ибо например есть вот это: www.o3-software.de/en/index.xhtml Ну и для Active Oberon веб-сервак тоже есть искаропки.
Да и дернуть сишную либу можно легко из любого в общем императивного языка (особенно из реализации которая компилируется в нативный бинарь). Без костылей.