контейнеры stl, out of range

[sss]

Алексей1153++, у меня есть совет - попробуй хранить не просто указатели, а указатели на объекты со счетчиком ссылок.  Так сделано везде в ОС, где объекты разделяются между несколькими потоками и списками и скорее всего является лучшим решением.... Тогда будет четкое соответствие: структура узла создается и увеличивает счетчик ссылки на объект данных, переданный как параметр конструктора. В деструкторе - уменьшает свой счетчик.  Вообще, [мое мнение] - в топку STL... Когда дело доходит до многопоточности и многоссылочности - городят огород и кричат - смотрите как красиво....  [/мое мнение]

[Алексей++]

До компутера дома не добрался, ребёнок вввымотал )) (Вру, добрался, но до студии - нет )) Так что, опять до вечера.

sss, я раньше STL не пользовался, сейчас начинаю пробовать и понимаю, что где-то он ОЧЕНЬ удобный (в плане скорости реализации алгоритма) , а где-то, как в моём сейчас случае, лучше по старинке, ручками. Всё равно я напишу так, что будет работать быстрее и с меньшими затратами памяти, чем с STL. А потом стану экспериментировать, благо ночи длинные

[lapulya]

sss, stl это часть!!! языка, как и статические переменные (в топку их!!! они "не поддерживают" многопоточность), например, можно их использовать, а можно и не использовать, дело программиста. stl многопоточности не помеха (обратное то же верно). Я вообще не понимаю как stl мешает многопоточности... если рассуждать следуя твоей логике , то все классы MFC (ну почти все), все API функции (ну за исключением тех, что отвечают за синхронизацию потоков), да почти вообще все мешает многопоточности! В топку все это!

[Алексей++]

lapulya, я хоть раз написал про "в топку" ? ) Я оцениваю, какой путь займёт меньше времени и более понятен. Вот и всё. Не надо столько эмоций ))) В том же MFC есть вещи, которыми я не пользуюсь, используя вместо их более понятные АПИ. А что-то в MFC сделано удобнее

[lapulya]

Алексей1153++, ээээ так я sss писал, а не тебе (спать надо раньше ложиться ).

[Алексей++]

гы. Ну неважно)))

[Антон (LogRus)]

LogRus,
Я бы так делать не советовал... насколько мне помнится (могу и ошибаться), но

Стандарт гарантирует, что вектор должен выделить последовательный участок памяти для хранения в нем данных, но только это... т.е. ни больше и ни  меньше. То, что вектор обязан выделить массив элементов этого типа и более того, что доступ к i-ому элементу возможен по такому адресу *(vector[0] + i), этого стандарт не гарантирует (во втором я уверен почти на 100% ).

парирую
Ну что же разберёмся в причинах и следствиях
Причина: вектор гарантировано выделяет не прерывный блок памяти под хранимые элементы
Следствие: можешь спокойно пользоваться алгеброй указателей используя указатель на первый элемент в качестве начала непрерывного блока данных.

LogRus,
...... Да, большинство компиляторов именно так и делают (подозреваю, что так делают все компиляторы), но используя доступ подобным образом программист действует на свой страх и риск. 

парирую
1. Компилятор тут не причём, берём исходник STL и читаем.
2. я не призывал, использовать странные конструкции для получения доступа к элементу вектора, я всего лишь показывал, что механизмы доступа по индексу просты и эффективны

Добавлено через 11 минут и 41 секунду:

Алексей1153++, у меня есть совет - попробуй хранить не просто указатели, а указатели на объекты со счетчиком ссылок.  Так сделано везде в ОС, где объекты разделяются между несколькими потоками и списками и скорее всего является лучшим решением.... Тогда будет четкое соответствие: структура узла создается и увеличивает счетчик ссылки на объект данных, переданный как параметр конструктора. В деструкторе - уменьшает свой счетчик.

boost::shared_ptr

[мое мнение] - в топку STL... Когда дело доходит до многопоточности и многоссылочности - городят огород и кричат - смотрите как красиво....  [/мое мнение]

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

