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

@GoshaRubi · Регистрация: 18.09.2018

Студворк — интернет-сервис помощи студентам

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

@rat0r · 06.01.2020, 04:03

Сообщение от IGPIGP

В частности в данном случае сказано о том что типы "подобны/similar" если совпадают cv сигнатуры

???
В определении similar types не сказано, что cv-сигнатуры должны совпадать.

IGPIGP · 06.01.2020, 12:05

Сообщение от rat0r

В определении similar types не сказано, что cv-сигнатуры должны совпадать.

может я и не верно говорю. Вот фрагмент который я понял как идентичность по cv сигнатуре и U

Two types T1 and T2 are similar if they have cv-decompositions with the same n such that corresponding Pi components are the same and the types denoted by U are the same.

Я это понял, как требование идентичности, так как пошаговая идентичная декомпозиция даёт идентичность cv-сигнатур, а идентичность U это идентичность того что в остатке.

Добавлено через 8 минут
Но если исходить из

Сообщение от IGPIGP

данное условие - тавтология. И может быть принято как достаточное условие в качестве отправной точки (неуклюжий вариант). А далее можно формулировать случаи когда возможны отличия

то вот это разъяснение возможного отличия от отправной точки

A prvalue expression of type T1 can be converted to type T2 if the following conditions are satisfied, where cvji denotes the cv-qualifiers in the cv-qualification signature of Tj:60
(3.1)
T1 and T2 are similar.

Можно трактовать как добро на случай если T1=Base* , a T2=Derived* (наш случай).
Там далее указаны требуемые условия по cv когда они допускают отличия но важно же не это. Важно что мы знаем что преобразование
Derived* в Base* допускается языком. А тот факт что, скажем, возможно Derived* в const Base* не имеет к нашему случаю отношения.

@Azazel-San · 06.01.2020, 13:25

Сообщение от IGPIGP

так как пошаговая идентичная декомпозиция даёт идентичность cv-сигнатур

Лично я ничего такого не вижу. Где сказано, что она что-то "даёт"?

C++
1
2
3
4
int main() {
  char* pc;
  char* const* pcc = &pc;
}

Код выше валидный? Почему?

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

Сообщение от IGPIGP

а идентичность U это идентичность того что в остатке

Идентичность U это идентичность полученных типов после разименования указателя.

IGPIGP · 06.01.2020, 13:54

Сообщение от Azazel-San

Код выше валидный? Почему?

Сигнатуры в вашем коде не идентичны.

@hoggy · 06.01.2020, 14:19

Сообщение от rat0r

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

пруф?

@Azazel-San · 06.01.2020, 16:22

Сообщение от IGPIGP

Сигнатуры в вашем коде не идентичны.

Ну, да.
Вы достаточно наблюдательны.

Сообщение от IGPIGP

Можно трактовать как добро на случай если T1=Base* , a T2=Derived* (наш случай).
Там далее указаны требуемые условия по cv когда они допускают отличия но важно же не это. Важно что мы знаем что преобразование
Derived* в Base* допускается языком. А тот факт что, скажем, возможно Derived* в const Base* не имеет к нашему случаю отношения.

Соглашусь, derived* в base* вполне валидное преобразование, но derived** в base** - уже не уверен.
Правда я так и не понял к чему здесь

Сообщение от https://timsong-cpp.github.io/cppwp/n4659/expr.add#6

if the expressions P or Q have type “pointer to cv T”, where T and the array element type are not similar

Там же нету cv T.

Добавлено через 49 минут
И, по-моему, у hoggy как раз все ок, ведь у него массив указателей, а не массив объектов:

C++
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
struct base {    
    virtual ~base() {}
    virtual void print() = 0;
};
 
struct derived final : base {
    int j;
    
    void print() override { std::cout << "[derived::print] j = " << j << "\n"; }
};
 
int main() {    
/*
    derived darr[2]; // an array of objects
    darr[0].j = 1;
    darr[1].j = 2;
    
    base* bp = darr;
    bp[1].print(); // ub, throws SIGSEGV
*/
    derived* dparr[2]{new derived(), new derived()}; // an array of pointers
    dparr[0]->j = 1;
    dparr[1]->j = 2;
    
    base** bpp = (base**)dparr; // same as reinterpret_cast<base**>(dparr)
    bpp[1]->print(); // valid
}

И это вполне логично, т.к. арифметика указателей не учитывает размеры полиморфных объектов.

@zayats80888 · 06.01.2020, 16:45

Сообщение от Azazel-San

Правда я так и не понял к чему здесь
Сообщение от https://timsong-cpp.github.io/... expr.add#6
if the expressions P or Q have type “pointer to cv T”, where T and the array element type are not similar
Там же нету cv T.

