Создание многомерных динамических массивов (динамических многомерных поинтеров)

Привет знатокам!
Решил написать небольшую функцию по созданию многомерных массивов. Возникло затруднение создать динамические многомерные поинтеры на массивы. Сейчас объясню что хочу.
входные/выходные данные: посылаем указатель на структуру в которой первым элементом будет поинтер(одномерный массив) с неизвестным количеством элементов. Количество элементов равно количеству измерений многомерного массива. Второй элемент возвращаемый поинтер на массив.
функция читает элементы массива; первый элемент количество измерений массива, последующие элементы количество элементов в каждом измерении.
Создать динамический массив не сложно, но возникает сложность когда количество измерений не определено.
Возможно ли это средствами С++, я только начал разбираться в С++ , по моему (возможно неумному) мнению не очень удобный язык особенно приведение типов это полный абзац. кучи хендлов и LP по сути являющимися одним и этим же DWORD - кто придумал это г.? После ассемблера это просто отрыв головы((
Спасибо.

0

Сообщение от AAAAAlexeyyyyy Кстати что такое UB?

UB - Undefined Behaviour - Неопределенное поведение. В вики есть статья с примерами.

Язык C++ - это не Java, у него нет виртуальной машины, которая может контролировать доступ, например, к памяти. Корректный доступ к памяти оставлен на совести программиста чтобы не замедлять программу тотальным контролем за памятью со стороны среды исполнения и все операции вне разрешенной памяти объявлены неопределенными. Они могут работать, могут не работать, могут работать сейчас, но сломаться потом. Могут запустить форматирование вашего жесткого диска, или запустить игру тетрис вместо того, что вы ждете. Это неизвестно. Память, где лежит FDFD - не ваша, это память менеджера кучи. Вы не имеете права писать туда что-то, даже если это работает. Вам может показаться, что если у вас получилось поставить успешный эксперимент, то это означает, что все было корректно, но нет - в C++ это так не работает. Фактически вы просто должны знать язык лучше, чем может вам объяснить компилятор, чтобы успешно писать на нем. Поэтому он считается сложным в большинстве сообществ.

Сообщение от AAAAAlexeyyyyy компилятор будет правильно трактовать эти индексы? и работать с ним как с обычным массивом или мы просто

Мы можем повторить вручную тот же способ пересчета индексов, что применяется компилятором при доступе к элементам встроенных многоамерных массивов. Это несложно. Алексей в 6 посте показал как. Нужно понимать, что встроенные массивы тоже линейны по своей памяти.

Сообщение от AAAAAlexeyyyyy Неплохо было посмотреть реализацию этого!

Правильная реализация с нуля (с минимумом библиотечных средств как вы и хотели) с учетом всех нюансов - это большая работа. Можно собрать макет на базе вектора, это будет проще и короче по коду.

0

Сообщение от DrOffset Вы не имеете права писать туда

ну как я и предполагал, new - грубо говоря, выделила память, а дальше ей все равно, как и показывает эксперимент с fdfd...
эксперимент как раз и позволил, как вы написали глубже знать язык - я писал в том посте - интересное наблюдение...
Давайте начистоту вы знали про эту особенность? хорошо не Вы, а все те, кто прочитал этот пост знали про эту особенность?
Так что данное сообщение можно считать как deep learning))
А если говорить как вы писали... чтобы лучше контролировать программу, то мне кажется использование этого языка - мнимое удобство. Я должен еще и знать исходники всех операторов, что они там чудят(( даже при использовании стандартной лексики языка - которую пропускает компилятор.
А еще существуют библиотеки в общем - мдя...

0

Сообщение от AAAAAlexeyyyyy Давайте начистоту вы знали про эту особенность?

Почему такой результат работы функции?
У меня есть пруфы. Прочтите. Тема 2019 года. Естественно я знаю про все особенности, которые вам могут только прийти в голову и которые не могут.

Сообщение от AAAAAlexeyyyyy то мне кажется использование этого языка - мнимое удобство.

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

Сообщение от AAAAAlexeyyyyy Я должен еще и знать исходники всех операторов, что они там чудят

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

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

Сообщение от AAAAAlexeyyyyy грубо говоря, выделила память, а дальше ей все равно

Это зависит от реализации. Реализаций много, внутри они могут быть организованы совершенно по-разному. Единственное что требует язык - следовать установленному контракту, все, что сверх этого - как угодно.

Контракты для new и delete описаны здесь:
https://eel.is/c++draft/new.delete
По-хорошему ваша программа не должна выходить за их предел при работе с new\delete. Если нужно что-то другое, то имеет смысл заменить глобальный аллокатор на какой-то свой собственный.

0

Сообщение от AAAAAlexeyyyyy Вопрос как раз и был контролирует ли new пересечение областей выделенной памяти

в том смысле, что два new[] не пересекутся (если между ними не было delete[] ) - да, контролирует

0

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

ну что-то я не очень доверяю Вашим словам Уважаемый доктор!
В посте #39 вы пишите одно

Сообщение от DrOffset И пытаться переназначать области, используя зависимую от компилятора отладочную информацию (те самые FDFD, - они существуют только в debug режиме в компиляторе MSVC)

В посте #41 у Вас уже другое

Сообщение от DrOffset Память, где лежит FDFD - не ваша, это память менеджера кучи.

Не поленился проверил загрузил через отладчик проект, который я делаю
определил с помощью new двумерный массив и оказалось, что fdfd все-таки существует, не только в моем больном воображении и воображении больного компилятора)). Чтобы полностью исключить возражения по быстрому написал функцию которая распечатывает содержимое следующей после поинтеров на данный массив ячейки памяти. Запустил без отладчика, как ни странно мой компьютер оказался тоже не совсем здоров и выдал fdfd(((
У вас классный ник DrOffset Может дорогой доктор полечит меня мой компьютер и компилятор)) очередной порцией интересных историй про его high level, что надо глубже учить язык, только бы его не проглотить))

