А как управлять внешними зависимостями? Единый репозиторий пакетов, где все лежит в стандартизированном виде, или поддержка различных инструментов, как клонирование напрямую с git или штуки на подобии conan и vcpkg. А в каком виде? Так же в коде типо `import "https://github.com/fmtlib/fmt#master"`?
Можно ли это реализовать в новом компиляторе c++, который будет одновременно поддерживать стандарт и расширять его необходимыми фичами для самособираемости кода? С учетом модулей, возможно даже без нестандартных pragma можно будет уже собирать код с дефолтными флагами.
В даже в настоящее время проект - это просто папки и набор файлов в них с описанием того что нужно с этим сделать, вместо указания того, что нужно сделать непосредственно с их содержимым.
Я не понимаю разницу? Или хочется чтобы, то как собирается приложение было сразу в исходном коде?
Извините за оффтоп и за критику, но не могу больше терпеть. Часто вижу ваши комментарии, пишите интересные вещи, вроде бы, и по делу, вроде бы. Но они часто заминусованные. Причина, как мне кажется, это ваш стиль написания. Каждый комментарий как пережеванная каша из слов. Нужно несколько раз прочитать и все равно нет гарантии понимания. И мне обидно, что из-за этого ваше мнение, кажется, остается не услышанным.
Мне кажется так однозначно говорить, что синтетика это синтетика, а полноценная демка будет работать по другому тоже не правильно. Если в синтетике работает быстрее, то нужно просто понять почему. Может полноценная демка, сама по себе будет описана не оптимально без учета неких особенностей.
Эффективность тоже можно получить за счёт того что не выделяется память под маленькие объекты и что указатель на значение лежит не в объекте, а рядом с указателем на vtable, что позволяет их грузить одновременно, а не по очереди
До конца тоже не понял. Для классического полиморфизма не важно как и где выделяется память же, главное ссылку на объект заиметь.
Я наверное плохо читал, у AnyAny есть бенчмарки? Особенно интересно учитывая, что автор этой статьи сделал опровержение и эффективности все таки не обнаружено.
В статье упоминаются сторонние библиотеки типа c-ares. А в каком случае использовать их вместо getaddrinf()? Мне в голову приходит только кросс платформенные приложения, чтобы не сильно разбираться, а что там резолвит в windows, и мобилках.
Я все таки не понял откуда повышение производительности тут. Только за счет того, что указатель на объект лежит рядом с указателем на VTable? Если так смотреть, то это ведь все равно не прямой вызов методов. Плюс если компилятор где-то мог сделать девиртуализацию, то тут уже не сможет.
Так это еще не production ready реализация, а только прототип?
В своем проекте тоже столкнулся с надобностью ивентной системы и она у меня уже прошла несколько итераций. В общем идеи все те же что и в этой статье. Тоже может статью написать? Для меня неожиданными моментами стали - время жизни подписчика событие. подписчик не должен переживать события и для этого нужна отписка в деструкторе. У меня для этого RAII объект Subscription. - время жизни события. при отписке от события нужно учитывать, что само событие может быть уже и не живо. - во время диспатчинга события, уничтожается само событие. У меня есть логика, которая по событию уничтожает и пересоздает объект владелец события. То есть диспатчинг события должен переживать само событие. - рекурсия - во время обработки события, заэмиттили то же самое событие. - ну про многопоточку понятно - если подписываться или отписываться во время диспатчинга события, может быть не очень хорошо.
Ну и по поводу реализации без virtual. Я по разному экспериментировал и пришел к тому, что у меня обработчик хранится в std::function. Можно искать и другие реализации, возможно более эффективные но скорее всего со своими ограничениями.
alignas(A) char data[sizeof(A)];
A* a = std::launder(reinterpret_cast<A*>(data));
Если A не POD тип? Если он наследуется от какого-то Base который имеет свои поля, который наследуется от некоего IAbstract у которого есть виртуальные методы реализуемые в A. Какие могут быть проблемы в c++17?
Доступ к приватным членам возможен только в контексте, где они видны компилятору , то есть внутри области, доступной на этапе компиляции. Попытка применить этот механизм к чужому классу без полного определения приведёт к ошибке компиляции — это гарантирует отсутствие произвольного доступа.
А я не понял как это работает. Если специализация идет не изнутри класса, то разве взятие адреса приватной переменной доступно? Адрес берется для инстанцирования шаблона, но в начале статьи ведь упоминалось, что нельзя взять адрес приватной переменной.
Шаблоны в C++ инстанцируются на этапе компиляции, и если специализация шаблона происходит в контексте, где приватный член доступен (например, внутри класса или через friend), то компилятор разрешит взять его адрес
class Foo{
private:
int a;
int b;
std::string& c;
};
Вообще я сам игрался с указателями на поля члены, делал на этом сериализацию. Для меня стали проблемой обращение к полям ссылкам и базовому классу. Код есть тут (с++17): https://github.com/aethernetio/aether-client-cpp/blob/main/aether/reflect/reflect.h Много пришлось подмазать макросами. Ну и в моем случае необходимость менять класс это фича, а не проблема.
Подумал было, что это уже должно работать в стандартном `std::tuple`, но как оказалось оно implementation defined. Плюс для msvc EBO оказывается нужно включать специально. Пример https://godbolt.org/z/dhEGfqnbz
У меня вопрос про [[no_unique_address]] А нет ли в компиляторах реализации своих кастомных атрибутов для до c++20 эпохи, так чтобы я мог наделать макросов и использовать [[no_unique_address]] фичу в c++17?
Вчера только решил попробовать. Не было связи с сервером. Обидно.
А как управлять внешними зависимостями? Единый репозиторий пакетов, где все лежит в стандартизированном виде, или поддержка различных инструментов, как клонирование напрямую с git или штуки на подобии conan и vcpkg. А в каком виде? Так же в коде типо `import "https://github.com/fmtlib/fmt#master"`?
Можно ли это реализовать в новом компиляторе c++, который будет одновременно поддерживать стандарт и расширять его необходимыми фичами для самособираемости кода? С учетом модулей, возможно даже без нестандартных pragma можно будет уже собирать код с дефолтными флагами.
Я не понимаю разницу?
Или хочется чтобы, то как собирается приложение было сразу в исходном коде?
Извините за оффтоп и за критику, но не могу больше терпеть.
Часто вижу ваши комментарии, пишите интересные вещи, вроде бы, и по делу, вроде бы. Но они часто заминусованные. Причина, как мне кажется, это ваш стиль написания. Каждый комментарий как пережеванная каша из слов. Нужно несколько раз прочитать и все равно нет гарантии понимания.
И мне обидно, что из-за этого ваше мнение, кажется, остается не услышанным.
Мне кажется так однозначно говорить, что синтетика это синтетика, а полноценная демка будет работать по другому тоже не правильно.
Если в синтетике работает быстрее, то нужно просто понять почему. Может полноценная демка, сама по себе будет описана не оптимально без учета неких особенностей.
Я это утверждение не понял. AnyAny ведь внутри тоже будет использовать указатель?
на примере
self это ссылка (читай указатель).
До конца тоже не понял. Для классического полиморфизма не важно как и где выделяется память же, главное ссылку на объект заиметь.
Я наверное плохо читал, у AnyAny есть бенчмарки? Особенно интересно учитывая, что автор этой статьи сделал опровержение и эффективности все таки не обнаружено.
В статье упоминаются сторонние библиотеки типа
c-ares. А в каком случае использовать их вместоgetaddrinf()?Мне в голову приходит только кросс платформенные приложения, чтобы не сильно разбираться, а что там резолвит в windows, и мобилках.
Я все таки не понял откуда повышение производительности тут. Только за счет того, что указатель на объект лежит рядом с указателем на VTable?
Если так смотреть, то это ведь все равно не прямой вызов методов. Плюс если компилятор где-то мог сделать девиртуализацию, то тут уже не сможет.
Так это еще не production ready реализация, а только прототип?
В своем проекте тоже столкнулся с надобностью ивентной системы и она у меня уже прошла несколько итераций. В общем идеи все те же что и в этой статье. Тоже может статью написать?
Для меня неожиданными моментами стали
- время жизни подписчика событие.
подписчик не должен переживать события и для этого нужна отписка в деструкторе. У меня для этого RAII объект Subscription.
- время жизни события.
при отписке от события нужно учитывать, что само событие может быть уже и не живо.
- во время диспатчинга события, уничтожается само событие.
У меня есть логика, которая по событию уничтожает и пересоздает объект владелец события. То есть диспатчинг события должен переживать само событие.
- рекурсия - во время обработки события, заэмиттили то же самое событие.
- ну про многопоточку понятно - если подписываться или отписываться во время диспатчинга события, может быть не очень хорошо.
Ну и по поводу реализации без virtual. Я по разному экспериментировал и пришел к тому, что у меня обработчик хранится в std::function. Можно искать и другие реализации, возможно более эффективные но скорее всего со своими ограничениями.
Статья то не про ассемблер, а про то как устроен машинный код.
Да нет, там в оригинале прямо написано
std::string. То есть проблема не в переводе, а в первоисточнике.не работает
У меня вопрос про конструкцию
Если
Aне POD тип? Если он наследуется от какого-тоBaseкоторый имеет свои поля, который наследуется от некоегоIAbstractу которого есть виртуальные методы реализуемые вA. Какие могут быть проблемы в c++17?А я не понял как это работает. Если специализация идет не изнутри класса, то разве взятие адреса приватной переменной доступно? Адрес берется для инстанцирования шаблона, но в начале статьи ведь упоминалось, что нельзя взять адрес приватной переменной.
В коде я не вижу ни "внутри класса" ни "friend".
А вот такое оно сможет переварить?
Вообще я сам игрался с указателями на поля члены, делал на этом сериализацию. Для меня стали проблемой обращение к полям ссылкам и базовому классу.
Код есть тут (с++17):
https://github.com/aethernetio/aether-client-cpp/blob/main/aether/reflect/reflect.h
Много пришлось подмазать макросами. Ну и в моем случае необходимость менять класс это фича, а не проблема.
Подумал было, что это уже должно работать в стандартном `std::tuple`, но как оказалось оно implementation defined. Плюс для msvc EBO оказывается нужно включать специально.
Пример https://godbolt.org/z/dhEGfqnbz
А статья есть про это?
У меня вопрос про [[no_unique_address]]
А нет ли в компиляторах реализации своих кастомных атрибутов для до c++20 эпохи, так чтобы я мог наделать макросов и использовать [[no_unique_address]] фичу в c++17?
https://godbolt.org/z/Mb57YsMjc странно. Тут работает.