I think it's like a punch in the face. We used to ridicule Linux and praise ourselves that we have separated ports and base upgrade mechanic. It means we admit Linux's way is practically easier, more flexible and more reasonable than our own that we finally have to adopt it. It's shameful. What about you?
Вполне может. Алиасинга того же нет, да и вообще язык строже.
Но скорее всего с llvm так не поступает. Потому что вот например Rust
попытался передавать где только может "restrict" и llvm сломалось,
пришлось не выпендриваться: https://github.com/rust-lang/rust/issues/54878
А если речь идет именно про базовую, то насколько я помню
туда входит совсем небольшое количество утилит, насколько это критично по сравнению
со всем остальным набором софта в котором есть куча разночтений.
Какой-либо унификации документации, конфигурации, вывода информации в софте толком нет. Всюду и везде будет явно и отчётливо видно, что вот эта небольшая программа/утилита написана одним человеком, а вот эта другим.
Как-то притянуто за уши. Кроме базовых утилит набор-то софта у обоих одинаковый. От GNOME до Wireshark, от mongodb до nginx все же одинаковое. Или разработчики *BSD для всех этих тысяч популярных проектов с открытым кодом дописывают документацию, переделывают им формат конфигов и так далее? Почему-то я очень в этом сомневаюсь.
там вроде можно собрать такую программу размером в примерно 1 мегабайт
Ну в данном случае мы же говорим не о бинарнике, а разделяемой библиотеке на Rust.
У меня она занимает 27K после strip, думаю с panic=abort можно еще ужать.
Это конечно "hello world" с одной функцией:
А уж какое лютое шаманство творится при сборке и сопряжении с Rust…
А в чем шаманство? Я писал интерфейс на Qt/C++ и логику на Rust. Общение
было с помощью Rust/FFI. Rust/FFI я сам конечно не писал он автоматом генерировался.
Но у меня конечно не было цели влезть в ±5МБ, хотя в теории это возможно,
если статически слинковаться с Qt и выкинуть неиспользуемые функции,
но я проверял давно и с Qt 4.x, возможно с Qt 5.x все хуже (имеется ввиду провверял возможность влезть в ±5 мегабайт).
системная разработка — это сложно. Вот казалось бы, возьми существующий подход (придумывать ничего не нужно) и примени к существующему коду. Начинаешь — и тут же сталкиваешься со многими неочевидными и сложными вещами
Честно говоря не заметил ничего специфичного относительно "системности".
Все было бы тоже самое для любого большого сложного проекта с длинной историей разработки который при этом все еще развивается. В таких проектах точно так же тривиальный патч может проходить целую череду review/not accepted если изменяемый пакет/модуль много где используется.
С надёжностью работы вообще проблем нет. То, что вы тут накопали — это хитрые случаи name mangling
Э… "name mangling" такая же полноправная часть ABI как и все остальное. И то что приложение не запуститься пожаловавшись на ненайденный символ или одна из функций отвалилась, потому при вызове функции не удалось подгрузить плагин такая же проблема как и падение программы из разного размера объектов или их разного выравнивания (кстати там и выравнивание упоминается, а не только mangling).
Разве это не сделает библиотеки более модульными
удобными в использовании?
Ну в моем представлении основная проблема с использованием сторонних библиотек две:
1) Нужна сборка для конкретно твоего компилятора и возможно твоего C++ runtime для того чтобы использовать чужой код, поэтому очень часто нужно собирать из исходников
2) В сторонней библиотеке используется система сборки X, а у тебя Y
И отсюда возникают разные крайности, от библиотек в виде одного заголовочного файла до нежелания вообще использовать любой сторонний код.
Не уверен как тут модули могут помочь. Адепты "однозаголовочных библиотек" не добавляли даже один .cpp файл (ну кроме тестов), не вижу причин чтобы они перешли на модули. А не для однозаголовочных библиотек все также система сборки X vs Y.
поверю, когда увижу, что подключение новых 3rdparty библиотек перестало быть болью в голове и заднице
Вроде бы в этом аспекте ничего нового. Они для ускорения компиляции, для борьбы с нарушение ODR, изоляции имен и т.д. Но это же не пакетный менджер и даже не унификация описания инструкции по сборке.
А вот в мире Linux и Unix — всё было совсем по другому.
Ну…
Например из man gcc (секция про -fabi-version):
Version 1 is the version of the C++ ABI that first appeared in G++ 3.2.
Version 2 is the version of the C++ ABI that first appeared in G++ 3.4, and was the default through G++ 4.9.
Version 3 corrects an error in mangling a constant address as a template argument.
Version 4, which first appeared in G++ 4.5, implements a standard mangling for vector types.
Version 5, which first appeared in G++ 4.6, corrects the mangling of attribute const/volatile on function pointer types, decltype of a plain decl, and use of a function parameter in the
declaration of another parameter.
Version 6, which first appeared in G++ 4.7, corrects the promotion behavior of C++11 scoped enums and the mangling of template argument packs, const/static_cast, prefix ++ and --, and a
class scope function used as a template argument.
Version 7, which first appeared in G++ 4.8, that treats nullptr_t as a builtin type and corrects the mangling of lambdas in default argument scope.
Version 8, which first appeared in G++ 4.9, corrects the substitution behavior of function types with function-cv-qualifiers.
Version 9, which first appeared in G++ 5.2, corrects the alignment of "nullptr_t".
Version 10, which first appeared in G++ 6.1, adds mangling of attributes that affect type identity, such as ia32 calling convention attributes (e.g. stdcall).
Version 11, which first appeared in G++ 7, corrects the mangling of sizeof... expressions and operator names. For multiple entities with the same name within a function, that are
declared in different scopes, the mangling now changes starting with the twelfth occurrence. It also implies -fnew-inheriting-ctors.
Version 12, which first appeared in G++ 8, corrects the calling conventions for empty classes on the x86_64 target and for classes with only deleted copy/move constructors. It
accidentally changes the calling convention for classes with a deleted copy constructor and a trivial move constructor.
Version 13, which first appeared in G++ 8.2, fixes the accidental change in version 12.
То есть не все так однозначно, если хочется быть уверенным в надежности работы программы,
и между частями кода используется C++ ABI, я бы все одной версией g++ собрал,
на всякий случай.
Потому что объект синхронизации должен с кем-то разделяться иначе его использование бессмысленно. А здесь видно что каждый вызов использует свой уникальный объект, то есть бессмыслица какая-то. Если только конечно внутри конструктора CriticalSection нет обращение к какой-то глобальной сущности.
64-битная система обеспечивает доступ к памяти по 8 байт на одно чтение/запись
Непонятно что имеется ввиду. Физически и логически битность ОС к тому сколько максимум можно за раз записать отношения не имеет. Физически там LPDDR4 память, сколько бит из нее раз может забрать процессор никак не меняется от битности ОС.
Логически для 32битного arm есть инструкции STRD/LDRD, с помощью них можно запустить запись чтение сразу 8 байт.
Из личного опыта. Как-то заказчик в ТЗ прописал что хочет покрытия тестами, так как после основного этапа разработки собирается сопровождать разработанное ПО своими силами. И в проекте было полно тестового кода не только юнит тестов, но эмулирующих работу с GUI и т.п… Но тесты начали приносить пользу (раз где-то в неделю отлавливая баги) только когда доля покрытого тестами кода стала превышать 80% покрытия.
А до этого момента автотесты прогоняемые CI помогало найти ошибку до начала ручного тестирования только считанное количество раз.
Когда я вернулся домой, меня ждала новость — проект работает
Какой-то очень неправдоподобный конец истории.
Весь опыт подсказывает, что либо это придуманная история
или авто и ручное тесты не покрывали большую часть функционала,
за счет этого в коде и появилась куча странного функционала который
непонятно как прошел QA.
Ну там довольно много просвещенно управлению пакетами в Debian vs FreeBSD.
И это было в 2011, а в 2019:
https://forums.freebsd.org/threads/what-do-you-think-about-the-new-package-base.70608/
Но скорее всего с llvm так не поступает. Потому что вот например Rust
попытался передавать где только может "restrict" и llvm сломалось,
пришлось не выпендриваться: https://github.com/rust-lang/rust/issues/54878
Так я писал
А если речь идет именно про базовую, то насколько я помню
туда входит совсем небольшое количество утилит, насколько это критично по сравнению
со всем остальным набором софта в котором есть куча разночтений.
Как-то притянуто за уши. Кроме базовых утилит набор-то софта у обоих одинаковый. От GNOME до Wireshark, от mongodb до nginx все же одинаковое. Или разработчики *BSD для всех этих тысяч популярных проектов с открытым кодом дописывают документацию, переделывают им формат конфигов и так далее? Почему-то я очень в этом сомневаюсь.
Ну в данном случае мы же говорим не о бинарнике, а разделяемой библиотеке на Rust.
У меня она занимает 27K после strip, думаю с panic=abort можно еще ужать.
Это конечно "hello world" с одной функцией:
Бинарник собранный в release режиме кстати занимает 207k с main вида 'println!("hello")'.
А в чем шаманство? Я писал интерфейс на Qt/C++ и логику на Rust. Общение
было с помощью Rust/FFI. Rust/FFI я сам конечно не писал он автоматом генерировался.
Но у меня конечно не было цели влезть в ±5МБ, хотя в теории это возможно,
если статически слинковаться с Qt и выкинуть неиспользуемые функции,
но я проверял давно и с Qt 4.x, возможно с Qt 5.x все хуже (имеется ввиду провверял возможность влезть в ±5 мегабайт).
Честно говоря не заметил ничего специфичного относительно "системности".
Все было бы тоже самое для любого большого сложного проекта с длинной историей разработки который при этом все еще развивается. В таких проектах точно так же тривиальный патч может проходить целую череду review/not accepted если изменяемый пакет/модуль много где используется.
Э… "name mangling" такая же полноправная часть ABI как и все остальное. И то что приложение не запуститься пожаловавшись на ненайденный символ или одна из функций отвалилась, потому при вызове функции не удалось подгрузить плагин такая же проблема как и падение программы из разного размера объектов или их разного выравнивания (кстати там и выравнивание упоминается, а не только mangling).
Ну в моем представлении основная проблема с использованием сторонних библиотек две:
1) Нужна сборка для конкретно твоего компилятора и возможно твоего C++ runtime для того чтобы использовать чужой код, поэтому очень часто нужно собирать из исходников
2) В сторонней библиотеке используется система сборки X, а у тебя Y
И отсюда возникают разные крайности, от библиотек в виде одного заголовочного файла до нежелания вообще использовать любой сторонний код.
Не уверен как тут модули могут помочь. Адепты "однозаголовочных библиотек" не добавляли даже один .cpp файл (ну кроме тестов), не вижу причин чтобы они перешли на модули. А не для однозаголовочных библиотек все также система сборки X vs Y.
Вроде бы в этом аспекте ничего нового. Они для ускорения компиляции, для борьбы с нарушение ODR, изоляции имен и т.д. Но это же не пакетный менджер и даже не унификация описания инструкции по сборке.
По идее для любой работы с utf-8 строками где раньше использовался char.
Еще меньше проблем с "aliasing".
Ну…
Например из man gcc (секция про -fabi-version):
То есть не все так однозначно, если хочется быть уверенным в надежности работы программы,
и между частями кода используется C++ ABI, я бы все одной версией g++ собрал,
на всякий случай.
Потому что объект синхронизации должен с кем-то разделяться иначе его использование бессмысленно. А здесь видно что каждый вызов использует свой уникальный объект, то есть бессмыслица какая-то. Если только конечно внутри конструктора CriticalSection нет обращение к какой-то глобальной сущности.
Непонятно что имеется ввиду. Физически и логически битность ОС к тому сколько максимум можно за раз записать отношения не имеет. Физически там LPDDR4 память, сколько бит из нее раз может забрать процессор никак не меняется от битности ОС.
Логически для 32битного arm есть инструкции STRD/LDRD, с помощью них можно запустить запись чтение сразу 8 байт.
Из личного опыта. Как-то заказчик в ТЗ прописал что хочет покрытия тестами, так как после основного этапа разработки собирается сопровождать разработанное ПО своими силами. И в проекте было полно тестового кода не только юнит тестов, но эмулирующих работу с GUI и т.п… Но тесты начали приносить пользу (раз где-то в неделю отлавливая баги) только когда доля покрытого тестами кода стала превышать 80% покрытия.
А до этого момента автотесты прогоняемые CI помогало найти ошибку до начала ручного тестирования только считанное количество раз.
Какой-то очень неправдоподобный конец истории.
Весь опыт подсказывает, что либо это придуманная история
или авто и ручное тесты не покрывали большую часть функционала,
за счет этого в коде и появилась куча странного функционала который
непонятно как прошел QA.
Немного непонятно, месяцы привязаны к обращение Луны вокруг Земли,
при чем здесь понравилось или не понравилось?
Ну это как в анекдоте:
Option<impl Trait>неудачное редактирование съело правильное форматированиеА зачем
Option<Box<dyn Trait>>, нельзя просто Option` вернуть?