Здравствуйте Михаил, Вы писали:
М>Здравствуйте Odi$$ey, Вы писали:
[...]
М>Заметим, что M$ вовсю рвется на рынок вторичного софта. М>А это значит, что под всякими "благовидными" предлогами будет и дальше М>постоянно ставить палки в колеса конкурентам. М>В том числе и разработчикам на VC.
~~
Эт-точно. (c) С чего бы это они MSVC7 до стандарта не стали дотягивать?
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте Бадян, Вы писали:
Б>Здравствуйте уважаемые господа.
Б>Прошу простить за офтопик, но где еще спросить если не здесь? Б>Я тут для собственных нужд затеял разработку библиотеки компонентов (только WinAPI). Б>Конешно не все сразу. Для начала CMyStatusBar. Смысл то в том, что в результате удобства будет не меньше чем у VCL (как насчет MFC не знаю, ибо не знаю я ее), а размер проги будет измеряться десятками килобайт а не сотнями или тысячами, как это щас принято, почему-то.
Б>Господа, не смейтесь, ибо это не смешно. Судите сами VCL, MFC, ATL/WTL утвердили стандарт на огромнейшие приложения. Тогда как на API минимальная прога весит чуть более килобайта. А достаточно функционально наполненная может уместиться и в 20К.
Б>Или не парить себе (и Вам) мозги и писать на VCL (забить на старый-добрый VisualC++), перейти на Delpi/C++Builder?
На VC++ действительно, ИМХО, стоит забить. Но только в силу его бесконечных отклонений от стандарта и "Microsoft Specific". :) А отсюда — невозможности накрутить приличную структуру шаблонов. Может, и правда лучше использовать BC++? Но только как компилятор.
Б>Ассемблерщик я, ассемблерщик…
ИМХО, — правильная затея. По крайней мере, хоть частично избавишься от зависимости от закидонов маркетинговых войн гигантов.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте Геннадий Васильев, Вы писали:
ГВ>На VC++ действительно, ИМХО, стоит забить. Но только в силу его бесконечных отклонений от стандарта и "Microsoft Specific". А отсюда — невозможности накрутить приличную структуру шаблонов. Может, и правда лучше использовать BC++? Но только как компилятор.
Вот не стал бы я так категорично... Недавние тесты (VC7 vc BCB6) показывают:
1. поддержка стандарта в bcb немногим лучше (или немногим хуже), чем в VC
2. оптимизация много хуже
3. linker в bcb — вообще убивал бы... а другие использовать не получается, формат кажется proprietary (последнее — еще в стадии разборок, так что утверждение спорно-некатегоричное)
примеры:
№1 BCB ругается на "template<>" при специализации члена шаблона вне класса. Т.е. при специализации класса
template<>
class C<some_templ_param> {...}
всё окей, а вот такое не проканывает:
template<>
void C<some_templ_param>::f() {...}
№2. как часть одного проекта, понадобился высокоэффективный битовый поток, без лишних копирований информации.
одни и тот же код, на VC7 работал в 1.5 раза быстрее чем на BCB. Кстати, на VC6 тот же код работал еще быстрее чем на VC7
№3. есть подозрение на плохое выкидывание неиспользуемых секций/модулей, разбираемся дальше.
А стандарт — вещь конечно правильная, но... Есть потребность в портабельности библиотек на Windows CE. Так вот, в версиях компиляторов для девайсов до Windows CE 3.0 (PocketPC) включительно нет даже exceptions! Они появились только в CE.NET
А ведь так хочется частичной специализации и прочих вкусностей... Это, конечно, снова камень в сторону MS...
Эхх, нет в жизни счастья
Здравствуйте orangy, Вы писали:
O>А стандарт — вещь конечно правильная, но... Есть потребность в портабельности библиотек на Windows CE. Так вот, в версиях компиляторов для девайсов до Windows CE 3.0 (PocketPC) включительно нет даже exceptions! Они появились только в CE.NET O>А ведь так хочется частичной специализации и прочих вкусностей... Это, конечно, снова камень в сторону MS... O>Эхх, нет в жизни счастья
Здравствуйте AndrewVK, Вы писали:
O>>А стандарт — вещь конечно правильная, но... Есть потребность в портабельности библиотек на Windows CE. Так вот, в версиях компиляторов для девайсов до Windows CE 3.0 (PocketPC) включительно нет даже exceptions! Они появились только в CE.NET O>>А ведь так хочется частичной специализации и прочих вкусностей... Это, конечно, снова камень в сторону MS... O>>Эхх, нет в жизни счастья
AVK>Переходите на .NET
А вы мне перекуете все девайсы в мире на CE.NET, чтобы я больше не мучался?
Это был я
А>А вы мне перекуете все девайсы в мире на CE.NET, чтобы я больше не мучался?
И перепишете всё, что уже есть (~500KLOC) с С++ на С#?
И даже гарантируете приемлимую скорость работы? Учтите, на девайсах не P4 2ГГц, а в лучшем случае ARM 206Mhz (скоро полезут XScale, но до этого еще дожить надо)
Эхх, всё бы вам категорично заявлять, быстренько апгрейдиться, не поняв еще, надо ли оно вам, привыкнуть, а потом с пеной у рта спорить о крутости... Нет, я не утверждаю, что .NET дрянь, а С++ рулез. Просто есть у меня одно мааааленькое подозрение... Когда у штурвала оказывается MS, у меня появляется бооольшое сомнение в стабильности и логической завершенности того, что будет через несколько лет. Прикрутим сбоку ручку — будет .ORG, перекуем ассембли на junction или mount-points (в тезаурус посмотрел — получим .BIZ, специально для бизнесменов. И получим то же самое, что сейчас с объектной моделью например Office, когда приблуда для Office 97 нифига не работает в Office 2000.
Ладно, можете не отвечать, я всё равно не люблю подобных споров, просто категоричные заявления типа "Пользуй .НЕТ" мне напоминают старый анекдот "Ты туда нэ ходы. Там ограбят, раздэнут, убьют... И туда тоже нэ ходы, там тоже ограбят, раздэнут, убьют... А что делать-то? А ты здэс раздэвайся!"
Если вы любите колбасу и политику, то вам лучше не знать, как делают и то и другое (с)
Здравствуйте orangy, Вы писали:
O>И перепишете всё, что уже есть (~500KLOC) с С++ на С#?
Зачем? MC++ никто не отменял.
O>И даже гарантируете приемлимую скорость работы? Учтите, на девайсах не P4 2ГГц, а в лучшем случае ARM 206Mhz (скоро полезут XScale, но до этого еще дожить надо)
По поводу скорости почитай статейку здесь.
O>Ладно, можете не отвечать, я всё равно не люблю подобных споров, просто атегоричные заявления типа "Пользуй .НЕТ"
Это не категоричные заявления. Просто совет.
Здравствуйте AndrewVK, Вы писали:
AVK>Здравствуйте orangy, Вы писали:
O>>И перепишете всё, что уже есть (~500KLOC) с С++ на С#? AVK>Зачем? MC++ никто не отменял.
Ну и что? Сами по себе исходники под него не портируются.
O>>Ладно, можете не отвечать, я всё равно не люблю подобных споров, просто атегоричные заявления типа "Пользуй .НЕТ" AVK>Это не категоричные заявления. Просто совет.
Этот совет, увы, хорош только для новых проектов и только для определенного круга задач.
Re: Есть ли смысл в библ. компонентов на чистом API?
Здравствуйте Бадян, Вы писали:
Б>Здравствуйте уважаемые господа.
Б>Прошу простить за офтопик, но где еще спросить если не здесь? Б>Я тут для собственных нужд затеял разработку библиотеки компонентов (только WinAPI). Б>Конешно не все сразу. Для начала CMyStatusBar. Смысл то в том, что в результате удобства будет не меньше чем у VCL (как насчет MFC не знаю, ибо не знаю я ее), а размер проги будет измеряться десятками килобайт а не сотнями или тысячами, как это щас принято, почему-то.
Б>Господа, не смейтесь, ибо это не смешно. Судите сами VCL, MFC, ATL/WTL утвердили стандарт на огромнейшие приложения. Тогда как на API минимальная прога весит чуть более килобайта. А достаточно функционально наполненная может уместиться и в 20К.
Я смысла в этом не вижу. Насколько я знаю, основная задача MFC — облегчить создание UI. По-моему, эта задача выполнена. Зачем изобретать велосипед? MFC писал не один человек и не один год. Код достаточно качественен и документации море. Я сомневаюсь, что кто-то может так вот сесть и создать что-то намного лучшее.
Здравствуйте Lexey, Вы писали:
AVK>>Зачем? MC++ никто не отменял. L>Ну и что? Сами по себе исходники под него не портируются.
Что значит сами по себе не портируются?
AVK>>Это не категоричные заявления. Просто совет. L>Этот совет, увы, хорош только для новых проектов и только для определенного круга задач.
Это смотря какой у вас проект. Иногда проще переписать бывает. Преимуществ дотнет дает прилично.
Здравствуйте AndrewVK, Вы писали:
AVK>Здравствуйте Lexey, Вы писали:
AVK>>>Зачем? MC++ никто не отменял. L>>Ну и что? Сами по себе исходники под него не портируются. AVK>Что значит сами по себе не портируются?
Вот то и значит. Как ты себе представляешь автоматическое портирование C++ кода на MC++?
AVK>>>Это не категоричные заявления. Просто совет. L>>Этот совет, увы, хорош только для новых проектов и только для определенного круга задач.
AVK>Это смотря какой у вас проект. Иногда проще переписать бывает. Преимуществ дотнет дает прилично.
Я оперировал теми цифрами, которые приводил orangy. Портировать или переписывать 500k исходников — это самоубийство и никаких преимуществ тут не хватит. Заметим, что и недостатков у dotnet тоже прилично.
Здравствуйте Lexey, Вы писали:
L>Вот то и значит. Как ты себе представляешь автоматическое портирование C++ кода на MC++?
Никак. Код компилирующийся на VC6 будет компилироваться на MC++.
AVK>>Это смотря какой у вас проект. Иногда проще переписать бывает. Преимуществ дотнет дает прилично.
L>Я оперировал теми цифрами, которые приводил orangy. Портировать или переписывать 500k исходников — это самоубийство и никаких преимуществ тут не хватит.
Не надо ничего переписывать. Все и так компилируется. Вон Влад в дотнетовском контроле ATL использовал и ничего, работает.
L> Заметим, что и недостатков у dotnet тоже прилично.
Ну так надо прикинуть что перевешивает.
Здравствуйте AndrewVK, Вы писали:
AVK>Здравствуйте Lexey, Вы писали:
L>>Вот то и значит. Как ты себе представляешь автоматическое портирование C++ кода на MC++? AVK>Никак. Код компилирующийся на VC6 будет компилироваться на MC++.
Ты явно путаешь VC7 и Managed Extensions for VC7. MC++ — это как раз C++ с managed-расширениями. VC7 будет компилировать большую часть кода без VC6 просто так, но управляемым код от этого никак не станет.
AVK>>>Это смотря какой у вас проект. Иногда проще переписать бывает. Преимуществ дотнет дает прилично.
L>>Я оперировал теми цифрами, которые приводил orangy. Портировать или переписывать 500k исходников — это самоубийство и никаких преимуществ тут не хватит. AVK>Не надо ничего переписывать. Все и так компилируется. Вон Влад в дотнетовском контроле ATL использовал и ничего, работает.
Влад писал свой контрол специально под managed-расширения. Могу еще раз повторить — сам компилятор за тебя не будет портировать unmanaged код в managed. Все портируемые классы нужно явно описывать как managed, а если старый класс у тебя использовал множественное наследование, то про перевод его в managed можешь спокойно забыть.
L>> Заметим, что и недостатков у dotnet тоже прилично. AVK>Ну так надо прикинуть что перевешивает.
Здравствуйте Lexey, Вы писали:
L> Ты явно путаешь VC7 и Managed Extensions for VC7.
Не, не путаю.
L>MC++ — это как раз C++ с managed-расширениями. VC7 будет компилировать большую часть кода без VC6 просто так, но управляемым код от этого никак не станет.
Где я писал про управляемый код? Вполне достаточно MSIL кода.
L>Влад писал свой контрол специально под managed-расширения. Могу еще раз повторить — сам компилятор за тебя не будет портировать unmanaged код в managed.
Ты что то путаешся. Unmanaged код даже на шарпе можно написать. В данном же случае нужен код под MSIL. L>Все портируемые классы нужно явно описывать как managed,
Не нужно.
Здравствуйте AndrewVK, Вы писали:
AVK>Здравствуйте Lexey, Вы писали:
L>> Ты явно путаешь VC7 и Managed Extensions for VC7. AVK>Не, не путаю.
Значит мы друг друга не понимаем. Для меня MC++ — это именно managed-расширения, а для тебя выходит только компиляция в MSIL.
L>>MC++ — это как раз C++ с managed-расширениями. VC7 будет компилировать большую часть кода без VC6 просто так, но управляемым код от этого никак не станет. AVK>Где я писал про управляемый код? Вполне достаточно MSIL кода.
Ради чего? Ради MSIL-кода? С тем же успехом можно вызывать обычные unmanaged-функции.
L>>Влад писал свой контрол специально под managed-расширения. Могу еще раз повторить — сам компилятор за тебя не будет портировать unmanaged код в managed. AVK>Ты что то путаешся. Unmanaged код даже на шарпе можно написать. В данном же случае нужен
Это я знаю. И что?
>код под MSIL.
Зачем тебе код в MSIL если он все равно не будет использовать возможностей среды, а будет создавать только лишний overhead? Да и даже с простой компиляцией кода в MSIL еще придется потрахаться.
L>>Все портируемые классы нужно явно описывать как managed, AVK>Не нужно.
Здравствуйте Lexey, Вы писали:
L>Значит мы друг друга не понимаем. Для меня MC++ — это именно managed-расширения, а для тебя выходит только компиляция в MSIL.
Не, давай вернемся к началу. Ты сказал что для тебя дотнет неприемлем потому что надо переписывать исходники. Я сказал что переписывать не надою Где я говорил что нужен именно managed код?
AVK>>Где я писал про управляемый код? Вполне достаточно MSIL кода.
L>Ради чего? Ради MSIL-кода?
Ради того чтобы перейти на дотнет.
L> С тем же успехом можно вызывать обычные unmanaged-функции.
Не с таким же, на интеропе много потеряешь.
AVK>>Ты что то путаешся. Unmanaged код даже на шарпе можно написать. В данном же случае нужен L>Это я знаю. И что?
Какое имеет отношение к возможности работы под дотнетом?
L>Зачем тебе код в MSIL если он все равно не будет использовать возможностей среды, а будет создавать только лишний overhead?
В новых кусках можно будет возможности среды использовать. И потихоньку переписывать старый код. Ты же страдал что эксепшенов нет.
Здравствуйте MaximE, Вы писали:
ME>Я смысла в этом не вижу. Насколько я знаю, основная задача MFC — облегчить создание UI. По-моему, эта задача выполнена. Зачем изобретать велосипед? MFC писал не один человек и не один год. Код достаточно качественен и документации море. Я сомневаюсь, что кто-то может так вот сесть и создать что-то намного лучшее.
ME>P.S. И написана MFC тоже на чистом API
Единственный трезвый человек. И никто ничт о не сможет возразить
P.S. (bcgjkmpetvst==используемые)
Crescite, nos qui vivimus, multiplicamini
Re[3]: Есть ли смысл в библ. компонентов на чистом API?
Здравствуйте OLEGus1, Вы писали:
ME>>Я смысла в этом не вижу. Насколько я знаю, основная задача MFC — облегчить создание UI. По-моему, эта задача выполнена. Зачем изобретать велосипед? MFC писал не один человек и не один год. Код достаточно качественен и документации море. Я сомневаюсь, что кто-то может так вот сесть и создать что-то намного лучшее.
ME>>P.S. И написана MFC тоже на чистом API
OLE>Единственный трезвый человек. И никто ничт о не сможет возразить OLE>P.S. (bcgjkmpetvst==используемые)
Гм. Я могу возразить. Как раз потому, что MFC писали не один год, она не отличается стройностью и быстродействием. Очень много завязок на старый 16-разрядный код (CAsyncSocket тому пример). Начали-то ее разрабатывать еще под Win3.0 (если мне склероз не изменяет).
А реализовать что-то нестандартное, не укладывающееся в Doc-View? А? Пробовали? Удовольствие еще то.
Поэтому писать свою либу стОит. Неплохо позаимствовать некоторые идеи из того-же WTL'а. Но реализовать именно библиотеку, а не набор шаблонов. Тогда использовать ее для больших проектов будет одно удовольствие.
_____________________
С уважением,
Stanislav V. Zudin
Re[4]: Есть ли смысл в библ. компонентов на чистом API?
Здравствуйте Stanislav V. Zudin, Вы писали:
SVZ>Поэтому писать свою либу стОит. Неплохо позаимствовать некоторые идеи из того-же WTL'а. Но реализовать именно библиотеку, а не набор шаблонов. Тогда использовать ее для больших проектов будет одно удовольствие.
А вот спорим что ты такую либу не напишешь?
А отсюда — невозможности накрутить приличную структуру шаблонов. Может, и правда лучше использовать BC++? Но только как компилятор.
Они появились только в CE.NET
Ты явно путаешь VC7 и Managed Extensions for VC7. MC++ — это как раз C++ с managed-расширениями. VC7 будет компилировать большую часть кода без VC6 просто так, но управляемым код от этого никак не станет.
