Восходящее преобразование массива производного класса к родительскому?

Есть два класса base_Class(родитель) и derived_Class(потомок)
Есть некая виртуальная функция в base_Class которая принимает в качестве параметра массив объектов класса f(base_Class **mass)
Чтобы воспользоваться данной функцией для производного класса, необходимо привести массив производного класса к массиву родительского
Массивы: base_Class *baseMass[100], derived_Class *derivedMass[100]
Как произвести такое приведение типов?

0

Сообщение от rat0r Никак. hoggy, UB

rat0r, преобразование массива к указателю на первый элемент, вы полагаете некорректным?

0

rat0r, в книге Programming: Principles and Practice Using C++ Страуструп проделывает такой же фокус(глава 25.4), и никакой проверки (reinterpret_cast<base**>(0) + 1) == reinterpret_cast<base**>(reinterpret_cast<der**>(0) + 1)(ну или как там можно это проверить и вообще можно ли) не делает. Получается папа учит детишек говнокодить?

1

Сообщение от hoggy UB - неопределенное поведение. в данном случае поведение - определенное.

В данном случае поведение неопределённое.

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

Ожидаемый тобой результат ≠ определённое поведение. В рамках UB возможно любое поведение, в т.ч. ожидаемое именно тобой (пусть даже не только тобой).

Сообщение от hoggy о каком таком неопределенным поведении ты толкуешь

О котором явно сказано в https://timsong-cpp.github.io/... expr.add#6

Сообщение от hoggy учитывая, что в данной ситуации поведение совершенно точно определенно

Совершенно точно указаны условия, в результате выполнения которых "the behavior is undefined". И эти условия совершенно точно выполнены. Так что, поведение совершенно точно неопределённое.

Сообщение от hoggy Разве я это заявляю? конечно. ты не заметил что обозначил ситуацию как UB, невзирая на то, что поведение полностью определенно?

Похоже, ты бредишь.

Сообщение от hoggy только потому что так написанно в твоей книжке. безотносительно к причинам настоящих UB, о которых в этих твоих книжках скромно умалчивается?

Ты хотел пруф UB — ты его получил.
А причины по которым какую-то ситуацию обозначили как UB — это другой вопрос (и банально манёвр в сторону ).

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

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

Сообщение от hoggy задай этот вопрос тому, кто такое утверждает.

Так это ты писал про некие легальные преобразования типов.

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

Сообщение от IGPIGP преобразование массива к указателю на первый элемент, вы полагаете некорректным?

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

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

Сообщение от zayats80888 в книге Programming: Principles and Practice Using C++ Страуструп проделывает такой же фокус

Ты считаешь цитату из книжки Страуструпа контраргументом к написанному в стандарте?

0

Сообщение от rat0r Ты считаешь цитату из книжки Страуструпа контраргументом к написанному в стандарте?

Нет, я вроде спросил о другом...

0

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

