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

_>перечислите, на ваш взгляд, основные минусы STL
_>принимаются только ответы с аргументацией

невозможность привязки итераторов к виджетам
т.е. если у меня есть например stl-список в памяти и экранный список в диалоге, нет никакой возможности запихнуть итераторы в 32-битные поля SetItemData, передать через lParam и т.д.
по возможности пользуюсь аналогичными классами MFC, в которых вместо итераторов есть замаечательный тип POSITION
для кроссплатформенных проектов думаю выдрать afxtempl их MFC и сделать свою маленькую библиотеку контейнеров (а заодно немного расширить контейнеры MFC).

еще общие соображения: STL слишком крут для С++. В самом языке нет тех возможностей, чтобы библиотеки типа STL выглядели более дружественно. Отсюда все эти шаблонные навороты. Такие фундаментальные концепции как "контейнер", "итератор" и "алгоритм" стоит реализовывать на уровне самих языков, а не городить огороды с шаблонами.

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

XC>еще общие соображения: STL слишком крут для С++. В самом языке нет тех возможностей, чтобы библиотеки типа STL выглядели более дружественно. Отсюда все эти шаблонные навороты. Такие фундаментальные концепции как "контейнер", "итератор" и "алгоритм" стоит реализовывать на уровне самих языков, а не городить огороды с шаблонами.

Да там главная мулька -- это бесконечная расширяемость STL.
На практике, же попытка воспользоваться этой мулткой -- признак чистейшего и незамутнённого безумия. ИМХО, разумеется

А вообще идея продумать и написать небольшую юиюлиотеку, в которой будут
массивы, списки, деревья и простые умные указатели
Хэши и хэшмэпы (а не то прекрасное изделие, которое есть в stl под названием map)
стредства управления памятью
средства доступа к бинарным файлам
средства сериализации в текст (хотя против потоков я как раз ничего не имею, просто хочется, чтобы всё совместимо осталось)
средства сереализации в бинарный архив
система исключений
строчки.

И типа более или менее всё -- она позитивная весьма.

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

E>>всех -- это всех встречающихся у пользователей
LM>На скольких типах процессоров\матерей Вы свою программу тестировали?

Сотнях.

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

RO>Предлагаю реализовать аналог std::deque без итераторов.
А в чём проблема?

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

T>По моему STL-ем пытались решить именно эту проблему.
T>Сейчас её же пытается решить BOOST...
ИМХО, причина в некоторой консервативности комитета. Примерная цитата из "Дизайн и эволюция С++"(о принятие очереднрого стандарта)

В некоторый момент мы были вынуждены остановить прием новых заявок(на изменение\дополнение), т.к. уже внесенных(но нерасмотренных) предложений было очень много. И не сделай мы этого стандарт никогда бы не вышел, т.к. скорость поступления заявок превышал скорость их рассмотрения

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

T>Здравствуйте, LuciferMoscow, Вы писали:
LM>>Покажите мне массив, который может увеличивать свой размер, не требующий памяти их хипа. Я хочу ЭТО увидеть

<skipped>
T>выдача:
T>

T>D:\Lang\test>g++ -o din_arr din_arr.cpp
T>D:\Lang\test>din_arr.exe 10
T>0, 1, 2, 3, 4, 5, 6, 7, 8, 9
T>

T>g++ (GCC) 3.4.5 (mingw special)

MS VC++ 8
Error 1 error C2057: expected constant expression f:\porno\zoofilia\hard\test\test\test.cpp 15

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

S>Ну, а те, кого не интересует мнения классиков, обречены вечно наступать на свои же грабли.
S>Ибо, как известно, дурак учится на своих ошибках, а умный на чужих %).

S>К сожалению, такой порядок дел не изменить в силу все той же закостенелости мышления и нежелании что-либо менять.
S>Поэтому, ИМХО, данная ветка уже давно перешла в ранг холиворов вроде C vs C++.

S>Остается только надеяться, что такое положение дел положительно скажется на развитии стандартной библиотеки.

