Форум программистов, компьютерный форум CyberForum.ru

Грязный хук. - C++

Восстановить пароль Регистрация
 
 
Рейтинг: Рейтинг темы: голосов - 14, средняя оценка - 4.86
Genius Ignat
1233 / 771 / 44
Регистрация: 16.09.2009
Сообщений: 2,014
01.03.2010, 11:17     Грязный хук. #1
Провёл не большой анализ по одному коду, и выянил не которые особенности,
о которых не пишут в книгах о языке C++.
Это я узнал из книги INside COM.

Также помню не в тему спор завёл где то на форме, про виртуальный деструктор и
где его надо прописывать.
Правильнее и безопаснее прописывать конечно везде, если не брать концепцию COM.

C++
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
#include <iostream.h>
class Abstract {
public:
/*Абстрактному классу не нужен виртуальный деструктор потому что Release может действовать и без него,
*/
virtual long Release() = 0;
};
class MyClass: public Abstract  {
public:
    MyClass(){ cout<<"Create MyClass\n"; }
    virtual ~MyClass() {cout<<"Destroy\n"; }
    
virtual long Release(){
/*подразумивается как delete obj, верно ли я предполагаю, поэтому деструктор вызывается с нужного места  иерархии: тоесть с производного класса.
*/  delete this;                
             return 0;
    }
};
 
 
int main(){
MyClass  *obj = new MyClass;
Abstract *aobj = obj;
aobj->Release();
//delete aobj; не сработает так как в базовом нет виртуального деструктора.
return 0;
}
Тогда получается COM компонент явно через delete( к указателю базового класса) не удалить,
так как в базовом классе отстутсвует виртуальный деструктор.

Я то знаю почему надо что бы delete не работало, мне это известно.

Я просто хочу узнать у более опытных прогеров верно ли мое предположение о том как действует
Release():
/*подразумивается как delete obj, верно ли я предполагаю, поэтому деструктор вызывается с нужного места иерархии: тоесть с производного класса.
*/
Или применяется ещё что то.
Ответьте пожалейста, заранее благодарен.
Лучшие ответы (1)
Similar
Эксперт
41792 / 34177 / 6122
Регистрация: 12.04.2006
Сообщений: 57,940
01.03.2010, 11:17     Грязный хук.
Посмотрите здесь:

Delphi WinAPI Хук на DblClick
Хук C++ Builder
WordPress Хук
C++ Глобальный хук клавиатуры
Грязный фон HTML, CSS

Искать еще темы с ответами

Или воспользуйтесь поиском по форуму:
После регистрации реклама в сообщениях будет скрыта и будут доступны все возможности форума.
CyBOSSeR
Эксперт C++
 Аватар для CyBOSSeR
2293 / 1663 / 86
Регистрация: 06.03.2009
Сообщений: 3,675
01.03.2010, 18:13     Грязный хук. #21
Evg, по поводу условий легальности delete this: [16.15] Is it legal (and moral) for a member function to say delete this?
После регистрации реклама в сообщениях будет скрыта и будут доступны все возможности форума.
Genius Ignat
1233 / 771 / 44
Регистрация: 16.09.2009
Сообщений: 2,014
01.03.2010, 18:18  [ТС]     Грязный хук. #22
CyBoSSeR:
Оперативно.
Evg
Эксперт С++Автор FAQ
 Аватар для Evg
