7. Идеальный способ наплодить утечек. Берём List, получаем ref на элемент, прикапываем, меняем List до наступления реаллокации. Без контроля алиасинга будет масса весёлых часов отладки.
Скорее всего да. А ещё я хочу от C++ того, чего в нём не будет ещё лет 5 — нормальной модульности.
Вообще же частенько бывают ситуации, когда поднимать пакетный репозиторий бессмысленно — например требуется всего-то вытаскивать автоматом при сборке парочку бинарных SDK, маленький репозиторий с общим для нескольких продуктов кодом и пару опен-сорс пакетов вроде юнит-тестового фреймворка и логгера.
Как раз наоборот — хотелось бы не иметь дела с такими костылями. Хотелось бы иметь систему сборки и доставки зависимостей в одном флаконе. Нечто, аналогичное 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. Как ни прискорбно, все языки с автоматически управляемой памятью делают управление всеми остальными ресурсами полностью ручным.
Вообще же частенько бывают ситуации, когда поднимать пакетный репозиторий бессмысленно — например требуется всего-то вытаскивать автоматом при сборке парочку бинарных SDK, маленький репозиторий с общим для нескольких продуктов кодом и пару опен-сорс пакетов вроде юнит-тестового фреймворка и логгера.
В общем, мечты, мечты...
Короче, возможность описать для модуля папку с инклюдами, папку с исходниками, список зависимостей — и получить сборку всего этого добра одной командой. Короче, я слишком многого хочу.
Т.е. это тот же Скайп, вид в профиль. С вендор локом и централизованным сервером.
Про шифрование «точка-точка» они рассказывают. Других подтверждений я что-то не видел.
Костыльнуть можно уже сейчас, через aligned_storage. Но это конечно же именно костыльнуть.
"Без рантайма" обычно означает "без среды исполнения, GC, etc.", т.е. максимум обвязка на системные функции вроде работы с памятью, сетью, ФС и т.п.
По поводу рантайма. Если есть несколько динамических либ, каждая из которых собрана со своим рантаймом. Какой рантайм использовать? Особенно если исполняемый файл без рантайма? В общем решаемо, но головной боли добавляет.
Аналогия из реальной жизни. Почему эти нехорошие электрики закрывают щитки крышкой, а иногда и на замок? Для чего прячут кабели? А для того, чтобы жильцам было удобно ходить, а не приходилось перепрыгивать через оголённые кабели. Прыжок не туда == шашлык.
Хитрого системного кода мало. Просто системного и прикладного — много. И вот его хотелось бы писать удобно, а не прыгать через раскиданные на полу высоковольтные кабели.