Преобразование ссылок на массив [KRESTOPROBLEMY] (4 стр)

Aroch
> еще раз int(&)[100] и int(&)[120] это два разных типа

Еще раз - почему??? Почему тип int[2] не рассматривается как порожденый от int[1] с добавлением одного элемента (и.т.д. индуктивно)? Что запрещает?

Dmitry_Milk
> Еще раз - почему?
/_-
чтобы нельзя было передать массив с другим размером.

Зачем надо запрещать передачу ссылки на массив большего размера туда, где ожидается ссылка на массив меньшего размера? Что от этого поломалось бы?
Про меньшее в большее речь не идет, с этим случаем все ясно.

=A=L=X=
> Если ты не заметил - ему уже ответили.
Ответ содержал циклическую отсылку на самого себя.

-Почему массив меньшего размера нельзя передавать по ссылке как массив большего?
"Потому что такая-то аналогия с поршнями".
-Почему эта аналогия не работает для классов?
"Потому что она работает только для массивов".
-Почему?
"Потому что массив меньшего размера нельзя передавать по ссылке как массив большего".
Всё.

Aroch
> чтобы нельзя было передать массив с другим размером.
Ещё один циклический ответ.

Dmitry_Milk
> Почему тип int[2] не рассматривается как порожденый от int[1] с добавлением
> одного элемента (и.т.д. индуктивно)? Что запрещает?

Потому что надо смотреть на реалистичные примеры использования таковых массивов.
Еще один пример приведу - в таких СУБД как Paradox ранее текстовые поля были всегда фиксированного размера (char [20] например), при этом конец строки добивался пробелами, если в него пытались ложить строку меньшего размера.
И вот представь себе если в таком API мы передаём char name[50] в процедуру которая принимает char nickname[20] - она просто сформирует неправильные данные и компилятор этого не заметит.
Это ошибка так делать.

Dmitry_Milk
> Зачем надо запрещать передачу ссылки на массив большего размера туда, где
> ожидается ссылка на массив меньшего размера?
чтобы отследить ошибку, если ты пишешь что ты хочешь принимать массив только N размера, то будьте добры дайте мне массив N размера. C точки зрения механики особо ничего бы не сломалось, ты точно также можешь просто скопировать данные из большего массива в заранее подготовленный массив N размера и передать его потом, и если тебя такая логика устраивает, то можешь тупо скастовать, но вот только подобная логика это лишь частный случай, а в общем случае требования к данным внутри массива могут быть какими угодно и тупая конвертация из массива[N+M] в массив[N] приведет к ошибке в работе программы и ты потом будешь искать причину и побежишь на форум уже ныть: "Почему язык такой тупой не дает мне отследить это, я ведь указал ему что мне надо массив N какого хрена он принял массив N+M?"

Panzerschrek[CN]
std::vector. Можно передавать любого размера, можно использовать как массив

Aroch
> чтобы отследить ошибку, если ты пишешь что ты хочешь принимать класс только басе&
> типа, то будьте добры дайте мне класс басе& типа. C точки зрения механики
> особо ничего бы не сломалось, ты точно также можешь просто скопировать данные
> из деривед& в заранее подготовленный басе& и передать его
> потом, и если тебя такая логика устраивает, то можешь тупо скастовать, но вот
> только подобная логика это лишь частный случай, а в общем случае требования к
> данным внутри класса могут быть какими угодно и тупая конвертация из
> деривед& в басе& приведет к ошибке в работе программы и ты потом будешь
> искать причину и побежишь на форум уже ныть: "Почему язык такой тупой не дает
> мне отследить это, я ведь указал ему что мне надо класс басе& какого хрена он
> принял класс деривед&?"

1 frag / 2 deaths
> аналогия с поршнями"

Да я про свой ответ. не только char name[50] в Paradox-похожих СУБД нельзя передавать в char nick[20], но и наоборот. Несмотря на меньший размер - не произойдёт добития пробелами, требуемого системой.

1 frag / 2 deaths
если ты думаешь что аналогия с наследованием тут уместна, то у меня для тебя печальные новости.

Aroch
Тут бы вопрос:

Dmitry_Milk
> Почему тип int[2] не рассматривается как порожденый от int[1] с добавлением
> одного элемента (и.т.д. индуктивно)? Что запрещает?

На который ты дал циклический ответ. Низачот.

Dmitry_Milk
> Зачем надо запрещать передачу ссылки на массив большего размера туда, где
> ожидается ссылка на массив меньшего размера? Что от этого поломалось бы?
- нам нужно отправить 30 булочек!
- но там могут принять только 2 булочки!
- да и хер с ним, остальные 28 булочек идут лесом.
и пофиг, что в этих 28 булочках остались логин и пароль.

Kartonagnick
> - нам нужно отправить 30 булочек!
> - но там могут принять только 2 булочки!
> - да и хер с ним, остальные 28 булочек идут лесом.
> и пофиг, что в этих 28 булочках остались логин и пароль

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

Dmitry_Milk
> Почему тип int[2] не рассматривается как порожденый от int[1] с добавлением
> одного элемента (и.т.д. индуктивно)? Что запрещает?
потому что "Dmitry_Milk" это не наследник от "Dmitry" с добавлением "_Milk",
это два принципиально различных набора данных.
и там, где ожидается "Dmitry_Milk", "Dmitry" уже не проканает.

1 frag / 2 deaths
> Правильный ответ: потому что это никому не надо было, вот и не стали усложнять
> компилятор.
doublefacepalm.jpg