Нужно же на чем-то писать то, что будет «скрывать особенности архитектуры и изолировать сущности разной природы», необходимость работать с архитектурой и с этими сущностями «разной природы» все равно по большому счету никуда не девается. C и C++ как раз для этого и нужны. Хотите изолироваться по максимуму — пишите на Java или C#.
После перемещения обращаться к b переменной нельзя. Она исчезла, переместилась, ее больше нет. Это сделано специально, чтобы избежать неопределенного поведения, присущего С++:
Прошу прощения, но здесь вы все-таки немножко передергиваете. В приведенном вами примере неопределенное поведение связано все-таки не с реализацией move-семантики в C++ («настоящая/не настоящая»), а с реализацией std::string. Точно это же самое неопределенное поведение можно вызвать и без всякой move-семантики, например:
std::string str;
str.back();
C++ Core Guidelines рекомендуют оставлять moved-from объект в состоянии «default value of the type», что довольно разумно.
Ну, Qt существует, естественно, не в вакууме, как для сборки под Android ему нужны Android SDK и NDK, так и для сборки под iOS, соответственно, нужен Xcode. Эмуляторы есть в составе Xcode, но, чтобы его поставить, нужно устройство с MacOS. Говорят, на Хакинтоше Xcode нормально работает, но я лично не пробовал.
Как по мне, фреймворк, в котором несколько зрелых и устоявшихся языков могут, скажем так, бесшовно интегрироваться в единое приложение (причем каждый может быть использован для своей цели в соответствии со своими плюсами), который обеспечивает для них единую систему сборки, единый IDE и единую библиотеку модулей — это куда лучшее решение, чем очередной сляпанный на коленке недоязычок ad hoc, для которого нет ничего, который не может воспользоваться никакими уже существующими наработками без их тотального переписывания «на себе» (естественно, с внесением новых ошибок в процессе этого дела, а как же) и так далее.
Знаете, программировать вообще сложно, и тут ничего не поделать. Любые абстракции, которые создаются для «упрощения» этого процесса, имеют свойство рано или поздно протекать. Асинхронность в JS и так прошла довольно долгий путь от обычных коллбеков через промисы до async/await, где стала выглядеть практически как «псевдосинхронный код». А замести асинхронность под ковер в однопоточном языке, который, будучи рассчитан преимущественно на фронтенд-применение, вынужден постоянно взаимодействовать как с GUI, так и с сетью, и при этом обязан обеспечивать достаточную отзывчивость с точки зрения пользователя, не так-то просто. Чем быстрее новичок поймет все это, тем быстрее он перестанет быть новичком. Ему же лучше.
Пихать такие вещи, как сборка проектов и их разворачивание, в ЯЗЫК — это довольно странно. Обычно для этого все-таки используются такие вещи, как фреймворки и системы сборки, зачастую к тому же поддерживающие несколько языков сразу. ЯП — он все-таки несколько про другое. С «подключением» (не подгрузкой) библиотек/модулей — да, можно отчасти согласиться в том плане, что до сих пор по историческим причинам, как правило, используются заголовочные файлы, что не очень удобно, так как их приходится фактически каждый раз заново обрабатывать в каждом файле, в который они включаются. Но есть и в этом плане подвижки, в C++17 предлагали включить модули:
Правда, именно в C++17 их не включили, но в C++20 они наверняка появятся. Что же касается «подгрузки библиотек/модулей», то если речь идет именно о легком доступе к какому-то репозиторию, где много всяких модулей, то это тоже скорее вопрос фреймворка, а не языка, например, в Visual Studio для этого есть nuget с обширной библиотекой модулей для всех поддерживаемых Visual Studio языков, для MacOS/iOS есть CocoaPods, который тоже поддерживает сразу несколько языков, и так далее. Пихать это в ЯЗЫК тоже, как минимум, странно. Ну и не вижу я проблем с интеграцией C++ в IDE, хотя бы в том же Visual Studio (в отличие от Visual Studio Code, но тут проблема не в языке, а в… хм… «IDE»).
В Qt приложение зачастую можно написать так, что от C++ там будет только штампованный main.cpp из десятка строчек, инициализирующий декларативную машинерию и подгружающий локализацию, и все. Интерфейс при этом будет написан на QML, который вполне по силам освоить даже дизайнеру (он для этого и разработан), а бизнес-логика — на JS. При этом все будет летать, потому что QML-файлы инстанцируются в Qt'шные классы, у которых все внутренности (кроме пользовательских обработчиков событий, пожалуй, которые в данном случае будут на JS) написаны на C++. Причём даже все это можно ускорить ещё больше, перенеся момент парсинга/инстанцирования с момента подгрузки QML-файла на момент сборки приложения с помощью Qt Quick Compiler.
Ну если вы хотите iOS, то придется по-любому ваш продукт на чем-то переписывать — либо на ObjC/Swift (но тогда вам придется параллельно поддерживать обе, мягко говоря, не пересекающиеся кодовые базы), либо на чем-то кроссплатформенном, второе, по-моему, предпочтительнее. Правда, лично я все больше с Qt/QML имею опыт, Flutter не пробовал. Кстати, забавно, раньше при виде фразы «cross-platform mobile toolkit» в статье модно было плеваться в комментариях в стиле «фи, не нативно» (в том смысле, что контролы в UI выглядят не «родными»). Но в последнее время эта тенденция как-то затихает, и «собственный графический движок» у таких тулкитов и «единообразие внешнего вида приложения на всех платформах» уже начинает постепенно выставляться как плюс.
В Android любые пользовательские приложения выполняются каждое в своей «песочнице», при этом неважно, скомпилировано ли приложение в платформенный машинный код или в платформонезависимый байткод типа Dalvik. Более того, со времен ART то, что вы называете «виртуальной машиной» практически отсутствует, потому что ART автоматически перекомпилирует байткод из APK в нативный платформенный код («исполняемый файл Линукса», если угодно) заранее после установки приложения либо во время первого запуска, а не занимается постоянной JIT компиляцией байткода во время его выполнения как Dalvik VM. Более того, никто не мешал и не мешает прицепить .so даже к байткоду в Dalvik VM — через JNI. Так что ваши представления о реализации механизмов защиты приложений в Android несколько… хм. Ну и Android NDK был с нами с первых версий Android и никуда пропадать не планирует, на его основе вполне себе пишутся и работают приложения в нативном коде под Android, я лично делаю это на Qt, вот сейчас и Flutter появился примерно с той же парадигмой. Это вовсе не «шаг назад», а скорее «шаг вперед», особенно в плане производительности.
Разница между IDE и блокнотом проходит по букве I — «integrated». В VS Code, в отличие от «взрослой» Visual Studio, нет этой самой буквы I. И плагины сами по себе там не помогают, они не работают без кучи сторонних toolchain'ов, которые надо устанавливать и настраивать вообще отдельно, и даже с этими toolchain'ами они работают с кучей ограничений, вон выше kekekeks привел хороший пример. Не дотягивает VS Code до «честной взрослой IDE», никак не дотягивает. Это как если бы я в Visual Studio поставил «поддержку C++», а она мне и говорит человеческим голосом — сорян, парень, cl.exe не входит в мою комплектацию, иди куда хочешь и ставь откуда хочешь. И какой-нибудь парсер для IntelliSense где-нибудь отковыряй, а то у меня будет только автодополнение в стиле Notepad++. И отладчик какой-нибудь заодно не забудь прихватить. Правда, как я со всем этим буду потом работать, и буду ли работать вообще — не могу обещать.
Правда? Прям сразу в VS Code есть отладчик, например, для плюсового кода, без необходимости подключать всякие gdb/lldb? Даладна. А как же это:
Note: The C/C++ extension does not include a C++ compiler or debugger. You will need to install these tools or use those already installed on your computer.
? Ну и «средства автодополнения кода» там точно так же не будут адекватно работать без сторонних штук типа clang или gnu global. Блокнот — он и есть блокнот.
Оба продукта по-прежнему активно разрабатываются, и нет никаких признаков того, что Microsoft намерена закрыть Visual Studio.
А с чего бы им его вообще закрывать? Эти продукты вообще разного класса, Visual Studio — это мощнейшее IDE, включающее в себя весь инструментарий, необходимый для разработки приложений, от и до, а VS Code — это блокнот (да к тому же еще и на Электроне), стильно-модно-молодежно.
Там по-моему немножко не так делается, из-под потоков, которые нужно остановить, "выдергиваются" страницы памяти (размапливаются) и gc делает в них все что ему требуется, двигает объекты, правит адреса, и так далее, а потоки останавливаются сами по page fault exception, потом jvm мапит все обратно и потоки продолжают работать как ни в чем не бывало.
Прошу прощения, но здесь вы все-таки немножко передергиваете. В приведенном вами примере неопределенное поведение связано все-таки не с реализацией move-семантики в C++ («настоящая/не настоящая»), а с реализацией std::string. Точно это же самое неопределенное поведение можно вызвать и без всякой move-семантики, например:
C++ Core Guidelines рекомендуют оставлять moved-from объект в состоянии «default value of the type», что довольно разумно.
Ну а так-то да, «азаза затралено».
Ну, Qt существует, естественно, не в вакууме, как для сборки под Android ему нужны Android SDK и NDK, так и для сборки под iOS, соответственно, нужен Xcode. Эмуляторы есть в составе Xcode, но, чтобы его поставить, нужно устройство с MacOS. Говорят, на Хакинтоше Xcode нормально работает, но я лично не пробовал.
Знакомо, знакомо. Google… Google never changes.
Да, именно на нее в данном конкретном случае я и намекал. В принципе, это и по треду в целом должно быть понятно :)
www.open-std.org/JTC1/SC22/WG21/docs/papers/2015/n4465.pdf
Правда, именно в C++17 их не включили, но в C++20 они наверняка появятся. Что же касается «подгрузки библиотек/модулей», то если речь идет именно о легком доступе к какому-то репозиторию, где много всяких модулей, то это тоже скорее вопрос фреймворка, а не языка, например, в Visual Studio для этого есть nuget с обширной библиотекой модулей для всех поддерживаемых Visual Studio языков, для MacOS/iOS есть CocoaPods, который тоже поддерживает сразу несколько языков, и так далее. Пихать это в ЯЗЫК тоже, как минимум, странно. Ну и не вижу я проблем с интеграцией C++ в IDE, хотя бы в том же Visual Studio (в отличие от Visual Studio Code, но тут проблема не в языке, а в… хм… «IDE»).
? Ну и «средства автодополнения кода» там точно так же не будут адекватно работать без сторонних штук типа clang или gnu global. Блокнот — он и есть блокнот.
А с чего бы им его вообще закрывать? Эти продукты вообще разного класса, Visual Studio — это мощнейшее IDE, включающее в себя весь инструментарий, необходимый для разработки приложений, от и до, а VS Code — это блокнот (да к тому же еще и на Электроне), стильно-модно-молодежно.
www.usenix.net/legacy/events/vee05/full_papers/p46-click.pdf
Насколько я знаю есть ряд вариантов таких «pauseless» gc, всякие continuously concurrent gc и так далее.
Там по-моему немножко не так делается, из-под потоков, которые нужно остановить, "выдергиваются" страницы памяти (размапливаются) и gc делает в них все что ему требуется, двигает объекты, правит адреса, и так далее, а потоки останавливаются сами по page fault exception, потом jvm мапит все обратно и потоки продолжают работать как ни в чем не бывало.