Цитата

что std::string не обрабатывает уникод

Кроме std::string, имеется также std::wstring. Оба этих типа есть просто:

Код

typedef basic_string<char>  string; typedef basic_string<wchar_t> wstring; // где wchar_t typedef unsigned short wchar_t;

Если почему-то ширины wchar_t недостаточно, воспользуйтесь преимуществами шаблонных классов и объявите что-то вроде

Код

typedef basic_string<unsigned long> swstring; // sw - superwide

Цитата

QString предлагает очень полезные возможности, например, arg(), sprintf(), section(), simplifyWhiteSpace(), toInt(), подмножество setNum() и конечно же поддержку регулярных выражений,

Очччччень напоминает "любимый" до невозможности CString.
Идея STL как раз и состоит в том, чтобы иметь сравнительно легкий класс строки, реализующий принципиальную функциональность, к-рая будет востребована на 75-90%, а громоздкие и специальные операции возложить на алгоритмы.
Известно немало библиотек, включая CRT, способных выполнять перечисл. выше операции. В частности, библ. Boost-a regex обрабатывает регулярные выражения. Большинство операций требует только 1 входной аргумент типа const char *. Зачем, спрашивается, создавать очередного монстра, подобного CString?

ИМХО, введение регулярных выражений в такой простейший класс string - глупость чистой воды.
Вы часто используете регекспы там где используете стринги? Не верю
Добавлено @ 05:57

Цитата(Fire @ 22.4.2005, 18:34)

Очччччень напоминает "любимый" до невозможности CString.

Насколько я помню, регексов там не было.

Цитата(chipset @ 23.4.2005, 05:56)

Насколько я помню, регексов там не было.

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

stl конечно хорошо, но нужно уметь и с ним и без него работать. Т. к. всякое может быть! Ведь на смену мтарым языкам приходят новые и кто знает может лет через 10 stl в С++ не будет! Хотя врятли!!!

Цитата

stl конечно хорошо, но нужно уметь и с ним и без него работать

Вся проблема в том, что с STL работать не умеют

Цитата

кто знает может лет через 10 stl в С++ не будет!

Вот, С++ как такового может и не быть, а STL останется

Цитата(AISIN @ 24.4.2005, 13:13)

tl конечно хорошо, но нужно уметь и с ним и без него работать. Т. к. всякое может быть! Ведь на смену мтарым языкам приходят новые и кто знает может лет через 10 stl в С++ не будет! Хотя врятли!!!

А никто и не говорит что следует забить на всё и программить только на STL. Просто надо использовать то что лучше.

Подниму-ка топик, а то последнее время слышу, что многие негативно относятся к STL

P/S/: Вдобавок: Template + STLport = +25% производительности

Это сообщение отредактировал(а) bel_nikita - 10.6.2005, 21:57

Давно хотел узнать мнение настоящих программистов по поводу этого вопроса.
ИМХО, штука эта очень "страшная", огромное количество вещей, работа которых не всегда понятна (имеется ввиду то, а что именно кроется за вызовом той или иной функции, что кроется в глубинах STL). А вдруг там баги?? Ведь никто не может поручиться за это. Некоторые вещи STL просто безобразны, например строки и потоки. Их скорость работы просто потрясает...
И лично мое непрофессиональное мнение, программист должен уметь собирать велосипед за быстрые сроки, а не изобретать его.

Цитата(yaja @ 11.6.2005, 21:55)

ИМХО, штука эта очень "страшная", огромное количество вещей, работа которых не всегда понятна (имеется ввиду то, а что именно кроется за вызовом той или иной функции, что кроется в глубинах STL).

Взять исходники и посмотреть Тем более, они не очень большие.
Вопрос можно? Когда вы вызываете какую-нибудь функцию ОС, вам не страшно из-за того, что вы не знаете (ну или по крайней мере не досконально знаете), что там внутри происходит? Это вообще, имхо, очень важная проблема - доверие к чужому коду.

Цитата(yaja @ 11.6.2005, 21:55)

А вдруг там баги??

Да не вдруг, а точно Но не в STL, а в конкретной реализации (например, печально известная Dinkumware из VC6). И учитывая число программистов, использующих ее, баги эти, как правило, хорошо известны, равно как и способы их объезда.

Цитата(yaja @ 11.6.2005, 21:55)

Некоторые вещи STL просто безобразны, например строки и потоки. Их скорость работы просто потрясает...