В приведенной цитате говорится о массиве который содержит объекты наследующего класса и попытке использовать указатель базового класса для доступа и арифметики как я понял.

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. [ Note: In particular, a pointer to a base class cannot be used for pointer arithmetic when the array contains objects of a derived class type.  — end note

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

0

Сообщение от zayats80888 Получается папа учит детишек говнокодить?

Можно и так это сказать, если есть желание.

Сообщение от IGPIGP В приведенной цитате говорится о массиве который содержит объекты наследующего класса и попытке использовать указатель базового класса для доступа и арифметики как я понял.

Это говорится в том куске, который ты выделил жирным. А цитата этим куском не ограничивается.

Сообщение от IGPIGP Это не имеет отношения к случаю когда мы имеем массив указателей базового класса.

Выделенный жирным текст примечения не имеет отношения, а нормативный текст — имеет.

0

rat0r, нормативный текст, приведенный вами, не имеет никакого отношения к коду hoggy. Поэтому действительно не понятно, что именно вы пытаетесь доказать.

1

Сообщение от stzer нормативный текст, приведенный вами, не имеет никакого отношения к коду hoggy.

Ты забыл дописать "мамой клянусь".

0

Сообщение от rat0r Ты забыл дописать "мамой клянусь".

Без этого вам не по понятию? У меня вполне средний английский и я согласен с stzer.
rat0r, вы запостите сюда тот фрагмент который имеете ввиду за

Сообщение от rat0r нормативный текст

клясться не нужно. Переводить тоже. Мы сами переведём. Просто покажите то место.
Как я перевёл P и Q это адресные выражения указывающие на элементы одного массива. И говорится от том, что они (любой из них) должны иметь базовый тип совместимый с типом элемента и квалификаторы должны поддерживать "симиларити". Это мне нужно ещё перечитать (стандарт пишут мрачные садисты, которые гордятся своими IQ, хотя читая по настоящему базовые концепции я не вижу оснований). То есть указатель на константу может указывать на не константу но не наоборот? Или имеется ввиду полное совпадение cv сигнатур для P и Q выраженных как cv T? Тут если кто объяснит просто и кратко, буду признателен.

1

IGPIGP, всё-таки пусть для нас эту цитату переведут.
Как понял я, самую суть:
Есть два выражения, P и Q. Если хотя бы одно из них имеет тип T *, и если этот T * - не указатель на массив, то это UB.
Один из кейсов - мы не можем взять адрес какого-то отдельного объекта, и прибавить, скажем, единицу.

Как это увязать с кодом выше - для меня загадка.

rat0r, нет, не забыл.

0

Сообщение от IGPIGP вы запостите сюда тот фрагмент который имеете ввиду за

Ты привёл правильный фрагмент в Восходящее преобразование массива производного класса к родительскому?
Ты не знаешь, что такое нормативный текст? Примечение (Note) это не нормативный текст. Нормативный — до Note.

Сообщение от IGPIGP Это мне нужно ещё перечитать

Сообщение от IGPIGP Тут если кто объяснит просто и кратко, буду признателен.

Сообщение от IGPIGP я согласен с stzer

Т.е. ты ещё не разобрался, но уже согласен что цитата не имеет отношения к коду? Это что-то вроде «не читал, но осуждаю».

0

Сообщение от rat0r Т.е. ты ещё не разобрался, но уже согласен что цитата не имеет отношения к коду? Это что-то вроде «не читал, но осуждаю».

То что я понял, говорит о том, что вы цитируете не имеющий отношение к делу текст. Я уже имею большой опыт общения с вами в том плане, что вы если что-то имеете ввиду, то это будет оценено как самое сокровенное и не в слух. Сплошная тайна и многозначность. Приведите тот текст который вы хотите считать главным доказательством. Я его там не увидел и признаю это. Так же как и признаю, тот факт, что текст писали ... Проясните смысл и я покажу как написать и по-русски и по-английски, что бы не набивать себе цену (как делают мелочные вонючие дегенераты), а так чтобы и ёжику было понятно. Так как писали когда-то учебники в стране где я родился. И писали великие учёные подчас. Корона не падала.

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

Сообщение от stzer Есть два выражения, P и Q. Если хотя бы одно из них имеет тип T *, и если этот T * - не указатель на массив, то это UB.

Я думаю нет. P и Q.это адресные выражения которые могут указывать (содержать адрес) элемента массива. И их тип включая квалификаторы (нижнего уровня как я понял) должен быть подобен (similar to) типу элемента массива. Критерии подобия я пока не шибко разобрал из того что там показано. И вследствие, я не уверен, а участник который привёл пример наслаждается этим фактом. Может быть он и снизойдёт до объяснения. Кто знает?
Однако, того что я понял пока достаточно, чтобы видеть, что это не к случаю.

0

IGPIGP, согласно определению base* и der* не similar, а стандарт написан по принципу "я не я и хата не моя", другими словами он не запрещает(наверное) компиляторам реализовать различное представление указателей на разные типы(разный размер, выравнивание, арифметика), главное что бы правила преобразований работали.

1

Сообщение от zayats80888 IGPIGP, согласно определению base* и der* не similar

А кто спорит? Это я понял. У них тип T разный для Q и P. Если в терминах текста. Но мы же говорим о указателях на базовый класс. И не важно на что они указывают. Они есть эдементы массива. То есть T=Base*. А указатели P и Q это указатели на этот тип. Я уже не знаю как ещё попросить объяснить, что тут не similar...

0

Сообщение от rat0r В данном случае поведение неопределённое.

серьёзно???

ты серьёзно не можешь предсказать что должен сделать код,
и что он сделает по факту?

серьёзно думаешь, что результат непредсказуемый???

Сообщение от rat0r Ожидаемый тобой результат ≠ определённое поведение. В рамках UB возможно любое поведение, в т.ч. ожидаемое именно тобой (пусть даже не только тобой).

в рамках UB возможно любое.
но в данном случае поведение определенное.

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

и если ты читал те самые книжки на которые любишь ссылаться,
и знаешь как обязана работать адрессная арифметика указателей,
то ты должен понимать, почему мой код работает именно так, как он работает.
и должен понимать, почему он не может сработать как то иначе.

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

Сообщение от rat0r Так это ты писал про некие легальные преобразования типов.

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

ты как вообще, русский текст нормально воспринимаешь?

я писал про ре-интерпритацию.
конкретно: что в отличие от легальных преобразований типов,
в случае ре-интерпритации не делается никаких дополнительных вычислений.
в результате можно поиметь некорректный результат.

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

Сообщение от rat0r Административным правонарушением является только переход на красный свет в результате которого произошла авария или просто переход на красный?

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

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


я прекрасно понимаю твою точку зрения.
и понимаю, что ты пытаешься мне сообщить.

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

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


понимаешь в чем фокус?
неопределенное поведение должны быть неопределенным.
а иначе, это уже не UB.

Сообщение от rat0r Ты хотел пруф UB — ты его получил.

ага.
я же не забыл сказать тебе "спасибо" ?

Сообщение от rat0r А причины по которым какую-то ситуацию обозначили как UB — это другой вопрос (и банально манёвр в сторону ).

ты в деццком садике что ли?
если тебе нужны манёвры - ты ошибся с собеседником.

на самом деле причины - это самое важное.
это - суть.
причины дают самое важное - понимание.

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

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

0

Сообщение от zayats80888 IGPIGP, согласно определению base* и der* не similar

Это бесспорно, с самого начала. Но я не разглядел вопроса. И сражался с вымышленными глупостями. Виноват.
rat0r, приношу извинения. На мой вопрос вы ответили невнятно. Ни к чему было обновлять страницу. Речь была не о array-to-pointer-decay. Я то думал что передаётся во всех случаях Base** но инициализированный разными объектами/подобъектами... Теперь ясно к чему цитата.
GoshaRubi, нет смысла в контексте полиморфного вызова в массивах из указателей на подобъекты. Именно массивы указателей на базовый класс полезны. А на этих указателях могут висеть любые типы иерархии. Тогда это имеет смысл. Иначе может помочь перегрузка, например, но о полиморфизме для Derived** перегрузки придётся забыть. А вот функция принимающая Base** сможет раскрыть возможность вызова виртуального метода.
Вот такой код возможен:

1

Сообщение от IGPIGP Теперь ясно к чему цитата.

Ок. Отвечать на всё, что выше, не нужно?

1

Сообщение от rat0r Ок. Отвечать на всё, что выше, не нужно?

Нет. С формальной точки зрения конечные базовые типы denoted as U не являются the same и в итоге Base** и Derived** не являются similar...
Хотелось бы всё же понять, что подвигло комитетчиков считать что ponter to pointer to derived нельзя использовать как pointer to pointer to base в контексте как итерации по массиву так и доступа к членам суперкласса. Какие подводные камни скалистого дна С++ могут ранить на этот раз?
-Размеры указанных ponter to pointer'ов могут отличаться? Если да, - когда, где и по какой причине.
-Доступ к по указателю Base* к объекту по его адресу сохранённому в Derived* в рамках строго ограниченных возможностями Base уже не законен? Если да, - когда, где и по какой причине.
А формально, - вы правы. В стандарт записали, что это фактически запрещено в контексте как итерации по массиву так и доступа к членам суперкласса. Или по крайней мере в одной из частей данного контекста.
Но почему?

0

Сообщение от IGPIGP -Размеры указанных ponter to pointer'ов могут отличаться? Если да, - когда, где и по какой причине.

Даже если у base* и der* одинаковый размер, читать значение из объекта типа der* через glvalue с типом base* это банально нарушение т.н. strict aliasing rules.

2

Сообщение от rat0r Даже если у base* и der* одинаковый размер, читать значение из объекта типа der* через glvalue с типом base* это банально нарушение т.н. strict aliasing rules.

Нужно освежить. Я думал нельзя писать в объект через указатель на другой тип. А читать... Тем более в функции которая знать не знает о том что ей дали не оригинальный указатель... Что тут может быть ужасного?
Указатель базового может быть использован для доступа к производному. Тут нет нарушения. А указатель на указатель к базовому нельзя использовать как указатель на указатель к производному(!).
Вообще, если говорить о нормативной документации, правовой, технической и в частности - стандартах то читая то что называют стандартами в ПО приходится сдерживать ненормативную лексику. В частности в данном случае сказано о том что типы "подобны/similar" если совпадают cv сигнатуры и базовые типы (U), Но это же очевидно. То есть если это один и тот же тип то это нечто подобное (самому себе). То есть, данное условие - тавтология. И может быть принято как достаточное условие в качестве отправной точки (неуклюжий вариант). А далее можно формулировать случаи когда возможны отличия при сохранении подобия (similarity). Что там далее и делается. Возможно поленились учесть случай для указателей на классы иерархии.

0