Я понимаю что некоторые изменения невозможно внести с сохранением обратной совместимости, и это одна из причин почему в c++ ещё долго будут проблемы. Тем не менее некоторые из данных примеров вполне могут работать даже с сохранением обратной совместимости, хотя я сомневаюсь что они будут изменены.
explicit по умолчанию не значит отсутствие возможности обозначить конструктор как implicit используя ключевое слово или атрибут.
[[nodiscard]] не препятствует игнорированию аргументов по умолчанию, а лишь вызывает предупреждение. После введения _ плейсхолдера в C++26 или используя каст в void.
enum class X{}; уже не экспортирует свои значения в окружающее пространство имён, и не конвертируется имплиситно из/в нижележащий тип. Но у него все ещё не может быть членов, что делает работу с ним менее удобной.
Для обьектов размером не более 2 указателей эквивалент `const auto`. Для обьектов большего размера `const auto&`.
В Cpp2 аргументы обладают дополнительной классификацией, in, copy, out, inout, move, forward. В зависимости от этого применяются соответствующие классификаторы. По умолчанию in.
При передаче даже простых функторов в алгоритмы вроде std::transform лябмды очень многословны. Меня устраивает явный захват переменных, но иногда хочется чего-то более простого.
В Cpp2 Герб Саттер сформировал очень приятный синтаксис, единый для функций и лямбд. Если вкратце, то auto в аргументах функции опционален и предполагается по умолчанию. Хотя меня и немного расстраивает отсутствие возможности явного захвата, сам синтаксис приятнее текущего.
Я люблю C++, но у языка однозначно есть недостатки, особенно если сравнивать его с другими современными языками.
explicit, [[nodiscard]] и пр. должны быть по умолчанию
У лямбд нет короткого синтаксиса
enum class вовсе не class
Конечно язык развивается, но zip_view, expected, статические operator[],() появились только в C++23. Рефлексию и pattern matching все ещё ждём. Надеюсь что они получатся лучше чем корутины, которые ещё долго можно будет рассматривать как недостаток языка.
Да, переход на новый стандарт может быть проблемным. Но это не повод оставлять UB навсегда. Без тестов сложно сказать наверняка, но в большинстве случаев IO будет значительно медленнее обнуления памяти. В критически важных местах необходимо будет вручную добавить атрибуты. Кроме того компиляторы могут добавить специальные правила для стандартных функций и не проводить инициализацию. Предлагаемый подход позволит легаси коду работать, а компиляторы будут заботиться о скорости.
Переменная на стеке совсем не факт что в регистре находится. При "выделении" переменой на стеке может вообще ничего не происходить, а просто увеличится указатель стека, причем сразу на размер нескольких переменных.
Разница между присваиванием и инициализацией для int может и не существенная, но эти термины работают и для сложных типов. А если писать дженерик код, то уже нельзя заранее знать будет ли разница, и стоит предполагать что будет. Это не синтаксический сахар, это основа системы классов C++.
Если речь про обращение к локальным переменным, то вполне вероятно что компиляторы будут выдавать предупреждение. Если переменная пересекает границу вызова функции по указателю или по ссылке, то компилятор не может знать будет ли чтение из этой переменной.
Возможно ImGui не так удобен если нужна стилизация. Нет разделения на форму и код. Нет встроенной поддержки системных тем.
Но функционально на нем можно сделать наверное все, что может понадобиться в относительно нормальном интерфейсе. А с дополнениями вроде ImPlot вообще мощнейший инструмент с минимальными затратами на освоение.
Мне искренне интересно, что по-вашему может Qt, что не получится сделать с Dear ImGui?
p1689 как раз был создан для стандартизации формата файла зависимостей.
Если я не ошибаюсь, то модули как фича в себе были добавлены в компиляторы раньше, чем поддержка p1689, но без системы сборки их применение было не очень удобным, так как был важен порядок передачи файлов в компилятор.
Rust для обеспечения безопасности и отсутствия UB вводит ограничения, начиная от проверки индексов при доступе к элементам массивов, до необходимости использования Arc<Mutex<T>> в многопоточных приложениях.
В большинстве случаев эти ограничения не важны, или обходятся, но, например, многопоточный мутабельный доступ к памяти может быть необходим.
Безопасность памяти не гарантирует корректность. Кроме того распространенность языков с динамической типизацией показывает что скорость написания может быть важнее безопасности типов. Можно задать вопрос: зачем нужны быстро написанные некорректные программы?
Их долго делали как раз отчасти потому, что необходимо было обеспечить взаимодействие системы сборки и компилятора, когда компилятор сначала анализирует файлы чтобы составить список зависимостей, чтобы потом обеспечить сборку.
Многие из идей раста близки современному C++. Небезопасные операции в которых легко совершить ошибку спрятаны в реализации, но в Rust значительно больше гарантий.
Но объем этих гарантий делает написание кода с супер высокими требованиями по производительности/задержке или с доступом к железу очень неудобным или невозможным без широкого использования unsafe. Вроде бы сообщество Rust планирует улучшить эргономику unsafe, но пока что некоторые вещи значительно удобнее делать на C++.
Так что Rust это конкурент C++ когда безопасность важнее производительности и конкурент языков со сборщиком мусора когда производительность важнее скорости разработки.
Игра 2024 года на Unreal выглядит лучше Crysis 2013 года. А ещё лучше посмотреть на то что последние версии Unreal могут не в играх, там явно видно производительность.
А многопоточку везде сложно писать. А там где "просто" можно уткнуться в невозможность нормального описания разделенных мутабельных данных или производительность мьютексов. И даже если эти проблемы можно обойти, нужно тщательно продумывать как это сделать не создав бутылочное горлышко.
Зачем брутфорс, можно отдельно хранить структуру папок/тэгов, и менять ее при изменении содержимого.
Насколько я вижу проблему, на данный момент путь к файлу - это его единственный и однозначный идентификатор. Но это не всегда правильно, потому что может быть несколько подходов к структурированию. Сейчас это потенциально решается символическими ссылками, но все ещё есть один "истинный" файл.
Если я правильно понимаю предложение с реляционной бд, все что мы видим в проводнике - это символические ссылки на файл. То есть убирается лишний "истинный" путь. Назвать это тэгами как будто лучше описывает структуру, хотя и сейчас можно имитировать тэги, например, папка с ссылками на фотографии "с Олегом" это эквивалент фильтрации по тэгу "с Олегом".
Я понимаю что некоторые изменения невозможно внести с сохранением обратной совместимости, и это одна из причин почему в c++ ещё долго будут проблемы. Тем не менее некоторые из данных примеров вполне могут работать даже с сохранением обратной совместимости, хотя я сомневаюсь что они будут изменены.
explicitпо умолчанию не значит отсутствие возможности обозначить конструктор как implicit используя ключевое слово или атрибут.[[nodiscard]]не препятствует игнорированию аргументов по умолчанию, а лишь вызывает предупреждение. После введения_плейсхолдера в C++26 или используя каст вvoid.enum class X{}; уже не экспортирует свои значения в окружающее пространство имён, и не конвертируется имплиситно из/в нижележащий тип. Но у него все ещё не может быть членов, что делает работу с ним менее удобной.
Для обьектов размером не более 2 указателей эквивалент `const auto`. Для обьектов большего размера `const auto&`.
В Cpp2 аргументы обладают дополнительной классификацией, in, copy, out, inout, move, forward. В зависимости от этого применяются соответствующие классификаторы. По умолчанию in.
При передаче даже простых функторов в алгоритмы вроде std::transform лябмды очень многословны. Меня устраивает явный захват переменных, но иногда хочется чего-то более простого.
В Cpp2 Герб Саттер сформировал очень приятный синтаксис, единый для функций и лямбд. Если вкратце, то
autoв аргументах функции опционален и предполагается по умолчанию. Хотя меня и немного расстраивает отсутствие возможности явного захвата, сам синтаксис приятнее текущего.Я люблю C++, но у языка однозначно есть недостатки, особенно если сравнивать его с другими современными языками.
explicit, [[nodiscard]] и пр. должны быть по умолчанию
У лямбд нет короткого синтаксиса
enum class вовсе не class
Конечно язык развивается, но zip_view, expected, статические operator[],() появились только в C++23. Рефлексию и pattern matching все ещё ждём. Надеюсь что они получатся лучше чем корутины, которые ещё долго можно будет рассматривать как недостаток языка.
Meta + ЛКМ для перетаскивания в любой области окна, Meta + ПКМ для Изменения размера. Не уверен про ваш DE, но везде где я пробовал это работает.
Да, переход на новый стандарт может быть проблемным. Но это не повод оставлять UB навсегда. Без тестов сложно сказать наверняка, но в большинстве случаев IO будет значительно медленнее обнуления памяти. В критически важных местах необходимо будет вручную добавить атрибуты. Кроме того компиляторы могут добавить специальные правила для стандартных функций и не проводить инициализацию.
Предлагаемый подход позволит легаси коду работать, а компиляторы будут заботиться о скорости.
Специально для таких случаев будет атрибут
[[indeterminate]].Переменная на стеке совсем не факт что в регистре находится. При "выделении" переменой на стеке может вообще ничего не происходить, а просто увеличится указатель стека, причем сразу на размер нескольких переменных.
Разница между присваиванием и инициализацией для int может и не существенная, но эти термины работают и для сложных типов. А если писать дженерик код, то уже нельзя заранее знать будет ли разница, и стоит предполагать что будет. Это не синтаксический сахар, это основа системы классов C++.
Если речь про обращение к локальным переменным, то вполне вероятно что компиляторы будут выдавать предупреждение. Если переменная пересекает границу вызова функции по указателю или по ссылке, то компилятор не может знать будет ли чтение из этой переменной.
Возможно ImGui не так удобен если нужна стилизация. Нет разделения на форму и код. Нет встроенной поддержки системных тем.
Но функционально на нем можно сделать наверное все, что может понадобиться в относительно нормальном интерфейсе. А с дополнениями вроде ImPlot вообще мощнейший инструмент с минимальными затратами на освоение.
Мне искренне интересно, что по-вашему может Qt, что не получится сделать с Dear ImGui?
А потом и в браузере и в оконном менеджере / композиторе те же горячие клавиши. И двигать руку на мышку становится совсем грустно.
gcc14+, clang16+, visual studio 2022 поддерживают p1689
p1689 как раз был создан для стандартизации формата файла зависимостей.
Если я не ошибаюсь, то модули как фича в себе были добавлены в компиляторы раньше, чем поддержка p1689, но без системы сборки их применение было не очень удобным, так как был важен порядок передачи файлов в компилятор.
Rust для обеспечения безопасности и отсутствия UB вводит ограничения, начиная от проверки индексов при доступе к элементам массивов, до необходимости использования Arc<Mutex<T>> в многопоточных приложениях.
В большинстве случаев эти ограничения не важны, или обходятся, но, например, многопоточный мутабельный доступ к памяти может быть необходим.
Безопасность памяти не гарантирует корректность. Кроме того распространенность языков с динамической типизацией показывает что скорость написания может быть важнее безопасности типов. Можно задать вопрос: зачем нужны быстро написанные некорректные программы?
const char*
C++20 modules примерно это и реализуют.
Их долго делали как раз отчасти потому, что необходимо было обеспечить взаимодействие системы сборки и компилятора, когда компилятор сначала анализирует файлы чтобы составить список зависимостей, чтобы потом обеспечить сборку.
Многие из идей раста близки современному C++. Небезопасные операции в которых легко совершить ошибку спрятаны в реализации, но в Rust значительно больше гарантий.
Но объем этих гарантий делает написание кода с супер высокими требованиями по производительности/задержке или с доступом к железу очень неудобным или невозможным без широкого использования unsafe. Вроде бы сообщество Rust планирует улучшить эргономику unsafe, но пока что некоторые вещи значительно удобнее делать на C++.
Так что Rust это конкурент C++ когда безопасность важнее производительности и конкурент языков со сборщиком мусора когда производительность важнее скорости разработки.
Игра 2024 года на Unreal выглядит лучше Crysis 2013 года. А ещё лучше посмотреть на то что последние версии Unreal могут не в играх, там явно видно производительность.
А многопоточку везде сложно писать. А там где "просто" можно уткнуться в невозможность нормального описания разделенных мутабельных данных или производительность мьютексов. И даже если эти проблемы можно обойти, нужно тщательно продумывать как это сделать не создав бутылочное горлышко.
Если честно не знал как работают жесткие ссылки. Тогда действительно не вижу в чем проблема файлов и папок.
Зачем брутфорс, можно отдельно хранить структуру папок/тэгов, и менять ее при изменении содержимого.
Насколько я вижу проблему, на данный момент путь к файлу - это его единственный и однозначный идентификатор. Но это не всегда правильно, потому что может быть несколько подходов к структурированию. Сейчас это потенциально решается символическими ссылками, но все ещё есть один "истинный" файл.
Если я правильно понимаю предложение с реляционной бд, все что мы видим в проводнике - это символические ссылки на файл. То есть убирается лишний "истинный" путь. Назвать это тэгами как будто лучше описывает структуру, хотя и сейчас можно имитировать тэги, например, папка с ссылками на фотографии "с Олегом" это эквивалент фильтрации по тэгу "с Олегом".