Подскажите, что лучше учить:
MFC или NET. FrameWork


или желательно учить и то, и то

Это сообщение отредактировал(а) OlegM - 25.12.2005, 15:20

лучше научиться пользоваться поиском, гуглом и научиться самому искать ответы на свои вопросы а также правильно эти вопросы задавать. Во.

А что здесь неправильного

И кстати я гугле не нашол

Это сообщение отредактировал(а) OlegM - 25.12.2005, 15:30

Почитай статью, на которую я тебе ссылку давал. Пойми.. .NET -- это другая платформа, нежели MFC, построенный на COM. Вопрос сродни "Что удобней: щетка или пылесос?".

ты мне как то написал что для VS 2005 надо надо учить С# или С++ но а что дальше?



Ну а для чего тогда ж MFC, и почему ты говориш что ее не надо учить, для VS?



И если я чего то не понемаю, то не злись, объясни надо ли учить и MFS и NET.FrameWork или что то одно или NET.FrameWork вообще не учится, а только испольузется?



А также хочу сказать что я неплохо знаю С++, и не очень то хочу учить С#, но если ето действительно надо

(ДА СКАЖИ МНЕ ВСЕ-ТАКИ ЧТО ЛУЧШЕ: MFS ИЛИ .NET FARMEWORK, ЧТО БОЛЬШЕ УПОТРЕБЛЯЕТСЯ)

