CLASHA - Объектно-ориентированное программирование на Си

[Shaos]

Метод это просто подпрограмма, у который первым аргументом (скрытым на уровне ЯВУ) передаётся указатель на объект, с которым она должна работать (обычно называемый this) - вот и всё

P.S. Кстати если я ничего не путаю TASM позволял писать в ООП стиле на ассемблере...

[Lavr]

Метод это просто подпрограмма, у который первым аргументом (скрытым на уровне ЯВУ) передаётся указатель на объект, с которым она должна работать (обычно называемый this) - вот и всё...

Ну так показал бы это разочек на низком уровне, тогда бы и было "вот и всё"...
Я бы с любопытством поглядел бы и как выглядит число "this".

[Shaos]

Метод это просто подпрограмма, у который первым аргументом (скрытым на уровне ЯВУ) передаётся указатель на объект, с которым она должна работать (обычно называемый this) - вот и всё...

Ну так показал бы это разочек на низком уровне, тогда бы и было "вот и всё"...
Я бы с любопытством поглядел бы и как выглядит число "this".

как выглядит? примерно как 32-битное целое

это ежели речь идёт о 32-битных системах...

[jdigreze]

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

На zx.pk.ru есть специалист по языкам, зовут Виталием, aka Vitamin. Вполне возможно, он сможет тебе предоставить образцы кода, что во что превращается и как выглядит при исполнении. На сколько я помню, он дипломку защищал по компиляции в ООП.

Заодно, кстати: а как ты представляешь себе, выглядит в коде очередь сообщений Винды?

Честно не интересовался. Как программист, думаю, что связанный список, с разбросанными по всей памяти значениями.

[Lavr]

На zx.pk.ru есть специалист по языкам, зовут Виталием, aka Vitamin. Вполне возможно, он сможет тебе предоставить образцы кода, что во что превращается и как выглядит при исполнении.

А книги нет подходящей? Когда мне было интересно как выглядят внутренности Винды в коде,
я купил неплохую книжку по программированию под Виндой на ассемблере.

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

А вот по ООП подходящей литературы такого плана не попадалось...


PS. Посмотрел поиском... ну, не одного меня похожие вопросы интересуют...
Методы реализации ООП на низком уровне

[jdigreze]

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

[Lavr]

Я могу предположить, почему нет примеров... опять же в общем. ...

Ну, рассуждения с примерами, немного "близкими к телу", нашел вот здесь:
Взгляд на ООП из низкого уровня — Архив WASM.RU
Хотя мне не совсем нравится приведенный там пример...

У меня просто такое ощущение, что когда знаешь программирование "снизу", то
все эти абстракции высокого уровня наоборот несколько сбивают с толку.

Если взять всем нам близкий в той или иной мере ZX-Spectrum: ещё в нём вводили
абстракцию Каналы и Потоки.
Мне, честно говоря, не нравилось, т.к. понимал, что происходит в коде и прямых
аналогий сильно не прослеживал, наоборот, эта абстракция казалась мне довольно
притянутой за уши...

[jdigreze]

Если взять всем нам близкий в той или иной мере ZX-Spectrum: ещё в нём вводили
абстракцию Каналы и Потоки.

Ну, на мой скромный, это ты зря так. Как раз абстракция каналов и потоков в спектруме вполне логична с точки зрения прикладника. Т.е. ввод и вывод абстрагируется от архитектуры конкретного "железа", и позволяет разработчику прикладных решений заниматься своим делом. На спектруме этой абстракцией пользовался неоднократно в былые времена - на самом деле она очень удобна, и вполне логично объяснима.

Кстати, пример объяснения ООП

Ну, рассуждения с примерами, немного "близкими к телу", нашел вот здесь:
Взгляд на ООП из низкого уровня — Архив WASM.RU
Хотя мне не совсем нравится приведенный там пример...

с первого взгляда напомнил мне один проект, к превеликому, так и не доведённый до логического завершения...
Так вот, по крайней мере в самом начале даны выкладки, применяемые мной в своё время на асме того же спектрума, а позже и в писишках, но уже на си, который без плюсов. На мой взгляд, это не совсем ООП, точнее, скорее даже совсем не ООП, хотя бы потому что это не объектное программирование, а программное управление объектами. Хотя сходство скорее всего имеется.

[Shaos]

На zx.pk.ru есть специалист по языкам, зовут Виталием, aka Vitamin. Вполне возможно, он сможет тебе предоставить образцы кода, что во что превращается и как выглядит при исполнении.

А книги нет подходящей? Когда мне было интересно как выглядят внутренности Винды в коде,
я купил неплохую книжку по программированию под Виндой на ассемблере.

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

А вот по ООП подходящей литературы такого плана не попадалось...