Сообщение от DrOffset Так что нет, удобство не мнимое, а вполне реальное. Вам просто не хватает опыта его оценить.

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

Сообщение от DrOffset Вы сейчас пишете этот текст из браузера, который написан на C++

Вау как круто, я просто под столом)) неужели?, а Вы кому-нибудь это рассказывали?
Вообще Windows,Linux,Unix.... написаны на С. И от этого кривой инструмент не становится прямее, просто нет ничего более подходящего(( И одним из подтверждений его кривизны являются бесконечные баги, которые надо править. Можно конечно сказать, что там туча людей работает, за всеми не уследишь итд - и это правда, а где же ваша любимая типизация которая как вы писали позволяет лучше контролировать код. Что-то мне кажется все таки общаясь на этом форуме можно легко подцепить эту серьезную хворь - демагогию. Похоже я не ошибался, что видоизмененное мироощущение все-таки здесь присутствует.


Выражаясь Вашим языком - пруффы в студию. screenshot отладчика где я проверял ваши глубокие знания. подчеркнуты 2 dword для поинтеров строк еще не заполненные (обычно эти поля перед заполнением содержат cdcdcdcd), и третий dword fdfdfdfd после выполнения оператора new; красным - точка останова с вызовом оператора new; iep - текущая выполняемая команда; ss:[ebp-e0] адрес нулевого поинтера который равен 0x016675A8.

Прекратите писать ерунду, эту ветку форума просмотрели более 1800 раз, зачем дескридитировать себя, все это читают и видят. Надо быть нормальными людьми. Знаете - пишите ответ, не знаю - пишите не знаю - это Все оценят и это только добавит к Вам уважения.
Врать надо девушкам, если они конечно будут Вас слушать))

А теперь можете заплевать меня своими обычными фразами про обидчивого неуча))

Миниатюры

 

0

