А кто реально применял Managed C++?

[aldep]

В чем его преимущества над С# и С++?

[Marmot]

Да, мне тоже было бы интерсно это узнать.
IMHO, мanaged C++ это уродец, которого MS создали, что бы показать что .Net поддерживает разные языки.
А в результате получился этакий кастрат...

[папа Карло]

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

[Woozy]

теперь если надо манаджед код пишу на шарпе, не манаджет на плюсах.

Завидую. Одновременно быть IT руководителем, database architect, DBA, писать код на C# и на простом C++. Ненужное вычеркнуть.

[aldep]

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

Мне тоже показалось, что UI лучше на C# а что-то сложное на C++.
Думал может не понял чего.

[vg]

2Woozy,

Завидую. Одновременно быть IT руководителем, database architect, DBA, писать код на C# и на простом C++. Ненужное вычеркнуть.

Он же НЕ пишет здесь: "Я - профессионал с большой буквы во всём ЭТОМ". Для повседневки вполне достаточно минимального знания C# и некого хорошего прошлого опыта, например, С++.
Я бы его взял на работу (без иронии).
Папа Карло приезжай. Устрою. По колодцам вместе бум лазить.

2aldep,

Мне тоже показалось, что UI лучше на C# а что-то сложное на C++.

Ну, нетути, нетути проблемы написания интерфейса - это в прынцыпе.
Если не в принципе, то установите последний 2003 год (апрель) релиз NET. Там такая же поддержка мастеров для Windows Forms при программировании в С++, как и для С# (так пишет MS). А в "старом" NET (2002) и так есть поддержка для Windows Forms - только писать надо руками, а не при рисовать формы при помощи визардов.

что-то сложное на C++.

Ну, очень страшно. А чтож это такое сложное, что нельзя написать на C# (это не издёвка. Мне действительно интересно, т.к. я не спец.).

ПС.
1) Мега-спецы - подскажите. У меня был вопрос относительно обёрток для адонет. Вопрос-то простой. Неужели никто не знает? У нас, в России - похоже народ не знает .
2) Не надо обижать Папу Карло.

[папа Карло]

теперь если надо манаджед код пишу на шарпе, не манаджет на плюсах.

Завидую. Одновременно быть IT руководителем, database architect, DBA, писать код на C# и на простом C++. Ненужное вычеркнуть.

№1 и 2 (только на датабаз, а дата -- есть разница ), три вычеркиваем. это на работе. 4 и 5 дома, в свое удовольствие

[папа Карло]

Я бы его взял на работу (без иронии).
Папа Карло приезжай. Устрою. По колодцам вместе бум лазить. :D2) Не надо обижать Папу Карло.

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

где ты там про АДО спрашивал? я пропустил..... сейчас поищем.... не нашел. линк на мессадж дай....

[vg]

2 Фридрих Энгельсович Карло Маркс.

Топик называется "Managed код в DLL".

[папа Карло]

прочитал.... в этом я слабо копенгаген. а нафига тебе это надо? (да и мало наверное кто тебе здесь ответит, спецов по .нету такого уровня еще здесь не созрело).

попробуй тут прочитать....

http://www.codeproject.com/dotnet/bridge.asp

можешь попробовать автору написать.... они обычно хорошо на вопросы реагируют.

[vg]

2 Папа Карло.

а нафига тебе это надо?

В общем-то надо, и сильно. Вкратце, речь идет о разработке
корпоративного стандарта (группы наших контор) и специальных
требованиях к методам доступа данных прикладных программистов.
(там писать-непереписать. работу будем раздовать многим разработчикам-подрядчикам).
Если буду вдаваться в подробности, то боюсь, что некоторые продвинутые здесь шепнут своим манагерам
на ушко, чтоб не брали этого "продвинутого" из Жопинск-Урюпинска
на работу (я про себя). Тогда точно мне - пицца по-приезду к вам.

спецов по .нету такого уровня еще здесь не созрело

В принципе и да и нет. Woozy, Marmot, Lepsik могли бы высказаться.
Но некоторые из них помогают только тем, кто Жопинск-Торонтовска,
а не Жопинск-Урюпинска.

попробуй тут прочитать....

