Спасибо дедушке морозу, интересовался темой мк, и в общем то все времени не было начать. Хотя по работе все время сталкиваюсь. Спасибо за такой чудесный комплект. И сладости конечно же с украшениями на ель
Можно из ассемблера. Не ясно зачем. Из статьи не ясно. Я вам прозрачно намекаю что статья требует переработки. А пока что это мысли вслух.
Как вызывать функции члены классов плюсовых вам уже ниже написали, и 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) Из статьи понятно что модификаторы типа в обычных и шаблонных(?) функциях не играют роли при выборе перегрузки если тип указан "по значению". Не раскрыты на мой взгляд ситуации когда перегрузка функции идёт шаблонной функцией с параметром типа "ссылка на тип"/"указатель на тип".
А так — браво, правда очень познавательно и освежил свои знания.
Вот тоже сразу бросилось в глаза. Доклад интересный, но может сложиться ложное впечатление "меняем стандартный вектор на иммутабельное творение автора, и здравствуй безопасная многопоточность".
Ну печаль же как сократили. Вы тогда delete уберите хоть чтобы никто таких ошибок не совершал, да и не ясно зачем виртуальные деструкторы убрали — ведь вы же сами Pet и Animal как чистый интерфейс хотите.
В том то и дело что не хочу с такими проблемами с тем чтобы начать использовать. Чтобы разработчик шел и говорил что ему позарез надо — необходимо чтобы он уже активно данным инструментом пользовался, хоть в каком-то виде.
Это ещё предстоит разобраться. Паяльник есть, так что робот так робот.
А мой вот внучек в чате не отвечает. Надеюсь хоть на почте дойдет получит.
Спасибо дедушке морозу, интересовался темой мк, и в общем то все времени не было начать. Хотя по работе все время сталкиваюсь. Спасибо за такой чудесный комплект. И сладости конечно же с украшениями на ель
Вот теперь вы уже движетесь в верном направлении.
Ещё о соглашениях о вызовах надо подумать, как передаются this и реализованы виртуальные функции, наследование в разных компиляторах и платформах.
Да о коде для вызова фаззера тоже не забыть.
Можно из ассемблера. Не ясно зачем. Из статьи не ясно. Я вам прозрачно намекаю что статья требует переработки. А пока что это мысли вслух.
Как вызывать функции члены классов плюсовых вам уже ниже написали, и operator++ ничем от стальных функций членов класса не отличается.
Я бы посоветовал переработать статью, включить сравнение с вызовом из плюсов через dlsym тот же, а так же описать инструменты для исследования сигнатуры символов в библиотеке.
Ну и напоследок- попробуйте для интереса подобрать нужную версию стандартной библиотеки хотя бы, удивитесь какое нестабильное ABI даже у gcc. Не говоря про мелкософтовские библиотеки.
Да я понимаю, просто в статье то пол слова про это. Такое ощущение что что-то автор хотел сказать, но что не понятно. И явно не про фаззинг.
Да я то никуда не двигаюсь. Я недоумеваю чего вы хотели в этой статье показать - фаззинга тут нет. Как определили сигнатуру вызываемых ф-й тоже пол слова. Как определили (видимо никак) с какой версией std::string линковаться тоже ни намека.
Ну а то что ассемблером можно подгружать код из динамической библиотеки - не ясна цель использования ассемблера. Намного логичнее и проще это сделать из плюсов тех же.
Честно говоря не совсем понятно какую проблему/задачу решал автор.
Если задача: «вызывать функцию из динамической библиотеки без исходников», то тогда зачем приведен header библиотеки? - ведь это исходник. Проблем вызвать ф-ю из библиотеки имея исходник в виде заголовочного файла на плюсах полно, но они лежат в области определения версии стандартной библиотеки и другого кода, который вызывает сама библиотека и с которым она слинкована для того чтобы вызывающая сторона могла слинковаться с тем же кодом, а совсем не в определении имен экспортируемых символов библиотеки- они и так уже в заголовочном файле описаны.
Если же header просто для понимания того что в библиотеке написано внутри, а для вызывающей стороны он не известен, тогда не ясно как вызывающая сторона определила типы (сигнатуру) функций внутри динамической библиотеки - по имени экспортируемых символов? - тогда это гадание на кофейной гуще, уж извините. Откуда появилась сигнатура функции ‘getter_string’? И как опять же решался вопрос с линковкой именно с той версией реализации ‘std::string’?
Примеров бы
А можете пояснить вот такой момент: для той же visual studio статическую библиотеку приходится собирать под 4 версии стандартной библиотеки ((дебаг + релиз) * (однопоточная + многопоточная)). И для каждой версии компилятора (2013, 2015 и т.д.) свой набор ещё конечно же.
Я верно понимаю что GCC сохраняет совместимость на том уровне, что собранное статическое чудо условно версией 4.0 будет работать без проблем с версией 5.0, с другой соответственно реализацией стандартной библиотеки, другими "фишками" компилятора и т.п.?
Или какие-то ограничения есть?
И если такое навалите в заголовочном файле вашего класса, то неожиданно для всех пользовательских типов появятся операторы сравнения, которые ещё и компилироваться не будут при вызове и, соответственно, отсутствии реализаций операторов '<' и '=='?
Очень приятная статья. Осталось не ясным:
1) ADL — это требование языка или "рост так все компиляторы делают"? То же самое про SFINAE. (поясню: многие компиляторы очень вольно трактуют эти правила(?), при чём как старые этим грешат так и современные).
2) Из статьи понятно что модификаторы типа в обычных и шаблонных(?) функциях не играют роли при выборе перегрузки если тип указан "по значению". Не раскрыты на мой взгляд ситуации когда перегрузка функции идёт шаблонной функцией с параметром типа "ссылка на тип"/"указатель на тип".
А так — браво, правда очень познавательно и освежил свои знания.
Вот тоже сразу бросилось в глаза. Доклад интересный, но может сложиться ложное впечатление "меняем стандартный вектор на иммутабельное творение автора, и здравствуй безопасная многопоточность".
не дописал: docs как инструмент редактирования тех же самых статей собственно.
Хабр Рецензии же. Вы же статьи публикуете, а Рецензии где писать?
Хабр Документы — то что мы все любили в Google docs
Ну печаль же как сократили. Вы тогда delete уберите хоть чтобы никто таких ошибок не совершал, да и не ясно зачем виртуальные деструкторы убрали — ведь вы же сами Pet и Animal как чистый интерфейс хотите.
В том то и дело что не хочу с такими проблемами с тем чтобы начать использовать. Чтобы разработчик шел и говорил что ему позарез надо — необходимо чтобы он уже активно данным инструментом пользовался, хоть в каком-то виде.
А где же пример на C++?