Здравствуйте, Cyberax, Вы писали:

C>Здравствуйте, Erop, Вы писали:

C>>>Причём далеко не только на gcc. Про то как разные настройки выравнивания или "Treat wchar_t as built-in type" на MSVC ломают бинарную совместимость напомнить?
C>>>Поэтому на С++ особо и нет бинарных интерфейсов.
E>>Ну так на С могли бы быть ровно те же проблемы. Просто у системы есть API на С, и нет API на С++
C>Откуда они на С возьмутся? Экспортируемые функции С не содержат полных сигнатур, так что им однофигственно что у тебя wchar_t — это отдельный тип, а не typedef для short'а.
Зато им не однофигственно сколько байт из стека доставать

C>Как раз твоя "главная проблема" на том же Линуксе вообще не стоит.
Как так "не стоит"? Исключения могут летать между разными версиями gcc? Или, аллокации можно передавать?

Здравствуйте, LuciferSaratov, Вы писали:

E>>Для связи с C++ объектами тоже можно аналогичную библиотеку написать...
LS>Для С++ можно написать, а там уже есть.

Ну так и системных API на плюсах мало... GDI+ разве отчасти...

E>Я правда не понимаю, откуда следует выделенное.
Скажем так, на чем реализован КОМ, я точно не знаю. Но полагаю, что на С, как и вся Windows. Но его интерфейсы — сишные. И это следует из спецификации.

E>А привёл я его тут, как пример успешной фиксации платформой одной из особенностей реализации С++...
Ну ты и джаву мог привести с тем же успехом. И питон. И .Нет, прости господи.

Здравствуйте, Vamp, Вы писали:

E>>А привёл я его тут, как пример успешной фиксации платформой одной из особенностей реализации С++...
V>Ну ты и джаву мог привести с тем же успехом. И питон. И .Нет, прости господи.

А ты перечитай моё первое сообщение, где я приводил примеры и COM в том числе

Здравствуйте, Erop, Вы писали:

C>>Откуда они на С возьмутся? Экспортируемые функции С не содержат полных сигнатур, так что им однофигственно что у тебя wchar_t — это отдельный тип, а не typedef для short'а.
E>Зато им не однофигственно сколько байт из стека доставать
Ну так то было решено ещё в эпоху PASCAL'я.

C>>Как раз твоя "главная проблема" на том же Линуксе вообще не стоит.
E>Как так "не стоит"? Исключения могут летать между разными версиями gcc? Или, аллокации можно передавать?
Да, и можно.

E>А ты перечитай моё первое сообщение, где я приводил примеры и COM в том числе
То есть, ты хотел сказать, что есть и другие реализации ООП, кроме С++? Тогда твое высказывание тривиально.

Здравствуйте, Vamp, Вы писали:

I>>Вот приведи сюда код который пропертю реализует и покажи средства инкапуляции филда в пропертю.
V>Вот ты мне можешь объяснить, зачем нужен такой уродец, как property?
А что в них уродливого?

MK>А что в них уродливого?
Все.

Здравствуйте, Cyberax, Вы писали:

E>>Зато им не однофигственно сколько байт из стека доставать
C>Ну так то было решено ещё в эпоху PASCAL'я.

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

C>>>Как раз твоя "главная проблема" на том же Линуксе вообще не стоит.
E>>Как так "не стоит"? Исключения могут летать между разными версиями gcc? Или, аллокации можно передавать?
C>Да, и можно.

Чего? Как оно нужный ::operator delete найдёт?
Про исключения тоже забавно. Из какого именно std::excegtion оин будут унаследованы? От STL которой версии?

Здравствуйте, Vamp, Вы писали:

V>То есть, ты хотел сказать, что есть и другие реализации ООП, кроме С++? Тогда твое высказывание тривиально.
То что я хотел сказать, я сказал уже много раз.