Да, спасибо за ссылку. Только что прочитал. В этой статье не то, чтобы ничего нет - там вообще ничего нет. Типичная статья
самоутверждающегося мена, окончившего подзаборную школу в
Жопинск-Оклахоменске. Лучше он бы и подолжал писать на Fortran.
Это английский мальчик, Michael Combs, с astrophysics and computer science
даже не пропёхал, что соглашения о вызовах в экспортируемых
функциях разные (в манагед - __clrcall, а в неманагед - ты сам задаёшь соглашения при помощи соответствующих модификаторов при определении экспортируемых именах функций).
Этот деятель ни словом не обмолвился об этом, поскольку, вероятно,
он не понимает всю серьёзность последствий.

они обычно хорошо на вопросы реагируют.

Реакция такого "спеца" мне не нужна (см. мой яд в его адрес выше).

[aldep]

Чисто теоретический совет, сам не пробовал.
А если попробовать COM wrappers вокруг .Net библиотек. Вроде можно вокруг любого класса сгенерить.
Только зачем понадобилось ADO.Net вызывать из unmanaged code?

[Marmot]

В принципе и да и нет. Woozy, Marmot, Lepsik могли бы высказаться.
Но некоторые из них помогают только тем, кто Жопинск-Торонтовска,
а не Жопинск-Урюпинска.

На это я имею сказать две вещи:
1. Не надо меня помещать в один список с Lepsik-ом, до уровня его интеллекта мне ещё долго надо прожить, и к надеюсь что я до такого не доживу
2. Я помогаю тому, кому могу помочь...

...что соглашения о вызовах в экспортируемых
функциях разные (в манагед - __clrcall, а в неманагед - ты сам задаёшь соглашения при помощи соответствующих модификаторов при определении экспортируемых именах функций).
...

vg, я знаю, что вы взглянули на то, чем я занимаюсь, более managed кода даже вообразить сложно.
IMHO, в вашем случае, программист должен заниматься разработкой логики программы, а не заниматься попытками совместить разные соглашения о вызовах.
Я скажу прямо, это плохой design, мазохизм какой-то!
Зачем так делать я не понимаю...
Application code должен быть managed!

[vg]

2Marmot.

Я скажу прямо, это плохой design, мазохизм какой-то!
Зачем так делать я не понимаю...
Application code должен быть managed!

Да. Немного всё запущено. И тараканы есть. Я и не претендую. Тем не менее.

1) Спасибо, что Вы отреагировали.
2) Вы сами как-то говорили, что программировали на С. Поэтому и мой пост выше был таков.
3) Мне на самом деле важно знать Ваше мнение. Для меня лучше здесь, на форуме выяснить некоторые детали относительно программирования в Канаде, чем ляпнуть что-либо нанимателю-манагеру, так, что он посмотрит на меня, как на сумасшедшего.
4) Я Вас не помещаю ни с кем, ни в какой ряд. Про это Вы зря.

Возможно с ADO.NET я несколько и переборщил (хотя на самом деле попытка решения этой задачи мною была предпринята). Чтобы Вы не думали, что я на самом деле невменяемый, скажу, что очень и очень не плохие Российские программеры (не из того города, где я живу) предложили мне «посмотреть и в эту сторону» при обсуждении проекта некого ТЗ, о котором ниже. Посмотрите Мармот на пост ниже, если не затруднит, конечно. Двумя словами трудно объяснить, для чего это всё.

2aldep.
Молодец. Видно – разбираешься в сабдж.

Можно и так, хотя не обязательно так. Почему? Прочитайте пост ниже. Там сказано про некие три модели, которые «забиты» в некое ТЗ.
То, о чём Вы говорите, приведёт к несколько «кривому решению» - с ещё одной прослойкой ПО.

Положим, мы обернули ADO.NET в некие COM классы, например, CoADONET.
Напрямую, это можно будет использовать только в модели, обозначенной номером 1, см. ниже пост, там, где ***ВЫВОД***.
В других моделях (2, 3), где используется __stdcall, необходимо ещё будет разработать обёртки, которые будут иметь «стандартный» интерфейс для прикладного ПО, и которые будут агрегировать тот самый CoADONET.

Т.е. для моделей 2, 3 механизм будет таков:

Прикладное ПО -> API «стандартных обёрток» -> CoADONET -> ADO.NET.

Долго. Вот и хотелось узнать у спецов, как обернуть эффективно.
Если вообще в этом случае это возможно.

[vg]

