Адрес элемента в векторе

привет всем!

есть код
он выводит например
0x19abc28
0x19abc28

подскожите всегдали вывод во второй строке будет такой же как в первой7
число элементов в векторе больше либо равно три конечно же!

0

Croessmah, ну я же честно написал:

Сообщение от Друг ньюфага Я бы сам никогда не догадался, если бы не прочитал у умных людей

Скажу ещё прямее: я подобрал тему на околокомитетской помойке (хоть и открытый мейл-лист, но там тусуются люди из комитета).

Реализовать std::vector в текущей модели памяти C++ без UB невозможно. Доказывать мне обратное бессмысленно, т.к. это не моё мнение. Да, я буду давить авторитетом.

Хотя желание поспорить понятно. Многим неуютно, когда идиоматический код оказывается нагромождением UB. Поэтому модель памяти собираются пропатчить так, что можно будет реализовать вектор с этой гарантией "непрерывности".

Сообщение от Croessmah т.е. array object не обязан быть object of array type.

Если полазать по стандарту, то видно, что "array object" называют именно массивы.

Сообщение от Croessmah new-expression может выделять array object, но при этом возвращает указатель не на array type.

Ну, за что Страуструпу надо оторвать яйца, можно лишний раз не напоминать.

Кстати, забавно:

Сообщение от Croessmah т.е. указатель на одиночный объект будет вести себя так, как будто он является указателем на первый элемент массива с размером 1.

Именно поэтому в коде написано &v[0] + 2
Чтобы нельзя было сослаться на это место.

Про new мне позволю себе подробно не разбирать. Отвечу так: когда в C вводили правило strict aliasing-а, возникла проблема: malloc принимает только размер и возвращает void*, какой же тип выделяет malloc, чтобы можно было кастануть этот void* и пользоваться памятью через типизированный указатель не нарушая strict aliasing-а? Решение было примерно таким: память под какой тип программист намеревался выделить, на кусок памяти такого типа malloc и возвращает указатель. malloc — это волшебная функция.
new это тоже волшебное выражение. У него особая роль в C++ — оно может создавать объекты. Даже если new[] сделан через new(size), то выделяется массив. Почему? Магия.
Если в стандарте кривоватые формулировки по поводу new (типа как под спойлером), их можно поправить.

А вот для работы вектора без UB нужно вносить правки серьёзнее исправления формулировок.

Добавлено через 40 минут

Сообщение от Croessmah Т.е. адресация между его началом и концом будет в пределах одного массива байт.