PS. Посмотрел поиском... ну, не одного меня похожие вопросы интересуют...
Методы реализации ООП на низком уровне

Вроде уже объяснили много раз... Ну ок - вот линк на почитать:

http://en.wikipedia.org/wiki/X86_calling_conventions

thiscall

This calling convention is used for calling C++ non-static member functions. There are two primary versions of thiscall used depending on the compiler and whether or not the function uses variable arguments.

For the GCC compiler, thiscall is almost identical to cdecl: The caller cleans the stack, and the parameters are passed in right-to-left order. The difference is the addition of the this pointer, which is pushed onto the stack last, as if it were the first parameter in the function prototype.

On the Microsoft Visual C++ compiler, the this pointer is passed in ECX and it is the callee that cleans the stack, mirroring the stdcall convention used in C for this compiler and in Windows API functions. When functions use a variable number of arguments, it is the caller that cleans the stack (cf. cdecl).

The thiscall calling convention can only be explicitly specified on Microsoft Visual C++ 2005 and later. On any other compiler thiscall is not a keyword. (However, disassemblers such as IDA must specify it. So IDA uses keyword __thiscall for this.)

P.S. Вот ещё: http://mentorembedded.github.io/cxx-abi/abi.html

Тут правда про Itanium - но зато понятно написано с примерами, а так - у каждого компилятора свои C++ ABI для x86...

P.P.S. И вот про разные компиляторы: http://www.agner.org/optimize/calling_conventions.pdf

P.P.P.S. Про доступность C++ объектов в сишном коде (и в ассемблерном ибо си - это "ассемблер высокго уровня" как мы помним ; ) и в том числе про виртуальные методы:

http://www.parashift.com/c++-faq-lite/g ... rom-c.html

Furthermore, if the class (or any base class) contains any virtual functions, almost all C++ compliers put a void* into the object either at the location of the first virtual function or at the very beginning of the object. Again, this is not required by the language, but it is the way "everyone" does it.

тут void* это указатель на таблицу виртуальных функций объекта, который добавляется к членам класса "неявно" (как правило в начале структуры, ассоциирующейся с объектом класса), если в классе есть хотя бы один виртуальный метод...

[Shaos]

Я могу предположить, почему нет примеров... опять же в общем. ...

Ну, рассуждения с примерами, немного "близкими к телу", нашел вот здесь:
Взгляд на ООП из низкого уровня — Архив WASM.RU
Хотя мне не совсем нравится приведенный там пример...

Это чуваки сами чего-то придумали - типа того как я в этом топике сочинаю, но только на асме

Если хочешь понять, как в нормальных C++ компиляторах это делается - гугли на тему "C++ ABI" ( ABI = Application Binary Interface )

[Lavr]

Это чуваки сами чего-то придумали - типа того как я в этом топике сочинаю, но только на асме

Но излагают доступно... Почитал - понравилось.

Если хочешь понять, как в нормальных C++ компиляторах это делается - гугли на тему "C++ ABI"
( ABI = Application Binary Interface )

Спасибо - посмотрю.

[Shaos]

Это чуваки сами чего-то придумали - типа того как я в этом топике сочинаю, но только на асме

Но излагают доступно... Почитал - понравилось.

На самом деле они скорее запутывают, чем вносят ясность - например в начало структуры они ставят идентификатор типа объекта - C++ компилятор ничего подобного не делает. И потом понятие класса у них отсутствует как класс - сразу объекты и сразу с методами - своими и общими...

Если хочешь понять, как в нормальных C++ компиляторах это делается - гугли на тему "C++ ABI"
( ABI = Application Binary Interface )

Спасибо - посмотрю.

В предыдщем моём сообщении тоже по линкам пройдись - много полезной инфы

[Lavr]

Задумался я о том, можно ли на голом Си покрыть всё разнообразие возможностей объектно-ориентированного программирования, которое даёт Си++. Например мой простой стиль C++ программирования легко переводится в C, но что делать с непростыми стилями?
...
А теперь подумаем как нам таким способом изобразить трёх котов ООП - инкапсуляцию, наследование и полиморфизм...

Интересная цитата попалась мне вот здесь мимоходом по означеному сабжу...

Ещё хуже, когда уже имеющиеся возможности языка (от которых, возможно, сначала показательно отказались) велосипедят сами. Немножко отстранённый, но популярный пример: пишут на Си (с отговоркой, что Си++ сложный и большой), а когда код разрастается, сами не осознают, что создали свои (корявые, небезопасные, бажные и часто неэффективные) классы, виртуальные функции и пр.

[Shaos]

Оно конечно всё так, но Си проживёт дольше, чем Си++

[Lavr]

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

Нашел я довольно неглупую статейку на эту тему:

Example of OOP (Win32 Asm)