Проблемы с декорайией С++ имён не так страшны, чтобы помешать использовать С++ в качестве языка части API OS

Но теперь я, кажется, уже хочу сказать, что ты не совсем хорошо умеешь читать

E>То что я хотел сказать, я сказал уже много раз.

Проблемы с декорайией С++ имён не так страшны, чтобы помешать использовать С++ в качестве языка части API OS

Я так и не смог понять, почему для иллюстрации этого тезиса ты выбрал КОМ, который НЕ НАПИСАН НА С++, не экспортирует С++ интерфейсы и вообще не имеет отношения к С++.

Здравствуйте, Vamp, Вы писали:

MK>>А что в них уродливого?
V>Все.
Слил?

MK>Слил?
Это смотря кто.

Здравствуйте, Vamp, Вы писали:

V>Я так и не смог понять, почему для иллюстрации этого тезиса ты выбрал КОМ, который НЕ НАПИСАН НА С++, не экспортирует С++ интерфейсы и вообще не имеет отношения к С++.

Потому, что COM, тем не менее, смог зафиксировать формат таблицы виртуальных функций, которому следуют ВСЕ компиляторы С++ под винду...

E>Потому, что COM, тем не менее, смог зафиксировать формат таблицы виртуальных функций, которому следуют ВСЕ компиляторы С++ под винду...
Да нет же! КОМ вообще не имеет дела с виртуальными таблицами, потому что НЕ экспортирует С++-классы. Программы на КОМ можно писать, например, на VB, в котором никаких виртуальных таблиц нет вообще.

Здравствуйте, Erop, Вы писали:

V>>Я так и не смог понять, почему для иллюстрации этого тезиса ты выбрал КОМ, который НЕ НАПИСАН НА С++, не экспортирует С++ интерфейсы и вообще не имеет отношения к С++.
E>Потому, что COM, тем не менее, смог зафиксировать формат таблицы виртуальных функций, которому следуют ВСЕ компиляторы С++ под винду...
Странно, но у gcc абсолютно такие же виртуальные таблицы. Странно, да?

Здравствуйте, Erop, Вы писали:

E>>>Зато им не однофигственно сколько байт из стека доставать
C>>Ну так то было решено ещё в эпоху PASCAL'я.
E>Блин! Так я про то же и говорю, что в С свои проблемы бинарной совместимости были, и что они были успешно решены. Было бы надо -- и с С++ справились бы...
Эти проблемы на пару порядков сложности различаются. Описание calling convention для С занимает страничку, описание ABI для C++ — около 500 (с учётом исключений, множественного наследования и всяких dynamic_cast).

E>>>Как так "не стоит"? Исключения могут летать между разными версиями gcc? Или, аллокации можно передавать?
C>>Да, и можно.
E>Чего? Как оно нужный ::operator delete найдёт?
Они forward compatible в libstdc++.

Здравствуйте, Cyberax, Вы писали:

E>>Чего? Как оно нужный ::operator delete найдёт?
C>Они forward compatible в libstdc++.

Ха! А если я перекрою, например?

Здравствуйте, Cyberax, Вы писали:

C>Странно, но у gcc абсолютно такие же виртуальные таблицы. Странно, да?
Не абсолютно, но похожие.
А вот с точки зрения COM'а -- точно такие же, кстати...

Здравствуйте, Vamp, Вы писали:

E>>Потому, что COM, тем не менее, смог зафиксировать формат таблицы виртуальных функций, которому следуют ВСЕ компиляторы С++ под винду...
V>Да нет же! КОМ вообще не имеет дела с виртуальными таблицами, потому что НЕ экспортирует С++-классы. Программы на КОМ можно писать, например, на VB, в котором никаких виртуальных таблиц нет вообще.

И что? Как то вообще связано с моим утверждением?
Я не утверждаю, что COM на С++ написан или на него ориентирован. Я всего лишь утверждаю, что он задал формат таблиц виртуальных функций под винду...