Это только слегка переделанный перепост с другого форума. Прошу прощения, что отсылаю пост «как есть» с другого Российского форума. Очень долго переделывать, подстраиваясь под «настроение» обитателей здешнего форума.
Это насчёт того, зачем всё это надо.

*** МОТИВАЦИЯ ***

В моём учреждении разрабатывается техническое задание (ТЗ) на создание информационной системы (ИС). В ТЗ мы формулируем «что нам надо, и как нам надо». Проектировать и реализовывать эту систему будут сторонние разработчики, поскольку мы – не программисты.

ИС – могутная и дорогостоящая. Разработка предполагается поэтапной (1-2 года). На каждом этапе, возможно, будут трудиться параллельно несколько фирм-разработчиков, реализующие отдельные составляющие ИС.

Одна из составляющей ИС – реляционные базы данных (БД) и соответствующие клиентские приложения. Мы намерены включить в ТЗ специальные требования к методам доступа к данным для разработчиков (для чего см. ниже). Предполагается, что программисты фирм-подрядчиков должны будут следовать требованиям ТЗ.

Предполагается, что на разных этапах разработки для разных БД разные подрядчики могут использовать любые языки программирования приложений (одни конторы будут писать на VB, другие Delphi или BCB++, третьи – MSVC++).

Сложность в том, что на стадии разработки ТЗ мы не можем сделать предположений относительно СУБД, которые могут изменяться при модернизации нашей ИС. Как впрочем, и относительно версий окошек рабочек и серверов и сетевой инфраструктуры. Т.е. сегодня у нас MS SQL Server, а «завтра», возможно мы переедем на оракл или db/2. Вопросы переноса данных с одной СУБД на другую СУБД при модернизации ИС не рассматриваются. Это наша забота. К сторонним программистам предъявляется только одно требование – их клиентское ПО должно «жить» с новыми источниками данных без перекомпиляции. Это требование для нас важно.

Можно, конечно, в договоре с подрядчиком просто оговорить, что их клиентское ПО должно «жить независимо от СУБД»? Мои сомнения относительно «просто строчки в договоре» в том, что:
- это может остаться только декларацией (невыполнимой даже на 50 %).
- подрядчик может согласиться на эту «строчку», но фактически не станет реализовывать в своих проектах СУБД-независимые архитектурные решения.



**** ОБЪЕКТЫ ДОСТУПА К ДАННЫМ ****

Я попытался проанализировать несколько «сценариев», которые могут иметь место в зависимости от того, как подрядчик будет программировать.

BDE
Здесь, на мой взгляд, больше иллюзия «независимости приложения от СУБД», чем её реализация на сегодняшний день. Когда-то - это было кул, но не сегодня. Уже начиная с версии Delphi 5.0 в отличие от 3.0 (тоже, разумеется, касается и BCB++) я к удивлению обнаружил, что native SQL Links драйвера MSACCESS уже не работают, по тому, что мелкософт чего-то не поделил с Борландом. Поддержка компонентами Борланда ODBC-сокетов вообще дубовая (по сравнению с тем, если это делать в VC++ хотя бы с использованием MFC). Не факт, что у Борланда найдутся «работающие», а не просто продекларированные native драйвера SQL Links для некой новой версии Oracle, на которую возможно мы переедем в будущем.
Таким образом, приложение, написанное для нашего предприятия на BCB++ с использованием BDE может уже через год не работать, так как для нашей новой СУБД (установленной при модернизации ИС) нет подходящего native драйвера Борланда.

ODBC
Это более привлекательно по сравнению с BDE. Ясно, что никто не должен Борланду, но все должны мелкософту. Если уж вышла новая версия некого SQL сервера, то уж естественно его разработчики постарались с драйверами ODBC (иначе, как ЭТО будет юзастья под окошками старыми клиентами с доступом к данным по ODBC). Мой опыт показывает, что приложения работают устойчиво, если ЭТО программировать средствами VC++ а не использовать сокеты компонент Борланда. Опасения в части ODBC только такие, что производители серверного софта могут решить, что хватит постоянно реанимировать архаичные технологии доступа к данным, и что, для того чтобы их SQL сервер был самым SQL сервером в мире, следует использовать только ихние сверхпроизводительные OLE DB компоненты. Доля шутки в этой шутке в том, что мелкософт, как мне кажется, давно рассматривает ODBC как устаревший способ доступа к данным, хотя и тянет это API от операционки к операционке для продления жизни старого клиентского софта.

