C++/CLI vs C# , Ваше мнение.

Цитата Hryak @ 04.05.08, 08:36

И возня с using лаконичнее возможности размещения объектов "на стеке" в C++/CLI?

Ты приводишь практически частный случай, когда из C# приходиться работать с неуправляемыми ресурсами, причем с using возиться, не всегда и обязательно.

По сути все удобства от C++/CLI на платформе .NET как раз и заканчиаются. Там где заканчиваются врапперы для обращения к нативному коду. ИМХО.

Пекарю пекарево, а кесарю кесарево. С++ был и остается стандартом в системном программировании. Не вижу повода зная С++ заморачиваться с ним при программировании бизнесс приложений. Каждой задаче свой инструмент. И если расматривать С++/CLI как язык для системного программирования, то честно говоря не вижу причин не писать на unmanaged С++.

Цитата juice @ 04.05.08, 10:35

Ты приводишь практически частный случай, когда из C# приходиться работать с неуправляемыми ресурсами, причем с using возиться, не всегда и обязательно.

SqlConnection - неуправляемый ресурс? И ты при работе с ним не используешь using ?

Цитата Hryak @ 04.05.08, 08:36

Цитата juice @ 02.05.08, 17:49

Во всем остальном, C# и VB.NET ИМХО проще, а главное лаконичней чем C++/CLI

И возня с using лаконичнее возможности размещения объектов "на стеке" в C++/CLI?

А можешь написать пример возни с "using" и красивого кода на C++/CLI

Цитата Hryak @ 04.05.08, 10:42

SqlConnection - неуправляемый ресурс?

Смотря, что ты под этим понимаешь. Сам объект распологается в управляемой куче. И будет собран сборщиком мусора. Другой вопрос, что после того, как ты с его помощью открыл физическое соединение с БД, ты должен его явно закрыть. Ты ведь вызываешь fclose для файлов? Т.к. сборщик мусора управляет памятью, а не физ. соединениями БД. Как ты это сделаешь, с помощью метода Close или Dispose не важно, но закрыть ты его должен. Альтернативой может быть реализация IDisposible в классе и управление тогда перекладывается на него и\или финалайзер. Тут уже скорее вопрос дизайна.

Цитата Hryak @ 04.05.08, 10:42

ты при работе с ним не используешь using ?

using по сути неявно генерит код c finaly, где будет вызыван метод Dispose. Лично я предпочитаю использовать явный вызов Dispose, но часто бывает, что объект SqlConnection, мне нужен в проинициализированном сотоянии для дальнейшей работы и я просто вызываю метод Close, а Dispose объкта SqlConnection вызывается уже в методе объекта реализующего IDisposible и позже по месту или вообще не вызывается оставаясь добычей сборщика мусора, главное, что бы ты закрыл физический конект к БД. Если будешь настаивать я проведу тебе лекцию по этому поводу, точно так же как и расскажу разнцу между методом Close и Dispose и зачем нужен using.

Ну я под .НЕТ пишу только на шарпе. А C++/CLI использую только чтобы обертывать требовательные по скорости модули, реализованные на чистом С++. Модули на чистом Си я могу обернуть и в шарпе интероп сервисами. Ну или использую C++/CLI для требовательного по скорости алгоритма реализуя внутренности методов .НЕТ объектов на чистом С++, если знаю что эта функциональность понадобится только в .НЕТе и не надо будет алгоритм импортировать в другие нативные модули... Также можно использовать C++/CLI для обертки большого куска Вин АПИ, это иногда проще чем интеропить кучу функций, тем более что этот кусок можно сразу сделать ООПным... Хотя чаще все же копи-пастю из Рефлектора то, что уже давно интеропнуто в System.Windows.Forms, только заприватено там внутри.

В общем, каждый язык для своей задачи. Я ж не дурак писать на C++/CLI интерфейс на винформз Но пару раз было писал отдельные сложные контролы на Managed C++ скрещивая Вин АПИ и ВинФормз, особенно когда нужно было, чтобы они не только ГДИ+ использовали, но и темы ХР.... Однако щас лучше буду использовать из шарпа свой класс C++/CLI интеропящий работу с темами из Visual Styles API...

Блин ну насколько же раньше проще было писать MC++ вместо нынешнего C++/CLI

