Здравствуйте, 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>>Покажите мне массив, который может увеличивать свой размер, не требующий памяти их хипа. Я хочу ЭТО увидеть
Здравствуйте, 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
Здравствуйте, LuciferMoscow, Вы писали: T>>Здравствуйте, LuciferMoscow, Вы писали: LM>>>Покажите мне массив, который может увеличивать свой размер, не требующий памяти их хипа. Я хочу ЭТО увидеть
<skipped> T>>g++ (GCC) 3.4.5 (mingw special) LM>
А если серьёзно, то это расширение gcc всего лишь синтаксическая надстройка над alloca+placement new.
Сочинить собственный велосипед в эту тему — тривиально.
Здравствуйте, Tonal-, Вы писали:
LM>>>>Покажите мне массив, который может увеличивать свой размер, не требующий памяти их хипа. Я хочу ЭТО увидеть T>>>g++ (GCC) 3.4.5 (mingw special) LM>>
T>Ты где-то просил чтобы решение было переносимо?
Это подразумевалось, т.к. мы говорим об STL. А как добавлять элементы в Ваш массив?
T>А если серьёзно, то это расширение gcc всего лишь синтаксическая надстройка над alloca+placement new. T>Сочинить собственный велосипед в эту тему — тривиально.
... << RSDN@Home 1.1.4 beta 4 rev. 358>>
Re[3]: Возвращаясь к украинской теме: Сколько же точек над i
Здравствуйте, Erop, Вы писали:
E>Это всё конечно плюсы. Минусы же такие, что STL не только тяжек в применении к реальным задачам, но ещё и переусложнён E>То есть, как это ни странно, расширяемость STL, ИМХО, вообще не нужная фича. Алгоритмы -- тоже очень ограниченно полезная. E>Совместимость STL на поверку оказывается фикцией, так как он очень сложный и код, его использующий, тоже сложный, а ошибки на каждой комбинации платформы и версии STL проявляются свои
E>Ну а эффективность STL она не благадаря этакой его кудрявости, всё-таки, а скорее вопреки.
Почему???
E>Конечно если у тебя нет никакой друго библиотеки примитивов и контейнеров, то надо использовать STL, чем писать просто на голом C++. E>Но если вдруг есть, или есть ресурсы, для разработки такой библиотеки, то, ИМХО, лучше пользоваться своей простой и понятной и эффективной и расширяемой конструкцией.
E>А если у вас короткий, компактный, дешёвый проект, то вам вся мощь STL только мешает E>Просто в STL так много всяких кустов и деревьев, что за ними виден прекрасный и полезный "лес", только на довольно большом проекте. А там, как раз, без него ещё лучше всё выходит. E>Ну а если вдруг таки у вас проект попроще, то сверхсложные синтаксические кусты просто закроют от вас лес и ничего вы позитивного не увидите.
Ты не поверишь, наверное, но я во всех своих мелких проектах (включая те, которые я делаю дома для себя, просто чтоб сделать какую-нть мелкую фигню) использую STL и ну вообще никаких проблем с ним не испытываю. А уж тем более в комбинации с boost. И "вся его мощь" мне только помогает
Здравствуйте, LaptevVV, Вы писали:
LVV>Подчеркивание того, что множество — ассоциативный контейнер — только с толку сбивает начинающего...
Действительно, начинающему куда как понятнее, как написать хорошую хэш-функцию
LVV>Множество — это множество, как бы оно ни было реализовано... LVV>Подчеркивать специфику реализации не стоило и для map — можно было б и как хеш реализовать...
Не понял. Ты как собираешься уникальность ключей гарантировать? Вот что бы ты не ответил, я тебе на это скажу: это и является спецификой предлагаемой тобой реализации, это и есть те самые "уши". Если через operator== — все типы должны подерижвать его. Если через hash_func — то же самое. Если через std::less или явный предикат (как в STL) — то же самое.
Выбор STL в далеко не самый плохой, потому что через operator== я вообще не представляю, как можно гарантировать что-либо, кроме уникальности (например, скорость поиска). Написание хорошей хэш-функции — задача далеко не тривиальная. Можешь в качестве упражнения написать хорошую хэш-функцию для int. А в STL мы имеем, в первую очередь, очень большую гибкость благодаря тому, что мы можем понимать эквивалентность ключей как нам заблагорассудится, даже для одного и того же типа; во-вторых, мы имеем вполне хорошую скорость поиска (логарифмическую); в-третьих, мы абсолютно на халяву получаем возможность доступа к контейнеру как к сортированной по нашему вкусу последовательности, что является крайне часто встречающейся задачей.
Так что в качестве универсального решения, которое подойдет на все случаи жизни, кроме особо критичных по скорости (когда имеет смысл использовать хэш), STL очень даже хороша.
Опять же, у хэшей своих проблем хватает, и без понимания того, как хэш будет работать в твоем _конкретном_ случае (т.е. на конкретных ожидаемых тобой данных), вообще лучше в хэш не соваться. Ты-то должен понимать, что "просто хэша" не бывает: чтобы быть эффективным, он должен быть заточен под конкретные условия использования.
LVV>А набор алгоритмов — это вообще напорминает свалку...
А конкретнее? Что ты предлагаешь?
LVV>И похоже на то, что новой редакции STL мы не скоро дождемся... Тока вместе со стандартом...
Естественно, потому что STL (т.е. библиотеки фирмы SGI) — такой штуки не существует в контексте данного обсуждения, а существует стандартная библиотека С++, которая, естественно, является частью стандарта С++.
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-уровня (регулируется) вложенности.
XC>невозможность привязки итераторов к виджетам XC>т.е. если у меня есть например stl-список в памяти и экранный список в диалоге, нет никакой возможности запихнуть итераторы в 32-битные поля SetItemData, передать через lParam и т.д. XC>по возможности пользуюсь аналогичными классами MFC, в которых вместо итераторов есть замаечательный тип POSITION XC>для кроссплатформенных проектов думаю выдрать afxtempl их MFC и сделать свою маленькую библиотеку контейнеров (а заодно немного расширить контейнеры MFC).
как мне кажется тут проблема у MFC... т.к. выделенное это С стиль
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, gid_vvp, Вы писали:
_>как мне кажется тут проблема у MFC... т.к. выделенное это С стиль
Ну так и винда и Х-винда и интерфейсы на всяких телефонах-контроллерах-кофеварках они все C-стиль
Как-то реальные задачи хочется программировать в реальных системах а не в последовательных С++-системах будущего
Тем более, что вдруг оно не наступит?
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, gid_vvp, Вы писали:
XC>>невозможность привязки итераторов к виджетам XC>>т.е. если у меня есть например stl-список в памяти и экранный список в диалоге, нет никакой возможности запихнуть итераторы в 32-битные поля SetItemData, передать через lParam и т.д. XC>>по возможности пользуюсь аналогичными классами MFC, в которых вместо итераторов есть замаечательный тип POSITION XC>>для кроссплатформенных проектов думаю выдрать afxtempl их MFC и сделать свою маленькую библиотеку контейнеров (а заодно немного расширить контейнеры MFC).
_>как мне кажется тут проблема у MFC... т.к. выделенное это С стиль
Здравствуйте, Erop, Вы писали:
E>Здравствуйте, gid_vvp, Вы писали:
E>>>Ну PowerPlant, например, тебя устроит?
_>>не знаю _>>а что это?
E> Коммерческая библиотека классов, которая поставляется, например, с CodeWarrior