Насчет строк - это особый вопрос, неоднократно поднимавшийся в c.l.c.m и RSDN. Я так понял, что основная проблема - излишнее копирование при операциях над строками, однако сделать строковый класс с подсчетом ссылок и copy on write, сохранив потокобезопасность, очень сложно.
По поводу потоков: часто вам от I/O требуется такая скорость, что они не справляются?

Цитата(yaja @ 11.6.2005, 21:55)

И лично мое непрофессиональное мнение, программист должен уметь собирать велосипед за быстрые сроки, а не изобретать его.

Не уловил разницы...

Хорошо. В последний раз попытаюсь выразить свои чувства.

Мне нравится язык С++. Точно также как мне нравится классическая физика - я её понимаю и для меня она логична. НО! Чем отличается техник от наукаря - первый пользуется формулами из справочника, другой - может эти формулы вывести сам (хотя не всегда это делает - только когда необходимо). Чисто эстетически я люблю, когда в моей программе как можно больше моего кода. Я недоверчивый человек, и могу признать, что в какой-либо определённой библиотеке минимум глюков, но я всегда буду стараться обойти эту библиотеку. Многие здесь работают в команде - тут я согласен: велосипеды запрещены. Но лично я всегда программировал (и, как предполагаю, в будущем ситуация не изменится) один, код всех моих программ известен только мне (ну и ещё моему отцу). Поэтому, извините, доводы вроде "лучше не изобретать велосипедов" отметаются. Мне это приятней - значит для меня это лучше! В чужой монастырь со своими законами не лезут, никому я не мешаю.
Теперь мне скажут: "А вдруг?". Действительно, вдруг я вынужден буду когда-нибудь работать в команде? И что?! Я уже разработал свою библиотеку, работающую аналогично тому же STL; неужели вы думаете, что я не смогу за полчаса разобраться в ней? (образно говорю, STL-то я знаю). Могу. И даже больше скажу: разработать что-то своё с нуля намного сложнее, чем "почитать сорсы" и потому я заранее буду круче всех тех, кто занимается последним.
Вопрос только в одном: кому-то оно надо и кто-то имеет время на это, а другим - увы.
P.S. На критику не отвечаю, надоело

ManiaK

Цитата

Могу. И даже больше скажу: разработать что-то своё с нуля намного сложнее, чем "почитать сорсы" и потому я заранее буду круче всех тех, кто занимается последним.

Это так кажется. И это естественное явление, если можно так выразиться. Через это все проходили. Я тоже в молодости был крут в программировании Казалось, что горы сверну. Но как только пришел на работу, получил реальные проекты и посмотрел на настоящий, красиво написанный код - я понял, что ничего не знаю. Тихо, мирно купил хороших книг по С++ и начал все заново
И изобретать велосипеды это тоже естественно. Через это все проходили. Но у нас, например, с тобой отличаи в программировании. У нас разные подходы. Только, не думай, что тебя кто-то считает не компетентным в чем-то, нет.
Тебе за программинг платят? Я думаю, что пока нет. Поэтому и возможность изобретать велосипеды есть. А мне платят. И чем быстрее я закончу проект или поставленную задачу тем лучше для меня. Начальству абсолютно не интересно, как этого я этого добился, как решал поставленные задачи. Их только волнует, грубо говоря, работает или не работает. Но и обязательно условие - это сопровождение кода. Могу написать я, а сопровождать код(добавлять, фиксить баги и т.д.) будет совсем другой человек. Так же я использую сторонние библиотеки. И если каждый из команды начнет изобретать свои велосипеды, потом отлаживать их, потом разбираться в чужих велосипедах - уйдет достаточно много времени. Чем больше времени - тем хуже нам Так что мой выбор STL. Эта вещица стандартизированная и если, что-то не понятно, то можно почитать и разобраться. А то, что в реализациях есть баги... нормально явление В вашем коде сколько баг? Выловить и исправить баги в данном случаи намного быстрее, чем написать свой велосипед, т.к. STL - имеет достачное распространение. Я например, не знавши STL , уже знал, что есть баги в VC от Dinkumware.
В общем, STL - ускоряет разработку в разы и нет нужды в низкокачественных велосипедах.
Ну, а у кого есть время на велосипеды - флаг вам в руки! У меня этого времени уже нет

З.Ы.: Только без обид

З.Ы.Ы: написал, так написал...

НЕНАВИЖУ, еще с консольного С++
Всегда все делал руцями.
Когда перешел к МФС, ВООБЩЕ забыл.
Это мечта АПИ_шников

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

Цитата

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

Это значит, что тим-лидер не знает, какой-то библиотеки Кому охота переучиваться?