Здравствуйте, Анатолий Широков, Вы писали:

АШ>>>Ну, не такое оно и неизбежное. Хотя вопрос был задан несколько с другой целью, а именно, чтобы человек задумался над тем, что на MFC свет клином не сошелся, MFC не стандартизирован и еще не известно будет он поддерживаться или нет. Тогда как STL — это стандартная библиотека, которая должна поддерживаться всеми современными компиляторами, код написанный на STL одинаково будет работать как под xNIX, так и под Windows.

I>>это очень смелое утверждение, для этого нужно прилагать усилия. навскидку, возникнут проблемы с мультитредностью стрингов, которые в реализации от GCC содержат багу вплоть до версии 3.xxx точно не помню.

АШ>Если вы как разработчик стали на кроссплатформенный путь с трудностями вам так или иначе придется столкнутся. Но разве мы об этом?

ну в общем-то... нет. в любом, случае портабильности можно добиться. чего не скажешь об MFC.
к тому же, опять-таки можно использовать алгоритмы, что делает местами программу намного красивее понятнее, надежнее, а за счет inline'а также и намного быстрее. все желающие могут сравнить скорость сортировки MFCшных массивов с простым стэлевским std::sort(arr.begin(), arr.end())
ПЫСЫ: только в режиме оптимизации, когда инлайнинг включается

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

CS>Здравствуйте, Анатолий Широков, Вы писали:

TW>>>я же говорю — у меня потребности не возникало
TW>>>сталкивался с написанием как системного так и прикладного софта на VC++ (как сам писал, так и просто видел работы других)
TW>>>нигде что-то с STL встречаться не приходилось

АШ>>Хорошо, попробуй выкинуть MFC из своих проектов и с чем ты останешься?
CS>Причём когда программишь на OpenGL, DirectX именно так и приходится делать...

ок
вырисовывается список
STL необходима для
1. кроссплатформенной разработки
2. реализации крупных низкоуровневых движков с четкими требованиями к потребляемым ресурсам и скорости (например игры)
(кстати, я так понимаю, работа со строками и массивами в STL происходит быстрее чем в MFC?)

что еще?

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

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

CS>>Здравствуйте, Анатолий Широков, Вы писали:

TW>>>>я же говорю — у меня потребности не возникало
TW>>>>сталкивался с написанием как системного так и прикладного софта на VC++ (как сам писал, так и просто видел работы других)
TW>>>>нигде что-то с STL встречаться не приходилось

АШ>>>Хорошо, попробуй выкинуть MFC из своих проектов и с чем ты останешься?
CS>>Причём когда программишь на OpenGL, DirectX именно так и приходится делать...

TW>ок
TW>вырисовывается список
TW>STL необходима для
TW>1. кроссплатформенной разработки
TW>2. реализации крупных низкоуровневых движков с четкими требованиями к потребляемым ресурсам и скорости (например игры)
TW> (кстати, я так понимаю, работа со строками и массивами в STL происходит быстрее чем в MFC?)

TW>что еще?

еще там, где нужен, хороший, надежный, сопровождаемый код.

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

TW>>ок
TW>>вырисовывается список
TW>>STL необходима для
TW>>1. кроссплатформенной разработки
TW>>2. реализации крупных низкоуровневых движков с четкими требованиями к потребляемым ресурсам и скорости (например игры)
TW>> (кстати, я так понимаю, работа со строками и массивами в STL происходит быстрее чем в MFC?)

TW>>что еще?

I>еще там, где нужен, хороший, надежный, сопровождаемый код.

это уже проблема не языка и технологий, а прокладки между креслом и клавиатурой

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


TW>>> (кстати, я так понимаю, работа со строками и массивами в STL происходит быстрее чем в MFC?)

TW>>>что еще?

I>>еще там, где нужен, хороший, надежный, сопровождаемый код.

TW>это уже проблема не языка и технологий, а прокладки между креслом и клавиатурой

