- crsib
- Постоялец
А вот я не знаю. У msvc например смещение vtable "плавает" при кастах по иерархии. К тому же в случае reinterpret_cast<char*>(0) = 1 каст тоже один. А вот последствия не приятные.
там всего одна инструкция
mov eax, Device
а как по вашему компоненты написанные на cpp используются на дельфи
>К тому же в случае reinterpret_cast<char*>(0) = 1 каст тоже один. А вот последствия не приятные.
ну мы же так делать не собираемся
uce
> а как по вашему компоненты написанные на cpp используются на дельфи
O_O. __thiscall и его аналоги на Delphi O_O
Мне всегда казалось, что там делается функциональный враппер. Хотя бы по тому, что С++ ABI не стандартизирован.
uce
> ну мы же так делать не собираемся
Мы так и делаем. Потому что в какой-то момент у нас случайно включается механика RTTI (исключение кинули, например) и layout класса потенциально изменяется. reinterpret_cast не в состоянии отследить такие изменения.
Кстати по теме о Торвальдсе и Столмане
> GNU Coding Standards:
> 3.1 Which Languages to Use
> When you want to use a language that gets compiled and runs at high speed, the best language to use is C. Using another language is like using a non-standard feature: it will cause > trouble for users. Even if GCC supports the other language, users may find it inconvenient to have to install the compiler for that other language in order to build your program. For
> example, if you write your program in C++, people will have to install the GNU C++ compiler in order to compile your program.
> C has one other advantage over C++ and other compiled languages: more people know C, so more people will find it easy to read and modify the program if it is written in C
То есть по мнению Столмана С++ не стоит использовать по двум причинам - надо качать компилятор и меньше людей знают С++))
crsib
> К тому же в случае reinterpret_cast<char*>(0) = 1 каст тоже один. А вот последствия не приятные.
я и без каста могу быть калекой
char * c = 0; (*c) = 0;
и что теперь жить под колпаком?
что значит
>у нас случайно включается механика RTTI
reinterpret_cast ничего не отслеживает в рантайме
mov eax, Device
uce
> reinterpret_cast ничего не отслеживает в рантайме
Дык и лейаут меняется в компайл-тайме. Да и тот же static_cast ничего не отслеживает в рантайме. Он просто корректно учитывает изменения в компоновке класса.
В более просто форме..
есть IObject.
есть Сircle : IObject
есть Square: IObject
есть Triangle: IObject
есть методы
Сollision(Сircle A,Сircle B); Сollision(Сircle A,Square B); Сollision(Сircle A,Triangle B); Сollision(Square A,Сircle B); Сollision(Square A,Square B); Сollision(Square A,Triangle B); Сollision(Triangle A,Сircle B); Сollision(Triangle A,Square B); Сollision(Triangle A,Triangle B);
задача имея IObject a,b - вызвать правильный метод.
по моему тут самый простой и быстрый использовать таблицу2д
susageP
как вариант у IObject сделать методы Сollision(IObject*p) = 0; Сollision(Сircle &p) = 0 и т.д.
и в нем когда тип this известен вызывать p->Сollision(*this)
я понимаю что в интерфейсе нет места типам Сircle и подобным, это как вариант
тогда не понятно зачем, нужено наследование?
тебе в каждом классе придется хранить тип фигуры, поэтому можно вообще
сделать
enum Shape { Triangle, Square, Circle }; struct Object { Shape shape; }
и использовать всякие там таблицы, массивы и прочую лабуду
susageP
Почти. Основной вопрос, что должно быть индексом в таблицу. Вот тут то и оказывается, что надо использовать либо type_info, что не очень круто. Либо самому уметь идентифицировать тип, что приводит нас к базовому понятию Reflection'а. Хотя в данном случает он совсем простой. Либо вариант ashujon. Который и именуется двойной диспетчеризацией, которая сегодня очень плотно обсуждалась.
Причем что "рефлекшн", что двойная диспетчиризация будут почти равны по скорости
2 virtual call + выборка из таблицы vs 2 virtual call. Однако, когда у нас появятся еще и Rect, Line, Polygon и бог еще знает что выяснится, что в варианте с рефлекшеном гораздо проще расширять иерархию. Более того, используемые методы симметричны, что очень легко можно учесть с минимальным (одно сравнение) ущербом для производительности. То есть кода будет фактически в два раза и от скорости "лобового" свитча по типам нас будет отделять только 2 virtual call'a
Тут уж каждый сам решает, что важнее - высокая гибкость или чуть более высокая скорость.
Sbtrn. Devil
>> Я бы сказал, не "перевешивают", а "дополняют" (ибо сборка мусора, что бы там ни говорили, суть генетическое архитектурное уродство).
Ну вообще-то я с удовольствием использую умные указатели в некоторых местах ;) Зато во всех остальных местах С++ позволяет обходиться обычными указателями :) Один мой приятель сейчас с матерной руганью пытается обойти жавовский сборщик мусора, чтобы избежать неимоверных тормозов у себя на фирме. Когда я рассказал ему про гибкость С++, позволяющую использовать умные указатели и сборку мусора бок о бок со сверхбыстрыми списками свободной памяти, он еще больше погрустнел.
>> вот это правильно (если он ругает С++, а он, насколько я понял из контекста ОПа, его ругает)
О, он не просто его ругает. В привычной торвальдсовской манере он называет идиотами и больными всех, кто на нем пишет... А также всех, кто использует свн для контроля версий... А также всех, кто не использует линукс... И тех, кто его использует... В общем, у меня сложилось впечатление, что тупы и больны все, кроме Торвальдса.
Торвальдс всю свою жизнь возится с ядром линукса, и наверняка ни с какими другими серьёзными проектами, на отличном от C языке, не связывался. Он на основе своего опыта с ядром ОС (что есть очень специализированная сущность) распространяет выводы на те области с которыми не связывался. Такое не обоснованное обобщение просто невежество, и на его основе невозможно утопить в грязи великий и могучий C++ :)
Что касается взаимодействия абстрактных интерфейсов сильно связанных сущностей, то похоже чистого и идеального ООП решения здесь нет. Любое решение имеет то там, то сям, свои неООП уродства. На мой взгляд решение с апкастом, с обязательной гарантией его корректности на уровне архитектуры системы, хотябы к промежуточному подинтерфейсу (в терминах java), который может предоставить необходимую специфическую информацию для выполнения работы - вполне приемлемо и не постыдно.
Вообще ООП это абстракция над неООП реальностью, ни какой объект не может существовать в абсолютном вакууме, объекты всегда связаны между собой. Например класс "прямоугольник" не имеет ни какого смысла без класса "графический контекст" который может этот прямоугольник нарисовать. Класс "облако" не имеет какого-либо смысла без класса "атмосфера", и как-бы ни казалось в общем случае, эти классы очень сильно связаны между собой, и если они представлены лишь чистыми интерфейсами как будет "в хорошем стиле ООП", то их реализация "в чистом ООП" становится по сути не возможной.
И поскольку ООП это абстракция, то обязательно есть узкие места, на примере того, которое здесь обсуждается. Поэтому идеалистам просьба не паниковать и перестать быть идеалистами. static_cast в купе с грамотной архитектурой - это отличный выход из ситуации, из-за которого с работы не уволят с позором.
P.S. Я не идеалист, я практик-реалист.
progmachine
> Класс "облако" не имеет какого-либо смысла без класса "атмосфера", и как-бы ни
> казалось в общем случае, эти классы очень сильно связаны между собой ....
progmachine
> P.S. Я не идеалист, я практик-реалист.
нуну
Читать мнения про личность Торвальдса - даже не смешно. Не надо так шутить.
Пока думаю подход с указателем на специализированнъй интерфейс в обьектах - самъй чистъй с точки зрения ООП вариант разрешения взаимодействия Device <- Object. Однако ето так, на первъй взгляд - реально инициатива тут дивайса, а не обьекта - соответно переброс етого действия на обьект (Texture::Bind) сделает немного сложнее нашу жизнь в плане общих действий етой операции между специализациями - примерно фильтр установки одних и тех же текстур.
С другой сторонъ, охота послать в топку всю ету виртуальность, т.к. она в данном случае не въполняет реальной работъ во время работъ аппликейшна, а просто следует архитектуре. С тем же успехом можно написать тупо 2 дивайса с идентичнъм интерфейсом и скомпилировать 2 раза (как впрочем и придется сделать, ибо ето все делается для двух платформ - одной платформе те 2 рендера не особо нужнъ, а для фанатов DX9/11 лишний екзешник не помешает).
cNoNim
> нуну
Не понимаю, что ты хотел этим сказать?
Тема в архиве.