Rust для обеспечения безопасности и отсутствия UB вводит ограничения, начиная от проверки индексов при доступе к элементам массивов, до необходимости использования Arc<Mutex<T>> в многопоточных приложениях.
В большинстве случаев эти ограничения не важны, или обходятся, но, например, многопоточный мутабельный доступ к памяти может быть необходим.
Безопасность памяти не гарантирует корректность. Кроме того распространенность языков с динамической типизацией показывает что скорость написания может быть важнее безопасности типов. Можно задать вопрос: зачем нужны быстро написанные некорректные программы?
Их долго делали как раз отчасти потому, что необходимо было обеспечить взаимодействие системы сборки и компилятора, когда компилятор сначала анализирует файлы чтобы составить список зависимостей, чтобы потом обеспечить сборку.
Многие из идей раста близки современному C++. Небезопасные операции в которых легко совершить ошибку спрятаны в реализации, но в Rust значительно больше гарантий.
Но объем этих гарантий делает написание кода с супер высокими требованиями по производительности/задержке или с доступом к железу очень неудобным или невозможным без широкого использования unsafe. Вроде бы сообщество Rust планирует улучшить эргономику unsafe, но пока что некоторые вещи значительно удобнее делать на C++.
Так что Rust это конкурент C++ когда безопасность важнее производительности и конкурент языков со сборщиком мусора когда производительность важнее скорости разработки.
Игра 2024 года на Unreal выглядит лучше Crysis 2013 года. А ещё лучше посмотреть на то что последние версии Unreal могут не в играх, там явно видно производительность.
А многопоточку везде сложно писать. А там где "просто" можно уткнуться в невозможность нормального описания разделенных мутабельных данных или производительность мьютексов. И даже если эти проблемы можно обойти, нужно тщательно продумывать как это сделать не создав бутылочное горлышко.
Зачем брутфорс, можно отдельно хранить структуру папок/тэгов, и менять ее при изменении содержимого.
Насколько я вижу проблему, на данный момент путь к файлу - это его единственный и однозначный идентификатор. Но это не всегда правильно, потому что может быть несколько подходов к структурированию. Сейчас это потенциально решается символическими ссылками, но все ещё есть один "истинный" файл.
Если я правильно понимаю предложение с реляционной бд, все что мы видим в проводнике - это символические ссылки на файл. То есть убирается лишний "истинный" путь. Назвать это тэгами как будто лучше описывает структуру, хотя и сейчас можно имитировать тэги, например, папка с ссылками на фотографии "с Олегом" это эквивалент фильтрации по тэгу "с Олегом".
Разница между раскладками влияет меньше чем разница между обычной клавиатурой и сплитом с нормальной прошивкой.
Во-первых положение рук у разделенных клавиатур значительно удобнее.
Во-вторых наличие слоев делает работу со специальными клавишами намного удобнее. Иногда необходимо пользоваться стрелочками, home, end, и слои позволяют не двигать руку для доступа к ним.
В-третьих наличие встроенного устройства манипуляции указателем позволит ещё меньше переключаться на мышь. Например, иногда сайты плохо работают с vimium'ом, и чтобы сделать действие удобнее навести курсор и нажать.
У альтернативных раскладок есть объективные преимущества по сравнению с qwerty, но даже первые два фактора делают использование сплит клавиатур удобным и с qwerty.
У меня вариация corne, и при использовании обычной клавиатуры положение zxcv совершенно неудобно. Отсутствие caps lock и нестандартные положения ctrl, alt, meta клавиш в моей раскладке (meta очень активно использую для навигации в WM) делают использование обычной клавиатуры очень медленным. Без переобучения обычные клавиатуры для меня некомфортны и скорость печати очень низкая из-за ошибок ввода, так что вот вам первый такой случай)
Майкрософт создали Debug Adapter Protocol, который предоставляет интерфейс для взаимодействия с дебагером без деталей конкретной работы. gdb и lldb можно использовать через него.
Написав реализацию аллокатора мы получаем возможность использовать большую часть стандартной библиотеки, требующую динамическое выделение памяти.
Как видно для сложных систем с RTOS C++ и негомогенной памятью C++ плохо подходит. И создаст больше проблем чем предоставит преимуществ.
Изначальное утверждение из-за которого идет спор. Как C, так и C++ вынуждены использовать разные способы выделения памяти для разных целей. Логично что и освобождение памяти должно происходить по-разному. С++ позволяет обернуть это выделение в отдельный тип, облегчить слежение за освобождением памяти, и продолжить использовать тот же самый код. Внутренности reserve() не обязательно знать, описание поведения оставляет очень мало простора для интерпретации.
И даже если стандартные реализации совсем не подходят по каким-то причинам, своя реализация с RAII выглядит гораздо привелкательнее чем ручной менеджмент на C.
Есть как минимум два подхода для реализации быстрой свертки. В предложеном вами нет перехлеста исходного сигнала, но нужно обрабатывать перехлесты промежуточных сверток. Альтернативный подход - overlap save предполагает перехлест исходных данных, но не требует дополнительной обработки.
Я не очень знаком с Rust, но насколько я понял вы используете композицию? Если это так, то мне кажется не совсем честным и правильным называть это наследованием. Если я не ошибаюсь, композиция вместо наследования довольно устоявшееся название паттерна.
Нужно заметить, что межзвёздная пыль врезается в аппарат (или аппарат врезается в пыль, что не принципиально) со скоростью более 20 км/с, поэтому полностью испаряется от соударения.
Регистрация проводится спектрографом, «на лету» и отправляется на Землю. Собственно материал ловушки так же испаряется, но его значительно больше.
Мне так кажется, поправьте если не прав
В России есть институт в котором проводятся исследования печатных проводников. Технология схожая, рисунок наносится типографскими методами, застывание под ультрафиолетом. Печатают в том числе солннечные панели. Но такая технология все-равно слабо применима, сопротивление будет больше чем у меди, а гибкие печатные платы уже производят, например на полиимидных основаниях. Применение конечно можно найти, прототипирование и изменение комутации в ходе отладки, но это все достаточно малые области
Увы даже не слишком сложные обсуждения могут перейти в ссору из-за неопонимания, несмотря на то, что люди на самом деле согласны. Всегда в споре с друзьями пытаюсь выяснить что именно подразумевает собеседник, а они назыавют меня занудой=(
Rust для обеспечения безопасности и отсутствия UB вводит ограничения, начиная от проверки индексов при доступе к элементам массивов, до необходимости использования Arc<Mutex<T>> в многопоточных приложениях.
В большинстве случаев эти ограничения не важны, или обходятся, но, например, многопоточный мутабельный доступ к памяти может быть необходим.
Безопасность памяти не гарантирует корректность. Кроме того распространенность языков с динамической типизацией показывает что скорость написания может быть важнее безопасности типов. Можно задать вопрос: зачем нужны быстро написанные некорректные программы?
const char*
C++20 modules примерно это и реализуют.
Их долго делали как раз отчасти потому, что необходимо было обеспечить взаимодействие системы сборки и компилятора, когда компилятор сначала анализирует файлы чтобы составить список зависимостей, чтобы потом обеспечить сборку.
Многие из идей раста близки современному C++. Небезопасные операции в которых легко совершить ошибку спрятаны в реализации, но в Rust значительно больше гарантий.
Но объем этих гарантий делает написание кода с супер высокими требованиями по производительности/задержке или с доступом к железу очень неудобным или невозможным без широкого использования unsafe. Вроде бы сообщество Rust планирует улучшить эргономику unsafe, но пока что некоторые вещи значительно удобнее делать на C++.
Так что Rust это конкурент C++ когда безопасность важнее производительности и конкурент языков со сборщиком мусора когда производительность важнее скорости разработки.
Игра 2024 года на Unreal выглядит лучше Crysis 2013 года. А ещё лучше посмотреть на то что последние версии Unreal могут не в играх, там явно видно производительность.
А многопоточку везде сложно писать. А там где "просто" можно уткнуться в невозможность нормального описания разделенных мутабельных данных или производительность мьютексов. И даже если эти проблемы можно обойти, нужно тщательно продумывать как это сделать не создав бутылочное горлышко.
Если честно не знал как работают жесткие ссылки. Тогда действительно не вижу в чем проблема файлов и папок.
Зачем брутфорс, можно отдельно хранить структуру папок/тэгов, и менять ее при изменении содержимого.
Насколько я вижу проблему, на данный момент путь к файлу - это его единственный и однозначный идентификатор. Но это не всегда правильно, потому что может быть несколько подходов к структурированию. Сейчас это потенциально решается символическими ссылками, но все ещё есть один "истинный" файл.
Если я правильно понимаю предложение с реляционной бд, все что мы видим в проводнике - это символические ссылки на файл. То есть убирается лишний "истинный" путь. Назвать это тэгами как будто лучше описывает структуру, хотя и сейчас можно имитировать тэги, например, папка с ссылками на фотографии "с Олегом" это эквивалент фильтрации по тэгу "с Олегом".
Разница между раскладками влияет меньше чем разница между обычной клавиатурой и сплитом с нормальной прошивкой.
Во-первых положение рук у разделенных клавиатур значительно удобнее.
Во-вторых наличие слоев делает работу со специальными клавишами намного удобнее. Иногда необходимо пользоваться стрелочками, home, end, и слои позволяют не двигать руку для доступа к ним.
В-третьих наличие встроенного устройства манипуляции указателем позволит ещё меньше переключаться на мышь. Например, иногда сайты плохо работают с vimium'ом, и чтобы сделать действие удобнее навести курсор и нажать.
У альтернативных раскладок есть объективные преимущества по сравнению с qwerty, но даже первые два фактора делают использование сплит клавиатур удобным и с qwerty.
"уродливо" слабенький аргумент в пользу "фундаментально сломан"
C++ развивался и развивается эволюцией. Просто заново сделать не получится, нужна обратная совместимость.
Сейчас есть несколько проектов языков преемников с нативной поддержкой C++, например Carbon и Cpp2, но они скорее в стадии исследования дизайна.
У меня вариация corne, и при использовании обычной клавиатуры положение zxcv совершенно неудобно. Отсутствие caps lock и нестандартные положения ctrl, alt, meta клавиш в моей раскладке (meta очень активно использую для навигации в WM) делают использование обычной клавиатуры очень медленным. Без переобучения обычные клавиатуры для меня некомфортны и скорость печати очень низкая из-за ошибок ввода, так что вот вам первый такой случай)
Майкрософт создали Debug Adapter Protocol, который предоставляет интерфейс для взаимодействия с дебагером без деталей конкретной работы. gdb и lldb можно использовать через него.
Написав реализацию аллокатора мы получаем возможность использовать большую часть стандартной библиотеки, требующую динамическое выделение памяти.
Изначальное утверждение из-за которого идет спор.
Как C, так и C++ вынуждены использовать разные способы выделения памяти для разных целей. Логично что и освобождение памяти должно происходить по-разному. С++ позволяет обернуть это выделение в отдельный тип, облегчить слежение за освобождением памяти, и продолжить использовать тот же самый код.
Внутренности reserve() не обязательно знать, описание поведения оставляет очень мало простора для интерпретации.
И даже если стандартные реализации совсем не подходят по каким-то причинам, своя реализация с RAII выглядит гораздо привелкательнее чем ручной менеджмент на C.
Есть как минимум два подхода для реализации быстрой свертки. В предложеном вами нет перехлеста исходного сигнала, но нужно обрабатывать перехлесты промежуточных сверток.
Альтернативный подход - overlap save предполагает перехлест исходных данных, но не требует дополнительной обработки.
Я не очень знаком с Rust, но насколько я понял вы используете композицию? Если это так, то мне кажется не совсем честным и правильным называть это наследованием. Если я не ошибаюсь, композиция вместо наследования довольно устоявшееся название паттерна.
А критика концептов с точки зрения математиков есть где-то в виде текста? Очень интересно.
А что за библиотека? Поделитесь ссылкой, пожалуйста.
Регистрация проводится спектрографом, «на лету» и отправляется на Землю. Собственно материал ловушки так же испаряется, но его значительно больше.
Мне так кажется, поправьте если не прав