к сожалению, не только, см выше замечания про итераторы и освобождение памяти. могу еще привести пример. нужно,
например, скопировать все элементы массива исключая первые три в другой (новый) массив (при условии что элементов >= 4)
как это будет выглядеть на MFC? могу сказать, что ужасно.
а в STL:

std::vector newArr(oldArr.begin() + 3, oldArr.end());

коротко и понятно, и надёжно. а в MFC на такой простой операции еще кучу багов насажаешь. а чего стоят такие приятные мелочи, как max_element, min_element?
а accumulate (для подсчета, например, суммы). а Вы проведите эксперимент, сколько Ваших знакомых посадят баг при написании трех строчек подсчёта суммы всех элементов массива и тогда может быть будете не так критично высказываться в адрес "прокладки"

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

TW>вырисовывается список
TW>STL необходима для
TW>1. кроссплатформенной разработки
йес

TW>2. реализации крупных низкоуровневых движков с четкими требованиями к потребляемым ресурсам и скорости (например игры)
ну я б не сказал

TW> (кстати, я так понимаю, работа со строками и массивами в STL происходит быстрее чем в MFC?)
будь точнее, какие строки? какие массивы?

ну в общем самые главные плюсы STL (естественно, по моему наискромнейшему мнению):
1. Содержит кучу "велосипедов"
2. Он стандартный
3. Хороший дизайн

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


TW>вопрос — в каких сферах применения чаще всего используют STL, в каких сферах хорошее знание STL является необходимостью?

Везде где нужны контейнеры и разнообразные алгоритмы работы с ними пользуй стл. А так как контейнеры обычно нужны везде и хоть как-то с ними надо еще и работать, то можно сказать что стл можно пользовать везде

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


I>это очень смелое утверждение, для этого нужно прилагать усилия. навскидку, возникнут проблемы с мультитредностью стрингов, которые в реализации от GCC содержат багу вплоть до версии 3.xxx точно не помню.

стл к мультредности не имеет никакого отношения. Об этом и Мейерс писал еще, и кажысь у Саттера где-то проскальзывало. Вас же не волнует что функция memcpy потоко-небезопасна. мультитредность это ваще очень платформо-зависимая тема и к стандартной библиотеке мало как относится. она ведь на то и стандартная — чтобы работало одинаково все и везде.

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


TW>ок
TW>вырисовывается список

Составлять подобный список -- неблагодарное дело. Ваш вопрос сродни вопросу, зачем нужен С++, когда есть чистый С. Человек, который всю жизнь пишет на С и который не знает С++, последний тоже вряд ли понадобится (с его точки зрения). И также бессмысленно составлять список задач, в которых С++ может дать выигрыш по сравнению с чистым С, также бесммысленно составлять специальный список задач для STL.

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

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


TW>>ок
TW>>вырисовывается список

G>Составлять подобный список -- неблагодарное дело. Ваш вопрос сродни вопросу, зачем нужен С++, когда есть чистый С. Человек, который всю жизнь пишет на С и который не знает С++, последний тоже вряд ли понадобится (с его точки зрения). И также бессмысленно составлять список задач, в которых С++ может дать выигрыш по сравнению с чистым С, также бесммысленно составлять специальный список задач для STL.


вы неправы
это все равно что сказать, будто бесмыссленно составляьть список задач, на которых к примеру VC# обходит VC++, или Unix обходит Windows

к тому же вопрос изначально ставился по другому — "где STL — это отраслевой стандарт?"

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

TW>вы неправы
TW>это все равно что сказать, будто бесмыссленно составляьть список задач, на которых к примеру VC# обходит VC++, или Unix обходит Windows

TW>к тому же вопрос изначально ставился по другому — "где STL — это отраслевой стандарт?"

Unix и Windows разные системы, точно так же как VC# и VC++ разные языки программирования. Следовательно, у них есть свои плюсы и минусы и сравнивать их имеет смысл.