Мысль в правильном направлении. Примерно так и хотят пофиксить проблему с вектором.
Есть такая хрень, как предоставление массивом из байтов памяти под объект (http://eel.is/c++draft/basic.m... es_storage). Идея разрешить адресную арифметику для объектов, для которых один и тот же объект-массив provides storage. Но это надо фиксить пункт про оператор плюс для указателей. Плюс надо в определении new указать, что оно выделяет именно массив байт, который можно использовать чтобы provide storage. Пока что про массив там ничего не сказано, сказано про " allocate size bytes of storage".

0

Сообщение от Друг ньюфага модель памяти собираются пропатчить так, что можно будет реализовать вектор с этой гарантией "непрерывности"

Стандарт итак гарантирует непрерывность данных в векторе. В С++17 ввели понятие "contiguous". Теперь вектор "dynamic contiguous array".

0

Сообщение от MrGluck Стандарт итак гарантирует непрерывность данных в векторе

Ради бога, пусть там есть непрерывность. Только не существует реализации вектора, в котором одновременно push_back работает за амортизационное O(1) и выполняется &v[n] == &v[0] + n for all 0 <= n < v.size().

0

А мне интересно кто тут под ником Друг ньюфага, начинает развод бадяжить.
То в #4 пишем
MrGluck, New man, просто мне друг сказал что тут какое-то не определенное поведение.
я подумал это значит что не известно будет такое же значение или не будет.
Т.е. я не я, моя твоя ничего не понимай.
И смотрим #21
Где у ТС уже совсем другие познания и стиль изложения. (Даже Страуструпа кастрировать собрался).

0

Сообщение от Друг ньюфага Поэтому модель памяти собираются пропатчить так, что можно будет реализовать вектор с этой гарантией "непрерывности".

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

Добавлено через 3 минуты

Сообщение от Друг ньюфага Доказывать мне обратное бессмысленно, т.к. это не моё мнение. Да, я буду давить авторитетом.

Если бы это было ваше мнение эту тему еще возможно стоило бы обсуждать. А так это не более чем источник ОБС (Одна Бабка Сказала)

Добавлено через 12 минут

Сообщение от Croessmah Речь идет не о типе массива, а о последовательно лежащих элементах, т.е. о массиве как о структуре данных. Возможно, товарищи меня поправят, но я считаю, что Вы неправы в этом вопросе.

Я так понимаю товарисч Друг ньюфага, путает понятия "распределенная память" и "сконструированные элементы" поэтому и думает что обращение за пределы size() обязательно ведет к UB что даже в таком случае далеко не всегда так. А следовательно не понимает что никакого UB не будет если обращаться в пределах size(). Ну и при этом не понимает где чья зона ответственности - программиста или вектора за вычисление адреса элемента при разных способах обращения.

Добавлено через 13 минут

Сообщение от Друг ньюфага Только не существует реализации вектора, в котором одновременно push_back работает за амортизационное O(1) и выполняется &v[n] == &v[0] + n for all 0 <= n < v.size().

Это с каких делов? Для несегментированных буферов она существовала еще когда STL не существовало. Другое дело что тогда несегментированным мог быть буфер не более 64KБ размером.

1

Fulcrum_013, я думаю, C++ — не Ваш конёк.
Вам лучше пообсуждать уменьшение EXE-файлов с помощью замены DOS stub.

0

Друг ньюфага,
Код оператора [] вектора
Внимательно смотри что именно он возвращает.
И доверять любым другим источникам (!неожиданно)не имею права по роду занятий.

0

всем спасибо
все свободны

0

Вот, если кому интересно, ссылка на сообщение от Richard Smith¹

Сообщение от https://groups.google.com/a/isocpp.org/d/msg/std-discussion/p4BXNhTHY7U/ahp5CzNFQQAJ <цитата вырезана> You didn't specify how to implement the piece that's not implementable :-) T *vector<T>::data() { return ??? } vector<int> vi; vi.push_back(1); vi.push_back(2); vi.push_back(3); vi.data()[2] = 12; // ub, there is no array object on which to do array indexing C++98's vector was fine, since it didn't pretend to expose an array to the user (there was no data(), iterators could be used to encapsulate the reinterpret_casts, and there was no contiguous iterator guarantee), but this has been unimplementable in the formal C++ object model since C++03 guaranteed that (&vi.begin())[2] should work. Obviously it's actually fine in practice (and your implementation will certainly make sure it works), the question here is how to tweak the formal wording to give the guarantees we actually want. There are a number of different options with different tradeoffs (should we require explicit code in std::vector to create an array object? should we allow nontrivial pointer arithmetic / array indexing on pointers that don't point to arrays? should we magically conjure an array object into existence to make this work? should we allow an array object to be created without actually initializing all of its elements? how should the lifetime of an array object work anyway?). I'll probably write a paper on that once we're done with p0137.

1)

Сообщение от https://isocpp.org/std/the-committee Project Editor: Richard Smith (Google). The project editor is the person ultimately responsible for applying committee-approved changes to the standard’s working draft.

0

Друг ньюфага,
из кода вектора STL
из кода моего аналога вектора

Т.е. указатель на лежащие подряд единым куском данные возвращается в корректных реализациях.
Ну а то что возвернутый указатель может nullptr оказаться ну дак на то и динамический массив а не статический.

Добавлено через 5 минут

Сообщение от Друг ньюфага since it didn't pretend to expose an array to the user

Которая делала вектор useless во многих делах где нужен именно RAW буфер. Например в вопросе забросить накопленные в нем вертексы в видеопамять или опять же передать его содержимое по сети как raw данные.

0