Добавлено 04.05.08, 13:48
Ответ на это: Предпочитаемый .NET язык (сообщение #1944531)

Цитата developer @ 02.05.08, 22:13

Может C++/CLI и не самый лучший и идеальный .NET-совместимый язык, но для тех кто работал или работает с ISO/ANSI C++ на мой вгляд неплохой вариант.

К слову говоря, когда Микрософт разрабатывали C++/CLI в их задачу входило сделать его максимально несовместимым с ISO/ANSI C++ От них этого потребовал комитет С++, чтобы Микрософт ни в коем случае не затронул будущие версии С++, код в которых мог бы неоднозначно компилироваться...

Loviard, соглашусь с тобой. С++/CLI имеет более широкие возможности по взаимодействию с неуправляемым кодом, более того он еще и работает быстрее с ним чем вызовы через PInvoke драйвер.

Цитата Loviard @ 04.05.08, 13:42

К слову говоря, когда Микрософт разрабатывали C++/CLI в их задачу входило сделать его максимально несовместимым с ISO/ANSI C++

Прикольно. Я почему то считал, что это версия Managed C++ (в VS 2003) была такой. А для VS 2005, разрабатывался по сути новый язык С++/CLI на основе старого Managed C++ Extention и вроде теперь заявляется поддержка стандарта. Или ты имеешь ввиду именно ту часть языка, что относится непосредственно к возможностям .NET C++/CLI?

Цитата Raino @ 04.05.08, 10:50

А можешь написать пример возни с "using" и красивого кода на C++/CLI

Писать не буду, сам представь - пяток вложенных using для организации детерминированного разрушения объектов или ни одного.

Цитата

Ты ведь вызываешь fclose для файлов?

Представь себе, не вызываю. Всё само делается, даже если произошло исключение и идет раскрутка стека. Безо всяких try / finally

Цитата

using по сути неявно генерит код c finaly, где будет вызыван метод Dispose.

Я в курсе.

Цитата

Лично я предпочитаю использовать явный вызов Dispose

В finally блоке? Не напрягает?

Цитата

Если будешь настаивать я проведу тебе лекцию по этому поводу, точно так же как и расскажу разнцу между методом Close и Dispose и зачем нужен using.

Не буду настаивать. Разницу между Close и Dispose я и так понимаю, а по поводу прочего - у нас слишком разные идеологии, чтобы ты мне что-нибудь смог доказать. Я люблю использовать автоматические объекты и не париться по поводу - а нужно ли ручками освобождать ресурс или нет. Я рад, что и в .NET я могу их использовать благодаря С++/CLI.

В эту дискуссию я влез не для того, чтобы доказывать, что С++/CLI немерянно крут, просто указал на одну немаловажную деталь, про которую тут все забыли.

Цитата

Блин ну насколько же раньше проще было писать MC++ вместо нынешнего C++/CLI

Вот уж действительно - каждому свое...

Цитата

К слову говоря, когда Микрософт разрабатывали C++/CLI в их задачу входило сделать его максимально несовместимым с ISO/ANSI C++ От них этого потребовал комитет С++, чтобы Микрософт ни в коем случае не затронул будущие версии С++, код в которых мог бы неоднозначно компилироваться...

Не ставь всё с ног на голову. При чем тут несовместимость?? Сейчас все совместимо, а требовалось, спецификация не мешала развитию С++.

Цитата Hryak @ 04.05.08, 13:58

Писать не буду, сам представь - пяток вложенных using для организации детерминированного разрушения объектов или ни одного.

Допускаю, что столь сильный девелопер (без иронии) знает почему в .NET нет детерминированого уничтожения объектов. Кстати хочу тебя поправить, вызов Dispose не приводит к разрушению .NET объекта... Его корректное дальнейшее использование (вернее не использование) на совести того, кто реализовывал IDisposible.

Цитата Hryak @ 04.05.08, 13:58

Представь себе, не вызываю. Всё само делается

Прикольно. Мне действительно интересно. Каким таким волшебным образом закроется физическое соединение с БД, без явного вызова Close, после освобождения памяти которое объект занимал в стеке, до того как он вышел из области видимсти?

Цитата Hryak @ 04.05.08, 13:58

Писать не буду, сам представь - пяток вложенных using для организации детерминированного разрушения объектов или ни одного.

Тогда вопрос, что тебе мешает явно вызывать Dispose не используя конструкцию с using? По пять штук кряду ... слабовато представляю. Видел обычно по парочке и при работе в GDI+. А там к слову гораздо эффективней переопределять Dispose или реализовывать IDisposible, чем создавать кисти и перья локально в методах. Преимуществ масса жрет меньше памяти да и работает быстрее.

Сообщение отредактировано: juice - 04.05.08, 14:18

Цитата juice @ 04.05.08, 13:56

Или ты имеешь ввиду именно ту часть языка, что относится непосредственно к возможностям .NET C++/CLI?

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

Цитата juice @ 04.05.08, 13:56

Прикольно. Я почему то считал, что это версия Managed C++ (в VS 2003) была такой.

Наоборот, если сравнить Managed Extensions for C++ и C++/CLI, то получается, что почти любую конструкцию MC++ (может за исключением __identifier) можно так или иначе, макросами например, свести к Чистому С++. Любые __gc, __pin, __box можно объявить через дефайны как пустое место или еще что... Даже свойства по сути дела, те же методы нормально скомпилировались бы... А в C++/CLI как ни пытайся, а со ссылкой ^ или с новым синтаксисом свойста ничего поделать не сможешь, чтобы оно скомпилировалось на Чистом С++. Или никаким новым зарезервированным словом Микрософт не перебьет будущие зарезервированные слова или просто идентификаторы, потому что все (или почти все) новые зарезервированные слова содержат пробел. Ведь ref class не является двумя зарезервированными словами, это одно с "разделителем". По отдельности они не подсвечиваются и их можно использовать в качестве своих идентификаторов...

Цитата Hryak @ 04.05.08, 13:58

Не ставь всё с ног на голову. При чем тут несовместимость?? Сейчас все совместимо, а требовалось, спецификация не мешала развитию С++.

А что я с ног на голову поставил?

Loviard, cспасибо за комментарии.

Цитата juice @ 04.05.08, 14:10

знает почему в .NET нет детерминированого уничтожения объектов.

Таков применяемый GC? Правда, это можно рассмотреть и с другой стороны - объекты уничтожаются, когда будет время, которое можно потратить на их уничтожение.

Цитата

Кстати хочу тебя поправить, вызов Dispose не приводит к разрушению .NET объекта...

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

Цитата

Каким таким волшебным образом закроется физическое соединение с БД, без явного вызова Close, после освобождения памяти которое объект занимал в стеке, до того как он вышел из области видимсти?

Почему до выхода из области видимости? При выходе из области видимости...

Цитата

Тогда вопрос, что тебе мешает явно вызывать Dispose не используя конструкцию с using?

Потому что команда где-то перед вызовом Dispose могла кинуть исключение и этот Dispose никогда не выполнится. Заворачивать же все в try / finally - загромождать код.

Цитата Loviard @ 04.05.08, 14:13

А что я с ног на голову поставил?

Цитата Loviard @ 04.05.08, 13:42

когда Микрософт разрабатывали C++/CLI в их задачу входило сделать его максимально несовместимым с ISO/ANSI C++

Цитата Hryak @ 04.05.08, 18:15

А что я с ног на голову поставил?

Hryak, еще раз повторяю свой вопрос.

Цитата Hryak @ 04.05.08, 18:15

Таков применяемый GC? Правда, это можно рассмотреть и с другой стороны - объекты уничтожаются, когда будет время, которое можно потратить на их уничтожение.

Вполне, но это несколько далековато от тематики обсуждения.

Цитата Hryak @ 04.05.08, 18:15

Почему до выхода из области видимости?

Потому, что память он там занимал именно тогда когда был в области видимости Перечитай внимательней. Кстати там был и вопрос. Я повторюсь. Как ты закроешь физическое подключение, расположив SqlConnection на стеке при этом не вызвав явно метод Close? Считай, что мне любопытно, я не гуру в C++/CLI, а потому интересуюсь.

Цитата Hryak @ 04.05.08, 18:15

Потому что команда где-то перед вызовом Dispose могла кинуть исключение и этот Dispose никогда не выполнится. Заворачивать же все в try / finally - загромождать код.

Я это прекрасно понимаю. Я приводил альтернативное решение с IDisposible, тем не менее даже в этом случае, то как будет конкретно написан код, зависит от того, как реализуется политика обработки исключений в приложении.

Ну и на последок согласись, что восемь вложенных using при работе с БД, через ADO.NET это через край фантастично.

Цитата juice @ 04.05.08, 18:34

Считай, что мне любопытно, я не гуру в C++/CLI, а потому интересуюсь.

Ну там действительно не-value объекты можно располагать в стэке.

Цитата Loviard @ 04.05.08, 18:50

Ну там действительно не-value объекты можно располагать в стэке.

Я понимаю. Я хочу понять как будет закрываться при этом физическое подключение если для него не использовать using/Dispose или Close, мои скромные познания С++/CLI сводятся к тому, что код можно записать примерно так:

     auto_handle<SqlConnection> connection = gcnew SqlConnection(myConnString);
     connection->Open();
 
     auto_handle<SqlCommand> command = gcnew SqlCommand("запрос", connection);
 
     ...
 
     auto_handle<SqlDataReader> reader = command->ExecuteReader();
     while(reader->Read())
     {
          ...
     }

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

Сообщение отредактировано: juice - 04.05.08, 19:00