In this International Standard, the notation cv (or cv1, cv2, etc.), used in the description of types, represents an arbitrary set of cv-qualifiers, i.e., one of {const}, {volatile}, {const, volatile}, or the empty set.

https://timsong-cpp.github.io/... ualifier#5

@hoggy · 06.01.2020, 17:08

Сообщение от Azazel-San

но derived** в base** - уже не уверен.

в общем случае каст провоцирует UB.

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

Сообщение от Azazel-San

И, по-моему, у hoggy как раз все ок, ведь у него массив указателей

и одиночное наследование.

@Azazel-San · 06.01.2020, 17:18

Сообщение от Azazel-San

по-моему, у hoggy как раз все ок

Хотя мы все еще можем выстрелить себе в ногу.
Как уже говорилось преобразование derived* в base* вполне валидное и не требует никаких танцев с бубнами, но вот уже derived** в base** можно преобразовать только через reinterpret. Это из-за того, что после разыменования base** мы можем получить base*, который указывает уже не на derived, а на некого другого наследника, что не очень круто.

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

Сообщение от hoggy

и одиночное наследование.

Да.

@hoggy · 06.01.2020, 17:20

Сообщение от Azazel-San

Это из-за того, что после разыменования base** мы можем получить base*, который указывает уже не на derived, а на некого другого наследника

в варианте hoggy - не можешь.

@Azazel-San · 06.01.2020, 17:24

Сообщение от hoggy

в общем случае каст провоцирует UB.

Еще примерчик, в дополнение к твоему.

Кликните здесь для просмотра всего текста

C++
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
struct base {    
    virtual ~base() {}
    virtual void print() = 0;
};
 
struct derived : base {
    int i;
    
    void print() override { std::cout << "[derived::print] j = " << i << '\n'; }
    virtual void do_nothing() { std::cout << "derived::do_nothing\n"; }
};
 
struct bad_guy : base {    
    void print() override { }
    virtual void hack() { std::cout << "bad_guy::hack\n"; }
};
 
int main() {
 
    derived* dparr[2]{new derived(), new derived()}; // an array of pointers
    
    dparr[1]->do_nothing(); // calls derived::do_nothing
    
    base** bpp = (base**)dparr; // same as reinterpret_cast<base**>(dparr)
    bad_guy really_bad_one;
    bpp[1] = &really_bad_one;
    
    dparr[1]->do_nothing(); // calls bad_guy::hack
 
}

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

@zayats80888 · 06.01.2020, 17:25

Сообщение от Azazel-San

Это из-за того, что после разыменования base** мы можем получить base*, который указывает уже не на derived, а на некого другого наследника, что не очень круто.

вроде нет, указывать он будет туда же, а вот то что (base**)ptr+1 и (der**)ptr+1 будут указывать в одно место, стандарт уже не гарантирует (хотя мне трудно представить, зачем может понадобится такая реализация)

@Azazel-San · 06.01.2020, 17:30

Сообщение от hoggy

в варианте hoggy - не можешь.

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

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

Сообщение от zayats80888

указывать он будет туда же

Это если кто-то не скажет ему указывать не туда же )

@zayats80888 · 06.01.2020, 17:35

Сообщение от Azazel-San

И мой пример выше, просто пример, что так тоже может быть.

кстати поэтому я писал, что "лучше" кастить к base*const*

@hoggy · 06.01.2020, 17:40

Сообщение от Azazel-San

Еще примерчик, в дополнение к твоему.

важно понимать,
что косяк здесь не в двойном касте.
а в некорректной ре-интерпритации типов.

твой пример можно подсократить вообще без каста двойного указателя,
но суть не изменится:

C++
1
2
3
4
5
6
7
8
int main() 
{
    derived* dparr[2]{new derived(), new derived()};
    
    bad_guy really_bad_one;
    dparr[1] = reinterpret_cast<derived*>(&really_bad_one); 
    dparr[1]->do_nothing();
}

@Azazel-San · 06.01.2020, 17:50

Сообщение от zayats80888

кстати поэтому я писал, что "лучше" кастить к base*const*

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

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

Сообщение от hoggy

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

Но мне кажется, в том числе и из-за этой ре-интерпритации типов и запрещен неявный каст derived** в base**, и надо явно кастить?

@hoggy · 06.01.2020, 18:08

Сообщение от Azazel-San

Но мне кажется, в том числе и из-за этой ре-интерпритации типов и запрещен неявный каст derived** в base**, и надо явно кастить?

конечно.
все неявные касты обязаны быть безопасными.
хочешь сделать что-то потенциально опасное - делай явно.

derived** в base** не просто опасен,
он классифицируется как UB,
потому что в общем случае корректность результата не может быть гарантирована
и по этой причине, лучше вообще так не кастить.

