Конечно, если бы idSoftware боялись UB, они бы не написали быстрый обратный квадратный корень. Но UB на то и UB, чтобы о работе программы нельзя было делать предположений после его возникновения.
Индексы реализованы через арифметику указателей в С и С++. Но то, что это технически одно и то же не значит, что они должны быть синтаксически одним и тем же. Взять вот такой пример. Можно было бы представить гипотетический язык "Супер-Си", в котором в этом случае происходило бы копирование массива, и sizeof выводил был нормально именно, что размер массива. Не хочется копировать массив - передавай его по указателю. Это была бы нормальная удобная семантика, консистентная со всем остальным в Си.
Да, спасибо, что подсветили. Тут к вопросу о том, возвращает ли malloc указатель на элемент массива? Если нет, то итерировать по этой памяти формально нельзя, даже если это - массив char.
Формально - да, так как lifetime массива не начался. Тут, вроде как, идёт дискуссия о внесении в том числе такого в стандарт. Это ещё к вопросу о том, что возвращает `malloc` - указатель на элемент массива, или нет?
Другое дело что это везде работает. Но если хочется прямо формально безупречно, то можно сделать что-то такое.
An array subscript is out of range, even if an object is apparently accessible with the given subscript (as in the lvalue expression a[1][7] given the declaration int a[4][5]) (6.5.6).
Не, ну там же не `int ***********ptr`) Я не вдавался в подробности эффективной имплементации списков, но там, всё-таки, должна быть структура, в которой данные и указатель на структуру. А указателя на указатель ... на указатель там, вроде, нет.
Тут я бы зашёл с другой стороны. Если new[] и delete[] и так знают размер массива (иначе как бы он тогда удалялся), зачем было делать вид, что он не известен (в случае аллокации). Но это - философский вопрос о совместимости с Си.
Чуть дополнил оригинальный пример, должно стать понятнее. Смотрите на приоритет операторов.
Вот да. Проблема может быть, если был
typdefмассива, а потом стал тайпдефаться в то же самое ужеstd::array. Получится неприятно.Конечно, если бы idSoftware боялись UB, они бы не написали быстрый обратный квадратный корень. Но UB на то и UB, чтобы о работе программы нельзя было делать предположений после его возникновения.
*Приводится к указателю на первый элемент в подавляющем большинстве случаев.
А в чём ещё ошибка?
Индексы реализованы через арифметику указателей в С и С++. Но то, что это технически одно и то же не значит, что они должны быть синтаксически одним и тем же. Взять вот такой пример. Можно было бы представить гипотетический язык "Супер-Си", в котором в этом случае происходило бы копирование массива, и
sizeofвыводил был нормально именно, что размер массива. Не хочется копировать массив - передавай его по указателю. Это была бы нормальная удобная семантика, консистентная со всем остальным в Си.Но не буду становится еслибыдакабышником)
Огонь! Сохранил себе, спасибо!
Если в плюсах можно (и нужно!) сказать, что лучше пользовать итераторы или ranged-for, то в С это выглядет вполне себе!
По идее, если литерал ДЛИННЫЙ, то будет удобнее, если в начале) Но почему тогда не отвести отдельную переменную?
Да, спасибо, что подсветили. Тут к вопросу о том, возвращает ли
mallocуказатель на элемент массива? Если нет, то итерировать по этой памяти формально нельзя, даже если это - массивchar.Ну, сконвертировать указатель на структуру в указатель на первое поле структуры можно. Так что в этом случае вы правы)
Там так и написано.
Формально - да, так как lifetime массива не начался. Тут, вроде как, идёт дискуссия о внесении в том числе такого в стандарт. Это ещё к вопросу о том, что возвращает `malloc` - указатель на элемент массива, или нет?
Другое дело что это везде работает. Но если хочется прямо формально безупречно, то можно сделать что-то такое.
Извините, я не очень понял, что вы имеете в виду) Если спросите другими словами, то отвечу.
За похвалу спасибо)
Нет. Выше в комментарии дали как раз ссылку на стандарт.
An array subscript is out of range, even if an object is apparently accessible with the given subscript (as in the lvalue expression a[1][7] given the declaration int a[4][5]) (6.5.6).
Ну да, я об этом и говорю. Как говорится, указатели абстрактнее, чем кажется.
И чаще всего мы программируем опротив абстрактной машины С++, а не конкретной железяки.
Не, ну там же не `int ***********ptr`) Я не вдавался в подробности эффективной имплементации списков, но там, всё-таки, должна быть структура, в которой данные и указатель на структуру. А указателя на указатель ... на указатель там, вроде, нет.
Является. В Сишном стандарте этот случай даже отдельно описан в списке UB из приложения.
А в чём закидон на UB? Если переаллокация сделается?
Непрерывная память - это лучшее, что придумали программисты)
Скорее, речь о правилах пользования этим концептом в нашем языке.
Тут я бы зашёл с другой стороны. Если
new[]иdelete[]и так знают размер массива (иначе как бы он тогда удалялся), зачем было делать вид, что он не известен (в случае аллокации). Но это - философский вопрос о совместимости с Си.