Антон @tntnkn
Не шалю, пишу статьи, починяю поломанное.
Информация
- В рейтинге
- 132-й
- Откуда
- Россия
- Дата рождения
- Зарегистрирован
- Активность
Специализация
Software Developer, Application Developer
C++
English
Linux
C
Python
Не шалю, пишу статьи, починяю поломанное.
Колдунство там для случаев, когда не известно, сколько скобочек ставить. Например, если бы я хотел написать свой flat(). Но это было бы UB.
UB есть и в вашем примере, строго говоря, по тем же причинам.
Если дело дошло до указателей на указатели на указатели, то это дело пахнет керосином.
Массивы в С++ - это не просто указатель. Как минимум, это указатель, к которому можно применять оператор сложения с числом. В противном случае получится UB.
Плюс, размер даже build-in массива известен компилятору (то есть без усилий программиста) до того, как произошёл array-to-pointer.
С std::array всё так. Можно сказать, что статья про то, что с ним-то всё как раз в порядке.
Если говорить о правилах языка - то выход за границу массива. Это UB, а при UB никаких гарантий поведения компилятора нет. Он может хоть "отформатировать диск", хоть запустить игрульку.
Modern C++ мы получили, осталось только дождаться С++2)
А так да, если можно использовать более надёжные конструкции без проблем в перформансе проекта - это же здорово!
Могу сослаться только на голову автора, сиречь меня. Заглавка - адаптация мема с Кодзимой.
Да. Но в контексте массивов не программист наделяет указатели дополнительными смыслами, а стандарт С++ (и Си). С этой точки зрения как раз и можно сказать, что тот же std::array позволяет сделать то, о чём вы и говорите.
Если '_____' - которое в статье, то это задумывалось, как отсылка к Большому Кушу)
А с std::array всё так)
Да. Но речь про массивы.
Конечно, про понимание вы написали абсолютно правильно. Кстати, про понимание указателей есть отличная статья.
Про std::array там речь тоже идёт.
Изначальная идея текста была именно в том, чтобы рассмотреть build-in массив именно в рамках плюсов. И в практической, и в теоретической части рассматриваются случаи, которых нет в Си.
Строго говоря, мне кажется, что "Си массив в Си" и "Си массив в С++" - это разные вещи, не смотря на одинаковую реализацию. Так как контекстов, в которых массив может использоваться, в плюсах много больше.
Под этим комментом пошло обсуждение скорости, думаю, лучше продолжить там.
Но говоря об обёртках - зачем делать свою обёртку над массивом, если есть std::array?
И в std::array, и в std::vector память расположена последовательно. Если std::vector хотя бы может переаллоцировать память, то std::array - это просто обёртка на буфером, то есть массивом.
Против практики не попрёшь, но...
И libstdc++, и libcxx в std::array в прямом смысле просто используют оператор индексации build-in массива в своём операторе индексации. Оно, скорее всего, заинлайнится. Поэтому мне пока что не очевидно, как std::array может проигрывать, во всяком случае в индексации. Да, там есть асерты даже в
operator[]
, но они не должны отрабатывать в продакшн коде.Инициализация и там и там агрегатов, так что тоже разницы не должно быть.
Тут хочешь не хочешь, но спросишь - почему не отвести отдельную переменную под этот литерал? Но об удобстве точно не спорят, пример хороший, спасибо!
Или перейти на С++2!
Классика) Причины понятны. Но я вот сам не встречал случаев, когда так записать и правда удобнее. Если у кого-то они есть, здорово бы было посмотреть.
Тут, мне кажется, тоже ещё вопрос, а быстрее ли build-in массив, чем std::array? Учитывая, что последний, фактически, это тонкая прослойка над первым, даже этот плюс не факт, что перевешивает.