[lapulya]

LogRus, не... выводы не правильные, где написано (может конечно и написано, но я не помню), что в выделенном вектором участке памяти:
1. элементы идут последовательно (0, 1, 2, ...)
2. элементы идут без пропусков адресного пространства (т.е. например между 0 и 1 нет места еще под несколько элементов)
3. что под каждый элемент выделяется ровно столько памяти, сколько нужно для хранения ровно 1 элемента, а например не больше (для каких то там целей оптимизации и т.д...)

Итого, твои выводы не верны, при условии, где-то в стандарте не опровергнуты мои пункты и им подобные (я такого не помню. хотя мог и забыть)

Да про компиляторы я нагорбил ))))) конечно речь о реализации stl, но суть дела не меняет.

[Алексей++]

где написано, что в выделенном вектором участке памяти:
1. элементы идут последовательно (0, 1, 2, ...)
2. элементы идут без пропусков адресного пространства (т.е. например между 0 и 1 нет места еще под несколько элементов)
3. что под каждый элемент выделяется ровно столько памяти, сколько нужно для хранения ровно 1 элемента, а например не больше (для каких то там целей оптимизации и т.д...)

по-моему, всякий нормально себя чувствующий разработчик так сделает

[lapulya]

Алексей1153++, ну ясен пень, но разговор о стандарте (о законности написания кода), а не о реализации. То, что не гарантировано стандартом, может быть реализовано как угодно (пусть и в теории), поэтому эээ по-хорошему так писать нельзя (ну мало ли, что там будет в другой версии библиотеки... кстати эту ошибку потом хрен найдешь, ну найдешь конечно, но придется хорошо так подебажить ).

И потом... это очень мало вероятно, но возможна следующая реализация:
1. поскольку при вставке элементов в середину вектора (худший случай в начало)
2. поскольку при удалении элементов из середины вектора (худший случай удаление первого)
происходит (во всех "нормальных", т.е. 99% реализациях) копирование (сдвиг) элементов внутри выделенного вектором объема памяти. Таким образом можно представить такую реализацию, при которой элементы из середины не удаляются, а только помечаются как удаленные (при этом копирования не происходит) и если производится вставка элемента в середину и попадаем в "удаленный" элемент, то вставка производится так же без копирования (ну понятно, что есть свои минусы, хотя понятно, что для больших векторов и частых, но равных по количеству операций удалений и вставок вектор будет работать быстрее).

[Алексей++]

во-первых, неплохо приписывать к коду - в какомй среде сиё писалось. И если несовместимость есть - это всплывёт у всех, поэтому точно можно будет знать, что вот это не работает при переносе с X на Y, а там и разработчики новой среды призадумаются, что неплохо бы сделать "как у всех" Так что, стандарт - это то, что уже много лет работает.

[lapulya]

Алексей1153++, меня как разработчика клиентского кода для данной или любой другой библиотеки совершенно по барабану в какой среде она писалась, мне нужно чтобы она работала в моей среда (все остальное мне до лампы). Разработчик библиотеки (stl имеется ввиду, как часть языка), как и разработчик компилятора ориентируется на стандарт, а не на "всех остальных". Для того чтобы его реализация библиотеки была востребована, она должна жестко следовать стандарту и быть:
1. максимально быстрой
2. жрать меньше памяти
3. собираться без проблем на любом компиляторе, который также следует стандарту
если все это есть, то это лучшая библиотека, все остальное значения не имеет. Да, если клиент библиотеки рассчитан на "как у всех", то с этой (лучшей) библиотекой клиентский код работать не сможет, но это проблемы клиента, чтобы проблем не было надо следовать стандарту и не полагаться на конкретные или удобные реализации (или как вариант брать нужные тебе исходники библиотеки в исходный код клиента, что не круто, потому как поддерживать и развивать библиотеку придется уже самому)

[Алексей++]

если клиент библиотеки рассчитан на "как у всех", то с этой (лучшей) библиотекой клиентский код работать не сможет, но это проблемы клиента

