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

K> Если язык допускает отрицательный индекс для встроенного массива (которым в общем случае является указатель), значит контейнеры должны соотвествовать этому поведению

Язык не допускает операции с указателями, предшествующими началу массивов. Само получение таких указателей UB. Контейнеры соответствуют этому поведению.

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

kan>Объясни, что является "обычным циклом" при обходе vector? а deque? а list? И почему я должен переписывать этот цикл,
kan>если я вдруг поменял list на vector?

А зачем менять в программе list на vector?
И почему это должно быть легко сделать?

E>А зачем менять в программе list на vector?
E>И почему это должно быть легко сделать?

Это не должно быть легко сделать. Скотт Мейджерс (надеюсь я не переврал имя автора) в своей книги пишет, что важно понимать, что у каждого контейнера — свои особенности поведения. Контейнеры, вообще говоря, не взаимозаменяемы, хотя иногда это и наблюдается.

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

S>Это не должно быть легко сделать. Скотт Мейджерс (надеюсь я не переврал имя автора) в своей книги пишет, что важно понимать, что у каждого контейнера — свои особенности поведения. Контейнеры, вообще говоря, не взаимозаменяемы, хотя иногда это и наблюдается.

Тогда почему лёгкость замены в программе list на vector -- это довод в пользу итераторов?

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

_>IROV.. wrote:

>> IID>for(int i=0; i!=array.size(); ++i)

>> Ты так на всякий случай загляни в std::vector<>::size(), и учти что это
_>Ну так загляни:
_>

_>size_type size() const
_>{    // return length of sequence
_>    return (_Myfirst == 0 ? 0 : _Mylast - _Myfirst);
_>}
_>

тебя устраивает каждый такт цыкла вызывать _лишний_ оператор сравнения?

>> будет вызыватся каждый такт цыкла.
_>

For many containers, such as vector and deque, size is O(1)

_>Это тебе не strlen. Так что мимо тазика.
O(1) бывает разным

зачем платить больше?

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

kan>>Объясни, что является "обычным циклом" при обходе vector? а deque? а list? И почему я должен переписывать этот цикл,
kan>>если я вдруг поменял list на vector?

E>А зачем менять в программе list на vector?
E>И почему это должно быть легко сделать?

У меня в проекте есть один алгоритм, который раньше был реализован вручную и широко использовал объединение множеств. Упорядоченность этих множеств была не важна, поэтому та реализация использовала list.

Позже алгоритм был переписан с использованием сторонней библиотеки. Но ту часть функциональности, которую библиотека не покрывает, всё равно пришлось делать вручную. Исторически сложившийся list остался на месте.

Буквально на днях я прикинул, что больше никакие специфические свойства list’а мне для этого алгоритма не нужны. Я внёс в программу два изменения. Первое — в typedef’е контейнера заменил слово list на vector. Второе — в то место, где этот контейнер заполнялся, добавил reserve(сколько надо).

Программа заработала сразу и дала прирост производительности в 10 миллисекунд на кадр входной видеопоследовательности.

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

kan>>>Объясни, что является "обычным циклом" при обходе vector? а deque? а list? И почему я должен переписывать этот цикл,
kan>>>если я вдруг поменял list на vector?

E>>А зачем менять в программе list на vector?
<...>
C>Буквально на днях я прикинул, что больше никакие специфические свойства list’а мне для этого алгоритма не нужны. Я внёс в программу два изменения. Первое — в typedef’е контейнера заменил слово list на vector. Второе — в то место, где этот контейнер заполнялся, добавил reserve(сколько надо).

C>Программа заработала сразу и дала прирост производительности в 10 миллисекунд на кадр входной видеопоследовательности.

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

R>>Имхо для языка бОльшая чАсть относится к первому типу, чем ко второму
S>Это слишком грубая дихотомия.

Он собственно это потом и добавил:

"There are only two kinds of languages: the ones people complain about and the ones nobody uses". Yes. Again, I very much doubt that the sentiment is original. Of course, all "there are only two" quotes have to be taken with a grain of salt.

S>На деле есть языки, которые используются до сих пор в своих областях, например FORTRAN. Он достаточно неплохо переносим (не 100%, конечно) и имеет неплохую защиту от дурака.

Его не ругают???

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


Ш>У STL много минусов (про некоторые из них можно поискать на форуме), но главный минус (из которого вытекают и все остальные) один -- эта библиотека перестала развиваться. По политическим соображениям STL включили в стандарт. Это привело к замораживанию интерфейса библиотеки (который далек от идеального). Конкретные реализации тоже плохо эволюционируют и не в том направлении. Фактически мы имеем дело с мертвой вещью. Ближайший аналог -- MFC.
Ш>Использовать мертвую вещь для новых проектов не стоит.
Ш>Теперь более конкретно.


Ш>1) STL это библиотека алгоритмов и контейнеров.
Ш>2) Какие алгоритмы есть в этой библиотеке? Из серьёзных и востребованых -- sort, stable_sort, heap_sort . Всё остальное -- не алгоритмы, а мелкие утилиты, в большинстве бесполезные (типа знаменитого for_each).