Строго говоря, сам Мелкософт уже начал отказываться от MFC (язык C++). Так что учи .NET (языки C++, VB.NET, C#, J# и др.) (кроме того, с нуля проще он учится). Хотя, это лично мое мнение.

Ну знаю я С++, и допустим выучу С#, ну а что дальше (по направлению в Visual Studio 2005)
Но STL хоть еще надо иле тоже нет
Добавлено @ 20:11
То Framework надо учить, или просто уметь использовать

Ладно...
Жил-был мелкософт. Придумал он такую штуку: Visual C++ для визуального программирования. И прикрутил он к ней библиотеку MFC. Шли времена... Люди замечали, что MFC -- не очень удобная вещь. И с ООП в ней не слишком, да и поднадоела.. Кто перешел на альтернативные библиотеки (например, Qt), кто вообще на Java. Поняла MS, что дело плохо. И в ответ Java придумала дотNET. Прикрутила к нему громадную библиотеку .NET Framework, а во главе поставила язык C#. А студию новую назвала VS 2003.

Цитата

То Framework надо учить, или просто уметь использовать

А на велосипеде надо ездить или только педали крутить??

OlegM MFC советую не трогать. NET трогать не советую.

Цитата

Ну знаю я С++, и допустим выучу С#, ну а что дальше (по направлению в Visual Studio 2005) Ну STL хоть еще надо иле тоже нет

Это сообщение отредактировал(а) OlegM - 26.12.2005, 10:57

Для изучения .NET необходимо знать C#, принципы работы CLR и уметь пользовать .NET Framework. Ни хрена никаких STL/ATL/блаблабла не надо. Меня интересует, как это можно "изучать Visual Studio"... Что ты в нем собираешься делать? P.S. Perchilla, от выкриков можно воздержаться. Имхо, вопрос исчерпан. Да и поставлен некорректно. Просто мальчик на лотке увидел VS 2005 и решил, что это круто... И 4 темы создавать не обязательно. СУВ

Цитата(Run @ 26.12.2005, 11:45)

Perchilla, от выкриков можно воздержаться

Никак не пойму, какие претензии ты мне хочешь предъявить? Тут никто не выкрикивает, а высказывает свое мнение, так же как и ты по поводу "Жил был дядя Билли, написал он MFC, но вдруг откуда ни возьмись появилася QT, и тогда наш дядя Билли написал нет фреймворк".

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

Цитата(S @ 26.12.2005, 07:45)

OlegM MFC советую не трогать. NET трогать не советую.

OlegM, MFC советую не трогать. А кроме .NET трогать больше и нечего, ответ очевиден.

Цитата(mr @ 2.1.2006, 19:37)

А кроме .NET трогать больше и нечего, ответ очевиден.

Java, кроссплатформенные библиотеки для С++...

Цитата(DeadSoul @ 2.1.2006, 18:51)

Java, кроссплатформенные библиотеки для С++...

Не понимаю, ну нафига кроссплатформенность Windows-программеру? Спрашивали-то про MFC и .NET, какая тут может быть Java ?

На скольки проценатах машин стоит .NET framework? Если цель - писать маленькие приложения, которые удобно распространять по интернету, то лучше MFC не найти. По крайней мере до тех пор, пока фрейморк не будет интегрирован в систему. Сколько процентов пользователей слышали про него? Сколько процентов из них, скачав прогамму и узнав, что без многометрового фреймоворка она не пойдет, будут качать и его? Например, местный "охотник" я не качаю только из-за того, что не хочется мудиться с сановской машиной. Будь он обычным вин приложением, наверное, многие его бы только и использовали.
К тому же надо учесть, что пользователи с большим недоверием относятся ко всему новому, и даже если вы впихнете машинку в архив с программой, и юзер согласиться этакую махину скачать, не факт, что он рискнет ее установить.

MFC был в прошлом. NET ориентирован на будущее, на Висту. .NET предназначен для создания в первую очередь корпоративных приложений. Я думаю, что если проект серьезный, ты его будешь сдавать заказчику вживую, не через интернет. Приложения, написанные для .NET/Java легче поддерживаются. Библиотеки этих платформ приучают к хорошему стилю ООП, в отличие от местами абсолютно нелогичного MFC.
Кстати, если вы следили за темами, которые насоздавал этот товарисчь, он хочет работать в VS 2005. Так что нужен ему .NET.

Exception, разве я говорил про корпоративные приложения? Здесь рулит j2ee имхо...

Откуда такое мнение?

1. Технология кросплатформенна - имеющиеся апликейшн серверы поддерживают как минимум 2 оси. Линуксовых серверов становится все больше и больше, зачастую бывает так, что у клиента половина серверов по одной осью, половина -под другой.

2. Не в пример лучшая поддержка разработчика у Sun. Есть куча серверов приложений, среди них много бесплатных (хотя в принципе это и не преимущество, т к для .net апликейшн сервер и не нужен).
Наличие бесплатных средств разработки на Java. Eclipse по потенциальным возможностям превосходит студию, к тому же несравненно более удобен и бесплатен. Большое количество готовых решений именно для приложений б. д.

Что может предоставить взамен .NET? Да только лишь хренову тучу языков разработки, большую часть из которых мало кто знает. Ну и в принципе не нужно мудиться с серверами приложений, но это опять таки не преимущество, поскольку есть бесплатные решения. Более высокую скорость работы .net программ можно и не брать в расчет - разница - копейки, все равно сервера б д будут вешаться на запросах к СУБД. Так что преимущество в скорости практически незаметна будет.

1. Задолбало, честно говоря, эти линки постить )
http://httpd.apache.org/cli
http://go-mono.org
.NET не только для Win & IIS.
2. Есть такие вещи, как WebMatrix (бесплатная студия для ASP.NET, поддерживается М$), SharpDevelop. Ну и всякие Express Editions.
"большое количество готовых решений" - поясни. Для .NET есть прекрасная библиотека Enterprise Library.
3. У Microsoft просто больше денег. Это факт. Сравни, сколько на рынке Java, и сколько .NET. И за это время он догнал (если не перегнал) яву.
Все имхо.

Хм. интересно и немного странно, что M$ позволяет щупать ручками свою технологию и при этом не пищит на весь мир. Я никогда не занимался .NET, но даже я не мог бы не слышать про столь мощное средство придания кросплатформенности, будь оно распространено. Поэтому тут есть вопросы, не сырой ли это проект и вообще насколько можно доверять. Что касается j2ee, тут все проверено временем и надежно.

Цитата(Exception @ 8.1.2006, 03:58 )

У Microsoft просто больше денег. Это факт. Сравни, сколько на рынке Java, и сколько .NET. И за это время он догнал (если не перегнал) яву.

Не догнал, количество гоотовых решений на .NET и Java не сравнить.
А по поводу денег, Java поддерживает не только Sun, туда вложили кучу денег IBM и Oracle, которые на рынке корпоративных приложений дольше MS.

P.S. А вообще это офтоп, вопрос был не про корпоративные приложения, а про десктоп.

Цитата(Амортизатор @ 8.1.2006, 04:33 )