Не знаю. Вот, например, никто мне так и не объяснил зачем нужны алгоритмы? Вот все эти count_if и foreach и merge?
Особенно хотелось бы понять, зачем нужен merge. В смысле почему нигде кроме stl нет такой *сверхнужной* фичи в стандартной библиотеке?

Насколько я понимаю в STL есть две великие идеи.
1) STL бесконечно расширяем. Туда можно дописывать новые контейнеры, алгоритмы, примитивы и всё будет совершенно монолитно и бесшовно интегрировано с STL. В этом смысле претензия, что типа нету B-деревьев, несостоятельная. Надо добавить B-деревья просто и всё.
2) Он совместим в смысле совместимости C++. То есть есть набор всяких соглашений и гарантий, которые будут выполняться любой реализацией и на любой платформе. Это конечно тоже очень круто и прикольно сделано
Ну и есть ещё одна тонкость -- STL ещё и довольно эффективен, и типобезопасен при этом.

Это всё конечно плюсы. Минусы же такие, что STL не только тяжек в применении к реальным задачам, но ещё и переусложнён
То есть, как это ни странно, расширяемость STL, ИМХО, вообще не нужная фича. Алгоритмы -- тоже очень ограниченно полезная.
Совместимость STL на поверку оказывается фикцией, так как он очень сложный и код, его использующий, тоже сложный, а ошибки на каждой комбинации платформы и версии STL проявляются свои
Ну а эффективность STL она не благадаря этакой его кудрявости, всё-таки, а скорее вопреки.
Вот собственно поэтому некоторым людям STL и не нравится.

Конечно если у тебя нет никакой друго библиотеки примитивов и контейнеров, то надо использовать STL, чем писать просто на голом C++.
Но если вдруг есть, или есть ресурсы, для разработки такой библиотеки, то, ИМХО, лучше пользоваться своей простой и понятной и эффективной и расширяемой конструкцией.

То есть получается немного парадоксально. Если у вас большой-пребольшой проект и контора, то вам конечно мог бы пригодиться прекрасный мощный и универсальный stl, но намного лучше вам подойдёт что-нибудь более простое и более по месту.

А если у вас короткий, компактный, дешёвый проект, то вам вся мощь STL только мешает

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

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

S>>Не надо далеко ходить... Нет способа преобразовать число в std::string и обратно. Так, чтобы было одновременно быстро, удобно и безопасно.

_>вот интерестно где есть такое? и чтоб всем трём одновременно условиям удовлетворяло?

Ну PowerPlant, например, тебя устроит?

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

ШЕ>Каждый раз натыкаюсь, и каждый раз матерюсь.
ШЕ>Бывает надо написать обощённый класс, который возвращает ссылку на тип,
ШЕ>а контейнер там vector и надо вдруг bool использовать...

ШЕ>... и начинаются подпорки ввиде специализаций и замены
ШЕ>внутреннего типа на какой-нибудь char

Его удаляют из следующей версии стандарта

You will always get what you always got
  If you always do  what you always did

Здравствуйте, LuciferMoscow, Вы писали:
T>>Здравствуйте, LuciferMoscow, Вы писали:
LM>>>Покажите мне массив, который может увеличивать свой размер, не требующий памяти их хипа. Я хочу ЭТО увидеть
<skipped>
T>>g++ (GCC) 3.4.5 (mingw special)
LM>

LM>MS VC++ 8
LM>Error 1 error C2057: expected constant expression f:\porno\zoofilia\hard\test\test\test.cpp 15

Ты где-то просил чтобы решение было переносимо?

А если серьёзно, то это расширение gcc всего лишь синтаксическая надстройка над alloca+placement new.
Сочинить собственный велосипед в эту тему — тривиально.

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

LM>>>>Покажите мне массив, который может увеличивать свой размер, не требующий памяти их хипа. Я хочу ЭТО увидеть
T>>>g++ (GCC) 3.4.5 (mingw special)
LM>>