ADO
Наверное, это наименьшее зло из того, что выше. Сомнения только в том, что, не смотря на все заверения мелкософта, настоящим стандартом, на мой взгляд, ЭТО так и не стало (здесь я могу сильно ошибаться). Достаточно посмотреть, что теперь уже ADO не модно. Теперь правильное программирование - только с использованием ADO.NET. Мелкософт заверяет, что, мол, не волнуйтесь, будет, будет поддерживаться ADO вместе с ADO.NET в будущем. Но что-то сильно напоминает соотношение ODBC-ADO.
Кроме того, здесь тоже присутствует некая доля иллюзии «стандартности». Ясно, что в ASCII коде программы разработчик будет использовать действительно стандартный интерфейс к методам компонент ADO. Это радует. Но то, что его скомпилированная программа будет использовать вполне конкретную версию компонент MDAC – это может, на мой взгляд, в будущем принести огорчения. Впрочем, у меня есть практический опыт таких огорчений, когда мы так и не смогли под W98 полноценно прикрутить MDAC для комплекса «АКСИОК» (это могутный комплекс для госконтор. Не помню кто разработчик). Возможно, это было из моей криворукости, вернее криворукости моих сотрудников. Но факт- под W2k и XP работает на ура, а под W98 – через пень-колоду. Динамичность, с которой мелкософт развивает OLE DB просто пугающая. Поэтому и сомнительно, как это будет работать, когда мы переедем на новые версии окошек, где старая версия ADO поддерживается не в полной мере, или для новой версии SQL сервера старый провайдер («зашитый» в коде клиентского ПО) уже не поддерживается. Думаю, без перекомпиляции клиентской проги в этом случае не обойтись. Этого как раз и хочется избежать для нашей ИС. Повторяю, что я считаю ADO лучшим в части построения «живучих» программ. Выше я только о своих сомнениях, которые, возможно, из-за моей малограмотности.


**** МЕТОДЫ ДОСТУПА К ДАННЫМ ****

Положим, что в результате обсуждения на этом форуме мне объяснили мою дремучесть и невежество и рассеяли все сомнения относительно вышесказанного. Подсказали, что, мол, «забивай» в ТЗ требование – использовать только ADO. Спорно – хорошо ли. Боюсь, наше учреждение в этом случае может потерять в качестве потенциальных разработчиков тех программеров, которые не знакомы с ADO, или по какой-то причине его ненавидят.

Однако есть другой ряд причин, по которым даже использование ADO может не обеспечить требуемой «живучести» приложений нашей ИС, имхо. Программер использует вполне определённый синтаксис SQL. Разработчики всех промышленных СУБД декларируют, что поддерживают стандарт ANSI SQL. Мой опыт показывает, что не факт. Диалекты SQL, например, T-SQL для MSSQL Server, JET-SQL для MSAccess, SQL для SQL Links – различаются как в части синтаксиса DDL, так и DML (например, в определении скалярных функций преобразования типов данных). Конечно, можно в ТЗ ограничить программистов обязательством использовать только, действительно стандартные лексемы и, например, не использовать скалярные функции SQL вообще. Не факт, что программер будет придерживаться этого правила. Да это может быть и не удобным (почти всегда). Например, программер «зашивает» в код функцию cast в предложении select, тогда как после модернизации мы переехали на СУБД, драйверы которой понимают ключевое слово convert вместо cast. Программер «зашивает» в коде строчку ucase, тогда как после модернизации мы переедем на источник данных, драйверам которого надо будет говорить upper вместо ucase. С DDL – ещё хуже (хотя это обычно не критично для клиентской проги).

Поскольку с этими проблемами непереносимости диалектов SQL я сталкивался не раз при решении задач адаптации клиентской проги для работы с различными СУБД, то есть понимание, что ЭТО нельзя оставлять «на самотёк» в ТЗ. Я проблему решал в своё время, как мне казалось, просто. Все SQL запросы вначале отправлялись на претрансляцию. Там в зависимости от драйверов конкретного источника данных выполнялась «корректировка» лексем. Только после этого строка SQL отправлялась драйверу в том виде, в котором он эту строку понимает. Модули претрасляции выполняли «корректировку», пользуясь мапингом в «настроечных» ASCII-файлах (так я делаю сейчас), или в подключаемых dll (так я делал раньше).


*** ВЫВОД ***

