всем, привет

вот решил заняться smart pointer-ами. Нашёл замечательную книжку (хочется так думать)
Джеффа Элджера и углубился в эту увлекательную область

написал вот что


и


CInteger - просто некоторый класс.
CPInteger - умный указатель для него.

в Main пишу следуещее:
    CPInteger psp;
    psp->msgbox();

в результате чего на экране появляется соответствующий messadgebox, т.е. всё работает нормально.

Далее изменяю CPInteger(см. 11 строку)

т.е. теперь перегруженный оператор -> всегда возвращает NULL, запускаю на выполнение... ВСЁ РАБОТАЕТ!!!!!
ради смеха пробовал return reinterpret_cast<CInteger>(87878787)  и что вы думаете? во время отладки стрелочка дебаггера 
благополучно перескакивает на строчку "void __stdcall msgbox() { MessageBox(NULL,"CInteger.msgbox","CInteger.msgbox",MB_OK); }"
, в в окошке watches значение указателя this отображается как 53CEC83!!! т.е. там есть объект...

я конечно понимаю что это smart поинтеры.. но всё ж

Сильно подозреваю компилятор.
использую Visual studio 2003, я в принципе на неё только пересел, может что-то не так настроил.....

Заранее спасибо.

замени на такое :

и потестируй теперь )

О! наконец-то, вылетело!! 
появилось сообщение следующего содержания - "Access Violation Writing location 0x00000004".

но у меня есть 2 вопроса:
1. неужели вызов функции по адресу 0x00000000 возможен??? вроде бы само по себе действие подобного рода должно вызывать остановку программы.
2. допустим что мы всё же прыгнули на 0 адресс, но не может же быть такого чтоб там где-то в памяти случайно оказалось то что нам нужно - message box всё же появлялся и причём с правильным текстом (специально менял, чтоб убедиться). Значит всё же что-то в памяти весело.. хотя никакой объект не создавался. Откуда там это взялось?

Эти вопросы возникли из за неправильного представления работы метода.
Метод эта такая же функция , которой неявно передается дополнительный параметр this
т.е. 


вызов с нулевым обэектом такой функции никакого вреда не принесет, так как параметр this не используется
однако доработанный метод

как видите при таком варианте, значение this используется.
 Поэтому теперь при вызове метода с невалидным указателем , запись значения по чужому адресу  спровоцирует Access Violation

Добавлено @ 21:45


да забыл сказать, что metod и eго содержимое хранится не в объекте, а статически. А описание методов внутри класса нужно не для того , чтоб создались методы, а для чтоб ограничить права доступа к методам и для удобного наследования этих правил.  

Это сообщение отредактировал(а) mes - 21.9.2008, 21:46

сорри за оффтопик, но зачем вам __stdcall?

Добавлено через 4 минуты и 6 секунд

если только эта функция не virtual...

mes, спасибо за толковое объяснение, теперь всё ясно.

JOker, в данном примере использование __stdcall скорее привычка нежели необходимость.

всем спасибо.
вопрос закрыт.  

А зачем нужна эта привычка, если не секрет?   

мне просто с COM приходилось иметь дело, а там все вызовы обязательно __stdcall, чтобы избежать проблем при написание клиента и компонента с использованием разных языков и компиляторов  

а вы находите что-то негативное в этом формате вызова?или просто за чистоту кода?  

не все, а только те, которые являются частью интерфейса, да и там их не нужно вручную прописывать как __stdcall, для этого используются макросы

ну ясное дело что только те, которые являются частью интерфейса - это не суть важно, я к тому что оттуда эта привычка и пошла. 

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

я имел ввиду STDMETHOD, а это уже не вопрос вкуса или стиля

а почему? 

потому что методы, которые являются частью com интерфейса, рекомендуется объявлять через макросы, для единообразия со сгенерированным по idl кодом

а что вручную написать virtual HRESULT __stdcall - очень большая ошибка?

дело в том , что __sdtcall предназначен для функций, а не для методов, и возможна такая реализация компилятора, где
определенный посредством директивы __stdcall метод, будет не соответствовать реальному соглашению о вызове.
Тогда как макрос STDMETHOD гарантирует соответствие.

Добавлено @ 15:29

такая же как вместо этого написать virtual long __stdcall

Это сообщение отредактировал(а) mes - 22.9.2008, 15:30

вот только что-то мне слабо вериться в существование такого компилятора, а ещё меньше в то, что он станет достаточно популярным на рынке ....

По поводу сравнения с HRESULT - тут наверно имелась ввиду информативность кода. Согласен, что при взгляде на макрос сразу ясно с какой функцией мы емеем дело... но опять же насколько это нужно?

Лично моё мнение, что использование данного макроса должно носить скорее рекомендательный характер, нежели обязательный.

ну давольно, по-моему мы увлеклись 

ну здесь уже каждый сам себе злобный буратина, жизнь научит  

Дело не только в компиляторе,а в программисте.
написать STDMETHOD во первых гораздо легче и безопаснее , чем virtual __stdcall HRESULT - одно слово вместо трех,
а во вторых переносимее, потому что нужно всего будет определить один дефайн под конкретный компилятор.

Добавлено @ 16:17

ага рекомендательный. Но рекомендация возникла не на пустом месте )


 


а вот реализация макроса взятая с msdn :

тут видно различие под разные платформы, а этого уже достаточно в качестве аргументации использования макроса. 



Это сообщение отредактировал(а) mes - 22.9.2008, 16:24

ну, ок, убедили 
буду переучиваться.

__stdcall не является частью стандарта, поэтому использование такого кода будет существенно ограничено
и во-вторых дефолт - __cdecl - вы усложняете работу пользователям ваших классов

я ещё раз повторяю что это только лишь пример. О каком ограничении может идти речь? - она не будет работать на той системе, на которой я её написал? и каким пользователям? себе самому что ли

да ладно, не нервничайте   
мы все поняли