Войти
ФлеймФорумПрограммирование

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

Страницы: 1 2 3 4 58 Следующая »
#30
7:36, 29 мар. 2018

Panzerschrek[CN]
> почему между массивами разных размеров нету отношений родства.
ради безопасности, это два разных типа, если ты пишешь что ожидаешь массив размером N, то он и должен быть размера N, а не N + M. То же самое что с const. Ты же не возмущаешься почему нельзя привести const char* к char* без "хаков".


#31
8:18, 29 мар. 2018

Я починил:

func((const int(&)[100])y);

#32
8:28, 29 мар. 2018

Aroch
> Ты же не возмущаешься почему нельзя привести const char* к char* без "хаков"

Но char* к const char* можно ведь? а int[100] и int[120] нельзя ни туда, ни сюда. Ну с int[100] к int[120] вполне понятно почему нельзя - принимающая сторона будет рассматривать память от 100 до 119 элемента как легальную для доступа. А вот с запретом кастования int[120] к int[100] уже не так очевидно, потому что int[120] хочется в этом контексте рассмотреть как

struct A100
{
   int e[100];
};

struct A120 : public A100
{
  int e2[20];
};
#33
8:35, 29 мар. 2018

Dmitry_Milk
> уже не так очевидно

Да вполне очевидно, если ты матрицу 2x2 реализовал как int[4], то явно не захочешь чтобы в процедуры с ней работающие можно было засунуть int[9] под 3x3, потому что это даст некорректный результат, лучше чтобы компилятор ругался.
На самом деле когда в функцию хочется пихать массивы разных размеров - есть прямая поддержка этого у Си в виде int[] и выдумывать тут ничего не надо.

#34
8:37, 29 мар. 2018

=A=L=X=
>Да вполне очевидно, если ты матрицу 2x2 реализовал как int[4], то явно не захочешь чтобы в процедуры с ней работающие можно было засунуть int[9] под 3x3, потому что это даст некорректный результат.
При чем тут матрица, зачем компилятору что-то додумывать за программиста?
Вот если бы там было вместо int[4] - int[2][2], тогда еще можно было бы так говорить.

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

#35
8:42, 29 мар. 2018

nes
> Нету в Си такой поддержки.

Держи: https://ideone.com/rebq6A

+ Показать

#36
8:48, 29 мар. 2018

=A=L=X=
Грязный трюк, это равносильно:

void foo(int* ptr, int size);
#37
8:48, 29 мар. 2018

=A=L=X=
> int arr[], int size

Насколько я понял топикстартера, ожидаемый цимес был в том, чтоб не передавать size - типа принимающая сторона всегда могла написать sizeof(x) (который всегда был бы равен 100) и при этом гарантированно не вылезти за пределы легальной памяти.

P.S. эээ, конечно же sizeof(x) = 100 * sizeof(int), а не 100, вечно детали упускаю из внимания :(

#38
8:57, 29 мар. 2018

=A=L=X=
> если ты матрицу 2x2 реализовал как int[4]

То ССЗБ. Если ты хочешь, чтоб обозначаемая тобой сущность была именно тем, что нужно, и никак не другим - то сделай ее структурой/классом, ни от чего не порождая. А массивы по своей сути всегда предполагают легальность слайсов.

P.S. впрочем, я не уверен для случая move-семантики.

#39
9:03, 29 мар. 2018

nes

> Грязный трюк

Напротив - именно за счёт таких продуманных и искусных трюков Си и получил бешеную популярность.

> Насколько я понял топикстартера, ожидаемый цимес был в том, чтоб не передавать size

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

> А массивы по своей сути всегда предполагают легальность слайсов

Я показал как предполагается реализовывать слайсы в Си - это int arr[] как есть. В чём проблемы то?

#40
9:07, 29 мар. 2018
2018
не юзать vector/array/shared_ptr<char[]>
зато юзать МОССИВЫ
#41
9:13, 29 мар. 2018

Dmitry_Milk
> Но char* к const char* можно ведь?
можно вообще любой тип к любому если сильно хочется, что дальше то?

#42
9:22, 29 мар. 2018

Aroch, речь ведь про автоматик касты. И вопрос топика в том, почему наложен запрет на автоматический каст fixed-size массива от большего размера к меньшему, ведь такой каст ни проблем с нарушением доступа к памяти, ни проблем с искажением типов элементов не вызывает.

#43
9:47, 29 мар. 2018

Dmitry_Milk
> речь ведь про автоматик касты.
С++ язык со строгой типизацией данных, еще раз int(&)[100] и int(&)[120] это два разных типа, и если в чьей то голове считается нормальным автокаст от 120 к 100, то для других это повод для проверки на наличие ошибки, на что компилятор и укажет.

#44
9:53, 29 мар. 2018

Ну и на всякий случай для ТС'a если ему делать совсем нечего, https://ideone.com/3lLBiA и по другому он больше не умеет.

Страницы: 1 2 3 4 58 Следующая »
ФлеймФорумПрограммирование

Тема в архиве.