В чем разница между динамическим массивом и статическим?

ребята, я не понимаю различия. вроде читал литературу.

ну вот говорят, что динамический массив, это массив выделение памяти под который будет происходит в процессе выполнения программы.

и тут я залез в онлайн компилятор (с++ 14) и сделал так
объясните пожалуйста в чем действительно разница между статическим и динамическим массивом, чтобы я мог точно понимать что есть что

0

Сообщение от HelicopterK52 А Вы знаете хоть одну реализацию компилятора, которая бы на 100% соответствовала стандарту, не содержала багов и других сюрпризов?

Я не анализировал компиляторы подобным образом...

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

Да, но для С++ это действительно когда речь идет о Unspecified behavior/Implementation defined, но никак не про Undefined behavior.
Опять же. Речь о С++ а не про платформы

0

Сообщение от DrOffset Ну вот здесь есть довольно показательный пример, как мне кажется.

А еще можно привести std::string::operator[]

0

Сообщение от Undisputed Да, но для С++ это действительно когда речь идет о Unspecified behavior/Implementation defined, но никак не про Undefined behavior.

Кто Вам такое сказал?
Для undefined behavior в стандарте также сказано:

Permissible undefined behavior ranges from ignoring the situation completely with unpredictable results, to behaving during translation or program execution in a documented manner characteristic of the environment (with or without the issuance of a diagnostic message), to terminating a translation or execution (with the issuance of a diagnostic message).

2

HelicopterK52,
Если что то документировано то это другое дело.
Я же говорю про то что не документировано и с точки зрения с++ а не конкретных платформ

0

Сообщение от Undisputed Если что то документировано то это другое дело.

Так оно документировано, просто не стандартом c++. Стандарт принципиально не способен задокументировать всё.
Банальный пример - запись по не выровненному адресу. На каких-то платформах это будет нормально работать, а на каких-то вывалится здоровенная аппаратная ошибка.
Как стандарт c++ должен подобное документировать? Только как undefined (или unspecified) behavior.

0

Сообщение от HelicopterK52 Так оно документировано, просто не стандартом.

Ну вот кстати что модель многопоточности, что каст функций в void * вполне документированы стандартом POSIX. При этом стандарту C++98 это никак не мешало вообще не описывать эти вещи у себя.

0

Сообщение от DrOffset Ну вот кстати что модель многопоточности, что каст функций в void * вполне документированы стандартом POSIX.

До C++11 многопоточности в с++ вообще не существовало, а многопоточные программы на C++ были. Как так?

0

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

0

Сообщение от Undisputed Даже несмотря на то, что вы делаете это от имени вспомогательного указателя, это не отменяет тот факт что фактический объект лежащий в памяти по адресу int * pa =reinterpret_cast<int*>(a); это тот самый двумерный массив 3х3, первый оператор идексации которого может быть в диапазоне 0-2.

Очень близко, но на самом деле UB наступит раньше выхода за диапазон 0-2.

Теперь подробнее.
Есть объект a типа int[3][3]. Что является значением указателя pa, инициализированного как int * pa =reinterpret_cast<int*>(a);?
Ну, во-первых, a попадает под array-to-pointer conversion, т.к. reinterpret_cast между указателями требует prvalue аргумент, а

Сообщение от https://timsong-cpp.github.io/cppwp/n4659/expr#9 Whenever a glvalue expression appears as an operand of an operator that expects a prvalue for that operand, the lvalue-to-rvalue, array-to-pointer, or function-to-pointer standard conversions are applied to convert the expression to a prvalue.

reinterpret_cast<int*>(a) преобразует указатель с типом int(*)[3], со значением "указатель на нулевой элемент массива a —a[0]".
reinterpret_cast<int*>(a) определён как static_cast<int*>(static_cast<void*>(a)) https://timsong-cpp.github.io/... ret.cast#7
Каст к void* не меняет значения указателя

Сообщение от https://timsong-cpp.github.io/cppwp/n4659/conv.ptr#2 A prvalue of type “pointer to cv T”, where T is an object type, can be converted to a prvalue of type “pointer to cv void”. The pointer value is unchanged by this conversion.

Значение по-прежнему "указатель на a[0]".
Про static_cast<int*>(...):

Сообщение от https://timsong-cpp.github.io/cppwp/n4659/expr.static.cast#13 A prvalue of type “pointer to cv1 void” can be converted to a prvalue of type “pointer to cv2 T”, where T is an object type and cv2 is the same cv-qualification as, or greater cv-qualification than, cv1. If the original pointer value represents the address A of a byte in memory and A does not satisfy the alignment requirement of T, then the resulting pointer value is unspecified. Otherwise, if the original pointer value points to an object a, and there is an object b of type T (ignoring cv-qualification) that is pointer-interconvertible with a, the result is a pointer to b. Otherwise, the pointer value is unchanged by the conversion.

