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

@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)

Новые блоги и статьи Все статьи Все блоги /
Беседа с ИИ о программистах, недопускающих к созданию и правке кода генеративные ИИ и причины этого zorxor 21.09.2026 Раньше я радовался или получал некоторые эмоции, пусть небольшие, но всё же, от самого процесса написания кода, рекомпиляции и запуска, видя постепенное развитие программы и прочее. А теперь лень. . .	Мобильное приложение ColorStep pavlinmavlin 17.09.2026 Реализовал приложение Красный, Зеленый, Синий в Unity3d + c#. Название изменил на ColorStep. Приложение прошло модерацию и теперь доступно для скачивания. Делал его сам, шаг за шагом — и вот,. . .	Запрет дублирования строк в табличной части Maks 13.09.2026 Реализация из решения ниже выполнена на нетиповом справочнике "Нормы ТО" с табличной часть "Виды ТО", разработанного в КА2, со следующими реквизитами: - ВидТО (СправочникСсылка. ВидыТО); - ВидГСМ. . .	Скрипты Tampermonkey для CyberForum, ChatGPT, Claude и пр. Jin X 06.09.2026 Скрипты Tampermonkey для CyberForum, ChatGPT, Claude и пр. Работая с форумом и нейросетями в браузере часто хочется что-то подкорректировать или добавить какого-то функционала. Ниже прикреплён. . .
Программа опроса у.з. расходомера SLS-720F Argus19 02.09.2026 Программа опроса у. з. расходомера SLS-720F Программа опрашивает один раз в минуту три ультразвуковых расходомера SLS-720F через интерфейс RS-485 по протоколу Modbus RTU. Опрашиваются регистры. . .	Hyper-V: Компьютер должен поддерживать доверенный платформенный модуль 2.0. Maks 31.08.2026 При установке Windows 11 на виртуальную машину Hyper-V 2-го поколения вылезла такая ошибка: Решение: в параметрах виртуальной машины, в разделе "Безопасность" (Security) активировать флаг. . .	Архитектура биовида Стива в Майнкрафте: Зачем бонобо кубический каннибализм anaschu 30.08.2026 Кубический Вагинокапитализм в Minecraft: Математический инвариант ОДУ и рок Стивов-бонобо Главная задача разработанной «Модели Всего» — наглядно продемонстрировать наличие системной «судьбы». . .	Оттачиваю умение писать js программы. russiannick 30.08.2026 Проектом выходного дня стало написание Книги шифров Виженера. Итогом стала версия 200, синий туман. Синий туман назван так, потому что замораживает текст под собой. Нажатие синих кнопок управляют. . .

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

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