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

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

Новые блоги и статьи Все статьи Все блоги /
SDL3 для Web (WebAssembly): Обработчик клика мыши в браузере ПК и касания экрана в браузере на мобильном устройстве 8Observer8 02.02.2026 Содержание блога Для начала пошагово создадим рабочий пример для подготовки к экспериментам в браузере ПК и в браузере мобильного устройства. Потом напишем обработчик клика мыши и обработчик. . .	Философия технологии iceja 01.02.2026 На мой взгляд у человека в технических проектах остается роль генерального директора. Все остальное нейронки делают уже лучше человека. Они не могут нести предпринимательские риски, не могут. . .	SDL3 для Web (WebAssembly): Вывод текста со шрифтом TTF с помощью SDL3_ttf 8Observer8 01.02.2026 Содержание блога В этой пошаговой инструкции создадим с нуля веб-приложение, которое выводит текст в окне браузера. Запустим на Android на локальном сервере. Загрузим Release на бесплатный. . .	SDL3 для Web (WebAssembly): Сборка C/C++ проекта из консоли 8Observer8 30.01.2026 Содержание блога Если вы откроете примеры для начинающих на официальном репозитории SDL3 в папке: examples, то вы увидите, что все примеры используют следующие четыре обязательные функции, а. . .
SDL3 для Web (WebAssembly): Установка Emscripten SDK (emsdk) и CMake для сборки C и C++ приложений в Wasm 8Observer8 30.01.2026 Содержание блога Для того чтобы скачать Emscripten SDK (emsdk) необходимо сначало скачать и уставить Git: Install for Windows. Следуйте стандартной процедуре установки Git через установщик. . . .	SDL3 для Android: Подключение Box2D v3, физика и отрисовка коллайдеров 8Observer8 29.01.2026 Содержание блога Box2D - это библиотека для 2D физики для анимаций и игр. С её помощью можно определять были ли коллизии между конкретными объектами. Версия v3 была полностью переписана на Си, в. . .	Инструменты COM: Сохранение данный из VARIANT в файл и загрузка из файла в VARIANT bedvit 28.01.2026 Сохранение базовых типов COM и массивов (одномерных или двухмерных) любой вложенности (деревья) в файл, с возможностью выбора алгоритмов сжатия и шифрования. Часть библиотеки BedvitCOM Использованы. . .	SDL3 для Android: Загрузка PNG с альфа-каналом с помощью SDL_LoadPNG (без SDL3_image) 8Observer8 28.01.2026 Содержание блога SDL3 имеет собственные средства для загрузки и отображения PNG-файлов с альфа-каналом и базовой работы с ними. В этой инструкции используется функция SDL_LoadPNG(), которая. . .

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

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