Объект b типа T == int, конечно, есть по адресу A, который представляет указатель static_cast<void*>(a). Но объект a[0] типа int[3] не является pointer-interconvertible со своим первым элементом типа int (см. https://timsong-cpp.github.io/... onvertible)
Значит, static_cast<int*>(...) не меняет значения указателя и он по-прежнему указывает на a[0].

Итак, имеем переменную int * pa =reinterpret_cast<int*>(a); с типом int* и значением указатель на a[0].

Теперь к арифметике указателей.

Сообщение от https://timsong-cpp.github.io/cppwp/n4659/expr.add#4 When an expression that has integral type is added to or subtracted from a pointer, the result has the type of the pointer operand. If the expression P points to element x[i] of an array object x with n elements,86 the expressions P + J and J + P (where J has the value j) point to the (possibly-hypothetical) element x[i+j] if 0≤i+j≤n; otherwise, the behavior is undefined. Likewise, the expression P - J points to the (possibly-hypothetical) element x[i−j] if 0≤i−j≤n; otherwise, the behavior is undefined.

Вроде всё в порядке, до тех пор, пока мы прибавляем к pa значения от 0 до 3. pa указывает на a[0], следовательно, pa + 2 указывает на a[2]. Естественно, напрягает тот факт, что указатель с типом int* указывает на объект с типом int[3]. Про это написано чуть ниже

Сообщение от https://timsong-cpp.github.io/cppwp/n4659/expr.add#6 For addition or subtraction, if the expressions P or Q have type “pointer to cv T”, where T and the array element type are not similar, the behavior is undefined.

Думаю, даже без заглядывания в определение similar types, ожидаемо, что типы int и int[3] are not similar.

Вот и UB. То, что тут массив двумерен, а там был трёхмерен — не играет существенной роли.

2

Сообщение от Undisputed а гарантий нет

С точки зрения C++ гарантий нет. С точки зрения реализации гарантии есть.
Важно понять, что язык, как и его библиотека - это лишь причиндалы, это они подгоняются под платформы, а не наоборот.

0

В качестве упражнения можете попробовать найти UB при попытке что-то прочитать через pa (типа int j = *pa;). (Наверное это слишком просто для упражнения).

0

Сообщение от Undisputed Даже несмотря на то, что вы делаете это от имени вспомогательного указателя, это не отменяет тот факт что фактический объект лежащий в памяти по адресу int * pa =reinterpret_cast<int*>(a); это тот самый двумерный массив 3х3,

Оно и не должно отменять этого факта равно как и факта впадения Волги в Каспийское море. Возглас: -"Как бы чего не вышло!" это вечный вопрос. Но он может здорово навредить. При запоре, например.
Указатель на определённый байт, является переменной хранящей его адрес. Тип значения по указателю не тип одномерного массива int[3] а это тип int и это значит, что индекс исходного массива равно как и подмассивов тут вообще не причём. Просто указатель указывает на первый элемент. И пользуясь индексированием по указателю - мы имеем законное право пройти хоть всю память. Но мы идём лишь до последнего элемента. Что не так? Стрикт алиайзинг? Сам компилятор пользуется адресной арифметикой.
Я не имел ввиду такие экзотические типы как bool (обычно 1 байт) и не думаю, что выравнивание как-то может помешать. Это потому, что размер массива всегда равен n*sizeof(T) если количество элементов n (независимо от количества измерений), а Т - тип конечного элемента.

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

Сообщение от rat0r Естественно, напрягает тот факт, что указатель с типом int* указывает на объект с типом int[3]

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

1

Сообщение от IGPIGP При запоре, например.

Сообщение от IGPIGP ему-то, как раз, не нужно слабительное

Пожалуйста, найди себе форум по интересам для демонстрации своей копрофилии.

0

Сообщение от rat0r Пожалуйста, найди себе форум по интересам для демонстрации своей копрофилии.

Вот уж не стану угождать вашим интересам. За новое слово - спасибо, прогуглил и нахожу его удачным для описания ситуации. Тема изрядно загажена, - да. Однако, в вашей терминологии, - мы с вами на одном поле не копрофилировали и прошу на вы обращайтесь.
Что касается некорректности обращения к адресному пространству массива через указатель на его первый элемент - не убедительно. Вообще.

0

Всё-таки нужно сделать финальное уточнение. UB ещё до выхода за границы наступает в C++17. До C++17 UB будет из-за выхода за границы.

0

Сообщение от rat0r даже без заглядывания в определение similar types, ожидаемо, что

Указатель гуляет по элементам двух-мерного массива типа int.
Так что очень даже similar

Ещё, ожидаемо, что двух-мерный массив : int a[][3] ={ {1,2,3}, {4,5,6}, {7,8,9} };
будет хранить свои элементы в памяти именно в такой последовательности,
в какой они указанны при инициализации.
Вот так: один за другим, в одном непрерывном блоке памяти.

Ещё, ожидаемо, что указатель:
int* pa =reinterpret_cast<int*>(a);
Будет указывать на первый элемент двух-мерного массива.

И теперь, почитав внимательно раздел 8.7 Additive operators,
Вы верно поймете, что указатель p1:

обязан указывать на элемент со значением 4

поведение определено:
по адресу, который хранит p1 обязан находиться объект типа int, со значением 4.

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

Сообщение от rat0r До C++17 UB будет из-за выхода за границы.

Я понимаю, что некоторые люди - альтернативно одаренные.
Мыслят каким то странным образом.

Всё же, где вы там увидели выход за пределы диапазона?

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

Сообщение от IGPIGP И пользуясь индексированием по указателю - мы имеем законное право пройти хоть всю память.

Это не законно

Чужую память даже просто читать нельзя,
без риска нарваться на access violation

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

Сообщение от Croessmah std::string s1("abc"); const std::string s2("abc"); //до C++11 char x = s1[s1.size()];//UB char x = s2[s2.size()];//Ok

почему это для константной строки OK, а для мутабельной UB??

1

Сообщение от eva2326 почему это для константной строки OK, а для мутабельной UB?

Потому что это C++

С++03 21.3.4 basic_string element access C++ const_reference operator[](size_type pos) const; reference operator[](size_type pos); Returns: If pos < size(), returns data()[pos]. Otherwise, if pos == size(), the const version returns charT(). Otherwise, the behavior is undefined.

0

Сообщение от Undisputed Если в коде есть место неопределенному поведению то программа фактически не валидная.

Ничего подобного! Это значит что программа при каких-то условиях может стать невалидной. Скажем, переполнение знаковых чисел формально UB, но оно часто используется, поскольку упрощает код.

Сообщение от HelicopterK52 А раз реализация не полностью соответствует стандарту, то стоит ли полагаться только на стандарт?

Проблема в том, что в разных компиляторах разные баги. Да и в более новых версиях баги исправляются и поведение компилятора притягивают к стандарту.

Сообщение от Undisputed Вот это UB можно, а то нельзя?

Любое UB можно если знаешь что делаешь. Проблемы начнутся при портировании, обновлении компилятора и тому подобном. Уверены что такого не произойдет или преимущества от UB перекрывают риск - вперед. Но здесь, на форуме, UB лучше не допускать из педагогических соображений.

Сообщение от Undisputed фактический объект лежащий в памяти по адресу int * pa =reinterpret_cast<int*>(a); это тот самый двумерный массив 3х3

После приведения к указателю "UB", связанные с массивом, уже неактуальны. Можете попытаться привязаться к выходу за пределы памяти, но тоже вряд ли что выйдет: там выделено 3x3x(sizeof(int)) байт.
Примерно этим пользуются при вызове функций memset(), memcpy() и т.п.: неважно сколько измерений у массива, это просто непрерывный блок байтов.

Сообщение от eva2326 Это не законно Чужую память даже просто читать нельзя, без риска нарваться на access violation

Как раз для Си законно, он оперирует непрерывной моделью памяти, целиком доступной одному процессу. Access violation вызывается не программой, а операционкой.
.
Ну и вернусь немного назад во времени чтобы разобраться с порядком хранения элементов в многомерном массиве. Похоже, моя первая модель была неудачной, попробую другую:
То есть формирование массива идет не слева направо как я думал (int arr[X])[Y], а справа налево. При объявлении массива это выглядит странновато, зато при обращении к элементу вполне логично.

0

Сообщение от Croessmah const_reference

Сообщение от Croessmah if pos == size(), the const version returns charT()

Хотите сказать, что с++03 предписывает возвращать ссылку на локальный объект? ))
Это же UB.

Есть ссылочка на pdf?
(C++03: N1577, N1655, N1733)

0

Сообщение от eva2326 Хотите сказать, что с++03 предписывает возвращать ссылку на локальный объект?

Зачем локальный? Есть же статические.
return *"";
Ну и, скорее всего, там в любом случае есть нолик в конце строки.
Не выделять же каждый раз память под c_str,
поэтому return data[pos] будет нормально работать.

0