Алексей1153,
пересекутся, я это и проверил,я об этом писал был создан трехмерный массив. Потом некоторое время я работал с данными этого массива. В том числе создавал другие массивы. Потом меня осенила идея проверить можно ли это? - и уже к существующему первому массиву решил добавить страниц, листов и глав - после этого new начала затирать точки которые она сама расставляет fdfdfdfd. и при попытке удаления массива, страницы или листа выдавала исключение, когда я прописывал fdfdfdfd на то место где оно должно было быть - исключение пропало.
Следующий эксперимент был - записал в этот видоизмененый массив с новой страницей(поинтером) - fdfdfdfd на следующее место после нового поинтера как писал drOffset в запрещенную память. И это исключение опять пропало. я думаю эти fdfdfdfd нужны для delete в качестве рэперных точек. кстати при удалении она записывает туда опять cdcdcdcd
Мы уже с вами обсуждали что new создает динамические страницы с большими дырками между страницами и в этом плане линейные массивы лучше. Я не исключаю, что в этих областях хранится какая-то служебная информация может по размеру страниц, количеству страниц,( поэтому дырки между страницами), и писать туда вроде как нельзя. Но факт остается фактом.((
Я посмотрел эти области не заполнены случайными байтами - правда не дизассемблировал - не было желания, может там вообще какие либо фрагменты кода.

0

Сообщение от AAAAAlexeyyyyy Вообще Windows,Linux,Unix.... написаны на С.

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

Сообщение от AAAAAlexeyyyyy А мне кажется все таки язык кривой

это не язык, а руки

Сообщение от AAAAAlexeyyyyy пересекутся

нет

-------------
И вообще, сделай лицо попроще. Поначалу ты выглядел адекватным, а щас понесло тебя, аж неприятно

0

Сообщение от AAAAAlexeyyyyy В посте #41 у Вас уже другое

В смысле другое? Это все то же. Менеджер кучи C++ находится в его стандартной библиотеке, а стандартная библиотека поставляется с компилятором. Здесь нет никакого противоречия.

Сообщение от AAAAAlexeyyyyy а где же ваша любимая типизация которая как вы писали позволяет лучше контролировать код.

Ну никто не обещал, что одним единственным инструментом удастся решить все проблемы. Как вы сказали правильно - лучше все равно ничего нет.

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

И что? Не понятно с чем вы спорите. Никто не писал, что не существует. Я писал, что FDFD существует в реализации стандартной библиотеки от MS в отладочном режиме. А вы как использовали debugging heap, так и продолжаете использовать, запустились вы под отладчиком или без него - не важно. Именно поэтому у вас прилетают исключения. В отладочном режиме в библиотеке стоят проверки на наличие этих маркеров, и при их отсутствии библиотека бросает системное исключение.
Вот пожалуйста статья об этом (crt-debug-heap):
https://learn.microsoft.com/en... w=msvc-170
Вот ваш FD:

The no_mans_land buffers on either side of the user data area of the block are currently 4 bytes in size, and are filled with a known byte value used by the debug heap routines to verify that the limits of the user's memory block haven't been overwritten. The debug heap also fills new memory blocks with a known value. If you elect to keep freed blocks in the heap's linked list, these freed blocks are also filled with a known value. Currently, the actual byte values used are as follows: no_mans_land (0xFD) The "no_mans_land" buffers on either side of the memory used by an application are currently filled with 0xFD.

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

Если перейти на GCC\Linux, там вы такого не найдете (но можете найти что-то другое). Если ваш код с привязкой к реализации MS и эксплуатацией UB будет работать в Windows и MSVC, то в GCC уже не будет. О чем я писал. Все эти вещи находятся на пределами C++ и для программирования о них вообще можно не знать.

Сообщение от AAAAAlexeyyyyy Для достижения стабильности мне чуть ли исходники операторов тогда надо изучать

Ну если вы собрались делать странное, не программировать на языке, а "хакать" его и его библиотеку, то да, надо будет знать внутренности. Если же писать именно на C++ и не делать дичь вместо этого, то ничего этого не обязательно. Я не говорю, что совсем не нужно - все-таки понимать что делается внутри полезно, но к C++ это будет уже относиться слабо. В любом случае использовать это для программирования логики программ, а не для отладки - точно не нужно.

Сообщение от AAAAAlexeyyyyy Прекратите писать ерунду, эту ветку форума просмотрели более 1800 раз, зачем дескридитировать себя, все это читают и видят.

Есть такой рассказ Шукшина - "Срезал". Почитайте на досуге
Пока что дискредитируете себя тут только вы.

0

Сообщение от AAAAAlexeyyyyy Вообще Windows,Linux,Unix.... написаны на С.

Ох уж эти пионэрские байки в интернете...

Единственная операционная система, которая в какой-то мере могла быть "написана на С" - это тот самый Unix до эпохи System V из конца 70-х годов прошлого века, в процессе работы над которым (и для работы над которым) Денис Ритчи собственно и задумал язык С.

0

Ух ты сколько букв, и все в прежнем стиле наверное, я боюсь не осилю.))) да еще и какие знатоки пишут мастер красивого письма и дохтор. Я думаю, что кто-нибудь ЭТО прочитает... По делу, друзья мои, по делу пишите. Удачи!

0