Читаю тут книжку по STL. Понимаю, что он супер логичный и стройный. Но наиболее распространённые средства разработки имеют свою библиотеку C++ классов: MFC, OWL. Очевидно, это связано с тем, что Visual C++, Borland C++/Delphy появились куда раньше, чем C++ & STL стандартизовались. Формально Visual C поддерживает STL, но нет ни мастеров (Class/App Wizard-ов), ни путёвого help-а, ни совместимости с MFCшными классами, работающими с разными API.
Не безнадёжно ли опоздал лапочка STL ? Надо ли его изучать, использовать в реальных Win проектах ? Или это скорей академические игрушки ?
Здравствуйте, potap, Вы писали:
P>Читаю тут книжку по STL. Понимаю, что он супер логичный и стройный. Но наиболее распространённые средства разработки имеют свою библиотеку C++ классов: MFC, OWL. Очевидно, это связано с тем, что Visual C++, Borland C++/Delphy появились куда раньше, чем C++ & STL стандартизовались. Формально Visual C поддерживает STL, но нет ни мастеров (Class/App Wizard-ов), ни путёвого help-а, ни совместимости с MFCшными классами, работающими с разными API.
P>Не безнадёжно ли опоздал лапочка STL ? Надо ли его изучать, использовать в реальных Win проектах ? Или это скорей академические игрушки ?
P>Спасибо за внимание.
STL решает чуть другие задачи, чем MFC, OWL, VCL.
Эти библиотеки используются в коде, реализующем визуальный интерфейс, который (код) изначально не(или очень трудно)переносим.
STL может использоваться в коде, реализующем логику программы, поскольку реализует многие общеупотребимые алгоритмы и хранилища данных. Такой код, как правило, пишется переносимым, поэтому хранилища данных из VCL/MFC плохо подходят.
Здравствуйте, potap, Вы писали:
P>Здравствуйте,
P>Читаю тут книжку по STL. Понимаю, что он супер логичный и стройный. Но наиболее распространённые средства разработки имеют свою библиотеку C++ классов: MFC, OWL. Очевидно, это связано с тем, что Visual C++, Borland C++/Delphy появились куда раньше, чем C++ & STL стандартизовались. Формально Visual C поддерживает STL, но нет ни мастеров (Class/App Wizard-ов), ни путёвого help-а, ни совместимости с MFCшными классами, работающими с разными API.
P>Не безнадёжно ли опоздал лапочка STL ? Надо ли его изучать, использовать в реальных Win проектах ? Или это скорей академические игрушки ?
Видимо ты пока не прочувствовал, зачем нужен STL.
Я бы вообще не стал его сравнивать с MFC и OWL.
Зачем нужен Class/App Wizard для STL — тоже слабо себе представляю.
Тебе нужен Wizard, чтобы пользоваться встренными типами (int, double,...)?
Скорее всего нет...
STL никуда не опоздал, хотя было бы лучше, если бы он появился раньше.
Это не академическая игрушка, как ты выразился, а то, что реально используются
на реальных проектах и не только виндовых.
Кстати, если хочешь, то можешь устроить голосование и выяснить,
каков процент из проголосовавших реально использут STL на реальных проектах.
Лучше, чтобы в этом голосовании не учитывались лабораторные работы в универах...
Здравствуйте, _wqwa, Вы писали:
W>STL решает чуть другие задачи, чем MFC, OWL, VCL. W>Эти библиотеки используются в коде, реализующем визуальный интерфейс, который (код) изначально не(или очень трудно)переносим.
В MFC тоже есть классы общего назначения : строки, массивы и пр. Так может не надо использовать в интерфейсной задаче STL классы, чтобы не получать проблем стыковки общих и интерфейсных (а также разноapiшных классов, таких как gdi,socket,internet,doc/view и др.) классов. Ведь интерфейсные MFCшные классы "заточены" на MFCшные же общие классы. Например, CWnd::GetWindowText принимает на вход CString&.
Здравствуйте, bkat, Вы писали:
B>Кстати, если хочешь, то можешь устроить голосование и выяснить, B>каков процент из проголосовавших реально использут STL на реальных проектах. B>Лучше, чтобы в этом голосовании не учитывались лабораторные работы в универах...
Здравствуйте, potap, Вы писали:
P>Здравствуйте, bkat, Вы писали:
B>>Кстати, если хочешь, то можешь устроить голосование и выяснить, B>>каков процент из проголосовавших реально использут STL на реальных проектах. B>>Лучше, чтобы в этом голосовании не учитывались лабораторные работы в универах...
P>Спасибо за идею. Устрою.
Здравствуйте, potap, Вы писали:
P>В MFC тоже есть классы общего назначения : строки, массивы и пр. Так может не надо использовать в интерфейсной задаче STL классы, чтобы не получать проблем стыковки общих и интерфейсных (а также разноapiшных классов, таких как gdi,socket,internet,doc/view и др.) классов. Ведь интерфейсные MFCшные классы "заточены" на MFCшные же общие классы. Например, CWnd::GetWindowText принимает на вход CString&.
Дело вкуса. Я чем дальше, тем больше использую STL даже в интерфейсных программах. Но при этом мне ничего не мешает использовать CString там, где с ним все получается проще, чем без него.
Здравствуйте, potap, Вы писали:
P>Здравствуйте, _wqwa, Вы писали:
W>>STL решает чуть другие задачи, чем MFC, OWL, VCL. W>>Эти библиотеки используются в коде, реализующем визуальный интерфейс, который (код) изначально не(или очень трудно)переносим.
P>В MFC тоже есть классы общего назначения : строки, массивы и пр. Так может не надо использовать в интерфейсной задаче STL классы, чтобы не получать проблем стыковки общих и интерфейсных (а также разноapiшных классов, таких как gdi,socket,internet,doc/view и др.) классов. Ведь интерфейсные MFCшные классы "заточены" на MFCшные же общие классы. Например, CWnd::GetWindowText принимает на вход CString&.
Я ведь об этом же и говорю. Порой удобнее юзать всякие CString and CArray в GUI-коде.
А в логике -- лучше STL.
Хотя, я как и г-н Можаев, всюду использую STL.
O$>если уж кто и опоздал, так это тот кто бросится сейчас MFC изучать
Кстати, что думает народ по поводу целесообразности изучения MFC в настоящее время?
Мне часто задают подобный вопрос, а однозначного ответа никак не добьются.
O$>>если уж кто и опоздал, так это тот кто бросится сейчас MFC изучать
S>Кстати, что думает народ по поводу целесообразности изучения MFC в настоящее время? S>Мне часто задают подобный вопрос, а однозначного ответа никак не добьются.
Это означает, что однозначного ответа нет и не надо его искать
