По моему мнению, в boost даже в часть библиотек внедрить модули будет сложнее чем в STL. Хотя бы по тому, что бусту нужно быть совместимым с кучей реализаций, а STL как правило все же под один компилятор затачивается (даже если несколько, то все равно требования к версии жесткие). Ну и объемы кода несравнимые опять же.
Я предполагаю, что возможно какие-то новые и максимально независимые библиотеки, вроде Boost.Stacktrace могут получить поддержку в виде модулей, но не более того.
Идею я вашу понял, я сам о подобном думал. Беда в том, что в таком режиме станет неюзабельной и STL, и 98% всех существующих библиотек. (посмотрите под капот того же variant — дичь же!).
Возможно ситуацию спасет введение в язык какого-то unsafe блока по аналогии с Rust — в который можно пихать что угодно (ну или #pragma unsafe — но с препроцессором тяжело проконтролировать что оно за пределы файла не уедете). И вот в комбинации с этим блоком, да, можно вводить -safe ключ, который запрещает сырые указатели и что там еще вам не нравится :)
(проблема больше в том, что достаточно сложно определить чем там можно отстрелить себе ногу — например, висячие ссылки тоже никто не отменял, а и без указателей и без ссылок вообще не понятно как эффективный код писать).
Да как нет, deprecated auto_ptr например; ключевой слово auto в старом значении тоже выкинули. Выкинули из языка триграфы.
Просто выкидывание фич из библиотеки происходит просто медленно, а из самого языка — еще в десять раз медленнее. Но в C++20 «депрекейчение» вроде пободрее пошло (в STL).
Абсолютная совместимость не постулируется. Стараются лишь чтобы как можно больше кода не сломалось при переходе на новый стандарт. Ну разумеется, недопустимо, чтобы код при сборке с новыми стандартом стал работать по-другому, а в редких случаях, когда сборка ломается — изменения таки имеют шанс попасть в новую версию (опять же, если все согласятся что это очень редкий кейс).
Сырые указатели, да, никто в обозримом будущем не выкинет (как это было в первоапрельской шутке)
Я с вот этой веткой CLang игралсся: github.com/arcosuc3m/clang-contracts
Делал на работе по ней презентацию с примерами, если честно, никому текущая реализация не понравилась. Очень много неочевидных моментов.
Так что я как только прочитал, что контракты выкидывают — прямо вздох облегчения :)
Если расклад такой да, смахивает на лицемерие. Но это можно попытаться узнать на этапе собеседования вопросами «а чем вы планируете меня занять на новой должности?»
если будет какое-то монотонное «поддержка ХХХ… сопровождение YYY...», то должно напрячь) можно спросить «а зачем указан в вакансии С++42, где он у вас там применяться планирует?» Я когда на работу устраивался, спрашивал как применяются указанные в вакансии технологии, мне вполне без утайки все сказали.
Опять же странно если начнут отмазываться корпоративными секретами, ибо всегда можно найти способ как не сказать слишком много)
А что не так-то? В компании не было знающего человека, они его нанимают, чтобы пришел и все сделал по-человечески (тесты и код по паттернам) :) если в требованиях вакансии это отражено — в чем проблема?
Не знаю как сейчас, но когда я 6 лет назад пробовал собрать кросс под нужный мне ARM, тормозило просто ужасно. Так что я думаю все тормоза MinGW применимы и к GCC в cygwin. Опять же, в качестве приоритета в cygwin — портируемость, а не производительность.
Из того что не работает — пробовал завести distcc под cygwin, он тупо крашился) спрашивал в одном из своем посте в комментах — кто-то вообще заводил distcc+cygwin, мне не ответили.
Сам такой Игнат, выбрал как раз такую опцию, думаю, не зря. К сожалению, не знаю пока сколько времени займет эта «переоценка», лежу дома, посещаю психиатра, пью таблетки…
Я не спорю что некоторые выделяют «4 матных корня», мол всякие там пидарасы — это не мат, но я лишь отметил что очень, очень часто, «мат» и «матершина» является синонимом обсценной лексики вообще. Поэтому я рассмотрел корневой комментарий просто как занудство «ага! в статье написано матерные, а пидар — не мат, так что накося-выкуси, автор!», т.к. предметом статьи лингвистика не является, а обсценная лексика точно так же должна быть исключена в СМИ.
Я предполагаю, что возможно какие-то новые и максимально независимые библиотеки, вроде Boost.Stacktrace могут получить поддержку в виде модулей, но не более того.
Возможно ситуацию спасет введение в язык какого-то unsafe блока по аналогии с Rust — в который можно пихать что угодно (ну или #pragma unsafe — но с препроцессором тяжело проконтролировать что оно за пределы файла не уедете). И вот в комбинации с этим блоком, да, можно вводить -safe ключ, который запрещает сырые указатели и что там еще вам не нравится :)
(проблема больше в том, что достаточно сложно определить чем там можно отстрелить себе ногу — например, висячие ссылки тоже никто не отменял, а и без указателей и без ссылок вообще не понятно как эффективный код писать).
Просто выкидывание фич из библиотеки происходит просто медленно, а из самого языка — еще в десять раз медленнее. Но в C++20 «депрекейчение» вроде пободрее пошло (в STL).
Абсолютная совместимость не постулируется. Стараются лишь чтобы как можно больше кода не сломалось при переходе на новый стандарт. Ну разумеется, недопустимо, чтобы код при сборке с новыми стандартом стал работать по-другому, а в редких случаях, когда сборка ломается — изменения таки имеют шанс попасть в новую версию (опять же, если все согласятся что это очень редкий кейс).
Сырые указатели, да, никто в обозримом будущем не выкинет (как это было в первоапрельской шутке)
github.com/arcosuc3m/clang-contracts
Делал на работе по ней презентацию с примерами, если честно, никому текущая реализация не понравилась. Очень много неочевидных моментов.
Так что я как только прочитал, что контракты выкидывают — прямо вздох облегчения :)
если будет какое-то монотонное «поддержка ХХХ… сопровождение YYY...», то должно напрячь) можно спросить «а зачем указан в вакансии С++42, где он у вас там применяться планирует?» Я когда на работу устраивался, спрашивал как применяются указанные в вакансии технологии, мне вполне без утайки все сказали.
Опять же странно если начнут отмазываться корпоративными секретами, ибо всегда можно найти способ как не сказать слишком много)
Из того что не работает — пробовал завести distcc под cygwin, он тупо крашился) спрашивал в одном из своем посте в комментах — кто-то вообще заводил distcc+cygwin, мне не ответили.