Здравствуйте, Ikemefula, Вы писали:
CC>>http://wholetomato.com/products/featureRefactoring.asp
I>Короче говоря — ничего нет
I>Нужны высокоуровневые средтва, рефакторинг тот же.
Как будто тот же решарпер умеет что-то принципиально более сложное.

B>COM — это тезнология, не имеющая формально отношения к используемому языку. Но, для облегчения жизни разработчикам на С++ формат интерфейсов соответствует С++ному. В итоге, это позволяет писать на С++ код вида:

Напрямую — не позволяет. COM написан на С, там манглинга (вспомни, с чего начался топик) нет. Только через С++ биндинги.

I>Т.е. показать тебе именно пример где проперти не надо ?
То есть, property нужен только при работе с базами данных?

I>Windows Presentation Framework
Ничего про нее не знаю.

I>Я уже понял, что ты хотел сказать — в твоем коде/области проперти не нужны. Вполне возможно оно и так.
Нет, ты покажи мне код, где они нужны. Пока что ты показал только какое-то непонятное месиво, посвященное базам данных.

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

I>>Короче говоря — ничего нет
I>>Нужны высокоуровневые средтва, рефакторинг тот же.
MC>Как будто тот же решарпер умеет что-то принципиально более сложное.

Открой ссылку для асиста, открой картинку что я показал, сравни и напиши сюда свое мнение

"Как будто" — так и я умею. Смотри, как ловко:

Как будто нет ?

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

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

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

I>>>Здравствуйте, труженик села, Вы писали:

PD>>>>>>Если коротко — С — это высокоуровневый ассемблер. А С++ — это ЯВУ. Со всеми вытекающими.
I>>>>>Это как бы ЯВУ, на самом дело недо-ЯВУ.
ТС>>>>Совместимость с C делает его недо-ЯВУ.
B>>Затрахали уже своими "моё ЯВУ кавайнее твоего". Свой круг прикладных задач решать позволяет?

___>Позволяет. Но некоторые языки позволяют делать это лучше.

B>>Код более читабелен, по сравнению с альтернативами?

___>Код читабелен? Бу-га-га
___>На С++ код конечно читабелен. По сравнению с Брейнфаком. Но не более.
Вы про "среднюю температуру по больнице"? Или читабельность кода с 20 вложенными шаблонами равна читабельности кода, состоящего из пары классов, реализующих простой интерфейс?
Можно подумать, на C индусы не пишут
http://opensource.apple.com/source/procmail/procmail-1.2/procmail/src/procmail.c

B>>Производительность не меньше? Какие тогда проблемы юзать язык в тех задачах, где от него есть польза, забив, труъ ли это ЯВУ? Или надо шашечки, а не ехать?
___>Ехать. Но с комфортом.
Приведите пример задачи, которую нельзя "некриво" реализовать на С++ и я удивлю вас контрпримером

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

B>>COM — это тезнология, не имеющая формально отношения к используемому языку. Но, для облегчения жизни разработчикам на С++ формат интерфейсов соответствует С++ному. В итоге, это позволяет писать на С++ код вида:

V>Напрямую — не позволяет. COM написан на С, там манглинга (вспомни, с чего начался топик) нет. Только через С++ биндинги.
Причем здесь манглинг, если взаимодействие с компонентами реализуется посредством интерфейсов, а не эскпортированием методов по имени? А то, что системные функции COM незаманглены, всего лишь означает extern "C" при объявлении оных и совсем не говорит, что они написаны на C.

Здравствуйте, Ikemefula, Вы писали:
I>>>Нужны высокоуровневые средтва, рефакторинг тот же.
MC>>Как будто тот же решарпер умеет что-то принципиально более сложное.
I>Открой ссылку для асиста, открой картинку что я показал, сравни и напиши сюда свое мнение
Ну у решарпера на твоем скриншоте количество пунктов меню набивается за счет "convert шило to мыло" (например, абстрактный класс в интерфейс, ну и туда же преобразования пропертей — которые к C++ неприменимы). А так, что CreatorCray перечислил — это и есть основные возможности — и они заявлены. Не знаю, насколько это в ассисте хорошо работает, просто в этой теме шарповый рефакторинг почему-то преподносится как что-то неземное.

