Можно ли обойти динамический массив не зная его размер?

1

Сообщение от nmcf IGPIGP, почему тебя так размер волнует? Это главный признак правильного массива?

Признак типа "массив", это тип массив. Передайте ссылку на массив в функцию и она легко, без читерства определит размер. Это потому что тип поддерживает оператор sizeof. Указатель его тоже поддерживает, он же тип. Поэтому его размер - размер указателя. Неужели мы говорим на разных языках? Указатели можно использовать по разному. Можно десятичные в 16-ричные конвертировать. Показать?
Но это не значит, что указатель, - конвертер. Он об этом и не догадается.

1

Сообщение от IGPIGP Признак типа "массив", это тип массив.

Вот это придумали теоретики, ограничив понятие массив только тем, что объявлено на момент компиляции, наверное, чтобы строго изложить описание языка. Только как тогда называть то, что по сути массив, но не массив с точки зрения теории? Квазимассив?

0

Сообщение от nmcf Только как тогда называть то, что по сути массив, но не массив с точки зрения теории? Квазимассив?

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

0

Сообщение от nofx Есть ли способ обойти такой массив используя указатель pArr на него? Не используя count.

не портируемые. или ручные велосипеды.
никаких гарантий.
_msize выдает размер блока, который гарантированно не меньше,
но может быть больше, например.

Сообщение от nmcf Т. е. массив не может быть в памяти, выделенной new?

стандарт однозначно определяет понятие термина.
"массив данных" не имеет к нему никакого отношения.

1

