Здравствуйте Stanislav V. Zudin, Вы писали:

AVK>>А вот спорим что ты такую либу не напишешь?
SVZ>Обоснуй.
А чего тут обосновывать — ты просто не представляешь себе наверное объем работ.

... Янус версия 1.0 alpha 2

Здравствуйте AndrewVK, Вы писали:

AVK>>>А вот спорим что ты такую либу не напишешь?
SVZ>>Обоснуй.
AVK>А чего тут обосновывать — ты просто не представляешь себе наверное объем работ.

Ну почему же? Отлично представляю. Более того, писали мы под свои нужды и либы и контролы. Например, товарищ Gi написал замечательный визуализатор для алгоритмов -смотреть как строится какая-нибудь триангуляция — просто сказка . И все на голом API.
Насчет объема... Не нужно запихивать в либу все, что ни попадя. Так действительно MS'овского штата не хватит для ее реализации. А всякие плавающие окошки, настраиваемые меню и тулбары — _одному_ человеку месяца на три работы (проверено!).

Здравствуйте Stanislav V. Zudin, Вы писали:

SVZ>Гм. Я могу возразить. Как раз потому, что MFC писали не один год, она не отличается стройностью и быстродействием. Очень много завязок на старый 16-разрядный код (CAsyncSocket тому пример). Начали-то ее разрабатывать еще под Win3.0 (если мне склероз не изменяет).

Да, но в каждой версии MFC появлялись новые классы и изменялись старые

SVZ>А реализовать что-то нестандартное, не укладывающееся в Doc-View? А? Пробовали? Удовольствие еще то.

Я не агитирую за MFC. У каждой библиотеки для конкретной задачи есть свои минусы и плюсы (банальные слова). Когда используешь ее — надо их знать. MFC удобен именно для создания GUI. Это значит, что не надо пихать MFC куда ни поподя и жаловаться на производительность.

Я думаю, все мы знаем, что удобная быстрая библиотека классов на все случаи жизни — утопия

Здравствуйте MaximE, Вы писали:

ME>Да, но в каждой версии MFC появлялись новые классы и изменялись старые

SVZ>>А реализовать что-то нестандартное, не укладывающееся в Doc-View? А? Пробовали? Удовольствие еще то.

ME>Я не агитирую за MFC. У каждой библиотеки для конкретной задачи есть свои минусы и плюсы (банальные слова). Когда используешь ее — надо их знать. MFC удобен именно для создания GUI. Это значит, что не надо пихать MFC куда ни поподя и жаловаться на производительность.

Еще точнее, MFC годится _только_ для создания гуя. Более того, для гуя Notepad'ов и Dialog-based утилиток. Для более серьезных разработок приходится писать свои библиотеки.

ME>Я думаю, все мы знаем, что удобная быстрая библиотека классов на все случаи жизни — утопия

Ерунда. Если бы MFC не была так сильно завязана на злополучный Doc-View, она легко бы адаптировалась под самые разнообразные нужды (ну почти под любые) .
Все, что требуется от библиотеки — это удобная работа с окошками. Все остальное прикручивается.

SVZ>Для более серьезных разработок приходится писать свои библиотеки.

Дабы не обижать почтенную публику и себя (все-таки все мы занимаемся серьезными разработками), скажу лучше так: "Для более-менее нестандартных случаев приходится писать свои библиотеки."

Здравствуйте 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...
Эхх, нет в жизни счастья

... Янус версия 1.0 alpha 2

Здравствуйте AndrewVK, Вы писали:

AVK>Здравствуйте Lexey, Вы писали:

L>>Я уже сказал, что ровно с тем же успехом можно просто вызывать старый код, ничего не переписывая.
L>>Где ты увидел про эксепшены? Вот от чего, так от их отсутствия я уж точно страдать не буду.
AVK>Вобще то я свое сообщение написал в ответ на это

AVK>Так вот, в версиях компиляторов для девайсов до Windows CE 3.0 (PocketPC) включительно нет даже exceptions! Они появились только в CE.NET
AVK>А ведь так хочется частичной специализации и прочих вкусностей... Это, конечно, снова камень в сторону MS...
AVK>Эхх, нет в жизни счастья

Ладно, проехали.

Здравствуйте Stanislav V. Zudin, Вы писали:

SVZ>Начали-то ее разрабатывать еще под Win3.0 (если мне склероз не изменяет).
Начинали ее еще под досом вообщето
SVZ>А реализовать что-то нестандартное, не укладывающееся в Doc-View? А? Пробовали?
Пробовал. Без каких либо проблем
Кстати я и не пользуюсь Доками

Здравствуйте Stanislav V. Zudin, :

