Comments 22
Серьёзный заход. Тут на выходе должна книжка не меньше мейерсовской должна получиться.
Использование VLA считается не очень хорошей практикой, особенно в multithread приложениях. Помимо очевидного роста стека (который не рассчитан на то, чтобы хранить большие данные), мы лишаемся возможности хорошо обработать ошибку его переполнения, вероятность появления которой сильно возрастает.
Так что пример с решетом Эратосфена на VLA я бы назвал антипаттерном. Если нужен большой массив, то время потраченное на malloc будет все равно мало по сравнению со временем, которое потребуется для его заполнения.
Так что мой рецепт: используйте VLA только там, где он действительно дает ускорение, на этапе оптимизаций. Скорее всего это будут маленькие временные массивы для строк или передачи аргументов в другую функцию.
Так что пример с решетом Эратосфена на VLA я бы назвал антипаттерном. Если нужен большой массив, то время потраченное на malloc будет все равно мало по сравнению со временем, которое потребуется для его заполнения.
Так что мой рецепт: используйте VLA только там, где он действительно дает ускорение, на этапе оптимизаций. Скорее всего это будут маленькие временные массивы для строк или передачи аргументов в другую функцию.
И немедленно сами себя успешно срезали:
И лично от меня (вкусовщина чистейшая):
Я лучше Майерса почитаю.
- засунув размер массива в int.
- наделав кучу бредовых индексных переменных вне циклов
- насовав в учебный материал сложносочиненные конструкции из присваиваний-с-одновременным использованием
- проигнорировав даже элементарные проверки входных параметров
- используя return 0; в main иногда. По собственному желанию, так сказать.
- итерируя массив всякой ерундой вроде unsigned (хорошо еще не int), когда для этого есть size_t
- используя в коде на C++ преобразования типов в стиле C.
И лично от меня (вкусовщина чистейшая):
- кодстайл "экономлю строки — не ставлю скобки на однооператорные блоки" — плодит таких же экономщиков. А потом они плодят идиотские баги.
Я лучше Майерса почитаю.
Я лучше Майерса почитаю.
Конечно лучше!
Если вы это не сделаи 14 лет назад, то сейчас — самое время почитать.
Майерс и про программирование с использованием С++11 тоже пишет, или вы только старое издание видели?
При чём здесь Майерс и его издания. Майерс — замечательная книжка…
Но господин высказал свою сокровенную мечту почитать Майерса, чего он не сделал тогда 14 лет назад, когда он только был издан… а всякая мечта заслуживает поощрения и поддержки, чего я ему от всей души и пожелал.
А если о Маерсе изволите, то — замечательная книжка, ещё раз, но для начального знакомства, понимания на качественном уровне, "на пальцах" — не годится.
Но господин высказал свою сокровенную мечту почитать Майерса, чего он не сделал тогда 14 лет назад, когда он только был издан… а всякая мечта заслуживает поощрения и поддержки, чего я ему от всей души и пожелал.
А если о Маерсе изволите, то — замечательная книжка, ещё раз, но для начального знакомства, понимания на качественном уровне, "на пальцах" — не годится.
Вам намекают, что у Майерса не одна книжка. Новая книжка, которая затрагивает особенности C++11 вышла только в декабре 2014. Её прочитать 14 лет назад при всём желании было нельзя (и это не просто обновление старой книжки, а совершенно новый материал, не повторяющий старые книги).
И немедленно
Комментарии к этому юношесткому… срачу и задору ;-) — я полнотью выписал в следующей части чтоб не повторяться.
Самые поздние стандарты (C99, C++11)
Да как бы и C11 уже есть. Причём некоторые вещи он, в отличии от C99 сделал опциональными. Например VLA.
Да как бы и C11 уже есть. Причём некоторые вещи он,
Я говорю о практике применения. Вы говорите об академическом теоретизировании.
У вас есть под рукой компилятор, полностью поддерживающий C11?
Вы часто используете новинки C11, например, макросы для создания комплексных чисел?
Или… вы, может, про такое и не слышали, а стандарт упомнили для красного словца?
Причём некоторые вещи он, в отличии от C99 сделал опциональными. Например VLA.
Рассуждениями про "опциональность" в стандарте от души повеселили, спасибо…
Это напоминает то, как дети начинают повторять за взрослыми слова и жесты, играют "в больничку" и тычут сломинкой в жопу...
Опциональность в стандарте — это для разработчиков компилятора.
Вы разрабатываете компилятор C?
Вы в состоянии разрабатывать компилятор C?
Вы знаете компилятор C для реальны проектов кроме GCC или Clang (ну, ещё для полноты картины: Sun компилятор из SolarisStudio и Portable C Compiler, использовавшийся в NetBSD и OpenBSD).
Какая опциональность?
Очевидно, с эмбеддед вы совершенно незнакомы. А там просто зоопарк компиляторов, с очень разным уровнем поддержки стандартов. И про Keil, IAR, не говоря уж про какой-нибудь TI Code Composer вы не слышали.
Я безумно рад, что наши доморощенные энциклопедисты обладают такой широтой эрудиии, что слышали и и готовы обсуждать обо всём… даже об embedded:
Но это очень и очень частные вещи, которые ну никак не вписываются в контекст обсуждений на Хабрахабр… для массовой гопоты.
Так что реплика не в зачот — пробуй исчо! ;-)
Наш пострел — везде поспел.
Но это очень и очень частные вещи, которые ну никак не вписываются в контекст обсуждений на Хабрахабр… для массовой гопоты.
Так что реплика не в зачот — пробуй исчо! ;-)
Задумка хорошая, но, мне кажется, Вы ушли в сторону от идеи сжатого обзора STL.
Основные проблемы обычных массивов, как я их вижу:
1. Если они создаются динамически, то нужно очищать память, а на стеке большой массив не выделишь.
А если рассматривать массив как контейнер, то кроме статического размера, как его особенности, хорошо бы упомянуть чем он плох или хорош в плане поиска, вставки, удаления, расхода памяти ...
А то у вас получилось, что массивы плохи, так как их размер статический, поэтому появились контейнеры STL.
Повторюсь, идея хорошая, хотелось бы увидеть обзор контейнеров STL со сравнением когда и какие контейнеры стоит использовать, как с ними лучше работать, и какие у них есть недостатки.
Основные проблемы обычных массивов, как я их вижу:
1. Если они создаются динамически, то нужно очищать память, а на стеке большой массив не выделишь.
2. Неудобство передачи массивов в функции.
приходится передавать дополнительным параметром размер массива:
или писать шаблон принимающий массив по ссылке
И нельзя смешивать передачу массива по ссылке и передачу массива по указателю. Т.е. если передали массив по указателю, то передать его уже куда-нибудь как ссылку на массив не получится (поправте меня, если это можно сделать).
void foo(int *arr, size_t size)
{
//... здесь sizeof(arr) вернет размер указателя
}или писать шаблон принимающий массив по ссылке
template<typename T, size_t N>
void foo(T (&arr)[N])
{
//... здесь sizeof(arr) вернет размер памяти выделенной для массива
}И нельзя смешивать передачу массива по ссылке и передачу массива по указателю. Т.е. если передали массив по указателю, то передать его уже куда-нибудь как ссылку на массив не получится (поправте меня, если это можно сделать).
А если рассматривать массив как контейнер, то кроме статического размера, как его особенности, хорошо бы упомянуть чем он плох или хорош в плане поиска, вставки, удаления, расхода памяти ...
А то у вас получилось, что массивы плохи, так как их размер статический, поэтому появились контейнеры STL.
Повторюсь, идея хорошая, хотелось бы увидеть обзор контейнеров STL со сравнением когда и какие контейнеры стоит использовать, как с ними лучше работать, и какие у них есть недостатки.
В С++11 VLA отсутствуют. Это расширение GCC. Если скомпилировать с
-Wall -Wextra -pedantic (к чему нужно с первых уроков приучать студентов), то GCC прямо в этом признаётся:/tmp/gcc-explorer-compiler116129-74-h99924/example.cpp: In function 'int main(int, char**)':
7 : warning: ISO C++ forbids variable length array 'a' [-Wvla]
bool a[ n = atoi( argv[ 1 ] ) + 1 ];
^
Для студентов я бы ещё -Werror добавил. Программки то маленькие, можно и переписать себе позволить всё.
В С++11 VLA отсутствуют. Это расширение GCC.
VLA — это никак не расширение GCC. VLA — это расширение введенное стандартом языка C99.
6.19 Arrays of Variable Length
Variable-length automatic arrays are allowed in ISO C99, and as an extension GCC accepts them in C90 mode and in C++.
P.S. Всем, кто претендует на звание доморощенных энциклопедистов, хорошо бы научиться различать.
Ну и далее… Answer
This is variable length arrays or VLA which is a C99 feature but gcc and clang support it as an extension in C++ while Visual Studio does not.
…
Not to say that extensions are bad, the Linux kernel depends on many gcc extensions, so they can be useful in certain contexts.
gcc and clang support it as an extension in C++То есть вы пытались опровергнуть мои слова, и сами же подтвердили их.
Ещё раз, поскольку вы не поняли:
— В языке C, VLA — это стандартная возможность, введённая в C99. Кстати, в C11 VLA сделаны опциональными, так что в C11 ваш код тоже может вполне легально отказаться работать.
— В языке С++, никаких VLA нет. Согласно стандарту этот код не должен компилироваться. И то что они таки работают в GCC — это частная инициатива разработчиков GCC. Это расширение.
PS Да, и вспомните что я вам писал в личку. Я изменил своё мнение о вас из-за вашего поведения в комментариях и поставил вам минус.
введённая в C99
Так в C99, или в GCC, как в вашем предыдущем утверждении?
Вы уж как-то определитесь.
Что ж это вы так легко свои позиции сдаёте?
Кстати, в C11 VLA сделаны опциональными, так что в C11 ваш код тоже может вполне легально отказаться работать.
Ну как дети малые — повторяете глупости за своим коллегой: опциональным для разработчиков компилятора, а не для кода… и не для вас ;-)
Это расширение.
Да. Расширение. Но не только GCC, а всех нормальных существующих компиляторов (ну, VisualStudio мы ж туда относить не станем?).
Да, и вспомните что я вам писал в личку. Я изменил своё мнение о вас
Писали вы в личку из трусости — наговорили лишнего, а потом сами сдрейфили… "как бы чего не вышло".
А на "мнения" ваши — мне искренне класть — как вы и видите.
Жёлтый заголовок! Обещали про STL, вместо этого налили кучу воды про голые массивы в сях и плюсах.
Sign up to leave a comment.
Снова про STL