Pull to refresh
35
0
Александр @oktonion

Пользователь

Send message

Вот теперь вы уже движетесь в верном направлении.

Ещё о соглашениях о вызовах надо подумать, как передаются this и реализованы виртуальные функции, наследование в разных компиляторах и платформах.

Да о коде для вызова фаззера тоже не забыть.

Можно из ассемблера. Не ясно зачем. Из статьи не ясно. Я вам прозрачно намекаю что статья требует переработки. А пока что это мысли вслух.

Как вызывать функции члены классов плюсовых вам уже ниже написали, и operator++ ничем от стальных функций членов класса не отличается.

Я бы посоветовал переработать статью, включить сравнение с вызовом из плюсов через dlsym тот же, а так же описать инструменты для исследования сигнатуры символов в библиотеке.

Ну и напоследок- попробуйте для интереса подобрать нужную версию стандартной библиотеки хотя бы, удивитесь какое нестабильное ABI даже у gcc. Не говоря про мелкософтовские библиотеки.

Да я понимаю, просто в статье то пол слова про это. Такое ощущение что что-то автор хотел сказать, но что не понятно. И явно не про фаззинг.

Да я то никуда не двигаюсь. Я недоумеваю чего вы хотели в этой статье показать - фаззинга тут нет. Как определили сигнатуру вызываемых ф-й тоже пол слова. Как определили (видимо никак) с какой версией std::string линковаться тоже ни намека.

Ну а то что ассемблером можно подгружать код из динамической библиотеки - не ясна цель использования ассемблера. Намного логичнее и проще это сделать из плюсов тех же.

Честно говоря не совсем понятно какую проблему/задачу решал автор.

Если задача: «вызывать функцию из динамической библиотеки без исходников», то тогда зачем приведен header библиотеки? - ведь это исходник. Проблем вызвать ф-ю из библиотеки имея исходник в виде заголовочного файла на плюсах полно, но они лежат в области определения версии стандартной библиотеки и другого кода, который вызывает сама библиотека и с которым она слинкована для того чтобы вызывающая сторона могла слинковаться с тем же кодом, а совсем не в определении имен экспортируемых символов библиотеки- они и так уже в заголовочном файле описаны.

Если же header просто для понимания того что в библиотеке написано внутри, а для вызывающей стороны он не известен, тогда не ясно как вызывающая сторона определила типы (сигнатуру) функций внутри динамической библиотеки - по имени экспортируемых символов? - тогда это гадание на кофейной гуще, уж извините. Откуда появилась сигнатура функции ‘getter_string’? И как опять же решался вопрос с линковкой именно с той версией реализации ‘std::string’?

А можете пояснить вот такой момент: для той же visual studio статическую библиотеку приходится собирать под 4 версии стандартной библиотеки ((дебаг + релиз) * (однопоточная + многопоточная)). И для каждой версии компилятора (2013, 2015 и т.д.) свой набор ещё конечно же.
Я верно понимаю что GCC сохраняет совместимость на том уровне, что собранное статическое чудо условно версией 4.0 будет работать без проблем с версией 5.0, с другой соответственно реализацией стандартной библиотеки, другими "фишками" компилятора и т.п.?
Или какие-то ограничения есть?

Перегружать зависимые операторы для класса не обязательно, можно использовать операторы из std::rel_ops непосредственно, для этого надо воспользоваться using-директивой.

И если такое навалите в заголовочном файле вашего класса, то неожиданно для всех пользовательских типов появятся операторы сравнения, которые ещё и компилироваться не будут при вызове и, соответственно, отсутствии реализаций операторов '<' и '=='?

Очень приятная статья. Осталось не ясным:
1) ADL — это требование языка или "рост так все компиляторы делают"? То же самое про SFINAE. (поясню: многие компиляторы очень вольно трактуют эти правила(?), при чём как старые этим грешат так и современные).
2) Из статьи понятно что модификаторы типа в обычных и шаблонных(?) функциях не играют роли при выборе перегрузки если тип указан "по значению". Не раскрыты на мой взгляд ситуации когда перегрузка функции идёт шаблонной функцией с параметром типа "ссылка на тип"/"указатель на тип".
А так — браво, правда очень познавательно и освежил свои знания.

Вот тоже сразу бросилось в глаза. Доклад интересный, но может сложиться ложное впечатление "меняем стандартный вектор на иммутабельное творение автора, и здравствуй безопасная многопоточность".

