Возможна реализация компилятора, в которой данне действия будут выполнятся иначе и тогда код в на таком компиляторе станет не деиспособен, вобщем то на VS он тоже пока не работает, но погодите еще немного, сейчас внесем необходимые инструкции .

так погоди, тут вызывается конструктор. Что еще за оператор инициализации?  

конструктор вызовется и без ()

естественно, () это необязательная добавка. Впервые слышу об операторах инициализации.

Ну вот судя по всему борланд и положил на нее глаз ))

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


Сделал реализацию совместимую с VS и BCB, сейчас код выложу. Да комиляторозависимо, но это всеголишь интерфес к библиотеке, сама либа представлена набором функций, и если пользователь не может в силу несовместимости пользоваться простой конструкций, он сможет работать с функциями напрямую. 

Это сообщение отредактировал(а) vaddsm - 7.9.2008, 20:45

Стандарты бывают разные. В данном случае шла речь о стандарте соглашений вызова.
тут немного замутняет картину то, что используется __fastcall - a oно компиляторозависимое соглашение. 

Ужос ___х!    Дело в том что конвенции эти судя по тому, что каждый компилятор интерпритирует их в вольной форме для методов, разработаны для внешних функций а не для методов класса. Если понятно о чем я говорю... Например, стандартный __cdecl, родной для C, борланд помещает аргументы в стек, последним в стек идет this, в тоже время Microsoft, разместив аргументы в стеке, this передает через ecx. Для __stdcall соответственно. Почему об это я заговорил, по тому, что от конвенции зависит где именно в стеке будет this, после EBP или до. Тут все не так просто, развертывая стек надо еще смотреть, а что именно за метод по вызову. Сейчас дорабатываю.

Точто могу сказать одно, на консрукторы  в VS конвенции не распростроняются, что непеши всегда аргументы в стек, this в ecx.

Это сообщение отредактировал(а) vaddsm - 8.9.2008, 02:15

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


Это сообщение отредактировал(а) mes - 8.9.2008, 02:54

vaddsm, приведенный тобой кривой костыль не только непонятен/несопровождаем, но и зависим не только от компилятора, но и от опций, а именно: от stack frames и от оптимизации. выключи frames(а в release они по дефолту выключены) или включи оптимизацию - и аля-улю.
косяк, кстати:


как уже было упомянуто, формирование фрэймов в стэке зависит от опции(и от компилера).


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


в данном случае никакой необходимости в этом нет.


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

"боги", "гуру"... 

от соглашения зависит будет ли this помещен в стэк(до вызова метода) или нет. "после" - это особенности процесса компиляции.

пелена начинает спадать...

чего ему и пожелаем, чтобы не ловить потом необъяснимые косяки.

dumb, Спасибо, сейчас по пунктам отработаю приведенные вами замечания!

Вот пример, у меня работает при любом виде конструктора TAnyClass в средах BCB и VS. С опциями оптимизации, я пока не проработал. 



...

TAnyClass *x =  new TAnyClass();

Коменты будут.


P.S Права на чтение сегмента памяти не выставил, в следующем варианте будут.

Добавлено @ 04:44
В Борланде работает при любых опциях оптимизации. А в релизе пока нет.

Это сообщение отредактировал(а) vaddsm - 8.9.2008, 04:48

  ЛАЖА   

блин, так и не понял, зачем пихать ук. на функцию в DWORD? 
вместо

вполне прокатит

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

Добавлено через 1 минуту и 39 секунд

Lazin, CallMethod где? ГИДЕ? Он в TAnyClass, а ты this передаеш какой? На TMyLibInterface.



Это пример, в реали этот метод будет называться, где-то так: 

void hey_guy_do_never_try_to_name_method_like_this_f_king_long_method_name(void);

  

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