Как раз наоборот — хотелось бы не иметь дела с такими костылями. Хотелось бы иметь систему сборки и доставки зависимостей в одном флаконе. Нечто, аналогичное Cargo. К сожалению, в среде С++ это нереально из-за зоопарка тех самых систем сборки. Поэтому хорошим вариантом была бы система доставки зависимостей и управления сборкой
достать "пакет" откуда угодно — хоть из соседней папки, хоть из специального репозитория, хоть из гита
собрать "пакет" используя его родную систему сборки; результат сборки — бинарники, заголовки и, возможно, какие-либо специфичные конфиг-параметры
сделать результаты сборки и файлы заголовков видимыми в одной и той же форме, независимо от того, как хаотично они раскиданы в исходном проекте
Ещё вдогонку для интересующихся. biicode умеет тянуть зависимости только из репозитория. Как я понимаю, такое хранилище можно сделать и локально. Но зависеть от Git репозитория или соседней папки нельзя. Так что мимо.
Вдогонку. Пока наиболее близок biicode, но нужно разобраться, как его правильно готовить. Вообще же один из основных камней преткновения — отсутствие модулей, из-за чего нельзя нормально изолировать транзитивные зависимости.
В принципе интересно, но неясно, умеет ли NuGet нормально работать за пределами VS. Т.е. служить средством доставки зависимостей для, например, CMake или QMake проекта. Наверное, мне просто хочется аналога Cargo для С++:
загрузка зависимостей, в т.ч. транзитивная
транзитивная сборка зависимостей по необходимости
автоматическое "пробрасывание" Include папок, с возможностью делать публичные и приватные
мягкое или жёсткое версионирование
в качестве источников как репозитории артефактов, так и гит-репозитории, УРЛ, локальные папки
Короче, возможность описать для модуля папку с инклюдами, папку с исходниками, список зависимостей — и получить сборку всего этого добра одной командой. Короче, я слишком многого хочу.
Пардон, ошибся. Части клиента с открытым кодом. Ссылка на их гитхаб качественно закопана на сайте. Но вот какие части — надо выяснять. https://github.com/wireapp если что.
С ним классическая проблема — закрытый протокол.
Т.е. это тот же Скайп, вид в профиль. С вендор локом и централизованным сервером.
Про шифрование «точка-точка» они рассказывают. Других подтверждений я что-то не видел.
Ещё может быть буфер размером аккурат с те самые кишки, о содержимом и структуре которого только кишки и знают.
Костыльнуть можно уже сейчас, через aligned_storage. Но это конечно же именно костыльнуть.
Ок, т.е. структуры в D следуют той же семантике, что и в С++? Признаю, был не в курсе.
"Без рантайма" обычно означает "без среды исполнения, GC, etc.", т.е. максимум обвязка на системные функции вроде работы с памятью, сетью, ФС и т.п.
ЕМНИП RAII в D делается через scope statement. Это, уж простите, костыль в стиле C# using. Как я сказал, проблема даже не в перформансе — Golang хорошо демонстрирует, что может быть быстрый нативный язык с GC. Проблема в том, что все остальные ресурсы теперь приходится менеджить руками. Или в D появились детерминированные деструкторы?
По поводу рантайма. Если есть несколько динамических либ, каждая из которых собрана со своим рантаймом. Какой рантайм использовать? Особенно если исполняемый файл без рантайма? В общем решаемо, но головной боли добавляет.
Да, забыл. Garbage Collector также создаёт проблему таскания рантайма за собой и разборок между рантаймами в случае shared objects. Где язык без сборки мусора может спокойно работать на системном аллокаторе.
Небольшая поправочка :) unwrap/expect программу уронят гарантированно. А вот если переменную под указатель забыли занулить… А С++ переменные по умолчанию не зануляет.
Мне вот интересно насчёт этого аргумента про "как захочу я, а не компилятор". Сколько у вас реально было кода, в котором нужно было буквально перебирать байты вручную? Действительно ли настолько много, что защита помешала бы буквально во всей программе? Мне например такая "свобода всегда и везде" неудобна. Мне гораздо удобней иметь возможность снять такую защиту ровно там где нужно. И в будущем знать, что если я накосячил, то в первую очередь надо смотреть unsafe блоки. Знать, что эти блоки надёжно изолированы, а не просачиваются в виде указателей повсюду.
Аналогия из реальной жизни. Почему эти нехорошие электрики закрывают щитки крышкой, а иногда и на замок? Для чего прячут кабели? А для того, чтобы жильцам было удобно ходить, а не приходилось перепрыгивать через оголённые кабели. Прыжок не туда == шашлык.
Хитрого системного кода мало. Просто системного и прикладного — много. И вот его хотелось бы писать удобно, а не прыгать через раскиданные на полу высоковольтные кабели.
Garbage Collector ни разу не zero cost. Причём тот самый cost не столько в накладных расходах по тактам и памяти. Сколько в недетерминированности и отсутствии RAII. Как ни прискорбно, все языки с автоматически управляемой памятью делают управление всеми остальными ресурсами полностью ручным.
О Боже… Библиотеку мат. функций они уже в стандарт положили. По моему скромному мнению, С++ не хватает не столько стандартизированных библиотек, сколько стандартизированного (хотя бы де-факто) и лёгкого средства их доставки, сборки на месте и подключения (\me косится в сторону NuGet, NPM, Cargo, Go Get). Тогда можно было бы дорабатывать такие библиотеки независимо от ядра языка. И для простого добавления filesystem не требовался бы комитет.
Ещё один пример в копилку — пара итераторов над функцией-генератором. В Boost сейчас это сделано через std::function внутри, просто чтобы иметь "пустое" состояние сохранённой функции для маркера конца. А если итератор конца будет другого типа — можно будет спокойно вкладывать функтор в первый итератор по значению, не используя кучу
Хотел ответить развёрнуто, но не буду. Аргументы и так известны. Скажу просто. В С++ сделать неправильно просто, а правильно — не просто сложно, а требует иногда борьбы с компилятором. В Rust наоборот, сделать правильно проще, чем неправильно — пусть и порог этого действа повыше. И это есмь хорошо. Потому что лично я устал обрабатывать все краевые и не очень случаи своей головой. И я хочу работать с языком, у которого сравнительно простая и понятная семантика (да-да, borrow checker — это три простых правила и немного тренировки), а не 1500 страниц стандарта, забитые наполовину undefined behavior и implementation defined. Дальше продолжать не буду, дабы не надоедать.
В общем, мечты, мечты...
Короче, возможность описать для модуля папку с инклюдами, папку с исходниками, список зависимостей — и получить сборку всего этого добра одной командой. Короче, я слишком многого хочу.
Т.е. это тот же Скайп, вид в профиль. С вендор локом и централизованным сервером.
Про шифрование «точка-точка» они рассказывают. Других подтверждений я что-то не видел.
Костыльнуть можно уже сейчас, через aligned_storage. Но это конечно же именно костыльнуть.
"Без рантайма" обычно означает "без среды исполнения, GC, etc.", т.е. максимум обвязка на системные функции вроде работы с памятью, сетью, ФС и т.п.
По поводу рантайма. Если есть несколько динамических либ, каждая из которых собрана со своим рантаймом. Какой рантайм использовать? Особенно если исполняемый файл без рантайма? В общем решаемо, но головной боли добавляет.
Аналогия из реальной жизни. Почему эти нехорошие электрики закрывают щитки крышкой, а иногда и на замок? Для чего прячут кабели? А для того, чтобы жильцам было удобно ходить, а не приходилось перепрыгивать через оголённые кабели. Прыжок не туда == шашлык.
Хитрого системного кода мало. Просто системного и прикладного — много. И вот его хотелось бы писать удобно, а не прыгать через раскиданные на полу высоковольтные кабели.