не дописал: docs как инструмент редактирования тех же самых статей собственно.

Хабр Рецензии же. Вы же статьи публикуете, а Рецензии где писать?
Хабр Документы — то что мы все любили в Google docs

Ну печаль же как сократили. Вы тогда delete уберите хоть чтобы никто таких ошибок не совершал, да и не ясно зачем виртуальные деструкторы убрали — ведь вы же сами Pet и Animal как чистый интерфейс хотите.

Видимо что-то типа такого
#include <iostream>
#include <typeinfo>
#include <type_traits>

class IAnimal 
{ 
public: 
    virtual ~IAnimal() = 0; 
};
IAnimal::~IAnimal() {}

class IPet:
    public IAnimal 
{
public: 
    virtual ~IPet() = 0; 
};
IPet::~IPet() {}

class Cat:
    public IPet {};

class Dog:
    public IPet {};
    
class Fox:
    public IAnimal {};

template<class T>
class Cage 
{ 
public: 
    T *content; 
    const char* content_name() const { return typeid(T).name(); }

    Cage(T *content_ = nullptr): 
        content(content_) 
    {}
    ~Cage() { delete content; }

private:
    Cage(const Cage&) = delete;
};

template<class T, 
    class = std::enable_if_t<std::is_base_of<IPet, T>::value>/**/>
void touchPet(const Cage<T> &cage) {
    std::cout << cage.content_name() << std::endl;
}

template<class T, 
    class = std::enable_if_t<std::is_base_of<T, IPet>::value>/**/>
void pushPet(Cage<T> &cage) {
    delete cage.content;
    cage.content = new Dog();
}

void replacePet(Cage<IPet> &cage) {
    touchPet(cage);
    pushPet(cage);
}

template<class T, 
    class = std::enable_if_t<std::is_base_of<T, IPet>::value>/**/>
void enshurePet(Cage<T> &cage) {
    
    if(dynamic_cast<IPet*>(cage.content)) return;
    pushPet(cage);
}

int main(void)
{
    Cage<IAnimal> animalCage{new Fox()};
    Cage<IPet> petCage{new Cat()};
    Cage<Cat> catCage{new Cat()};
    Cage<Dog> dogCage{new Dog()};
    Cage<Fox> foxCage{new Fox()};

    touchPet( animalCage ); // forbid :-)
    touchPet( petCage ); // allow :-)
    touchPet( catCage ); // allow :-)
    touchPet( dogCage ); // allow :-)
    touchPet( foxCage ); // forbid :-)

    pushPet( animalCage ); // allow :-)
    pushPet( petCage ); // allow :-)
    pushPet( catCage ); // forbid :-)
    pushPet( dogCage ); // forbid :-)
    pushPet( foxCage ); // forbid :-)

    replacePet( animalCage ); // forbid :-)
    replacePet( petCage ); // allow :-)
    replacePet( catCage ); // forbid :-)
    replacePet( dogCage ); // forbid :-)
    replacePet( foxCage ); // forbid :-)

    return 0;
}

В том то и дело что не хочу с такими проблемами с тем чтобы начать использовать. Чтобы разработчик шел и говорил что ему позарез надо — необходимо чтобы он уже активно данным инструментом пользовался, хоть в каком-то виде.

А где же пример на C++?

Каждый раз читая или просматривая статьи с рекламой о PVS студии возникает вопрос с ценой и политикой распространения. И она, политика эта, такая… душная, уж извините.
И статический анализ круто, и ошибки иногда интересные ловите. Но вот связываться не хочется.
Это конечно имхо все, у вас там менеджеры связываются, триальные лицензии запрашивают, кто-то комментарии пишет в каждом файле с исходниками...

И сравнение с razer — очень спорное. Вот я "счастливый" обладатель двух мышек от razer и могу сказать что обе стабильно глючат с "залипанием", знаете, как будто в 90 вернулся и в мышке шарик грязью забился. Зато покатаешь ее немного, и снова работает. И обе на проводе умеют между прочим. И очень недешевые. И ковриков сменил массу специально для них. А все одно — глючат. Хотя светятся красиво. Так что конкурент так себе у этой мышки по субъективным ощущениям.

картинка_с_троллейбусом_из_буханки.jpg


А так очень даже увлекательно. Манга даже на калькуляторе под win. =)

Information

Rating
Does not participate
Location
Санкт-Петербург, Санкт-Петербург и область, Россия
Registered
Activity