LM>>MS VC++ 8
LM>>Error 1 error C2057: expected constant expression f:\porno\zoofilia\hard\test\test\test.cpp 15

T>Ты где-то просил чтобы решение было переносимо?
Это подразумевалось, т.к. мы говорим об STL. А как добавлять элементы в Ваш массив?

T>А если серьёзно, то это расширение gcc всего лишь синтаксическая надстройка над alloca+placement new.
T>Сочинить собственный велосипед в эту тему — тривиально.

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

E>Это всё конечно плюсы. Минусы же такие, что STL не только тяжек в применении к реальным задачам, но ещё и переусложнён
E>То есть, как это ни странно, расширяемость STL, ИМХО, вообще не нужная фича. Алгоритмы -- тоже очень ограниченно полезная.
E>Совместимость STL на поверку оказывается фикцией, так как он очень сложный и код, его использующий, тоже сложный, а ошибки на каждой комбинации платформы и версии STL проявляются свои

E>Ну а эффективность STL она не благадаря этакой его кудрявости, всё-таки, а скорее вопреки.
Почему???

E>Конечно если у тебя нет никакой друго библиотеки примитивов и контейнеров, то надо использовать STL, чем писать просто на голом C++.
E>Но если вдруг есть, или есть ресурсы, для разработки такой библиотеки, то, ИМХО, лучше пользоваться своей простой и понятной и эффективной и расширяемой конструкцией.

E>А если у вас короткий, компактный, дешёвый проект, то вам вся мощь STL только мешает
E>Просто в STL так много всяких кустов и деревьев, что за ними виден прекрасный и полезный "лес", только на довольно большом проекте. А там, как раз, без него ещё лучше всё выходит.
E>Ну а если вдруг таки у вас проект попроще, то сверхсложные синтаксические кусты просто закроют от вас лес и ничего вы позитивного не увидите.

Ты не поверишь, наверное, но я во всех своих мелких проектах (включая те, которые я делаю дома для себя, просто чтоб сделать какую-нть мелкую фигню) использую STL и ну вообще никаких проблем с ним не испытываю. А уж тем более в комбинации с boost. И "вся его мощь" мне только помогает

You will always get what you always got
  If you always do  what you always did

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

LVV>Подчеркивание того, что множество — ассоциативный контейнер — только с толку сбивает начинающего...
Действительно, начинающему куда как понятнее, как написать хорошую хэш-функцию

LVV>Множество — это множество, как бы оно ни было реализовано...
LVV>Подчеркивать специфику реализации не стоило и для map — можно было б и как хеш реализовать...
Не понял. Ты как собираешься уникальность ключей гарантировать? Вот что бы ты не ответил, я тебе на это скажу: это и является спецификой предлагаемой тобой реализации, это и есть те самые "уши". Если через operator== — все типы должны подерижвать его. Если через hash_func — то же самое. Если через std::less или явный предикат (как в STL) — то же самое.

Выбор STL в далеко не самый плохой, потому что через operator== я вообще не представляю, как можно гарантировать что-либо, кроме уникальности (например, скорость поиска). Написание хорошей хэш-функции — задача далеко не тривиальная. Можешь в качестве упражнения написать хорошую хэш-функцию для int. А в STL мы имеем, в первую очередь, очень большую гибкость благодаря тому, что мы можем понимать эквивалентность ключей как нам заблагорассудится, даже для одного и того же типа; во-вторых, мы имеем вполне хорошую скорость поиска (логарифмическую); в-третьих, мы абсолютно на халяву получаем возможность доступа к контейнеру как к сортированной по нашему вкусу последовательности, что является крайне часто встречающейся задачей.
Так что в качестве универсального решения, которое подойдет на все случаи жизни, кроме особо критичных по скорости (когда имеет смысл использовать хэш), STL очень даже хороша.
Опять же, у хэшей своих проблем хватает, и без понимания того, как хэш будет работать в твоем _конкретном_ случае (т.е. на конкретных ожидаемых тобой данных), вообще лучше в хэш не соваться. Ты-то должен понимать, что "просто хэша" не бывает: чтобы быть эффективным, он должен быть заточен под конкретные условия использования.