С++ же даёт много дополнительных возможностей по сравнению с С, не отбирая у программиста ни одной возможности из С. То есть он существенно дополняет и расширяет С (а не заменяет). То же можно сказать и про STL и С++. Начав использовать STL все возможности языка и остальных библиотек останутся при вас.

Что касается отраслевого стандарта -- STL сам по себе стандарт, и нельзя говорить об отраслевых стандартах, так границы его применения не проходят по границам отраслей.

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

TW>ок
TW>вырисовывается список
TW>STL необходима для
TW>1. кроссплатформенной разработки
TW>2. реализации крупных низкоуровневых движков с четкими требованиями к потребляемым ресурсам и скорости (например игры)

TW> (кстати, я так понимаю, работа со строками и массивами в STL происходит быстрее чем в MFC?)
нет, в MFC7.1/ATL отличный класс CString, совместимый по внешнему интерфейсу с одноименным из MFC4.x, но на порядок лучше внутренне.

с массивами в STL тоже не все гладко, особенно если ты держишь там смарт-поинтер.
в MFC я пишу так CArray< sptr<MyObj>, MyObj*>, и все аргументы методов массива у меня — MyObj*, а в std::vector< sptr<MyObj> > я получу аргумент методов типа const sptr<MyObj>&, что может вдвое увеличить накладные расходы на вызов методов (из-за создания промежуточных объектов-смартпоинтеров).

Однако, там где нужна мощь <algorithms>, STL показывает себя во всей красе, т.е., крутизна STL не столько в коллекциях (контейнерах), сколько в алгоритмах, оперирующих этими коллекциями. Перейдя на STL ты начнешь обходиться 3-мя строками там, где раньше городил большой огород.

хотя... никто не мешает тебе создать wrapper на любую твою коллекцию, с целью сделать ее совместимой с алгоритмами STL, и пользуйся потом всей мощью STL.

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


TW>вопрос — в каких сферах применения чаще всего используют STL, в каких сферах хорошее знание STL является необходимостью?

Во всех, где требуется иметь структуры данных и удобные механизмы работы с ними. Другими словами везде. Даже в hello-world...

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

V>с массивами в STL тоже не все гладко, особенно если ты держишь там смарт-поинтер.

Вроде господин Майерс говорил, что держать смарт-поинтер в коллекции очень опасно и надо всячести избегать. Или я чего-то путаю?

Здравствуйте, <Аноним>, Вы писали:

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

V>>с массивами в STL тоже не все гладко, особенно если ты держишь там смарт-поинтер.

А>Вроде господин Майерс говорил, что держать смарт-поинтер в коллекции очень опасно и надо всячести избегать. Или я чего-то путаю?

Путаешь. Он говорил про std::auto_ptr<>, который для этого просто не предназначен

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

G>С++ же даёт много дополнительных возможностей по сравнению с С, не отбирая у программиста ни одной возможности из С. То есть он существенно дополняет и расширяет С (а не заменяет).

IMHO не совсем правда.
Возможности, конечно, остаются. Но меняется подход к написанию программы, и часть возможностей оказывается не просто ненужной, но и маленько deprecated...

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

TW>однако за все это время как то не возникало необходимости использовать STL ни в своих разработках, ни для взаимодействия с чужим кодом, все делалось средствами различных API или MFC
TW>вопрос — в каких сферах применения чаще всего используют STL, в каких сферах хорошее знание STL является необходимостью?

ИМХО, использование MFC не даёт выигрыша перед STL, тем более если требуется писать кроссплатформенное приложение. Именно в таких случаях, собственно, STL и используют чаще всего.

TW>однако за все это время как то не возникало необходимости использовать STL ни в своих разработках, ни для
взаимодействия с чужим кодом, все делалось средствами различных API или MFC

а вот это зря. Вы убили зачастую кучу времени на изобретение велосипеда


TW>вопрос — в каких сферах применения чаще всего используют STL, в каких сферах хорошее знание STL является необходимостью?

Знание С++ предпологает знание и использование STL.