B>Причем здесь манглинг, если взаимодействие с компонентами реализуется посредством интерфейсов, а не эскпортированием методов по имени? А то, что системные функции COM незаманглены, всего лишь означает extern "C" при объявлении оных и совсем не говорит, что они написаны на C.
Сдается мне, ты вообще не понимаешь, о чем идет речь в это дискуссии.

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

E>>Вот, например, к акве-какаве в МэкОС Х тоже никак, кроме как через ОбжективС не достучишься.
LS>Если я правильно помню, все же можно — вроде, там есть некая библиотека, позволяющая C-коду взаимодействовать с Objective-C объектами.

А ты ей пользовался? Я вот пользовался. Всё равно удобно иметь кусок на Objective-C, на самом деле.
Для связи с C++ объектами тоже можно аналогичную библиотеку написать...

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

I>не между средами, а между компиляторами.
Не только компиляторами. COM-объект можно и из Word'а из VBA дёрнуть, например...

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

M_>ну ты понял, да?
Не я тут высказывал идею, что С лучше С++ из-за наличия в последнем STL...

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

C>Причём далеко не только на gcc. Про то как разные настройки выравнивания или "Treat wchar_t as built-in type" на MSVC ломают бинарную совместимость напомнить?

C>Поэтому на С++ особо и нет бинарных интерфейсов.

Ну так на С могли бы быть ровно те же проблемы. Просто у системы есть API на С, и нет API на С++
Было бы API на С++ -- там бы подумали каким образом декорировать имена, ну и во всех бы компиляторах появился бы ещё один __declspec...

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

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

V>Ты не понял, что ты сделал. КОМ — это сишный интерфейс, и реализован он на С.

И, тем не менее, из С++ COM-интерфейс виден, как объект с кучей виртуальных методов...
Из любой реализации под С++ под винду, обрати внимание

E>И, тем не менее, из С++ COM-интерфейс виден, как объект с кучей виртуальных методов...
Нет. Только при использовании биндингов. Сам по себе он сишный.

E>Из любой реализации под С++ под винду, обрати внимание
Потому, что он сишный.

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

B>Зачем запрещать? Напишите свою библиотеку, лучше STL. Выложите на SourceForge, напишите по ней с десяток статей и радуйтесь. А на практике получается, что народ, не способный написать нормальный код с использованием STL, пишет свои библиотеки, по кривости и глючности превосходящие STL в разы...

Имелось в виду, запретить в проекте, для которого выбирают язык...

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

E>>Из любой реализации под С++ под винду, обрати внимание
V>Потому, что он сишный.

Это, в данном случае, не важно. Важно ут совсем дургое -- API системы зафиксировало формат таблицы виртуальных функций, в случае COM-объекта. И привет, все компиляторы под винду его поддерживают

E>Это, в данном случае, не важно. Важно ут совсем дургое -- API системы зафиксировало формат таблицы виртуальных функций, в случае COM-объекта. И привет, все компиляторы под винду его поддерживают
Ты правда не понимаешь? КОМ — это приложение, реализованное на С. Не имеет никакого отношения к С++, и зачем ты его здесь приплетаешь, неясно.

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

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

E>Было бы API на С++ -- там бы подумали каким образом декорировать имена, ну и во всех бы компиляторах появился бы ещё один __declspec...
E>Другое дело, что декорирование имён совсем и не главная проблема. Главная проблема -- это аллокация памяти, исключения и т. д...
Как раз твоя "главная проблема" на том же Линуксе вообще не стоит.

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

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

E>>>Вот, например, к акве-какаве в МэкОС Х тоже никак, кроме как через ОбжективС не достучишься.
LS>>Если я правильно помню, все же можно — вроде, там есть некая библиотека, позволяющая C-коду взаимодействовать с Objective-C объектами.

E>А ты ей пользовался? Я вот пользовался. Всё равно удобно иметь кусок на Objective-C, на самом деле.

Удобно, кто бы спорил.

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

Для С++ можно написать, а там уже есть.

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

E>>Это, в данном случае, не важно. Важно ут совсем дургое -- API системы зафиксировало формат таблицы виртуальных функций, в случае COM-объекта. И привет, все компиляторы под винду его поддерживают
V>Ты правда не понимаешь? КОМ — это приложение, реализованное на С. Не имеет никакого отношения к С++, и зачем ты его здесь приплетаешь, неясно.

Я правда не понимаю, откуда следует выделенное.

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