Не совсем пойму, почему вы так уверенны в том, что ВСЁ MFC ЗАВЯЗАНО на Doc-View?
Есть прекрасные классы техже контролов файловые строковые и т.д.

Ну да ладно. Раз уж собрались все переписывать то заодно и все существующие компоненты COM перепишите. А то не понятно кто и на чм их писал, заодно WTL захватите и kernel32.dll на чистом ассме.

Здравствуйте Stanislav V. Zudin, Вы говорили:

SVZ>>"Для более-менее нестандартных случаев приходится писать свои библиотеки."
Пример в студию. И обоснование целесообразнозти написания билиотеки (не одноразового использования, а именно библиотеки).

Такое впечатление, что народ дико обленился и не хочет пользовать в "нестандартных случаях" API.

Здравствуйте OLEGus1, Вы писали:

SVZ>>>"Для более-менее нестандартных случаев приходится писать свои библиотеки."
OLE>Пример в студию. И обоснование целесообразнозти написания билиотеки (не одноразового использования, а именно библиотеки).

Я не открою Америки заявив, что в любой конторе, занимающейся софтописательством, есть собственные либы. В зависимости от решаемых задач, объем этих библиотек сильно разнится. Кому-то достаточно дописать пары контролов на MFC, кто-то пишет собственную версию Dockable windows и пр.
А еще есть фирмы типа Roguewave software, которые денежку зарабатывают на писательстве именно _библиотек_.

Вы хотите сказать, что все эти люди (фирмы) занимаются пустой тратой времени? Неужели нужно обосновывать необходимость создания, скажем, Stingray Objective Toolkit?

OLE>Такое впечатление, что народ дико обленился и не хочет пользовать в "нестандартных случаях" API.

Мда, дык ведь все равно придется писать свою либу... Хоть общего, хоть частного применения... Вообще, мне хотелось бы посмотреть реализацию "Docking windows" на 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, Вы писали:

OLE>>Ну да ладно. Раз уж собрались все переписывать то заодно и все существующие компоненты COM перепишите. А то не понятно кто и на чм их писал, заодно WTL захватите и kernel32.dll на чистом ассме.
SVZ>А вот это глупость. Полагаю, комментариев не требуется.
Это не глупость а попытка пошутить на тему бесперспективности данного занятие.
И если вы думаете что умнее парней из тогоже бормана, то это не совсем так. УНИВЕРСАЛЬНУЮ бублиотеку даже взяв за основу количественно и качественно MFC не напишете, да и нужда со временем пропадет в этом.

Здравствуйте OLEGus1, Вы писали:

OLE>Это не глупость а попытка пошутить на тему бесперспективности данного занятие.
OLE>И если вы думаете что умнее парней из тогоже бормана, то это не совсем так. УНИВЕРСАЛЬНУЮ бублиотеку даже взяв за основу количественно и качественно MFC не напишете, да и нужда со временем пропадет в этом.

С последним утверждением согласен на все 100. В конце концов все библиотеки пишутся, прежде всего, для себя любимого и для своих нужд.
Думаю, на этом можно закрыть флейм. Все равно ничего нового никто уже не напишет...

Здравствуйте Бадян, Вы писали:

Б>Здравствуйте уважаемые господа.

Б>Прошу простить за офтопик, но где еще спросить если не здесь?
Б>Я тут для собственных нужд затеял разработку библиотеки компонентов (только WinAPI).

Б>Господа, не смейтесь, ибо это не смешно. Судите сами VCL, MFC, ATL/WTL утвердили стандарт на огромнейшие приложения. Тогда как на API минимальная прога весит чуть более килобайта. А достаточно функционально наполненная может уместиться и в 20К.

Странная у Вас мотивация написания собственной библиотеки.
По-моему мнению написание собственной библиотеки может оправдываться следующим:
1) Удобство использования
2) Наличие специфичной функциональности, не существующей в стандартных библиотеках
3) Большая управляемость программы (отсутствие ещё одного чёрного ящика в продукте, например такого как MFC)
4) Скорость работы

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

P.S. Впрочем есть ещё одна причина, ради развлечения

AS>А чем WTL не устраивает? Если не использовать CString, который CRT тянет то размеры получаються минимальны.

CString _не_ тянет CRT
string стандартной поставки VC6.0 тянет CRT

Б>Господа, не смейтесь, ибо это не смешно. Судите сами VCL, MFC, ATL/WTL утвердили стандарт на

если ты посомотришь atlwin.h
то будешь несказанно удивлен что идея твоя уже реализована...

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 (а фар рулез по определению ) не умеют пользоваться аллокаторами и продвинутыми фичами языка С++ (безотносительно компилятора, если поддерживается)... Думаю, если бы умели, фар был бы еще рулезнее