16824 / 5245 / 320
Регистрация: 30.03.2009
Сообщений: 14,125
Записей в блоге: 26
01.03.2010, 18:32     Грязный хук. #23
Цитата Сообщение от CyBOSSeR Посмотреть сообщение
Evg, по поводу условий легальности delete this: [16.15] Is it legal (and moral) for a member function to say delete this?
А у тебя есть 100% уверенности по всем пунктам, которые написаны в этом факе? Т.е. если ты между delete и return не написал ни одной строки, то есть у тебя гарантия 100%, что между ними компилятор не наплодит какого-то кода (хотя бы по части exception'ов, о которых писал выше), который может зацепить this?

Добавлено через 8 минут
Просто вот о чём я пишу:

C++
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
class T
{
public:
  T();
  ~T();
};
 
extern int func2 (void);
 
int func (void)
{
  T t;
 
  return func2();
}
Функция func проще некуда, однако код нехилый

Код
...
        call    _Z5func2v, 0  <--- это вызов func2
         nop
.LLEHE1:
        mov     %o0, %l0
        add     %fp, -24, %g1
        mov     %g1, %o0
.LLEHB2:
        call    _ZN1TD1Ev, 0  <--- это вызов деструктора t (ожидаемо)
         nop
.LLEHE2:
        st      %l0, [%fp-28]
        b       .LL1    <---- это переход в конец процедуры (на return)
         nop
.LL6:
        st      %i0, [%fp-32]  <--- отсюда начинается код по размотке стека
.LL2:
        ld      [%fp-32], %l0
        add     %fp, -24, %g1
        mov     %g1, %o0
        call    _ZN1TD1Ev, 0
         nop
        st      %l0, [%fp-32]
.LL4:
        ld      [%fp-32], %o0
.LLEHB3:
        call    _Unwind_Resume, 0
         nop
.LLEHE3:
.LL1:
        ld      [%fp-28], %i0  <--- вот здесь реальный выход из процедуры
        ret
        restore
.LLFE2:
        .size   _Z4funcv, .-_Z4funcv
Данный тест не совсем подходит к нашей теме, поскольку в процедуре мы имеем локал типа класс. Но точно ли нет ситуаций, когда в "простом" методе не выскочит вот такой вот код. Я плохо владею плюсами, чтоы экспериментировать. Может для этого нужно какое-то ацкое множественное виртуальное наследование или ещё что-то типа того. К тому же здесь используется версия gcc, умеющая работать с libunwind, а другие компиляторы могут это дело реализовывать по другому и механизм будетболее тяжёлым
Genius Ignat
1233 / 771 / 44
Регистрация: 16.09.2009
Сообщений: 2,014
01.03.2010, 19:07  [ТС]     Грязный хук. #24
Если б Release(); портило всю малину его бы не использовали.
CyBOSSeR
Эксперт C++
 Аватар для CyBOSSeR
2293 / 1663 / 86
Регистрация: 06.03.2009
Сообщений: 3,675
01.03.2010, 19:08     Грязный хук. #25
Сообщение было отмечено автором темы, экспертом или модератором как ответ
Цитата Сообщение от Evg Посмотреть сообщение
А у тебя есть 100% уверенности по всем пунктам, которые написаны в этом факе? Т.е. если ты между delete и return не написал ни одной строки, то есть у тебя гарантия 100%, что между ними компилятор не наплодит какого-то кода (хотя бы по части exception'ов, о которых писал выше), который может зацепить this?
Да, я практически на 100% уверен, что если все приведенные пункты соблюдены, то проблем с использованием конструкции delete this не будет.

Кроме того, компиляторы разрабатывают не идиоты (я на это очень надеюсь), и никаких лишних обращений к this компилятор не наплодит, при условии что у программиста, использующего конструкцию, руки растут из правильного места.

Насчет исключений, вопрос также сводится к "пряморукости" программиста.

Опять же, я не знаю способа, позволяющего обойтись без данной конструкции при разработке объектов, непосредственно поддерживающих счетчик ссылок.
Genius Ignat
1233 / 771 / 44
Регистрация: 16.09.2009
Сообщений: 2,014
01.03.2010, 19:14  [ТС]     Грязный хук. #26
"пряморукости" программиста.
В точку.
Evg
Эксперт С++Автор FAQ
 Аватар для Evg
16824 / 5245 / 320
Регистрация: 30.03.2009
Сообщений: 14,125
Записей в блоге: 26
01.03.2010, 20:38     Грязный хук. #27
Цитата Сообщение от CyBOSSeR Посмотреть сообщение
Кроме того, компиляторы разрабатывают не идиоты (я на это очень надеюсь), и никаких лишних обращений к this компилятор не наплодит, при условии что у программиста, использующего конструкцию, руки растут из правильного места.
Я не пытаюсь оспаривать этот факт. Я просто спрашиваю, насколько ты уверен. Я в Си++ не специалист, а потому не могу оценивать подобные вещи "навскидку".

> Если б Release(); портило всю малину его бы не использовали

Его используют только под виндами на мелкомягком компиляторе или на всех архитектурах?
Genius Ignat
1233 / 771 / 44
Регистрация: 16.09.2009
Сообщений: 2,014
01.03.2010, 21:19  [ТС]     Грязный хук. #28
Evg:
COM в основном распространен на платформах майкрософт.
Evg:
Хотел спросить если ты в сеть выходишь с Lunix, поддерживает ли твой Web браузер
ActiveX компоненты.
Мне даже самому интересно, ActiveX же построена на COM.
Evg
Эксперт С++Автор FAQ
 Аватар для Evg
16824 / 5245 / 320
Регистрация: 30.03.2009
Сообщений: 14,125
Записей в блоге: 26
01.03.2010, 21:22     Грязный хук. #29
Цитата Сообщение от Genius Ignat Посмотреть сообщение
Хотел спросить если ты в сеть выходишь с Lunix, поддерживает ли твой Web браузер
ActiveX компоненты.
Мне даже самому интересно, ActiveX же построена на COM.
Это что? Типа видео с ютуба. Такое поддерживает
Genius Ignat
1233 / 771 / 44
Регистрация: 16.09.2009
Сообщений: 2,014
01.03.2010, 21:26  [ТС]     Грязный хук. #30
http://www.emanual.ru/download/www.eManual.ru_1.html
Evg
Эксперт С++Автор FAQ
 Аватар для Evg
16824 / 5245 / 320
Регистрация: 30.03.2009
Сообщений: 14,125
Записей в блоге: 26
01.03.2010, 21:29     Грязный хук. #31
Допустим, я всё это прочту, дальше то что? Не проще ли покзать на какой-нибудь сайт, тыкнуть пальцем и сказать "вот эта вот штука - это и есть ActiveХ"
CyBOSSeR
Эксперт C++
 Аватар для CyBOSSeR
2293 / 1663 / 86
Регистрация: 06.03.2009
Сообщений: 3,675
01.03.2010, 21:38     Грязный хук. #32
Цитата Сообщение от Evg Посмотреть сообщение
Я просто спрашиваю, насколько ты уверен.
Данная конструкция легальна с точки зрения языка и я на 100% уверен, что при осторожном обращении, данная конструкция безопасна.

Но все же, если есть возможность избежать ее использования, то так и следует поступить, чтобы ненароком не наступить на грабли.
Genius Ignat
1233 / 771 / 44
Регистрация: 16.09.2009
Сообщений: 2,014
01.03.2010, 21:56  [ТС]     Грязный хук. #33
на mail.ru
Если я в свое браузере отключаю поддержку ActiveX
Тогда рисунок, который рекламирует браузер IE8(microft) исчезает.

Добавлено через 6 минут
Если я в свое браузере отключаю поддержку ActiveX
Тогда рисунок, который рекламирует браузер IE8(microft) исчезает.
Это false ;высказывание.

Короче ActiveX это какая нибудь нестандартная кнопочка на странице либо ещё какая-нибудь феня.
Что бы искать сайты на которых висят ActiveX мне надо тратить время, но на mail.ru точно что то
есть иначе браузер бы не запрещал загрузку ActiveX.
На cyberforum мой браузер не реагирует.

Добавлено через 1 минуту
Короче не бери в голову, про этот ActiveX.
Yandex
Объявления
01.03.2010, 21:56     Грязный хук.
Ответ Создать тему
Опции темы

Текущее время: 18:46. Часовой пояс GMT +3.
КиберФорум - форум программистов, компьютерный форум, программирование
Powered by vBulletin® Version 3.8.9
Copyright ©2000 - 2016, vBulletin Solutions, Inc.
Рейтинг@Mail.ru