Прошу простить за офтопик, но где еще спросить если не здесь?
Я тут для собственных нужд затеял разработку библиотеки компонентов (только WinAPI).
Конешно не все сразу. Для начала CMyStatusBar. Смысл то в том, что в результате удобства будет не меньше чем у VCL (как насчет MFC не знаю, ибо не знаю я ее), а размер проги будет измеряться десятками килобайт а не сотнями или тысячами, как это щас принято, почему-то.
Господа, не смейтесь, ибо это не смешно. Судите сами VCL, MFC, ATL/WTL утвердили стандарт на огромнейшие приложения. Тогда как на API минимальная прога весит чуть более килобайта. А достаточно функционально наполненная может уместиться и в 20К.
Или не парить себе (и Вам) мозги и писать на VCL (забить на старый-добрый VisualC++), перейти на Delpi/C++Builder? А мегатонные приложения паковать каким-нить екзепаком?
Дык, сомневаюсь я, что 500 килобайтовую приблуду можна запаковать в 20К
Тагды посоветуйте хороший паковальщик.
Ассемблерщик я, ассемблерщик…
С уважением, Бадян.
В те далекие времена, когда байты были еще битами...
Re: Есть ли смысл в библ. компонентов на чистом API?
Здравствуйте Бадян, Вы писали:
Б>Здравствуйте уважаемые господа.
Б>Господа, не смейтесь, ибо это не смешно. Судите сами VCL, MFC, ATL/WTL утвердили стандарт на огромнейшие приложения. Тогда как на API минимальная прога весит чуть более килобайта. А достаточно функционально наполненная может уместиться и в 20К.
А чем WTL не устраивает? Если не использовать CString, который CRT тянет то размеры получаються минимальны. Шаблоны минимизируют размеры выходного кода. Точнее грамотное их использование. Ты предлогаешь что то новое?
Здравствуйте Бадян, Вы писали:
Б>Я тут для собственных нужд затеял разработку библиотеки компонентов (только WinAPI).
Я глубоко солидарен с тобой, а потому приглашаю посетить мой сайт: http://cprime.hypermart.net
Я тоже не люблю MFC и тоже предпочитаю чистый API. Предлагаю сотрудничество. Если хочешь создавать подобные компоненты, у меня есть кое-какие идеи, подробности почтой.
Б>Конешно не все сразу. Для начала CMyStatusBar.
Посмотри у меня на сайте. Этот StatusBar (как впрочем и кое-что еще) уже реализован. Исходники выложены.
Б>Господа, не смейтесь, ибо это не смешно. Судите сами VCL, MFC, ATL/WTL утвердили стандарт на огромнейшие приложения. Тогда как на API минимальная прога весит чуть более килобайта. А достаточно функционально наполненная может уместиться и в 20К.
Насчет ATL/WTL. Это гораздо лучше (в смысле минимализации и оптимальности кода), чем MFC. К тому же ATL/WTL компоненты довольно легко встраивать в приложения, написанные на чистом API. Но есть и свои недостатки (не буду о них — это слишком долго, да и для многих неубедительно).
Б>Или не парить себе (и Вам) мозги и писать на VCL (забить на старый-добрый VisualC++), перейти на Delpi/C++Builder?
Это (IMHO) не лучший вариант. Не даром на западе дельфисты не ценятся.
Мне никогда не нравилась MFC. (c) Charles Petzold
Re: Есть ли смысл в библ. компонентов на чистом API?
Здравствуйте Бадян, Вы писали:
Б>Господа, не смейтесь, ибо это не смешно. Судите сами VCL, MFC, ATL/WTL утвердили стандарт на огромнейшие приложения. Тогда как на API минимальная прога весит чуть более килобайта. А достаточно функционально наполненная может уместиться и в 20К.
а вот кто бы мне объяснил, почему это из двух приложений с одинаковой функциональностью приложение MFC получится больше чем на чистом API В MFC-приложении — только функциональность и вызовы функций из mfcXX.dll, а проге на winapi или wtl — ВСЁ.
Re[2]: Есть ли смысл в библ. компонентов на чистом API?
O$>Здравствуйте Бадян, Вы писали:
Б>>Господа, не смейтесь, ибо это не смешно. Судите сами VCL, MFC, ATL/WTL утвердили стандарт на огромнейшие приложения. Тогда как на API минимальная прога весит чуть более килобайта. А достаточно функционально наполненная может уместиться и в 20К.
O$>а вот кто бы мне объяснил, почему это из двух приложений с одинаковой функциональностью приложение MFC получится больше чем на чистом API В MFC-приложении — только функциональность и вызовы функций из mfcXX.dll, а проге на winapi или wtl — ВСЁ.
А посмотри сколько будет весить сама mfcXX.dll — около 1Mb.
Попытаюсь угадать следующий вопрос — так она же везде стоит?
Ответ: нет не везде, а если стоит, то может быть не та версия, так что ее придется прилогать к своему exe. И что получается...
Re[3]: Есть ли смысл в библ. компонентов на чистом API?
Здравствуйте dupamid, Вы писали:
Б>>>Господа, не смейтесь, ибо это не смешно. Судите сами VCL, MFC, ATL/WTL утвердили стандарт на огромнейшие приложения. Тогда как на API минимальная прога весит чуть более килобайта. А достаточно функционально наполненная может уместиться и в 20К.
O$>>а вот кто бы мне объяснил, почему это из двух приложений с одинаковой функциональностью приложение MFC получится больше чем на чистом API В MFC-приложении — только функциональность и вызовы функций из mfcXX.dll, а проге на winapi или wtl — ВСЁ.
D>А посмотри сколько будет весить сама mfcXX.dll — около 1Mb. D>Попытаюсь угадать следующий вопрос — так она же везде стоит? D>Ответ: нет не везде, а если стоит, то может быть не та версия, так что ее придется прилогать к своему exe. И что получается...
Ну, давай посмотрим На сайте фирмы, где я работаю, лежит среди прочего пара десятков MFC-программ c динамической линковкой MFC и нужная версия MFC42.dll. Клиент, у которого не та версия mfc42.dll 1 раз качает ее, а дальше только маленькие (относительно WTL и WINAPI) собственно программы. Тоже при обновлениях.
Аналогичная ситуация с местом, занимаемым на диске.
Так что недостатков у MFC много, вот только про размер — ненадо, а?
Re: Есть ли смысл в библ. компонентов на чистом API?
Здравствуйте Бадян, Вы писали:
Б>Или не парить себе (и Вам) мозги и писать на VCL (забить на старый-добрый VisualC++), перейти на Delpi/C++Builder? А мегатонные приложения паковать каким-нить екзепаком? Б>Дык, сомневаюсь я, что 500 килобайтовую приблуду можна запаковать в 20К Б>Тагды посоветуйте хороший паковальщик.
кстати о паковальщиках — ради сомнительного удовольствия в виде экономии места на диске ждать пока программа распакуется в памяти в те же "мегатонны"
Re[4]: Есть ли смысл в библ. компонентов на чистом API?
O$>Здравствуйте dupamid, Вы писали:
Б>>>>Господа, не смейтесь, ибо это не смешно. Судите сами VCL, MFC, ATL/WTL утвердили стандарт на огромнейшие приложения. Тогда как на API минимальная прога весит чуть более килобайта. А достаточно функционально наполненная может уместиться и в 20К.
O$>>>а вот кто бы мне объяснил, почему это из двух приложений с одинаковой функциональностью приложение MFC получится больше чем на чистом API В MFC-приложении — только функциональность и вызовы функций из mfcXX.dll, а проге на winapi или wtl — ВСЁ.
D>>А посмотри сколько будет весить сама mfcXX.dll — около 1Mb. D>>Попытаюсь угадать следующий вопрос — так она же везде стоит? D>>Ответ: нет не везде, а если стоит, то может быть не та версия, так что ее придется прилогать к своему exe. И что получается...
O$>Ну, давай посмотрим На сайте фирмы, где я работаю, лежит среди прочего пара десятков MFC-программ c динамической линковкой MFC и нужная версия MFC42.dll. Клиент, у которого не та версия mfc42.dll 1 раз качает ее, а дальше только маленькие (относительно WTL и WINAPI) собственно программы. Тоже при обновлениях.
O$>Аналогичная ситуация с местом, занимаемым на диске.
O$>Так что недостатков у MFC много, вот только про размер — ненадо, а?
Насколько я понял, здесь речь шла об ОДНОЙ программе, а не о пакете программ.
Re[5]: Есть ли смысл в библ. компонентов на чистом API?
Здравствуйте dupamid, Вы писали:
D>Насколько я понял, здесь речь шла об ОДНОЙ программе, а не о пакете программ.
Странно, а я понял что уважаемый Бадян хочет стать автором библиотеки, которою как минимум будет использовать он во всех своих программах, а как максимум — все программисты всего мира во всех своих программах.
Re[2]: Есть ли смысл в библ. компонентов на чистом API?
O$>Здравствуйте Бадян, Вы писали:
Б>>Или не парить себе (и Вам) мозги и писать на VCL (забить на старый-добрый VisualC++), перейти на Delpi/C++Builder? А мегатонные приложения паковать каким-нить екзепаком? Б>>Дык, сомневаюсь я, что 500 килобайтовую приблуду можна запаковать в 20К Б>>Тагды посоветуйте хороший паковальщик.
O$>кстати о паковальщиках — ради сомнительного удовольствия в виде экономии места на диске ждать пока программа распакуется в памяти в те же "мегатонны"
Нуу... теория в том, что пока с диска читаются 50 метров екзешника (со скоростью 5 м/сек), простаивают 2ГГц лошадиных сил.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[3]: Есть ли смысл в библ. компонентов на чистом API?
Здравствуйте Sinclair, Вы писали:
S>Здравствуйте Odi$$ey, Вы писали:
O$>>Здравствуйте Бадян, Вы писали:
Б>>>Или не парить себе (и Вам) мозги и писать на VCL (забить на старый-добрый VisualC++), перейти на Delpi/C++Builder? А мегатонные приложения паковать каким-нить екзепаком? Б>>>Дык, сомневаюсь я, что 500 килобайтовую приблуду можна запаковать в 20К Б>>>Тагды посоветуйте хороший паковальщик.
O$>>кстати о паковальщиках — ради сомнительного удовольствия в виде экономии места на диске ждать пока программа распакуется в памяти в те же "мегатонны" :no: S>Нуу... теория в том, что пока с диска читаются 50 метров екзешника (со скоростью 5 м/сек), простаивают 2ГГц лошадиных сил.
А ты диск пожми :) А то ведь два экземпляра пятидесятиметрового пакованного экзешника займут 100 метров памяти, в то время как непакованного — немногим более 50.
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Re[4]: Есть ли смысл в библ. компонентов на чистом API?
O$>Здравствуйте dupamid, Вы писали:
O$>Ну, давай посмотрим На сайте фирмы, где я работаю, лежит среди прочего пара десятков MFC-программ c динамической линковкой MFC и нужная версия MFC42.dll. Клиент, у которого не та версия mfc42.dll 1 раз качает ее, а дальше только маленькие (относительно WTL и WINAPI) собственно программы. Тоже при обновлениях.
... А потом клиент ставит какой-нить драйвер сканера с др. версией MFC для интерфейса
и все остальное валится нафиг.
У меня была такая ж: один драйвер хотел одну версию MFC,
а другой (COM-объект) — другую. Очень весело.
...А отсюда наливаем, когда рецепт написан совсем неразборчиво...
Re[5]: Есть ли смысл в библ. компонентов на чистом API?
O$>>Ну, давай посмотрим На сайте фирмы, где я работаю, лежит среди прочего пара десятков MFC-программ c динамической линковкой MFC и нужная версия MFC42.dll. Клиент, у которого не та версия mfc42.dll 1 раз качает ее, а дальше только маленькие (относительно WTL и WINAPI) собственно программы. Тоже при обновлениях.
М>... А потом клиент ставит какой-нить драйвер сканера с др. версией MFC для интерфейса М>и все остальное валится нафиг. М>У меня была такая ж: один драйвер хотел одну версию MFC, М>а другой (COM-объект) — другую. Очень весело.
разные версии mfc42.dll ? а в чем выражалось "хотение"? (просто не видел такого никогда)
Re[6]: Есть ли смысл в библ. компонентов на чистом API?
O$>разные версии mfc42.dll ? а в чем выражалось "хотение"? (просто не видел такого никогда)
Это было давно. Помню только, что с одной стороны были Oracle Objects for OLE,
с другой — практически все остальное.
К сожалению, не помню точной версии Objects. У них там сложно с этим в Oracle :)
Причем нужная версия DLL не подходила ни с VC 4.2, ни с 5.0.
Откуда они ее взяли — неизвестно. Возможно — какая-то ранняя версия.
А шестого VC тогда еще не было.
Похоже ситуация с версией уже устаканилась. Я имею в виду — для всего, что
выпущено за последние 2-3 года.
Но что конфликт версий реально возможен — это факт. Для софта, выпуска
в районе где-то 96-97 года.
Вообще, у Oracle с MS была постоянная борьба за виндовозного клиента.
С каждой версией винды, VB или Office — M$ чего-там подшаманит — и
у оракловского клиента глюки.
То есть перед установкой нужно всегда внимательно читать доку — на чем его тестировали :).
Заметим, что M$ вовсю рвется на рынок вторичного софта.
А это значит, что под всякими "благовидными" предлогами будет и дальше
постоянно ставить палки в колеса конкурентам.
В том числе и разработчикам на VC.
...А отсюда наливаем, когда рецепт написан совсем неразборчиво...
Re: Есть ли смысл в библ. компонентов на чистом API?
Здравствуйте Бадян, Вы писали:
Б>Или не парить себе (и Вам) мозги и писать на VCL (забить на старый-добрый VisualC++), перейти на Delpi/C++Builder? А мегатонные приложения паковать каким-нить екзепаком? Б>Дык, сомневаюсь я, что 500 килобайтовую приблуду можна запаковать в 20К
А ведь есть KOL...? Если не в кусе — это замена VCL. Позволяет полномасшатбное приложение сделать весом в 20к....
Б>Тагды посоветуйте хороший паковальщик.
Паковальщики — это страшный BAD. Крис Касперски очень хорошо это расписал.
Re[2]: Есть ли смысл в библ. компонентов на чистом API?
Здравствуйте DeusNoxious, Вы писали:
DN>А ведь есть KOL...? Если не в кусе — это замена VCL. Позволяет полномасшатбное приложение сделать весом в 20к....
Недавно узнал об этом KOL, заинтересовался, скачал примерчик — просмотрщик bmp-ек. 15кб exe. Протащился Взял WTL, сваял тоже самое, получилось 15 кб exe Только потом оказалось, что тот exe-шник пакованный был
Б>>Тагды посоветуйте хороший паковальщик. DN>Паковальщики — это страшный BAD. Крис Касперски очень хорошо это расписал.
А где можно почитать? А то я и так знаю, что это плохо, а конкретных аргументов/тестов нет.
Как все запущенно...
Re[3]: Есть ли смысл в библ. компонентов на чистом API?
Здравствуйте OLEGus1, Вы писали:
D>>А посмотри сколько будет весить сама mfcXX.dll — около 1Mb.
OLEG>В таких случаях советую прилинковывать bcgjkmpetvst dll. получаются программы < 100 k
Очень интересно, а это за такая "bcgjkmpetvst dll"???
Это шутка, или Вы не читали предыдущих сообщений?
Re[7]: Есть ли смысл в библ. компонентов на чистом API?
Здравствуйте Михаил, Вы писали:
М>Здравствуйте 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>Это не категоричные заявления. Просто совет.
Этот совет, увы, хорош только для новых проектов и только для определенного круга задач.
"Будь достоин победы" (c) 8th Wizard's rule.
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'а. Но реализовать именно библиотеку, а не набор шаблонов. Тогда использовать ее для больших проектов будет одно удовольствие.
А вот спорим что ты такую либу не напишешь?
Здравствуйте Stanislav V. Zudin, Вы писали:
AVK>>А вот спорим что ты такую либу не напишешь? SVZ>Обоснуй.
А чего тут обосновывать — ты просто не представляешь себе наверное объем работ.
Здравствуйте AndrewVK, Вы писали:
AVK>>>А вот спорим что ты такую либу не напишешь? SVZ>>Обоснуй. AVK>А чего тут обосновывать — ты просто не представляешь себе наверное объем работ.
Ну почему же? Отлично представляю. Более того, писали мы под свои нужды и либы и контролы. Например, товарищ Gi написал замечательный визуализатор для алгоритмов -смотреть как строится какая-нибудь триангуляция — просто сказка . И все на голом API.
Насчет объема... Не нужно запихивать в либу все, что ни попадя. Так действительно MS'овского штата не хватит для ее реализации. А всякие плавающие окошки, настраиваемые меню и тулбары — _одному_ человеку месяца на три работы (проверено!).
_____________________
С уважением,
Stanislav V. Zudin
Re[4]: Есть ли смысл в библ. компонентов на чистом API?
Здравствуйте Stanislav V. Zudin, Вы писали:
SVZ>Гм. Я могу возразить. Как раз потому, что MFC писали не один год, она не отличается стройностью и быстродействием. Очень много завязок на старый 16-разрядный код (CAsyncSocket тому пример). Начали-то ее разрабатывать еще под Win3.0 (если мне склероз не изменяет).
Да, но в каждой версии MFC появлялись новые классы и изменялись старые
SVZ>А реализовать что-то нестандартное, не укладывающееся в Doc-View? А? Пробовали? Удовольствие еще то.
Я не агитирую за MFC. У каждой библиотеки для конкретной задачи есть свои минусы и плюсы (банальные слова). Когда используешь ее — надо их знать. MFC удобен именно для создания GUI. Это значит, что не надо пихать MFC куда ни поподя и жаловаться на производительность.
Я думаю, все мы знаем, что удобная быстрая библиотека классов на все случаи жизни — утопия
Re[5]: Есть ли смысл в библ. компонентов на чистом API?
Здравствуйте MaximE, Вы писали:
ME>Да, но в каждой версии MFC появлялись новые классы и изменялись старые
SVZ>>А реализовать что-то нестандартное, не укладывающееся в Doc-View? А? Пробовали? Удовольствие еще то.
ME>Я не агитирую за MFC. У каждой библиотеки для конкретной задачи есть свои минусы и плюсы (банальные слова). Когда используешь ее — надо их знать. MFC удобен именно для создания GUI. Это значит, что не надо пихать MFC куда ни поподя и жаловаться на производительность.
Еще точнее, MFC годится _только_ для создания гуя. Более того, для гуя Notepad'ов и Dialog-based утилиток. Для более серьезных разработок приходится писать свои библиотеки.
ME>Я думаю, все мы знаем, что удобная быстрая библиотека классов на все случаи жизни — утопия
Ерунда. Если бы MFC не была так сильно завязана на злополучный Doc-View, она легко бы адаптировалась под самые разнообразные нужды (ну почти под любые) .
Все, что требуется от библиотеки — это удобная работа с окошками. Все остальное прикручивается.
_____________________
С уважением,
Stanislav V. Zudin
Re[6]: Есть ли смысл в библ. компонентов на чистом API?
SVZ>Для более серьезных разработок приходится писать свои библиотеки.
Дабы не обижать почтенную публику и себя (все-таки все мы занимаемся серьезными разработками), скажу лучше так: "Для более-менее нестандартных случаев приходится писать свои библиотеки."
_____________________
С уважением,
Stanislav V. Zudin
Здравствуйте AndrewVK, Вы писали:
AVK>Здравствуйте Lexey, Вы писали:
L>>Значит мы друг друга не понимаем. Для меня MC++ — это именно managed-расширения, а для тебя выходит только компиляция в MSIL. AVK>Не, давай вернемся к началу. Ты сказал что для тебя дотнет неприемлем потому что надо переписывать исходники. Я сказал что переписывать не надою Где я говорил что нужен именно managed код?
Во-первых, я не говорил, что для меня dotnet неприемлим. Я говорил, что портировать на него старые проекты я бы не стал. Гхм, а нахрена мне просто перекомпилированные исходники? С тем же успехом можно просто вызывать функции из библиотек через InterOp.
AVK>>>Где я писал про управляемый код? Вполне достаточно MSIL кода.
L>>Ради чего? Ради MSIL-кода? AVK>Ради того чтобы перейти на дотнет.
Ну и какой же это переход? Это из разряда сегодня я скомпилировал VC6, а завтра VC7. Что я сменил кроме компилятора?
L>> С тем же успехом можно вызывать обычные unmanaged-функции. AVK>Не с таким же, на интеропе много потеряешь.
А по-моему это ты на нем дофига потеряешь. Так нужно маршалить только вызов собственно unmanaged функции, а в твоем варианте нужно маршалить все вызовы unmanaged-функций, которые эта функция вызывает.
AVK>>>Ты что то путаешся. Unmanaged код даже на шарпе можно написать. В данном же случае нужен L>>Это я знаю. И что? AVK>Какое имеет отношение к возможности работы под дотнетом?
Не вижу связи с темой разговора.
L>>Зачем тебе код в MSIL если он все равно не будет использовать возможностей среды, а будет создавать только лишний overhead? AVK>В новых кусках можно будет возможности среды использовать. И потихоньку переписывать старый код. Ты же страдал что эксепшенов нет.
Я уже сказал, что ровно с тем же успехом можно просто вызывать старый код, ничего не переписывая.
Где ты увидел про эксепшены? Вот от чего, так от их отсутствия я уж точно страдать не буду.
Здравствуйте Lexey, Вы писали:
L>Я уже сказал, что ровно с тем же успехом можно просто вызывать старый код, ничего не переписывая. L>Где ты увидел про эксепшены? Вот от чего, так от их отсутствия я уж точно страдать не буду.
Вобще то я свое сообщение написал в ответ на это
Так вот, в версиях компиляторов для девайсов до Windows CE 3.0 (PocketPC) включительно нет даже exceptions! Они появились только в CE.NET
А ведь так хочется частичной специализации и прочих вкусностей... Это, конечно, снова камень в сторону MS...
Эхх, нет в жизни счастья
Здравствуйте AndrewVK, Вы писали:
AVK>Здравствуйте Lexey, Вы писали:
L>>Я уже сказал, что ровно с тем же успехом можно просто вызывать старый код, ничего не переписывая. L>>Где ты увидел про эксепшены? Вот от чего, так от их отсутствия я уж точно страдать не буду. AVK>Вобще то я свое сообщение написал в ответ на это
AVK>Так вот, в версиях компиляторов для девайсов до Windows CE 3.0 (PocketPC) включительно нет даже exceptions! Они появились только в CE.NET AVK>А ведь так хочется частичной специализации и прочих вкусностей... Это, конечно, снова камень в сторону MS... AVK>Эхх, нет в жизни счастья
Ладно, проехали.
"Будь достоин победы" (c) 8th Wizard's rule.
Re[4]: Есть ли смысл в библ. компонентов на чистом API?
Здравствуйте Stanislav V. Zudin, Вы писали:
SVZ>Начали-то ее разрабатывать еще под Win3.0 (если мне склероз не изменяет).
Начинали ее еще под досом вообщето SVZ>А реализовать что-то нестандартное, не укладывающееся в Doc-View? А? Пробовали?
Пробовал. Без каких либо проблем
Кстати я и не пользуюсь Доками
Crescite, nos qui vivimus, multiplicamini
Re[7]: Есть ли смысл в библ. компонентов на чистом API?
Не совсем пойму, почему вы так уверенны в том, что ВСЁ MFC ЗАВЯЗАНО на Doc-View?
Есть прекрасные классы техже контролов файловые строковые и т.д.
Ну да ладно. Раз уж собрались все переписывать то заодно и все существующие компоненты COM перепишите. А то не понятно кто и на чм их писал, заодно WTL захватите и kernel32.dll на чистом ассме.
Crescite, nos qui vivimus, multiplicamini
Re[7]: Есть ли смысл в библ. компонентов на чистом API?
Здравствуйте Stanislav V. Zudin, Вы говорили:
SVZ>>"Для более-менее нестандартных случаев приходится писать свои библиотеки."
Пример в студию. И обоснование целесообразнозти написания билиотеки (не одноразового использования, а именно библиотеки).
Такое впечатление, что народ дико обленился и не хочет пользовать в "нестандартных случаях" API.
Crescite, nos qui vivimus, multiplicamini
Re[8]: Есть ли смысл в библ. компонентов на чистом API?
Здравствуйте OLEGus1, Вы писали:
SVZ>>>"Для более-менее нестандартных случаев приходится писать свои библиотеки." OLE>Пример в студию. И обоснование целесообразнозти написания билиотеки (не одноразового использования, а именно библиотеки).
Я не открою Америки заявив, что в любой конторе, занимающейся софтописательством, есть собственные либы. В зависимости от решаемых задач, объем этих библиотек сильно разнится. Кому-то достаточно дописать пары контролов на MFC, кто-то пишет собственную версию Dockable windows и пр.
А еще есть фирмы типа Roguewave software, которые денежку зарабатывают на писательстве именно _библиотек_.
Вы хотите сказать, что все эти люди (фирмы) занимаются пустой тратой времени? Неужели нужно обосновывать необходимость создания, скажем, Stingray Objective Toolkit?
OLE>Такое впечатление, что народ дико обленился и не хочет пользовать в "нестандартных случаях" API.
Мда, дык ведь все равно придется писать свою либу... Хоть общего, хоть частного применения... Вообще, мне хотелось бы посмотреть реализацию "Docking windows" на API. Без оформления в либу
_____________________
С уважением,
Stanislav V. Zudin
Re[8]: Есть ли смысл в библ. компонентов на чистом API?
Здравствуйте OLEGus1, Вы писали:
OLE>Здравствуйте Stanislav V. Zudin, :
OLE>Не совсем пойму, почему вы так уверенны в том, что ВСЁ MFC ЗАВЯЗАНО на Doc-View? OLE>Есть прекрасные классы техже контролов файловые строковые и т.д.
Согласен. CString не требует создания CDocument'а
Насчет завязки я немного погорячился, признаю. Просто в Stingray'евской либе ну никак было не избавиться от Doc-View. А customizable toolbars & docking windows хотелось Закончилось все это написанием собственной оконной либы.
OLE>Ну да ладно. Раз уж собрались все переписывать то заодно и все существующие компоненты COM перепишите. А то не понятно кто и на чм их писал, заодно WTL захватите и kernel32.dll на чистом ассме.
А вот это глупость. Полагаю, комментариев не требуется.
_____________________
С уважением,
Stanislav V. Zudin
Re[9]: Есть ли смысл в библ. компонентов на чистом API?
Здравствуйте Stanislav V. Zudin, Вы писали:
OLE>>Ну да ладно. Раз уж собрались все переписывать то заодно и все существующие компоненты COM перепишите. А то не понятно кто и на чм их писал, заодно WTL захватите и kernel32.dll на чистом ассме. SVZ>А вот это глупость. Полагаю, комментариев не требуется.
Это не глупость а попытка пошутить на тему бесперспективности данного занятие.
И если вы думаете что умнее парней из тогоже бормана, то это не совсем так. УНИВЕРСАЛЬНУЮ бублиотеку даже взяв за основу количественно и качественно MFC не напишете, да и нужда со временем пропадет в этом.
Crescite, nos qui vivimus, multiplicamini
Re[10]: Есть ли смысл в библ. компонентов на чистом API?
Здравствуйте OLEGus1, Вы писали:
OLE>Это не глупость а попытка пошутить на тему бесперспективности данного занятие. OLE>И если вы думаете что умнее парней из тогоже бормана, то это не совсем так. УНИВЕРСАЛЬНУЮ бублиотеку даже взяв за основу количественно и качественно MFC не напишете, да и нужда со временем пропадет в этом.
С последним утверждением согласен на все 100. В конце концов все библиотеки пишутся, прежде всего, для себя любимого и для своих нужд.
Думаю, на этом можно закрыть флейм. Все равно ничего нового никто уже не напишет...
_____________________
С уважением,
Stanislav V. Zudin
Re: Есть ли смысл в библ. компонентов на чистом API?
От:
Аноним
Дата:
04.09.02 15:12
Оценка:
Здравствуйте Бадян, Вы писали:
Б>Здравствуйте уважаемые господа.
Б>Прошу простить за офтопик, но где еще спросить если не здесь? Б>Я тут для собственных нужд затеял разработку библиотеки компонентов (только WinAPI).
Б>Господа, не смейтесь, ибо это не смешно. Судите сами VCL, MFC, ATL/WTL утвердили стандарт на огромнейшие приложения. Тогда как на API минимальная прога весит чуть более килобайта. А достаточно функционально наполненная может уместиться и в 20К.
Странная у Вас мотивация написания собственной библиотеки.
По-моему мнению написание собственной библиотеки может оправдываться следующим:
1) Удобство использования
2) Наличие специфичной функциональности, не существующей в стандартных библиотеках
3) Большая управляемость программы (отсутствие ещё одного чёрного ящика в продукте, например такого как MFC)
4) Скорость работы
В любом случае стоит подумать прежде чем начинать писать, и если Вы уверены, что в конечном этоге написание этой библиотеки сэкономит Ваше время и усилия, то вперёд.
P.S. Впрочем есть ещё одна причина, ради развлечения
Re[2]: Есть ли смысл в библ. компонентов на чистом API?
От:
Аноним
Дата:
06.09.02 00:28
Оценка:
AS>А чем WTL не устраивает? Если не использовать CString, который CRT тянет то размеры получаються минимальны.
O>Вот не стал бы я так категорично... Недавние тесты (VC7 vc BCB6) показывают: O>1. поддержка стандарта в bcb немногим лучше (или немногим хуже), чем в VC O>2. оптимизация много хуже O>3. linker в bcb — вообще убивал бы... а другие использовать не получается, формат кажется proprietary (последнее — еще в стадии разборок, так что утверждение спорно-некатегоричное)
Я сам пишу на vc 60, но вот что пишет по этому поводу Рошаль:
FAR 1.70 beta 2 (build 321) (16.12.2000)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Основное
~~~~~~~~
[!] Для компиляции FAR Manager использовался Borland C/C++ 5.02.
MSVC 6 SP4 не оправдал ожиданий (FAR 1.70 beta 1) и добавил
тормозов (работа с выделением памяти для мелкими объектов).
Веру-ю-у! В авиацию, в научную революци-ю-у, в механизацию сельского хозяйства, в космос и невесомость! Веру-ю-у! Ибо это объективно-о! (Шукшин)
Здравствуйте dad, Вы писали:
dad>Я сам пишу на vc 60, но вот что пишет по этому поводу Рошаль:
dad>
dad>FAR 1.70 beta 2 (build 321) (16.12.2000)
dad>~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
dad>Основное
dad>~~~~~~~~
dad>[!] Для компиляции FAR Manager использовался Borland C/C++ 5.02.
dad> MSVC 6 SP4 не оправдал ожиданий (FAR 1.70 beta 1) и добавил
dad> тормозов (работа с выделением памяти для мелкими объектов).
dad>
Жаль, что уважаемые товарищи из FAR (а фар рулез по определению ) не умеют пользоваться аллокаторами и продвинутыми фичами языка С++ (безотносительно компилятора, если поддерживается)... Думаю, если бы умели, фар был бы еще рулезнее
Здравствуйте orangy, Вы писали:
O>Жаль, что уважаемые товарищи из FAR (а фар рулез по определению ) не умеют пользоваться аллокаторами и продвинутыми фичами языка С++ (безотносительно компилятора, если поддерживается)... Думаю, если бы умели, фар был бы еще рулезнее
Мне вот интересно — а что, у кого то Фар тормозит, что так пекуться о скорости работы с памятью?
ICQ#: 198114726
В MFC-приложении — только функциональность и вызовы функций из mfcXX.dll, а проге на winapi или wtl — ВСЁ.
На сайте фирмы, где я работаю, лежит среди прочего пара десятков MFC-программ c динамической линковкой MFC и нужная версия MFC42.dll. Клиент, у которого не та версия mfc42.dll 1 раз качает ее, а дальше только маленькие (относительно WTL и WINAPI) собственно программы. Тоже при обновлениях.
Они появились только в CE.NET
Ты явно путаешь VC7 и Managed Extensions for VC7. MC++ — это как раз C++ с managed-расширениями. VC7 будет компилировать большую часть кода без VC6 просто так, но управляемым код от этого никак не станет.