LVV>А набор алгоритмов — это вообще напорминает свалку...
А конкретнее? Что ты предлагаешь?

LVV>И похоже на то, что новой редакции STL мы не скоро дождемся... Тока вместе со стандартом...
Естественно, потому что STL (т.е. библиотеки фирмы SGI) — такой штуки не существует в контексте данного обсуждения, а существует стандартная библиотека С++, которая, естественно, является частью стандарта С++.

You will always get what you always got
  If you always do  what you always did

VC6 — Оказывается в Watch есть символы форматирования http://rsdn.ru/article/vcpp/vcdebug-1.xml

Автор(ы): Александр Шаргин
Дата: 27.01.2002

d, i целое со знаком
U беззнаковое целое
O беззнаковое восьмеричное целое
x, X беззнаковое шестнадцатеричное целое
l, h "длинное" или "короткое" целое (префиксы, используемые совместно с символами d, i, u, o, x, X)
F вещественное число со знаком
E вещественное число со знаком в научной нотации
G вещественное число со знаком (нотация выбирается автоматически)
C cимвол
S строка в кодировке ANSI
Su строка в кодировке Unicode
St строка в кодировке ANSI или Unicode
Hr HRESULT или код ошибки Win32
Wc флаг класса окна
Wm код сообщения
<число> количество элементов массива

Дело в том что последний работает только для указателей в отличии от Борланда, поэтому мне раньше казалось что его нет.

И возможен доступ к вектору из отладчика по внятным именам dv._First,9 и такое dv._Last-dv._First . У Борланда этого не было. Кроме того VC6 сложные инлайны инлайнит до 256-уровня (регулируется) вложенности.

E>Ну PowerPlant, например, тебя устроит?

не знаю
а что это?

XC>невозможность привязки итераторов к виджетам
XC>т.е. если у меня есть например stl-список в памяти и экранный список в диалоге, нет никакой возможности запихнуть итераторы в 32-битные поля SetItemData, передать через lParam и т.д.
XC>по возможности пользуюсь аналогичными классами MFC, в которых вместо итераторов есть замаечательный тип POSITION
XC>для кроссплатформенных проектов думаю выдрать afxtempl их MFC и сделать свою маленькую библиотеку контейнеров (а заодно немного расширить контейнеры MFC).

как мне кажется тут проблема у MFC... т.к. выделенное это С стиль

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

E>>Ну PowerPlant, например, тебя устроит?

_>не знаю
_>а что это?

Коммерческая библиотека классов, которая поставляется, например, с CodeWarrior

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

_>как мне кажется тут проблема у MFC... т.к. выделенное это С стиль
Ну так и винда и Х-винда и интерфейсы на всяких телефонах-контроллерах-кофеварках они все C-стиль

Как-то реальные задачи хочется программировать в реальных системах а не в последовательных С++-системах будущего
Тем более, что вдруг оно не наступит?

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

XC>>невозможность привязки итераторов к виджетам
XC>>т.е. если у меня есть например stl-список в памяти и экранный список в диалоге, нет никакой возможности запихнуть итераторы в 32-битные поля SetItemData, передать через lParam и т.д.
XC>>по возможности пользуюсь аналогичными классами MFC, в которых вместо итераторов есть замаечательный тип POSITION
XC>>для кроссплатформенных проектов думаю выдрать afxtempl их MFC и сделать свою маленькую библиотеку контейнеров (а заодно немного расширить контейнеры MFC).

_>как мне кажется тут проблема у MFC... т.к. выделенное это С стиль

а как решить эту задачу используя C++ стиль?

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

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

E>>>Ну PowerPlant, например, тебя устроит?

_>>не знаю
_>>а что это?

E> Коммерческая библиотека классов, которая поставляется, например, с CodeWarrior

а её можно посмотреть не покупая?