интересно и немного странно, что M$ позволяет щупать ручками свою технологию и при этом не пищит на весь мир. Я никогда не занимался .NET, но даже я не мог бы не слышать про столь мощное средство придания кросплатформенности, будь оно распространено. Поэтому тут есть вопросы, не сырой ли это проект и вообще насколько можно доверять.

Ещё какой сырой - уж сколько лет его разрабатывают (хотя версия уже 0,9 - могёт скоро и увидим этот хлам). Главное смысла в нём не на грош - никто из никсовых программистов в здравом уме не будет использовать платформу дотнет, поскольку рано или поздно мелкомягкие потребуют отчисления за использование их технологий, либо будут вставлять палки в колёса используя недокументируемые закладки в виндовой вариации фрамеворка. Такова майкрософт и тут уж ничего не изменишь.
Если по теме, то я не думаю, что с приходом дотнета об MFC можно забыть. Припомните сколько лет мелкомягкие тащили за собой великий и ужастный ДОС. Столько же лет будет таскаться и традиционная платформа Win32, а значит и все библиотеки будут работать. Так что от безнадёжно кривогой связки WinAPI + MFC программистам не избавится ещё лет 10-15.

А я и не говорю, что связка mono+dotNET надежна. Просто раз уж зашли речи о кросплатформенности... Это уже далеко не главный плюс Java. Подумай сам, какой бред: J2EE+Win )
Просто mono показывает, что кроссплатформенность возможна в .NET. И в этом он не хуже Java.
2 ToshaCh
Мелкомягкие не могут брать денег у mono, dotgnu и других. Видно, ты не слышал о .NET CLI.
Почитай об этом на сайте мелкософта. Они открывают код фрэймворка и компилятора C# для их перевода на другие платформы.

Цитата(Exception @ 8.1.2006, 16:07 )

Видно, ты не слышал о .NET CLI

Я не слышал что они открытые, поэтому поверю тебе на слово. В общем долой офтоп про Яву и дотНет. ОК?

Это сообщение отредактировал(а) ToshaCh - 8.1.2006, 18:08

Цитата(ToshaCh @ 8.1.2006, 19:08 )

ОК?

OK
Да и вообще тему крыть пора (не матом всмысле )

Итак, думаю, все со мной согласятся, совет Олегу должен быть таким:

Определись, в какой именно сфере будешь (сможешь, будет возможность) работать.

1. Если в области разработки корпоративных приложений под виндовскими серверами, и непременно хочется работать в MSVS, то надо выбирать .NET естесвенно. Хотя надо предупредить, что работодателя не будут интересовать твои пристрастия)) Так что возможно придется осваивать еклипс и идею.

2. Кросплатформенные корпоративные приложения - J2EE. С-но учи Java, Eclipse тебе в руки. Конечно можешь взять MS VC и кросплатформенные сишные библиотеки, но нужен тебе геморой в этом возрасте?

3. Для всего остального из того, что предлагает любимая тобой студия годится только MSVC, и вот тут то и лучше остановиться на MFC. Хотя это мое личное мнение, остальные библиотеки тоже заслуживают внимания. Почему тут не стоит связываться с .NET - см. мой пост выше. Кстати, для начала может пойдет легче vcl и билдер, но это уже совсем другая тема.

Цитата(ToshaCh @ 8.1.2006, 14:17 )

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

Мои пять копеек:
Во-первых, где вы были последние 3 года? уже много воды утекло с момента выхода 2.0. Сырым этот продукт я при всём великом желании называть бы не стал;
Во-вторых, никсовые программеры пусть сидят на джаве и с++, их никто не приглашает в мир .NET, сама M$ никак не реагирует на факт существования Mono, наверное им это просто по барабану, а палки не вставляют потому что самим наверное интересно посмотреть, что из этого получится;
В-третьих, повторюсь: ну кому вообще нужна кроссплатформенность? Серьёзные заказчики не работают по принципу "половина серверов на линуксе, половина на Win2003", им важнее стабильность и надёжность приложения, а не универсальность типа "write once run everywhere".

Цитата(mr.DUDA @ 9.1.2006, 09:17 )

В-третьих, повторюсь: ну кому вообще нужна кроссплатформенность? Серьёзные заказчики не работают по принципу "половина серверов на линуксе, половина на Win2003", им важнее стабильность и надёжность приложения, а не универсальность типа "write once run everywhere".