Ш>sort, stable_sort

Ш>Что это за алгоритмы? А никто не знает -- произвол реализации. Хотя в том же Кнуте вагон алгоритмов сортировки.
Ш>И библиотека, претендующая на стандартную должна не фиг знает что содержать, а чисто конкретно -- sort 2, sort 3, sort 4, ..., quick sort, merge sort,
Ш>intro sort, quick random pivot sort и.т.д.

Ш>3) Контейнеры. Все STL контейнеры расчитаны на копирабельные типы. Это огромный минус. Причем совершенно непонятно, зачем такое ограничение. Никаких технических причин для этого нет. Сами контейнеры. Практически единственный мало-мальски полезный класс -- vector. А где списки? Я знаю много разных типов списков. Где они все? А где деревья? RB-tree AVL-tree B-tree ? Похоже, авторам так и не удалось прочитать Кнута. IQ не хватило.

Ш>Короче. Диагноз -- халтура. Два балла.

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

Я не критикую твой пост, меня и самого STL многим не устраивает, но все же я рад, что она включена в стандарт, и не буду говорить про то, что самого бы посадить в Комитет, и запел бы там, обсуждая, стандартизовывая, etc. Может посмотреть на это дело с бОльшей высоты...

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

R>>Имхо для языка бОльшая чАсть относится к первому типу, чем ко второму
S>Это слишком грубая дихотомия.
S>На деле есть языки, которые используются до сих пор в своих областях, например FORTRAN. Он достаточно неплохо переносим (не 100%, конечно) и имеет неплохую защиту от дурака.

фортран имеет защиту от дурака?
вот здесь поподробнее, какую конкретно?

IROV.. wrote:

> тебя устраивает каждый такт цыкла вызывать _лишний_ оператор сравнения?
Тесты в студию.

>> > будет вызыватся каждый такт цыкла.
> _>
> For many containers, such as vector and deque, size is O(1)
> _>Это тебе не strlen. Так что мимо тазика.
> O(1) бывает разным
> зачем платить больше?
Есть такая штука — premature optimization.

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

kan>Пётр Седов wrote:

>> А>>3. NULL-итераторы
kan>А как имея интервал [begin, NULL), вместо [begin, end) обойти его в обратном направлении (итератор bidirectional)? Или получить 3-ий с конца элемент (итератор random-access)? Или даже просто посчитать длину интервала (итератор random-access)?
Всё как обычно, я не против end-итератора. NULL-итератор — это не терминатор последовательности (как завершающий '\0' в C-строках). NULL-итератор нужен, чтобы ссылаться "в никуда". Здесь

Автор: Пётр Седов
Дата: 07.09.06

я уже ответил Роману Одайскому. Вкратце:

Я имел в виду, чтобы NULL-итератор был не вместо end-итератора, а в дополнение к нему.

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

NB>фортран имеет защиту от дурака?
NB>вот здесь поподробнее, какую конкретно?

Я не знаю что имел в виду автор высказывания, но на фортране однозначно дурак программировать не затянет
Хотя я фортарн люблю, если для вычматов, конечно

Пётр Седов wrote:

>> > А>>3. NULL-итераторы
> kan>А как имея интервал [begin, NULL), вместо [begin, end) обойти его в
> обратном направлении (итератор bidirectional)? Или получить 3-ий с конца
> элемент (итератор random-access)? Или даже просто посчитать длину
> интервала (итератор random-access)?
> Всё как обычно, я не против end-итератора. NULL-итератор — это не
> терминатор последовательности (как завершающий '\0' в C-строках).
> NULL-итератор нужен, чтобы ссылаться "в никуда". Здесь
Так а чем тогда "неициализированный" итератор не устраивает?

std::vector<Type>::iterator nullIterator;

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

NB>>фортран имеет защиту от дурака?
NB>>вот здесь поподробнее, какую конкретно?

E>Я не знаю что имел в виду автор высказывания, но на фортране однозначно дурак программировать не затянет

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

E>Хотя я фортарн люблю, если для вычматов, конечно

давно это было

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

NB>но то что серьезного конроля типов там нет, это факт.
Нахрена он в вычматах?

E>>Хотя я фортарн люблю, если для вычматов, конечно
NB>давно это было
Мне пока что пригождается время от времени

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

NB>>но то что серьезного конроля типов там нет, это факт.
E>Нахрена он в вычматах?

от дураков защищаться

E>>>Хотя я фортарн люблю, если для вычматов, конечно
NB>>давно это было
E>Мне пока что пригождается время от времени

главное, чтобы это приносило удовлетворение.

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

NB>>>но то что серьезного конроля типов там нет, это факт.
E>>Нахрена он в вычматах?

NB>от дураков защищаться

Да там типы всё время одни и теже. Столбец чисел, да матрица чисел. Так что контролируй типы не контролируй а толку никакого

NB>фортран имеет защиту от дурака?
NB>вот здесь поподробнее, какую конкретно?
Там нельзя сделать такое:

int*p=0;
*p=4;