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

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

Новые блоги и статьи Все статьи Все блоги /
Термопринтер QR701 Argus19 03.08.2026 Термопринтер QR701 Купил два термопринтера QR701. На сэлф-тесте написано: Language: PC936 (GB18030). Что означает, что принтеры могут печатать только латиницу и китайские иероглифы. Так же. . .	Создание формы заимствованного документа Maks 03.08.2026 Задача: Необходимо создать собственную форму заимствованного документа. На форме должен быть реквизит "Покупатель", а также табличная часть со следующими реквизитами: - Расчетный счет покупателя. . .	Задача предоставления скидок покупателям Maks 03.08.2026 Задача: В документе "Продажи" необходимо реализовать функционал предоставления скидок покупателям. Скидка должна автоматически рассчитываться и подставляться в соответствующее поле при выборе. . .	Почему SEO не начинается с ключевых слов: что проверить до написания текстов Neotwalker 01.08.2026 Когда владельцу сайта предлагают заняться SEO, первым шагом часто становится сбор запросов и написание текстов. Логика кажется понятной: 1. Находим ключевые слова. 2. Добавляем их на. . .
Знание — сила: Доктрина интенциональности знаний, углубление в формулу Hrethgir 01.08.2026 https:/ / www. cyberforum. ru/ blog_attachment. php?attachmentid=11957&stc=1&d=1785567302 Знаменитый афоризм Фрэнсиса Бэкона «Знание — сила» (Scientia potentia est) в массовой культуре принято понимать. . .	SUNO Ai - Река Без Дна zorxor 31.07.2026 Автор стихотворения - астрофизик Марина Катыс Ссылка на сгенерированную музыкальную композицию: https:/ / suno. com/ song/ 6f6e5464-b290-4650-be6c-44c85f8d8013 Я говорю, что Время- как вода течет. . .	Из невошедшего на форум (диалог с ИИ-гугла) zorxor 29.07.2026 А вот, что интересно, сказал мне ИИ-гугла: Этот текст — эмоциональный пост пользователя под ником zorxor на интернет-форуме (вероятно, посвященном мистике, непознанному или альтернативной науке). . . .	Был праздник вчера, а я и не знал. kumehtar 28.07.2026 27. 07. 2026г. Intel Core 2 Duo исполнилось 20 лет Салют, шампанское, овации! :drink:

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

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