Вот когда к тебе придут и скажут, делай что хочешь, но чтобы твоя программа работала под БелОС, вот тогда и поговорим насчет write once run everywhere. То что ты с этим не сталкивался, еще не значит что это не имеет место быть.

Цитата(LSD @ 9.1.2006, 10:46 )

но чтобы твоя программа работала под БелОС

"тонкий намёк" ?

Цитата(mr.DUDA @ 9.1.2006, 13:13 )

"тонкий намёк" ?

Не знаю как ты это понял, я говорил про ту ОС которую грозился разработать Лукашенко.

Мы вот тоже горя не знали пока не пришли ребята и не сказали, пишите под МСВС. И плевать что под эту зверюгу только древний Qt есть, у нас все должно работать под МСВС и точка. Вот именно тогда мы сильно порадовались что пишем на Java.

Цитата(LSD @ 9.1.2006, 14:18 )

Не знаю как ты это понял, я говорил про ту ОС которую грозился разработать Лукашенко.

Вспоминается великий и ужасный ОС ПРО
mr.DUDA
+1

LSD, лукашинская ОС - чистой воды популизм. В неё даже 1K$ не вложили до сих пор, в этом я имею основания быть уверенным. А вот о разных ОС для одной программы... Здесь вопрос спорный: насколько вздорным и непредсказуемым может быть заказчик. Правильно я понимаю? Просто, в моём личном опыте и опыте моих знакомых программеров (5 независимых компаний в Минске) не встречалось требований по наличию кроссплатформенности в продуктах. Возможно, как ты говоришь, это есть недостаток личного опыта. Но моё имхо таково: пока не стоит конкретная задача создания кроссплатформенного приложения, нет необходимости обязательно предусматривать кроссплатформенность в своих продуктах. Из этого следует простой вывод: в преобладающей части приложений она не является обязательной, а следовательно, является лишь дополнительным плюсом, за который заказчик платит свои деньги.

Резюмирую: в java кроссплатформенность заложена изначально, приложение на java будучи написано однажды, запустится и под win32, и под MacOS, и в любом линуксе. Это несомненно является плюсом. Но минус здесь найти довольно просто: не всякое приложение востребовано на платформе N, т.е. конечный пользователь (customer) всегда один, и требования у него более чем конкретные. Посему, случай, когда к программерам приходит заказчик и говорит: дайте мне приложение под все ОСи и желательно под БелОС тоже, в общей массе случаев довольно редки.

Цитата(mr.DUDA @ 9.1.2006, 21:20 )

Посему, случай, когда к программерам приходит заказчик и говорит: дайте мне приложение под все ОСи и желательно под БелОС тоже, в общей массе случаев довольно редки.

Зато сплошь и рядом случаи, когда требуется приложение под две оси: Win и Lunix

mr.DUDA - а знаешь как такие ОС, разрабатываются? Берется некий Linux, переводится на русский или белорусский или еще какой (переводится по мере возможности все, даже сообщения об ошибках: интерпретатор уже озабочен выполнением другой команды), меняются логотипы, надписи и т.д. Все это дело проходит гос сертификацию. Все мега ОС готова, ее можно даже не развивать.
И никому кроме людей которые это затеяли этот уродец не нужен, но это уже никого не интересует.Это так вопль отчаянья.

Цитата(mr.DUDA @ 9.1.2006, 21:20 )

Резюмирую: в java кроссплатформенность заложена изначально, приложение на java будучи написано однажды, запустится и под win32, и под MacOS, и в любом линуксе. Это несомненно является плюсом. Но минус здесь найти довольно просто: не всякое приложение востребовано на платформе N, т.е. конечный пользователь (customer) всегда один, и требования у него более чем конкретные.

А в чем тут минус, я не пойму? Такой подход порождает некоторые ограничения, это да. И для пользователя в этом нет особых преимуществ, но минуса тут нет.

Цитата(mr.DUDA @ 9.1.2006, 21:20 )

Посему, случай, когда к программерам приходит заказчик и говорит: дайте мне приложение под все ОСи и желательно под БелОС тоже, в общей массе случаев довольно редки.