Было найдено такое решение – разработать ведомственный, корпоративный стандарт, оговаривающий методы доступа к данным (для ведомственных контор). Этот стандарт предусматривает, по меньшей мере, три способа написания и использования в клиентских приложениях API доступа к данным:

1) API – построенное на COM
2) хэндл-ориентированное «обычное» API
3) COM-подобное API – для программистов С++ (удобнее, чем COM).

В техзадание оказалось возможным забить обязательство программистов (подрядчиков) использовать только это API. В коде клиентского ПО – ни каких вызовов мелкософтовского API или борландовских компонент. Используем только своё, самостийное API. Ясно, что такое API инкапсулирует объекты мелкософта или борланда (или и то и другое). Т.е. это API классов-обёрток.

В чём преимущество? Что это даёт? То, что такое API можно перекомпилировать при необходимости по десять раз в день, не нарушая работу клиенской проги нашей ИС. Придёт время в процессе модернизации ИС переписать это API для некого нового источника данных – это сможет сделать программер сравнительно невысокой квалификации. Даже я. Перекомпиляция клиентов не нужна вовсе. Три варианта написания и использования API включены в ТЗ, что бы как можно меньше связывать руки прикладным программистам.


*** МОДЕЛЬ****

Поскольку, как известно, легче пукнуть, чем понюхать, то, что бы в наш адрес не поступали такого рода рекламации от подрядчиков (Российские программеры очень капризны в последнее время) – была разработана «действующая модель» такого API. Дескать, всё реализуемо. Дескать, не надо, уважаемые господа программисты, волноваться и бояться. В кавычках я поставил «модель», поскольку использую её несколько лет. Когда я программирую в Борланде, у меня нет в проекте ни одного ихнего компонента доступа к данным. Т.е., ни в статике, ни в динамике не создаются и не используются компоненты типа TQuery и им подобные. Все только через API. Там есть и Query и не только.
Когда я программирую в MSVC, то в С++ коде нигде нет объявлений CDatabase, нет использования низкоуровневого API ODBC, нигде нет даже упоминания об ADO. Всё работает, как и в случае Борланда только через API.

Подрядчикам мы ПЕРЕДАЁМ исходники нашего API в качестве примера. Подрядчики вольны выбирать – или разработать своё собственное API (но обязательно с соблюдением наших требований на разработку API), или использовать наше, уже разработанное API.

Когда программист фирмы-подрядчика будет использовать хэндл-ориентированное API, он будет делать вызовы, аналогичные тем, что ниже (это фрагмент работающего кода):

Код: Выделить всё

Dim hr As Long                        				' код результата запроса
Dm I As Integer
        
        hr = QueryOpen(hQuery, "select id from tbl1") 		' выполняем запрос
        
        If (hr <> S_OK) Then
            MsgBox ("Can't open query")
            Exit Sub
        End If
        
        QueryFirst (hQuery)            				' указатель на первую запись
        While (QueryEof(hQuery) = False)	
                I = vbQueryIntegerField(hQuery, "id")			' получаем данные текущей записи
	…
	…
                QueryNext (hQuery)				' указатель на следующую запись
        Wend
        
        QueryFreeConnections (hQuery) 			' удаляем временные объекты
        QueryClose (hQuery)             				' закрываем активный набор данных

Здесь нет вызовов методов объектов мелкософта или Борланда. Здесь используется один из вариантов API, о котором я писал. Если господа прикладные программисты любят COM, то они будут писать нечто вроде (это тоже фрагмент работающего кода)

Код: Выделить всё

hr = IQuery.Open("select id from tbl1")  ' выполняем запрос
        
If (hr <> S_OK) Then
 MsgBox ("Can't open query" & Chr(13) & IQuery.ErrorMessage)
 Exit Sub
End If
        
IQuery.First                         		'  указатель не первую запись
 While (IQuery.IsEof = False)
                Id  = IQuery.IntegerField("id")
	…
…
                IQuery.Next		'  указатель на следующую запись
Wend
IQuery.FreeConnections		'  удаляем временные объекты соединения с базой данных
IQuery.Close			'  закрываем активные наборы данных

В последнем случае клиент-«супертонкий». Реализация объектов доступа к данным лежит на мидлаврном сервере. Там и BDE, и ODBC вместе с OLE дебюми в одном флаконе (вернее там, то, что нужно мидлварному серверу компонент доступа к данным в зависимости от его текущей конфигурации).