конечно, если у тебя дилема:
делать медленную копию массива из 10'000'000 элементов,
или кастануть за мгновение, тогда есть резон.

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

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

@rat0r · 06.01.2020, 19:11

Сообщение от hoggy

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

пруф?

http://eel.is/c++draft/basic.lval#11

Сообщение от hoggy

derived** в base** не просто опасен,
он классифицируется как UB

Хочешь сказать, у кода derived d; derived* dptr = &d; reinterpret_cast<base**>(&dptr); неопределённое поведение?

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

Сообщение от IGPIGP

может я и не верно говорю. Вот фрагмент который я понял как идентичность по cv сигнатуре и U

Что такое "cv сигнатура"?

@hoggy · 06.01.2020, 19:46

Сообщение от rat0r

http://eel.is/c++draft/basic.lval#11

ты ничего не путаешь?
какое отношение твоя ссылка имеет к твоему утверждению?

Сообщение от rat0r

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

какое вообще отношение твоя ссылка имеет к strict aliasing rules?

Сообщение от rat0r

Хочешь сказать, у кода derived d; derived* dptr = &d; reinterpret_cast<base**>(&dptr); неопределённое поведение?

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

поведение представленного тобою фрагмента кода вполне себе определенно.
а вот что будет дальше,
когда ты попробуешь использовать результат reinterpret_cast<base**>(&dptr) - это вопрос.

@zayats80888 · 06.01.2020, 19:46

Не по теме:

Сообщение от rat0r

Хочешь сказать, у кода derived d; derived* dptr = &d; reinterpret_cast<base**>(&dptr); неопределённое поведение?

мне кажется речь шла о *reinterpret_cast<base**>(&dptr)

Новые блоги и статьи Все статьи Все блоги /
Как дизайн сайта влияет на конверсию: 7 решений, которые реально повышают заявки Neotwalker 08.03.2026 Многие до сих пор воспринимают дизайн сайта как “красивую оболочку”. На практике всё иначе: дизайн напрямую влияет на то, оставит человек заявку или уйдёт через несколько секунд. Даже если у вас. . .	Модульная разработка через nuget packages DevAlt 07.03.2026 Сложившийся в . Net-среде способ разработки чаще всего предполагает монорепозиторий в котором находятся все исходники. При создании нового решения, мы просто добавляем нужные проекты и имеем. . .	Модульный подход на примере F# DevAlt 06.03.2026 В блоге дяди Боба наткнулся на такое определение: В этой книге («Подход, основанный на вариантах использования») Ивар утверждает, что архитектура программного обеспечения — это структуры,. . .	Управление камерой с помощью скрипта OrbitControls.js на Three.js: Вращение, зум и панорамирование 8Observer8 05.03.2026 Содержание блога Финальная демка в браузере работает на Desktop и мобильных браузерах. Итоговый код: orbit-controls-threejs-js. zip. Сканируйте QR-код на мобильном. Вращайте камеру одним пальцем,. . .
SDL3 для Web (WebAssembly): Синхронизация спрайтов SDL3 и тел Box2D 8Observer8 04.03.2026 Содержание блога Финальная демка в браузере. Итоговый код: finish-sync-physics-sprites-sdl3-c. zip На первой гифке отладочные линии отключены, а на второй включены:. . .	SDL3 для Web (WebAssembly): Идентификация объектов на Box2D v3 - использование userData и событий коллизий 8Observer8 02.03.2026 Содержание блога Финальная демка в браузере. Итоговый код: finish-collision-events-sdl3-c. zip Сканируйте QR-код на мобильном и вы увидите, что появится джойстик для управления главным героем. . . .	Реалии Hrethgir 01.03.2026 Нет, я не закончил до сих пор симулятор. Эта задача сложнее. Не получилось уйти в плавсостав, но оно и к лучшему, возможно. Точнее получалось - но сварщиком в палубную команду, а это значит, в моём. . .	Ритм жизни kumehtar 27.02.2026 Иногда приходится жить в ритме, где дел становится всё больше, а вовлечения в происходящее — всё меньше. Плотный график не даёт вниманию закрепиться ни на одном событии. Утро начинается с быстрых,. . .

@GoshaRubi 0 / 0 / 0 Регистрация: 18.09.2018 Сообщений: 4

	Восходящее преобразование массива производного класса к родительскому? 03.01.2020, 22:54. Показов 7079. Ответов 114 Метки ООП, с++ (Все метки) Есть два класса base_Class(родитель) и derived_Class(потомок) Есть некая виртуальная функция в base_Class которая принимает в качестве параметра массив объектов класса f(base_Class *mass) Чтобы воспользоваться данной функцией для производного класса, необходимо привести массив производного класса к массиву родительского Массивы: base_Class baseMass[100], derived_Class *derivedMass[100] Как произвести такое приведение типов? 0