Вовсе нет. Например та же Java позволяет компилировать приложения в native код, но этим мало кто пользуется почему? Есть разные типы приложений. Есть приложения для конечных пользователей и им переносимость действительно нафиг не нужна (все равно они с Windows не слезут ).
А вот например для серверной части переносимость очень полезна. Сегодня хостимся у одного провайдера, и работаем под Windows платформой, завтра у другого и работаем под Linux. С J2EE проблем не будет, главное чтоб сервер приложений был. А .NET такого переезда не переживет.
Другой пример, есть у нас СУБД Oracle, опять же начинаем с простенького 2-х процессорного сервака на x86 и Windows. Потом организация растет и пора переходить на что-то более серьезное UltraSPARC или Power5 и что тогда? PL/SQL и Java перенесутся спокойно, а вот Си-шные процедуры придется переписывать.

За что иногда хочеться придушить Майкрософт и лично Гейца, так это за отсутствие совместимости между версиями продуктов, в данном случае между первой и второй версией .Net Framework. Из-за этого сейчас не можем полностью переехать на 2-й фреймворк, так как нужно сохранять работспособность наших старых версий и сторонних разработок.

Что ни говори, с Java такой проблемы не возникало и код написанный и скомпилированный под Java 1.1 до сих пор прекрасно работает на Java 1.5, хотя Java существует уже куда дольше чем .Net.

Sun, ты ошибаешься. Ничто не мешает вместе сосуществовать CLR 1.1 и 2.0. А встроенный в VS 2005 Upgrade Wizard прекрасно и без ошибок конвертит старый код.
Добавлено @ 13:27
P.S. Закройте, пожалуйста, тему. Спор опять пришел к Java vs .NET

Цитата

Sun, ты ошибаешься. Ничто не мешает вместе сосуществовать CLR 1.1 и 2.0.

Ага, только нужно указывать под какой фреймворк какую dll и exe запускать Хорошо если у тебя небольшой проект, использующий только твои исполняемые файлы, а если ты используешь сторонние разработки, либо твой код используется сторонними разработчиками - вот тут начинается цирк.

Цитата

А встроенный в VS 2005 Upgrade Wizard прекрасно и без ошибок конвертит старый код.

LOL Может быть проект калькулятора на 20 строк и конвертируется а потом скомпилируется без ошибок.

Вообще-то, в файле app.config пишется, для какого фрэймворка прога. А в рантайме выбирается соответствующий.

Цитата

LOL

Смейся, смейся. Может у тебя есть "опытные данные"? Я конвертил довольно большой проект и были всего 2 ошибки. Исправил за минуту.

Цитата(Exception @ 16.1.2006, 11:42)

Вообще-то, в файле app.config пишется, для какого фрэймворка прога. А в рантайме выбирается соответствующий. Цитата LOL Смейся, смейся. Может у тебя есть "опытные данные"? Я конвертил довольно большой проект и были всего 2 ошибки. Исправил за минуту.

Exception, понятно что все можно настроить и допилить напильником. Но назвать это совестимостью никак нельзя. Совместимасть - это когда код написанный под версию 1.0 будет выполняться и на 1.1 и на 2.0. В итоге чтобы работали все программы для .Net нужно держать на машине все версии фреймворка, тогда как при нормальном человеческом подходе достаточно было-бы только самой последней версии.

может, со временем и у M$ мозги на место встанут (вздыхая)

З.Ы. раньше ведь ещё хуже было, фреймворку всего-то 4 года (сравним с java), болезни детского возраста со временем пройдут... имхо

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

Хм.. А разве в конфиге нельзя указать, что приложение будет работать и с 2.0? Тогда 1.1 и не нужен

Можно, но не факт что будет работать корректно. Как вариант можно дизассемблировать и компилировать под 2.0 фреймворк.

Ну да )
Кстати, кому нужно разрешить вып-ние в CLR 2.0, делайте вот что: создайте файл имяфайла.exe(dll).config и напишите:
.

Exception, простым указанием версии фреймворка можно отделаться не во всех случаях, так как для некоторых функций и классов изменилась сигнатура а некоторые выкинули из соображений безопасности, поэтому придеться вносить изменения в код, хоть и незначительные. Подробнее здесь
http://msdn.microsoft.com/library/default....netfxcompat.asp

Вот это и плохо