вот эту строчку я не понял

[lapulya]

Алексей1153++, ну если ты пишешь код и пользуешься библиотекой (пусть stl, поскольку на нее есть стандарт), и посмотрев в текущую реализацию библиотеки видишь, что, например, вектор пишет элементы строго последовательно, без пропусков и что размер выделенный под один элемент строго равен размеру элемента (не выделяется лишнего) и т.д., то ты возможно напишешь в своем коде прямое смещение по указателю (ну для i элемента + i сделать), что бы типа на пару тактов было быстрее... да с данной реализацией этот момент будет быстрее. И вот выходит новая версия (ну или другой производитель) и она работает в 2 раза быстрее, но она имеет уже другую организацию размещения элементов вектора в памяти. Твой клиентский код с ней работать не сможет, т.к. он завязан на реализацию вектора текучей версии библиотеки. 

Добавлено через 6 минут и 4 секунды:
Алексей1153++, в параллельной ветке идет обсуждение строк в частности про c_str(), так вот в stl string так же имеет c_str и возвращает (по стандарту!!!) хранимые данные, но как правило возвращается внутренний буфер, скастив const char * к char * по идее можно просто писать прямо в буфер! но если реализация будет другая....

[Вад]

lapulya, насколько я помню, все мэтры наперебой рекомендуют использовать vector<Type> взамен Type* при необходимости передать буфер в качестве параметра в функциях, использующих C-style-массивы. То есть, буквально

Код:

void foo(Type* buf, int size)
{
// blahblahblah
}

vector<Type> vec;
// ...
foo(&vec[0], vec.size());

считается вполне нормальным приёмом.

  23.2.4 Class template vector                                                                       [lib.vector]
1  A vector is a kind of sequence that supports random access iterators. In addition, it supports (amortized)
  constant time insert and erase operations at the end; insert and erase in the middle take linear time. Storage
  management is handled automatically, though hints can be given to improve efficiency. The elements of a
  vector are stored contiguously, meaning that if v is a vector<T, Allocator> where T is some type
  other than bool, then it obeys the identity &v[n] == &v[0] + n for all 0 <= n < v.size().

[lapulya]

Вад,

насколько я помню, все мэтры наперебой рекомендуют использовать vector<Type> взамен Type* ....

Я б посмотрел в каком контексте они это рекомендуют, т.е. что именно за объекты они рекомендуют туда засовывать, я ж писал, что если речь идет например о string, то и я бы рекомендовал использовать vector<string>. Если же там что-то более мутное (ну имеющее не 3 простых мембера класса, а что-то навороченное), да еще и имеющего внешние ссылки, то как же тут хранить vector<Type>. Более того, как я уже писал, при хранении vector<Type> нет возможности запихать в вектор объекты производных классов. ИМХО все зависит, от того что собираемся хранить, в большинстве случаев (ну у меня так получалось ) если в контейнере (не только в векторе) хранились объект мои классов или классов сторонних модулей (по отношению к моему модулю), то там или хранились объекты, на которые имелись (могли иметься, если объект не мой) внешние ссылки или объекты производных классов, так что vector<Type> ну ни как не прокатывал. Хотя конечно были и такие vector<string>, vector<int>, vector<Rect> (где Rect это структура c двумя int) и т.п.
Дааа , еще многие объекты создавались и уничтожались фабриками, так что их также нельзя хранить vector<Type>, можно, конечно, их заворачивать в умные указатели, но эта техника у меня не прижилась (у меня утечек практически никогда не было, были конечно исключения , но они отлавливались и уничтожались), то и нужны в подобных конструкциях я никогда не испытывал.

Оппааа  

Цитата: ANSI ISO/IEC 14882:2003

... &v[n] == &v[0] + n for all 0 <= n < v.size()

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

[Антон (LogRus)]

LogRus, не... выводы не правильные, где написано (может конечно и написано, но я не помню)

собственно всё сказано
единственное, что я напутал, так это причину и следствие