Я использую QtCreator. В нём есть возможность указывать пользовательские файлы подсветки синтаксиса и у меня такой файл есть (см. в репозитории). Кроме того в этой IDE можно настроить работу с языковым сервером любого языка, что я использую для разработки Ü. Есть ещё плагин для QtCreator, который я написал когда-то давно и который уже не актуален (с новыми версиями этой IDE не собирётся) и у которого из функционала есть только добавление пары функций контекстного меню, без которых и так можно обойтись.
Также я выше упомянул, что в ecode есть поддержка Ü и я в данный момент использую эту IDE для пары моих сторонних проектов, написанных на Ü.
Может быть. Но я лично этой IDE не пользуюсь и чтобы написать плагин, неплохо было бы в ней освоится, на что у меня особо времени нету (в проекте есть задачи поважнее). Но было бы неплохо, если бы кто-нибудь другой это сделал. Да и другие IDE тоже не надо забывать, вроде IDE от JetBrains, QtCreator, Geany и множество других.
Ü более чем дружелюбен для любой, даже самой сумасшедшей сериализации. Оператор typeinfo обеспечивает инспекцию типов, при инспектировании можно сгенерировать код любой сложности, который работает с этими данными - хоть через шаблоны, хоть через mixin (с генерацией текстового представления кода).
Ничего особо фантастического в переписывании C++ программ на Ü я не вижу. Это часто непрактично (работающий код переписывания не требует), но технически реализуемо, язык Ü достаточно богат функционалом в сравнении с C++.
Более прагматичный вариант - использовать Ü для написания новых программ. Я это уже практикую, в этом году уже один небольшой проект на Ü написал (см. мою предыдущую публикацию).
Плюсы использования Ü в сравнении с C++ вполне очевидны - безопасность работы с памятью, отсутствие граблей, унаследованных от C, более богатая (отчасти) стандартная библиотека, интегрированная система сборки и много чего ещё.
Деструкторов и не завозили, по той причине, что авторы языка Zig - неосиляторы C++, которые воспринимают значительную часть его нововведений в штыки.
В описанном вами подходе граблей всё ещё полно и назвать его "безопасным" - язык не поворачивается. Можно забыть написать удаление ресурсов в defer. Можно дважды удалить ресурс (если он куда-то в другую функцию передаётся, и та тоже вызывает освобождение в своём defer). Можно сохранить указатель ну некую область памяти и освободить её, забыв про этот указатель и разименовав его позже.
defer - вообще костыль, который противоречит базовым принципам структурного программирования. RAII его назвать нельзя, ибо RAII - это управление ресурсами на уровне типов.
Вообще, безопасность, это не "ну вроде норм выглядит", а формальное свойство, гарантируемое дизайном языка. В Zig её нету и авторы даже не пытаются её реализовать.
Очень дурной подход - сначала отказаться сознательно от деструкторов, разрешить по поводу и без жонглировать ручным выделением памяти и сырыми указателями и потом затыкать дыры, порождённые таким подходом, некоторым статическим анализатором, пусть и встроенным в компилятор.
Перемещение по-умолчанию некоторых типов и проверка на обращение к перемещённым переменным строго говоря ортогональны друг другу. Вполне возможно было бы сделать так, чтобы значения по умолчанию копируются, а для перемещения нужно использовать отдельный оператор языка, при этом сохранив проверку на обращение к объекту, который перемещён. Но авторы Rust решили так не делать и сделали любое копирование явным, видимо из боязни, что неявное копирование может в некоторых случаях к скрытому ухудшению производительности вести.
В C++ просто перемещения в строгом понимании вообще нету. std::move ничего не перемещает и только преобразует один вид ссылки в другой. Вся логика перемещения реализована через конструкторы перемещения или операторы перемещающего присваивания. При этом объект, подвергнутый "перемещению" все ещё существует, деструктор его будет вызван и ряд методов для него будут работать (но не все, там всё хитро с этим).
Это пример ущербного дизайна Rust, из-за которого некоторые типы молча перемещаются. К безопасности памяти это решение дизайна языка не имеет никакого отношения.
Чинится это, впрочем, весьма тривиально. Надо или s.clone() добавить, или сигнатуру функции my_func изменить.
При чём тут shared_ptr? Он к безопасности памяти отношения не имеет.
ошибки проверки заимствования возникают в самый неподходящий момент
Как раз подходящий. В Rust ошибки вылезают на этапе сборки, если программист где-то накосячил, что даёт возможность из по-быстрому исправить. А в языках без безопасности ошибки возникают во время выполнения, часто очень странным и тяжело-диагностируемым способом.
Судя по статье, Zig - весьма посредственный язык. Да, пару интересных плюшек там добавили, но не более того. Наибольшая его проблема заключается в том, что он зачем-то сознательно разрабатывается как небезопасный язык (с точки зрения доступа к памяти), хотя уже давно известно, что эту безопасность на уровне языка обеспечить возможно и это не ухудшает производительность и почти не ухудшает эргономику использования.
Ближний восток - местности там в основном плоские (хоть и не без гор местами) и пустынные. Самое то для колесниц. Ну а кавалерией они были как раз вытеснены, потому как кавалерия в проходимости сильно выигрывает.
Вот кстати да, упоминая колесо, забывают часто про дороги, без которых оно малополезно. Колесо реально может быть использовано только на весьма ровной естественной местности (вроде степи), перепады высот и водные преграды делают его использование слишком сложным. Решение - строить дороги и мосты. И с последним дело обстояло так себе большую часть времени, так что чаще использовался гужевой транспорт, а ещё лучше водный.
Про моря теплее нынешних вопрос есть. Сейчас в новостях говорят, что из-за того, что вода немного теплее стала, массово бледнеют и умирают кораллы. А как тогда они жили, когда моря были намного теплее? Или тогда они были к такой температуре привыкшими?
Предположу, что зависит от местности. Где-то кражи редки, а где-то наносят существенный урон и как следствие, меры против краж могут себя окупить. В данной новости о Калифорнии идёт речь, слыхал, что там мелкие кражи последние годы весьма участились, ибо их практически декриминализовали.
Проблема при решении задач часто заключается в том, что не очень то понятно, что какой-то из этих паттернов может быть использован. Часто требуется какое-то неявное допущение, с которым ещё не понятно истинно ли оно и как его истинность доказать, чтобы можно было этот паттерн использовать.
Злоупотребления конкуренцией не было. Любой ведь мог открыть такую торговую точку, которая описана в данной статье. Злоупотребление тут было скорее из-за самого закона, требующего весьма недешёвой лицензии. Чую я, что это наверняка какие-нибудь состоятельные держатели питейных заведений пролоббировали такой закон, дабы вытеснить с рынка менее состоятельных конкурентов. А забота о здоровье граждан - лишь благовидный предлог (который и сейчас бывает используется).
Меня во всей этой истории поражает, что уже тогда власти подходили весьма трепетно к соблюдению своих же законов и не устраивали обыск этих разливочных заведений без должных оснований. В какой-нибудь другой стране не церемонились бы с этим и лавочку быстро-бы прикрыли.
Я использую QtCreator. В нём есть возможность указывать пользовательские файлы подсветки синтаксиса и у меня такой файл есть (см. в репозитории). Кроме того в этой IDE можно настроить работу с языковым сервером любого языка, что я использую для разработки Ü. Есть ещё плагин для QtCreator, который я написал когда-то давно и который уже не актуален (с новыми версиями этой IDE не собирётся) и у которого из функционала есть только добавление пары функций контекстного меню, без которых и так можно обойтись.
Также я выше упомянул, что в ecode есть поддержка Ü и я в данный момент использую эту IDE для пары моих сторонних проектов, написанных на Ü.
Может быть. Но я лично этой IDE не пользуюсь и чтобы написать плагин, неплохо было бы в ней освоится, на что у меня особо времени нету (в проекте есть задачи поважнее). Но было бы неплохо, если бы кто-нибудь другой это сделал. Да и другие IDE тоже не надо забывать, вроде IDE от JetBrains, QtCreator, Geany и множество других.
Ü более чем дружелюбен для любой, даже самой сумасшедшей сериализации. Оператор typeinfo обеспечивает инспекцию типов, при инспектировании можно сгенерировать код любой сложности, который работает с этими данными - хоть через шаблоны, хоть через mixin (с генерацией текстового представления кода).
"Захватить мир" было бы очень даже хорошо, но с этим есть некоторые сложности. Я понятия не имею, как перейти к этой стадии.
Ничего особо фантастического в переписывании C++ программ на Ü я не вижу. Это часто непрактично (работающий код переписывания не требует), но технически реализуемо, язык Ü достаточно богат функционалом в сравнении с C++.
Более прагматичный вариант - использовать Ü для написания новых программ. Я это уже практикую, в этом году уже один небольшой проект на Ü написал (см. мою предыдущую публикацию).
Плюсы использования Ü в сравнении с C++ вполне очевидны - безопасность работы с памятью, отсутствие граблей, унаследованных от C, более богатая (отчасти) стандартная библиотека, интегрированная система сборки и много чего ещё.
Деструкторов и не завозили, по той причине, что авторы языка Zig - неосиляторы C++, которые воспринимают значительную часть его нововведений в штыки.
В описанном вами подходе граблей всё ещё полно и назвать его "безопасным" - язык не поворачивается. Можно забыть написать удаление ресурсов в defer. Можно дважды удалить ресурс (если он куда-то в другую функцию передаётся, и та тоже вызывает освобождение в своём defer). Можно сохранить указатель ну некую область памяти и освободить её, забыв про этот указатель и разименовав его позже.
defer - вообще костыль, который противоречит базовым принципам структурного программирования. RAII его назвать нельзя, ибо RAII - это управление ресурсами на уровне типов.
Вообще, безопасность, это не "ну вроде норм выглядит", а формальное свойство, гарантируемое дизайном языка. В Zig её нету и авторы даже не пытаются её реализовать.
Очень дурной подход - сначала отказаться сознательно от деструкторов, разрешить по поводу и без жонглировать ручным выделением памяти и сырыми указателями и потом затыкать дыры, порождённые таким подходом, некоторым статическим анализатором, пусть и встроенным в компилятор.
Перемещение по-умолчанию некоторых типов и проверка на обращение к перемещённым переменным строго говоря ортогональны друг другу. Вполне возможно было бы сделать так, чтобы значения по умолчанию копируются, а для перемещения нужно использовать отдельный оператор языка, при этом сохранив проверку на обращение к объекту, который перемещён. Но авторы Rust решили так не делать и сделали любое копирование явным, видимо из боязни, что неявное копирование может в некоторых случаях к скрытому ухудшению производительности вести.
В C++ просто перемещения в строгом понимании вообще нету. std::move ничего не перемещает и только преобразует один вид ссылки в другой. Вся логика перемещения реализована через конструкторы перемещения или операторы перемещающего присваивания. При этом объект, подвергнутый "перемещению" все ещё существует, деструктор его будет вызван и ряд методов для него будут работать (но не все, там всё хитро с этим).
Это пример ущербного дизайна Rust, из-за которого некоторые типы молча перемещаются. К безопасности памяти это решение дизайна языка не имеет никакого отношения.
Чинится это, впрочем, весьма тривиально. Надо или s.clone() добавить, или сигнатуру функции my_func изменить.
При чём тут shared_ptr? Он к безопасности памяти отношения не имеет.
Как раз подходящий. В Rust ошибки вылезают на этапе сборки, если программист где-то накосячил, что даёт возможность из по-быстрому исправить. А в языках без безопасности ошибки возникают во время выполнения, часто очень странным и тяжело-диагностируемым способом.
Судя по статье, Zig - весьма посредственный язык. Да, пару интересных плюшек там добавили, но не более того. Наибольшая его проблема заключается в том, что он зачем-то сознательно разрабатывается как небезопасный язык (с точки зрения доступа к памяти), хотя уже давно известно, что эту безопасность на уровне языка обеспечить возможно и это не ухудшает производительность и почти не ухудшает эргономику использования.
На человеческой/гужевой тяге колёсный транспорт по такому ландшафту тянуть сложнее, чем тот же груз на себе или на животных тащить.
Ближний восток - местности там в основном плоские (хоть и не без гор местами) и пустынные. Самое то для колесниц. Ну а кавалерией они были как раз вытеснены, потому как кавалерия в проходимости сильно выигрывает.
Вот кстати да, упоминая колесо, забывают часто про дороги, без которых оно малополезно. Колесо реально может быть использовано только на весьма ровной естественной местности (вроде степи), перепады высот и водные преграды делают его использование слишком сложным. Решение - строить дороги и мосты. И с последним дело обстояло так себе большую часть времени, так что чаще использовался гужевой транспорт, а ещё лучше водный.
Про моря теплее нынешних вопрос есть. Сейчас в новостях говорят, что из-за того, что вода немного теплее стала, массово бледнеют и умирают кораллы. А как тогда они жили, когда моря были намного теплее? Или тогда они были к такой температуре привыкшими?
Предположу, что зависит от местности. Где-то кражи редки, а где-то наносят существенный урон и как следствие, меры против краж могут себя окупить. В данной новости о Калифорнии идёт речь, слыхал, что там мелкие кражи последние годы весьма участились, ибо их практически декриминализовали.
Проблема при решении задач часто заключается в том, что не очень то понятно, что какой-то из этих паттернов может быть использован. Часто требуется какое-то неявное допущение, с которым ещё не понятно истинно ли оно и как его истинность доказать, чтобы можно было этот паттерн использовать.
Злоупотребления конкуренцией не было. Любой ведь мог открыть такую торговую точку, которая описана в данной статье.
Злоупотребление тут было скорее из-за самого закона, требующего весьма недешёвой лицензии. Чую я, что это наверняка какие-нибудь состоятельные держатели питейных заведений пролоббировали такой закон, дабы вытеснить с рынка менее состоятельных конкурентов. А забота о здоровье граждан - лишь благовидный предлог (который и сейчас бывает используется).
Меня во всей этой истории поражает, что уже тогда власти подходили весьма трепетно к соблюдению своих же законов и не устраивали обыск этих разливочных заведений без должных оснований. В какой-нибудь другой стране не церемонились бы с этим и лавочку быстро-бы прикрыли.
Почему средневековые города себе акведуков не строили?