чистий С++ !!!
Но - WinAPI все портить. 
было бы хорошо - создали особый API(понятый-стуруктурный).
может есть?
как в Java и в .NET - но только не меняя идею С++.
если что то не так... плиз, я не занимаюсь профессионално С++.   

Это сообщение отредактировал(а) jxr - 21.5.2006, 23:26

А в чём вопрос? 
Win32Api создавался не для С++ и даже не для Си а для процедурных языков (и даже Basic). 

я и об этом говорию...
не было бы плохо(супер!)...
...создать API для С++.
API - понятый-стуруктурный, типа Java и\или .NET
вообще есть такие подходы? 
или чего то я перепутаю?!
помогите разобраться, плиз.
PS. В Win32Api заниматься программированием очень сложно.   

Это сообщение отредактировал(а) jxr - 21.5.2006, 23:49

HINSTANCE - void*
LPSTR - это Си-строка(Может состоять тз Unicode символов!) 
LPVOID - void* 
STARTUPINFO - см. документацию 

я не спрашиваю... что  эти типы означает!
почему не void*  - а HINSTANCE.
void* - проще писать и понять.  

Это сообщение отредактировал(а) jxr - 22.5.2006, 00:14

jxr, потому, что никто тебе не гарантирует, что при выходе новой винды этот тип останется void* 

может, писать и понять и проще
но проще ли понять правильно?
не только HINSTANCE является void*
также и HBITMAP, например
и совсем неплохо, когда тип (в смысле языка) несёт информацию об объекте (то же ООП можно привести в пример)

кроме того, WinAPI совсем необязательно использовать
есть куча библиотек (VCL, MFC, ...), позволяющих строить интерфейсы
при их использовании можно (за исключением специфических ситуаций) вообще отказаться от функций WinAPI - они его "оборачивают" своими функциями и классами


ну, это довольно-таки субъективно
всё зависит от задач
если нужно что-нибудь сложное, для чего есть компонент в C++Builder'е (например), то, конечно же, проще использовать его, а не чистый WinAPI
а если мне надо вывести окошко с сообщением, то

не намного проще (если вообще проще), чем
 

реализации меняются, а название типа остается
имхо, так правильно, да и дело привычки    

сколько таких  библиотек? (VCL, MFC, ...) и для чего каждый... 
у меня Dev-C++ компилятор.
VCL библиотека бывает вместе с компиляторам или...?(Dev-C++)
VCL - если можно книга-справочник...?
спосибо.
 

Сейчас много оболочек живет типа VCL, MFC, QT, WTL... , но в том то и дело, что они - просто оболочки, да и к тому же нестабильные: почти каждый год они модифицируются и приходится вникать в эти изменения, запоминать переход от одной версии - к другой, а API - это то, вокруг чего все ходят, всем она не не нравится, всем она неудобна, но ведь ни одна оболочка не решит задачи, с которой не справится API. Это надо всегда помнить. К тому же, API, а по сути, ядро, меняется очень и очень мало. Даже если какой-нибудь интерфейс обновился, то API всегда его держит в следующих версиях для того, чтобы не было проблем с совместимостью. Вот даже сегодня существует полный набор функций, работающих с 16-ти битными версиями программ. А кто в последний раз к примеру видел грандиозную надпись на мониторе Windows 95? Но все равно выбор остается за разработчиком, поэтому везде найдутся любители и MFC и WTL и много чего еще. И даже они не считают, что знание API им не нужно. 

VCL - если можно книга-справочник...?
для каждого компилятора особый VCL?
VCL - производител = производител компилятора?
 

VCL - это от Борланда и, соответственно, для него. Не знаю, совместима ли с другими компиляторами. MFC и WTL от MS для MSVC, но кажется MFC поддерживается и некоторыми другими. 
Сначала определись с компилятором, а потом уже смотри, какие библиотеки для него есть.
Если идти от API, то лучше смотри в сторону MFC, а не VCL. Первая "тоньше", меньше и понятнее, хотя вторая, конечно, богаче.

Кстати, GremlinProg, не соглашусь с тобой насчет нестабильности, по крайней мере, MFC: за почти 10 лет было всего 2 существенных изменения: при выходе MFC 4 и при выходе VC2003. Да и то, оба раза переход не представлял проблем. Насчет API - согласна. 

Да, действительно, забыл сказать про MFC. Это пожалуй единственное исключение из правил. За счет того, что MFC была одной из самых первых, её стабильность поражает. Но, к сожалению, поражает она не только стабильностью, но и объёмом информации, в связи с чем MFC уже превратилась в некоторое подобие API, со своими интерфейсами и библиотеками, которые необходимо устанавливать для любого, хоть самого незначительного приложения MFC. Вывод сам напрашивается, лично для меня такой : "Зачем мне 2 апи?". Суть оболочки в том, что она невесома. MFC отню дь не невесома, поэтому к оболочкам я её уже давно не отношу. 

Верно, MFC большая дура. Она ведь не только оборачивает API, а еще и предлагает готовый фрейворк для работы с документами в SDI и MDI стилях, и не самый плохой. А это куча кода, который все равно придется писать для соответствующих приложений. MFC, конечно, еще и OLE-хвосты, и прочую муру по старой памяти тянет, увы... но часть можно отключить макросимволами. Если документ-вью фреймворк не нужен, тогда можно рассмотреть WTL - это сплошные шаблоны, куда уж тоньше. Конечно, насчет стабильности говорить пока рано, ей без году неделя.  

Это сообщение отредактировал(а) Earnest - 23.5.2006, 16:52

Earnest, похоже не будет у нас согласия
1. WTL - вещь далеко не новая. И MS на нее "забила" еще раньше, чем на MFC
2. WTL - шаблоны?!  Ты готов платить за эту билиотеку увеличеным временем компиляции?
3. WTL почти не пользуется спросом на рынке труда.