Сообщение от rikimaru2013 castaway, тоесть мой ответ не верный и мне не полагается балл?(

А ты только из-за баллов тут находишься? Твой ответ спорный, да и вообще вся тема спорная, холиварная...
По поводу баллов - я не тот кто их раздаёт. Мне на них плевать.

0

То, что это не тип данных, не позволяет говорить, что динамических массивов в C++ нет.

0

0

Сообщение от rikimaru2013 и куску кода: template<typename T, std::size_t N> * * * * * * * * std::size_t arraySize(T(&)[N])* * * * * * * * * * * { * * return N; }

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


http://rextester.com/BAWA95629

2

hoggy, и тем самым ваш код стал еще "не читабельнее".
Без всего кода, я бы сразу не понял, что этим хотел сказать программист.

0

Т. е. это просто способ получить размер в элементах, а не в байтах?

0

Сообщение от IGPIGP Во-первых это читерство, а во вторых для таких типов как int нет терминатора

char это unsigned __int8. в 16-битных компиляторах char это unsigned short int. В чем разница? В количестве байт? Она не существенна, хотя бы потому что существует двубайтовый wchar_t. Четкого понятия терминатора для строки кстати тоже нет. Если 0 является терминатором используемым в функциях из набора strxxx это еще не значит что это единственный возможный терминатор. Те же прерывания ДОС в качестве терминатора используют '$'. А возможно использование '\r' и '\n'. а так же бывает пользуют ETX или ETB.

0

Сообщение от Fulcrum_013 char это unsigned __int8

char это char. То что в ряде реализаций размер типов совпадает не причина считать, что это одно и то же самое. Даже то, что char это целый тип и приводится к целому в выражении где ожидается целое, не значит, что char и short это одно и то же. Когда вычисляется:
то если a это char то будет печататься символ, а если это целое то напечатается число. Но терминатор имеет смысл не для char а для с-строк. А это указатели на char.
Fulcrum_013, поскольку мы не понимаем друг друга в таких простых вещах как char != int и (int*) !=[]int то в с-строки предлагаю не уходить. И так нагородили, - будь здоров.
ps если Вы знаете число которое можно использовать в качестве терминатора для, скажем, int то напишите его.

0

Сообщение от Fulcrum_013 хотя бы потому что существует двубайтовый wchar_t

кто сказал, что оно два байта?
Одной виндой мир не ограничен. У меня, например, оно 4 байта.

Сообщение от Fulcrum_013 char это unsigned __int8

Нет такого типа как __int8, если в Вашем компиляторе char реализован именно так,
то это не значит что так оно везде.
Да, он целочисленный, да, занимает один байт, но, например, кто сказал что он unsigned?
char может быть как беззнаковым, так и знаковым - это определяется реализацией.

Сообщение от Fulcrum_013 Нам по другому объясняли. Массив в C и C++ это указатель на его начало. Неважно где он выделен, но это именно указатель на его начало.

Имя массива приводится к указателю без проблем,
только вот имя массива несет в себе дополнительную метаинформацию,
которая теряется при decay типа до указателя.
Не понимание этого момента может сильно стукнуть по башке в шаблонах.

2

Сообщение от Croessmah может сильно стукнуть по башке

Без шаблонов тоже может.
Меня вот всегда занимал вопрос удивительного отличия delete от delete []. Утверждается, что оно в том, что первый запускает деструктор для объекта по указателю где память выделялась оператором new, а второй, - для всех объектов, под которые память которые выделена оператором new[]. То есть, похоже что не просто "каждый компилятор желает знать, где сидит фазан"! Похоже, что каждый компилятор знает размер или может его узнать. Пусть память выделяется и освобождается операционной системой, по запросу программы, но конструкторы и деструкторы же не передаются? Значит информация должна где-то быть у программы?

0

Сообщение от Croessmah Не понимание этого момента может сильно стукнуть по башке в шаблонах

Я на это смотрю немного по другому. А именно для статического массива размер куска памяти на который он указывает определяем при компиляции.

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

Сообщение от IGPIGP Похоже, что каждый компилятор знает размер или может его узнать.

Компилятор его не знает. Но его обязан знать менеджер кучи.

Сообщение от IGPIGP Меня вот всегда занимал вопрос удивительного отличия delete от delete []

Как бы как бы. К примеру борландовский менеджер кучи в купе с кодегуардом позволяют пользовать delete для любых блоков и все ок. Начиная с версии Turbo C++ 1.0. Что говорит о том что менеджер кучи знает какого размера блок и соответсвенно сколько в нем элементов и т.д., и даже скорее всего знает какого они типа. Но при этом в документации написано что must use delete[] for arrays. А ноги растут оттуда что delete и delete[] перегружаемые операторы и не факт что все перегрузки окажутся настолько же умными как штатный менеджер кучи. Соответственно менеджер кучи хранит что-то в своих таблицах закрытым от общественности способом.

0

Сообщение от IGPIGP Утверждается, что оно в том, что

Не утверждается, а действительно так.
Попробуйте сами:
Если убрать [] вызовется один деструктор, а потом access violation

0

Сообщение от IGPIGP Значит информация должна где-то быть у программы?

Как правило, new[] выделяет чуть больше памяти, чем нужно для хранения элементов.
Добавляется некий хвостик перед основным буфером, который содержит число элементов,
собственно при new такой хвостик может отсутствовать, дабы не нужен,
соответственно операции new/new[] delete/delete[] должны соответствовать друг другу.
Вот пример: Передача по ссылке двумерного динамического массива в функцию

1

Сообщение от mimicria Если убрать [] вызовется один деструктор, а потом access violation

В MSVC. В BCC все будет ок, как будто вызвался []. Другие компиляторы в этом плане не тестировал. Но есть точная инфа что в первых компиляторах нужно было не просто delete[] а delete [Size]. Что говорит о том что все это зависит исключительно от умности менеджера кучи (набора информации который он пишет в свои таблицы при выделении блока)

0

Сообщение от mimicria Если убрать [] вызовется один деструктор, а потом access violation

потому как реальный указатель, который нужно удалить может отличаться.
Например:

Как видим, работа new и new[] может отличаться.
И вообще может вернуться указатель не на выделенную память,
а на некий определенный участок этой памяти.

Вот, например, при использовании delete оно знает, что объект один,
вызывает деструктор и передает адрес дальше в функцию освобождения(operator delete).
А теперь смотрите что получается, если мы передадим сюда то, что вернул нам new[],
то получим вызов одного деструктора и передачу в operator delete указателя,
только вот этот указатель уже не на выделенную память,
а несколько другой(тот, который вернулся пользователю).
Соответственно получим черт пойми что.
А если бы использовали delete[], то вот он уже знает о наличии хвоста и отработает корректно.

И рассмотрим обратную ситуацию.
Память выделялась с помощью new, а удаляется с помощью delete[].
delete[] предполагает, что есть хвост, ломится туда, читает оттуда кол-во элементов
и вызывает деструкторы для данного кол-ва объектов.
А теперь вопрос: что у нас в этом хвосте, если память выделялась new и никакого хвоста нет?
Правильно! Неизвестно что там.
Может 0, а может 100500.
Соответственно уже имеем UB (не наша память + вызов деструкторов для несуществующих объектов).
Плюс к этому добавляется то, что в operator delete уйдет указатель, смещенный "назад" на размер хвоста,
что также приведет к неопределенным последствиям.
Вызвали бы delete вместо delete[], то всё бы было нормально.

По ссылке выше есть пример "перезаписи" этого "хвоста".

5

Сообщение от Croessmah Как видим, работа new и new[] может отличаться. И вообще может вернуться указатель не на выделенную память, а на некий определенный участок этой памяти.

Это только один из многих возможных способов работы менеджера кучи. Опять же если выделяем память под один экземпляр пользовательского типа хвост никуда не денется, размер все равно нужон,либо не размер а пометка номера типа. То же самое в принципе касается и фундаментальных типов. Но для фундаментальных типов оверхед будет чуть ли не больше самих данных. Поэтому и работает менеджер кучи с ними по разному. простейший пример - битовая карта занят/свободен на каждый байт, что дает гарантированно оверхед не более 1/8. И такой менеджер кучи похоже и был у С++ в исходе, откуда и была необходимость указывать размер в delete[]. Но во первых при изменяемом размере кучи не самый удобный вариант, во вторых при выделении больших кусков способ с заголовком дает гораздо более меньший оверхед. Поэтому есть такое подозрение что современные менеджеры памяти пользуют сразу несколько сегментов кучи, в одном выделяют большие куски с заголовками, а для единичного распределения фундаментальных типов пользуют другой сегмент кучи с картой распределения.

0