1) Может кто-нибудь рассказать возможно ли написание pure С-приложения с поддержкой .NET?
2) Если первое возможно то есть ли в этом смысл?
2) Если первое возможно то есть ли в этом смысл?
» Вопросы про .NET
Ты хоть сам-то понимаешь что спрашиваешь?
Какой может быть смысл в бессмыслице? Кто такой pure С, что значит "с поддержкой .NET"?
Какой может быть смысл в бессмыслице? Кто такой pure С, что значит "с поддержкой .NET"?
dmka
Если бы я знал что такое поддержка .NET - я бы не спрашивал.
Что есть приложение поддерживающее платформу .NET?
Я знаю что можно писать такие приложенич в частности на C++.
Так вот и спрашиваю, можно ли писать такие приложения на чистом C (без использования каких-либо библиотек классов и шаблонов (например MFC или STL) и сторонних компонентов) с использованием только Win32 API.
Добавлено
Можно и ещё подробнее. Существует некий .NET Framework, который будет частью всех будущих OS, уже встроен в Windows Server 2003 и поставляется как редистрибутабле для 98/ME/NT/2000/XP. И есть приложения, для работы которых требуется сначала установить этот .NET Framework. Так вот ещё раз можно ли эти приложения писать на C с использованием только Win32 API. Насколько я понимаю рабочая среда будет Visual C++ .NET
Если бы я знал что такое поддержка .NET - я бы не спрашивал.
Что есть приложение поддерживающее платформу .NET?
Я знаю что можно писать такие приложенич в частности на C++.
Так вот и спрашиваю, можно ли писать такие приложения на чистом C (без использования каких-либо библиотек классов и шаблонов (например MFC или STL) и сторонних компонентов) с использованием только Win32 API.
Добавлено
Можно и ещё подробнее. Существует некий .NET Framework, который будет частью всех будущих OS, уже встроен в Windows Server 2003 и поставляется как редистрибутабле для 98/ME/NT/2000/XP. И есть приложения, для работы которых требуется сначала установить этот .NET Framework. Так вот ещё раз можно ли эти приложения писать на C с использованием только Win32 API. Насколько я понимаю рабочая среда будет Visual C++ .NET
Цитата:
Существует некий .NET Framework, который будет частью всех будущих OS
Да, мир перевернется!
Теоретически, на C, как и на ассемблере можно написать все, другое дело нужно ли..
Для .net есть компилеры для нескольких языков, которые компилят в промежуточный код, который выполняется на common language runtime (штука, похожая на java vm).
Т.е. чтобы эти приложения работали, им необходим clr (так же как и для java-приложений необходима jvm). Однако это не мешает обычным приложениям этот clr не использовать.
odl455
dmka прав. Одновременно на машине могут стоять и .NET Framework, и прошлая Win32 архитектура. Чтобы писать под .NET, надо чтобы был выпущен компилятор, который будет соответствовать требованиям CLS. Если хочешь писать под WinAPI, то можешь забыть про .NET, т.к. у него своя собственная библиотека классов BCL. Если хочешь писать на C++.NET, то учти, что нужно будет учитывать много требований и спецификаций (а также ограничений), чтобы код считался safe & managed, иначе он не будет обрабатываться CLR, что повлечет за собой НЕ-совместимость с .NET.
dmka прав. Одновременно на машине могут стоять и .NET Framework, и прошлая Win32 архитектура. Чтобы писать под .NET, надо чтобы был выпущен компилятор, который будет соответствовать требованиям CLS. Если хочешь писать под WinAPI, то можешь забыть про .NET, т.к. у него своя собственная библиотека классов BCL. Если хочешь писать на C++.NET, то учти, что нужно будет учитывать много требований и спецификаций (а также ограничений), чтобы код считался safe & managed, иначе он не будет обрабатываться CLR, что повлечет за собой НЕ-совместимость с .NET.
vladgangan
dmka
Тогда у меня такой вопрос. Любое ли приложение созданное при помощи Win32 API может быть портировано под платформу .NET? И что меня ещё более интересует, стоит ли планировать будущие проекты (реализация которых будет в ближайшие несколько лет) с учетом того, что поддержка .NET просто должна быть и всё. Как факт.
dmka
Тогда у меня такой вопрос. Любое ли приложение созданное при помощи Win32 API может быть портировано под платформу .NET? И что меня ещё более интересует, стоит ли планировать будущие проекты (реализация которых будет в ближайшие несколько лет) с учетом того, что поддержка .NET просто должна быть и всё. Как факт.
я не думаю что они откажутся от апи, тк в этом случае придется поставить крест на всех наработках за долгие, долгие годы. см что случилось с досом, какая никакая но поддержка осталась. так что имха, если ты сделаешь ставку только на апи, не думаю что ты проиграешь
odl455
Цитата:
Нет, про причинам отсутствия компилятора для оного раз. А компилятор для ansi c не может быть написан для .net, поскольку последний использует java-аналогичный концепт, что всяка сущность есть объект соответствующего класса. безплюсый си придерживается диаметрально противоположных принципов.
Цитата:
Вопрос немного не ясен. Портировать можно что угодно, хотя бы путем банального переписывания. Если речь идет о какой-то совместимости и приемственности, то все равно непонятно, какого эффекта хочешь достичь. Сформулируй задачу. Будет задача - постараемся дать ответ...
Цитата:
Сложный и неоднозначный вопрос. Все зависит от корпоративной политики в случае орагнизации или твоих персональных ориентиров. В принципе, пристроится к такому паровозу как микрософт может быть достаточно удобно и выгодно.
Цитата:
1) Может кто-нибудь рассказать возможно ли написание pure С-приложения с поддержкой .NET?
Нет, про причинам отсутствия компилятора для оного раз. А компилятор для ansi c не может быть написан для .net, поскольку последний использует java-аналогичный концепт, что всяка сущность есть объект соответствующего класса. безплюсый си придерживается диаметрально противоположных принципов.
Цитата:
Любое ли приложение созданное при помощи Win32 API может быть портировано под платформу .NET?
Вопрос немного не ясен. Портировать можно что угодно, хотя бы путем банального переписывания. Если речь идет о какой-то совместимости и приемственности, то все равно непонятно, какого эффекта хочешь достичь. Сформулируй задачу. Будет задача - постараемся дать ответ...
Цитата:
стоит ли планировать будущие проекты (реализация которых будет в ближайшие несколько лет) с учетом того, что поддержка .NET просто должна быть и всё. Как факт.
Сложный и неоднозначный вопрос. Все зависит от корпоративной политики в случае орагнизации или твоих персональных ориентиров. В принципе, пристроится к такому паровозу как микрософт может быть достаточно удобно и выгодно.
Цитата:
Тогда у меня такой вопрос. Любое ли приложение созданное при помощи Win32 API может быть портировано под платформу .NET?
В общем случае нет. Да и смыса особого не вижу переписывать (портировать вряд ли выйдет) уже работающе приложение под .net - времени уйдет туча, а пользы ноль.
Цитата:
И что меня ещё более интересует, стоит ли планировать будущие проекты (реализация которых будет в ближайшие несколько лет) с учетом того, что поддержка .NET просто должна быть и всё. Как факт.
Планировать нужно так, чтобы в будущем запланированное приносило прибыль. Строить планы основываясь только на лозунге ".net- это круто" абсолютный маразм. Я же не знаю твоих задач, поэтому и советовать не берусь.
Что касается гарантированной поддержки - есть .net redistributable, пакуешь его заказчику вместе со своей кривулькой и будет тебе поддержка
dmka
Если бы пользы не было, то зачем бы это вообще стали придумывать? Чую здесь ты не прав.
Следовательно ...
Цитата:
У пока меня нет такого лозунга. Я не спец по .NET, но последнее время всё чаще про него (неё) слышу. Вот и подумал, что стоит спросить ЗНАЮЩИХ людей.
Теперь я понимаю что вопрос слишком сложный и зделал соответствующие выводы.
Если бы пользы не было, то зачем бы это вообще стали придумывать? Чую здесь ты не прав.
Следовательно ...
Цитата:
Строить планы основываясь только на лозунге ".net- это круто" абсолютный маразм. Я же не знаю твоих задач, поэтому и советовать не берусь.
У пока меня нет такого лозунга. Я не спец по .NET, но последнее время всё чаще про него (неё) слышу. Вот и подумал, что стоит спросить ЗНАЮЩИХ людей.
Теперь я понимаю что вопрос слишком сложный и зделал соответствующие выводы.
odl455
Цитата:
А вопроса-то и нет. На первые тебе уже ответили со всех сторон. А что касается портирования, то вопрос задан неверно. Будет правильный вопрос - будет качественный ответ. В общем и целом Win32api и .net несовместимы. Т.е., конечно, они могут между собой общаться через различный interoperate, но если ты пойдешь по такому принципу, то получиться, что ни там не угодили, ни здесь.
Цитата:
Теперь я понимаю что вопрос слишком сложный и зделал соответствующие выводы.
А вопроса-то и нет. На первые тебе уже ответили со всех сторон. А что касается портирования, то вопрос задан неверно. Будет правильный вопрос - будет качественный ответ. В общем и целом Win32api и .net несовместимы. Т.е., конечно, они могут между собой общаться через различный interoperate, но если ты пойдешь по такому принципу, то получиться, что ни там не угодили, ни здесь.
Guderian
Цитата:
"И что меня ещё более интересует, стоит ли планировать будущие проекты (реализация которых будет в ближайшие несколько лет) с учетом того, что поддержка .NET просто должна быть и всё. Как факт. " - вот интересовавший меня вопрос
Цитата:
Под портироанием я имел ввиду - "переписать существующее приложение".
В любом случае спасибо всем за ответы.
Цитата:
А вопроса-то и нет.
"И что меня ещё более интересует, стоит ли планировать будущие проекты (реализация которых будет в ближайшие несколько лет) с учетом того, что поддержка .NET просто должна быть и всё. Как факт. " - вот интересовавший меня вопрос
Цитата:
А что касается портирования, то вопрос задан неверно.
Под портироанием я имел ввиду - "переписать существующее приложение".
В любом случае спасибо всем за ответы.
Цитата:
Если бы пользы не было, то зачем бы это вообще стали придумывать? Чую здесь ты не прав.
Ну ты как дитя малое. Придумали, чтобы срубить бабла себе в карман
Цитата:
Я не спец по .NET, но последнее время всё чаще про него (неё) слышу.
Ну так пользуйся этим и зарабатывай деньги, пока слышно. Если заказчик хочет .net - вперед с песней.
Тупо переписывать уже работающие приложения за свой счет убыточно - пока ты будешь это делать, M$ придумает еще что-нибудь не менее революционное и не совместимое с .net
. Все, ухожу в монастырь
Я считаю, что новые проекты стоит писать под .NET, но старые надо оставить как есть... 
odl455
Цитата:
Исключительно мое (хотя и не только мое) имхо - стоит. Одна из причин - цитата dmka:
Цитата:
Вот на обратном пути этого бабла от конечных пользователей к мелкомягким ты и можешь встать и насобирать его столько, сколько сможешь. Учитывая какой капитал они в него угрохали, назад пойдет очень не мало. Скажу только одно, заказы на разработки под .net уже есть и их не мало и они растут. Выход windows server 2003 только укрепит позиции. Выход юкона еще больше. Все они нацелены на .net. Как и все далеко идущие планы мелкомягких. Единственное, где они могут колебаться - это, собственно говоря, ЯВУ (следующая версия с# с поддержкой темплейтов, partial classes и др, X#, F# и прочие фантазии).
Цитата:
стоит ли планировать будущие проекты (реализация которых будет в ближайшие несколько лет) с учетом того, что поддержка .NET просто должна быть и всё
Исключительно мое (хотя и не только мое) имхо - стоит. Одна из причин - цитата dmka:
Цитата:
Придумали, чтобы срубить бабла себе в карман
Вот на обратном пути этого бабла от конечных пользователей к мелкомягким ты и можешь встать и насобирать его столько, сколько сможешь. Учитывая какой капитал они в него угрохали, назад пойдет очень не мало. Скажу только одно, заказы на разработки под .net уже есть и их не мало и они растут. Выход windows server 2003 только укрепит позиции. Выход юкона еще больше. Все они нацелены на .net. Как и все далеко идущие планы мелкомягких. Единственное, где они могут колебаться - это, собственно говоря, ЯВУ (следующая версия с# с поддержкой темплейтов, partial classes и др, X#, F# и прочие фантазии).
vladgangan
Цитата:
Где конкретно про это можно почитать? Какие есть ограничения для разработчиков системного программного обеспечения?
Цитата:
учти, что нужно будет учитывать много требований и спецификаций (а также ограничений), чтобы код считался safe & managed, иначе он не будет обрабатываться CLR, что повлечет за собой НЕ-совместимость с .NET.
Где конкретно про это можно почитать? Какие есть ограничения для разработчиков системного программного обеспечения?
odl455
Либо MSDN, либо книги по "Managed Extensions for C++". Видишь, даже название говорит само за себя - Managed Extensions - это значит, что код созданный на основе этих спецификаций будет обрабатываться CLR и считаться safe & managed. На данный момент я знаю мало книг, которую написаны на эту тему, но все же кое-чем могу помочь. У меня есть в электронном варианте вот эти 2 книги:
1) Programming with Managed Extensions for Visual С++.NET
http://www.microsoft.com/MSPress/books/5959.asp
2) Programming with Visual C++ .NET - Core Reference
http://www.microsoft.com/MSPress/books/5757.asp
Если заинтересуешься, то дай знать.
Либо MSDN, либо книги по "Managed Extensions for C++". Видишь, даже название говорит само за себя - Managed Extensions - это значит, что код созданный на основе этих спецификаций будет обрабатываться CLR и считаться safe & managed. На данный момент я знаю мало книг, которую написаны на эту тему, но все же кое-чем могу помочь. У меня есть в электронном варианте вот эти 2 книги:
1) Programming with Managed Extensions for Visual С++.NET
http://www.microsoft.com/MSPress/books/5959.asp
2) Programming with Visual C++ .NET - Core Reference
http://www.microsoft.com/MSPress/books/5757.asp
Если заинтересуешься, то дай знать.
vladgangan
А если писать на C++.NET, то все равно компилится в промеж. код? т.е. CLR всегда нужен бул под НЕТ или это отключаемая фишка? Там вроде можно включить #pragma unmanaged и это освобождает от манаджемента НЕТа. В таком случае промеж. код создается?
А если писать на C++.NET, то все равно компилится в промеж. код? т.е. CLR всегда нужен бул под НЕТ или это отключаемая фишка? Там вроде можно включить #pragma unmanaged и это освобождает от манаджемента НЕТа. В таком случае промеж. код создается?
klau
Значит так. Слушай сюда. У компилятора есть опция /clr, которая предоставляет контроль над компиляцией managed и unmanaged функций на модульном уровне. Соответствующие прагмы задействуют нужный тип компиляции. Функция, помеченная прагмой как unmanaged, будет скомпилирована для родной платформы (т.е. Win32) и CLR передаст выполнение этого куска программы самой родной платформе. Поэтому, как видишь, в промежуточный код они не преобразуются.
Значит так. Слушай сюда. У компилятора есть опция /clr, которая предоставляет контроль над компиляцией managed и unmanaged функций на модульном уровне. Соответствующие прагмы задействуют нужный тип компиляции. Функция, помеченная прагмой как unmanaged, будет скомпилирована для родной платформы (т.е. Win32) и CLR передаст выполнение этого куска программы самой родной платформе. Поэтому, как видишь, в промежуточный код они не преобразуются.
vladgangan
Понятно.
Но в любом случае все крутиться вокруг CLR - он как бы управляет всем, соответствено если CLR не будет, то не будет работать даже если там повсюду pragma unmanaged фигурирует. Некому будет передавать выполнение...
правильно я рассуждаю?
Понятно.
Но в любом случае все крутиться вокруг CLR - он как бы управляет всем, соответствено если CLR не будет, то не будет работать даже если там повсюду pragma unmanaged фигурирует. Некому будет передавать выполнение...
правильно я рассуждаю?
klau
Очень даже правильно.
Очень даже правильно
.Ребят, а в 2х словах: что такое .Net (и где об этом почитать)?
Я глупый наверное вопрос задам, но все-таки:раз С++ компилится в промежуточный код если стоит соотв галка в компиляторе, то за каким надо ставить эту галку и писать под .NET на C++? Вся фишка С++ в том что откомпиленная прога будет быстрой, если же компилить его в промежуточный код, то этот бонус теряется. То же и с хваленой "гибкостью" все что с ее помощью будет выигрываться , тут же будет теряться за счет более сложной работы в тех местах где идет взаимодействие с платформой (полагаю C# под это лучше заточен)... Так?
И сразу еще один вопрос можно ли написать кусок критичный к скорости выполненя на С++, откомпилить его под win32 получить dll, саму прогу всю написать под .NET и в ней эту dll использовать.
Сейчас пишу на BCB думаю переходить на NET, но еще ее даже не поставил, так что просьба особо не гнобить, а пояснить где и почему я не прав(если не прав)
И сразу еще один вопрос можно ли написать кусок критичный к скорости выполненя на С++, откомпилить его под win32 получить dll, саму прогу всю написать под .NET и в ней эту dll использовать.
Сейчас пишу на BCB думаю переходить на NET, но еще ее даже не поставил, так что просьба особо не гнобить, а пояснить где и почему я не прав(если не прав)
knst
Цитата:
В архитектуре .NET - все компилится в промежуточный код, который непосредственно при исполнении "компилится" в реальный код и исполняется.
Т.е. отличие от стандартного VB, который интерпретирует код, здесь идет как бы двухпроходная компиляция.
Это, кстати, не зависимо от языка программирования (C++, C#, VB.NET, J.NET и т.д.)
Вообще, преимущество .NET - это громадный фреймворк с библиотеками и классами. Разработчику необходимо гораздо меньше времени для разработки продукта, чем, скажем, на стандартном VC++ 6.0.
Базовые это - Windows Forms - Библиотеки стандартных визуальных компонентов, Web Services - мощный SOAP-подобный протокол вызова удаленных процедур, связь с XML, которая позволяет написать распределенное решение за несколько часов и т.д.
Цитата:
С++ компилится в промежуточный код
В архитектуре .NET - все компилится в промежуточный код, который непосредственно при исполнении "компилится" в реальный код и исполняется.
Т.е. отличие от стандартного VB, который интерпретирует код, здесь идет как бы двухпроходная компиляция.
Это, кстати, не зависимо от языка программирования (C++, C#, VB.NET, J.NET и т.д.)
Вообще, преимущество .NET - это громадный фреймворк с библиотеками и классами. Разработчику необходимо гораздо меньше времени для разработки продукта, чем, скажем, на стандартном VC++ 6.0.
Базовые это - Windows Forms - Библиотеки стандартных визуальных компонентов, Web Services - мощный SOAP-подобный протокол вызова удаленных процедур, связь с XML, которая позволяет написать распределенное решение за несколько часов и т.д.
Цитата:
архитектуре .NET - все компилится в промежуточный код, который непосредственно при исполнении "компилится" в реальный код и исполняется.
об этом и речь, такой подход очевидно ведет к поере в скорости. В 90% случаев никто этого не заметит, а вот в оставшихся 10%, такая потеря крайне нежелательна. Можно ли написать эти 10% на обычном С++?
knst
Ну вообще здесь дело не только в галке, которая якобы генерит код то такой, то сякой. Ты не сможешь просто написать на С++ некоторые специфичные для Win32 вещи, и откомпилировать их под .NET. Под .NET в С++ внесены некоторые модификации (расширения), которые позволяют использовать преимущества новой платформы, как то сборшк мусора, например и др. Они и язык теперь называют MC++ (Managed C++). В MC++ можно включать блоки не Managed-кода, в котором, например как раз есть прямой доступ к памяти и нет ограничений .NET по доступу к ней.
Не смотря на то что MS декларирует C# как самый лучший и исчерпывающий язык для .NET, сами программисты MS признают, что добиться самой эффективной, исключительной и полной реализации всех возможностей .NET можно только на MC++.
Если тебя волнует вопрос перехода с BCB на VS для программирования на С++, то смело переходи, писать чисто Native Win32 приложения там тоже можно, и вызывать такие dll из .NET приложений тоже.
Другое дело, что со временем необходимость и желание цепляться за Win32 всё равно скоро отомрёт с развитием Windows и неумолимым ростом производительности компов.
Ну вообще здесь дело не только в галке, которая якобы генерит код то такой, то сякой. Ты не сможешь просто написать на С++ некоторые специфичные для Win32 вещи, и откомпилировать их под .NET. Под .NET в С++ внесены некоторые модификации (расширения), которые позволяют использовать преимущества новой платформы, как то сборшк мусора, например и др. Они и язык теперь называют MC++ (Managed C++). В MC++ можно включать блоки не Managed-кода, в котором, например как раз есть прямой доступ к памяти и нет ограничений .NET по доступу к ней.
Не смотря на то что MS декларирует C# как самый лучший и исчерпывающий язык для .NET, сами программисты MS признают, что добиться самой эффективной, исключительной и полной реализации всех возможностей .NET можно только на MC++.
Если тебя волнует вопрос перехода с BCB на VS для программирования на С++, то смело переходи, писать чисто Native Win32 приложения там тоже можно, и вызывать такие dll из .NET приложений тоже.
Другое дело, что со временем необходимость и желание цепляться за Win32 всё равно скоро отомрёт с развитием Windows и неумолимым ростом производительности компов.
EZH
мысль понял, но за державу обидно... Опять нас поганый wintel дурит...
а по поводу
Цитата:
мысль понял, но за державу обидно... Опять нас поганый wintel дурит...
а по поводу
Цитата:
необходимость и желание цепляться за Win32 всё равно скоро отомрёт.... ну не знаю, думаю все-равно никто не будет писать на NET сложную математику. И дело не win32 , его то как раз не жалко, просто тебя послушать получается, что со временем С++ перейдет на позиции асемблера (мол "круто но ну его нафиг"). Опять MS костылей понаделал, ну не дает им покоя успех Java
knst
Цитата:
Да я думаю тебе и не придется её самому писать. Я уверен что много базовой, но в то же время сложной математики будет реализованно на низком уровне, очень оптимизированно, и предоставлено программерам в качестве библиотек. Тебе останется только оперировать этими функциями по нужному тебе алгоритму, фактически не теряя производительности. Как пример, возьми просто DirectX. Никто же не собирается переписывать его на .NET - он просто дан тебе для пользования, и доступен в том числе из .NET...
Цитата:
Хоть убей не пойму где ты это увидел в моем посте. С++ как рулил, так и будет рулить в будущем. Просто тут он развивается в рамках новых концепций программирования - виртуальных машин, что очень даже хорошо. И MS тут не причем, Java тоже ведь на этом успешно выросла, многие языки идут к этому, это эволюция концепции программирования.
Да и native C++ не умрет тоже. GCC ведь никто не забрасывает, наоборот - это чуть ли не единственный компилятор, поддерживающий полные стандарты С++. И он тоже развивается, причем как на *nix платформе, так и на win.
Просто каждый программер в определенный момент определяется чем он хочет зарабатывать себе на хлеб - системным или прикладным программированием. Отсюда и выбор языка и платформы под него. Хотя можно одним заниматься для работы, а другим для души. Программеры ведь народ такой...
Цитата:
думаю все-равно никто не будет писать на NET сложную математику
Да я думаю тебе и не придется её самому писать. Я уверен что много базовой, но в то же время сложной математики будет реализованно на низком уровне, очень оптимизированно, и предоставлено программерам в качестве библиотек. Тебе останется только оперировать этими функциями по нужному тебе алгоритму, фактически не теряя производительности. Как пример, возьми просто DirectX. Никто же не собирается переписывать его на .NET - он просто дан тебе для пользования, и доступен в том числе из .NET...
Цитата:
просто тебя послушать получается, что со временем С++ перейдет на позиции асемблера (мол "круто но ну его нафиг")
Хоть убей не пойму где ты это увидел в моем посте. С++ как рулил, так и будет рулить в будущем. Просто тут он развивается в рамках новых концепций программирования - виртуальных машин, что очень даже хорошо. И MS тут не причем, Java тоже ведь на этом успешно выросла, многие языки идут к этому, это эволюция концепции программирования.
Да и native C++ не умрет тоже. GCC ведь никто не забрасывает, наоборот - это чуть ли не единственный компилятор, поддерживающий полные стандарты С++. И он тоже развивается, причем как на *nix платформе, так и на win.
Просто каждый программер в определенный момент определяется чем он хочет зарабатывать себе на хлеб - системным или прикладным программированием. Отсюда и выбор языка и платформы под него. Хотя можно одним заниматься для работы, а другим для души. Программеры ведь народ такой...
EZH
Цитата:
Тут надо определиться: хотим ли мы писать код с использованием .NET Framework или просто хотим писать C++ прогу используя Visual Studio 7.0(7.x) IDE
Если мы просто создаем приложение на стандартной C++ (ну, возможно с использованием Win32/MFC), но не юзаем .NET Framework - глубоко пожалуйста. Сами компилим и работаем с проектами, написанными на Visual C++ 6.0. В IDE появилось несколько прикольных штучек - вот нам и понравилось. Плюс расширенный MFC (чуть более стандартных классов).
Конечно, некоторые вещи надо немного поменять (например MFC-шный CString немного изменен). Но все остальное - да пожалуйста. Не юзаешь MC++ - все чудесно.
Другой штук - это если ты хочешь написать прогу на C++ с использованием Windows Forms, ADO.NET, Web Services и т.д.
Вот тогда - да, никуда ты не денешься без установки .NET Framework на клиентской машине, CLR (промежуточного кода) и т.д.
Цитата:
Ты не сможешь просто написать на С++ некоторые специфичные для Win32 вещи
Тут надо определиться: хотим ли мы писать код с использованием .NET Framework или просто хотим писать C++ прогу используя Visual Studio 7.0(7.x) IDE
Если мы просто создаем приложение на стандартной C++ (ну, возможно с использованием Win32/MFC), но не юзаем .NET Framework - глубоко пожалуйста. Сами компилим и работаем с проектами, написанными на Visual C++ 6.0. В IDE появилось несколько прикольных штучек - вот нам и понравилось. Плюс расширенный MFC (чуть более стандартных классов).
Конечно, некоторые вещи надо немного поменять (например MFC-шный CString немного изменен). Но все остальное - да пожалуйста. Не юзаешь MC++ - все чудесно.
Другой штук - это если ты хочешь написать прогу на C++ с использованием Windows Forms, ADO.NET, Web Services и т.д.
Вот тогда - да, никуда ты не денешься без установки .NET Framework на клиентской машине, CLR (промежуточного кода) и т.д.
Предыдущая тема: Как с конвертировать в Delphi?
Форум Ru-Board.club — поднят 15-09-2016 числа. Цель - сохранить наследие старого Ru-Board, истории становления российского интернета. Сделано для людей.