Комментарии 23
И снова с нами куча дидактических ошибок:
Напоминаю про кодстайл:
- вы продолжаете использовать всякую ерунду в качестве индексов массива. Уж коль скоро сослались на container::size_type, так и используйте. Иначе как вы потом объясните людям, что их программа отваливается на 64 разрядной системе после второго гигабайта? Привычка садить int везде — вырабатывается быстро, искореняется — с трудом. Даже семинары с коктейлями не помогают.
- STL, векторы, и НИ ОДНОГО итератора. Просто выкинута из обсуждения вся прелесть ортогонализации алгоритмов от структур данных. Зато в теги слово "итераторы" вы засунули. Почему итераторы лучше индексов? Хотя бы потому, что итератор можно сделать константной ссылкой, что гарантирует невозможность испортить массив. Ошибка программиста (опечатка, например), которая нарушает здравый смысл (попытка записи в массив при его распечатке, например), при наличии константной ссылки будет отловлена еще на этапе компиляции.
- самопальный и громоздкий обмен вместо std::swap(). Использование std::swap() — наиболее правильно и переносимо. На какой-то платформе std::swap развернется в xor-swap, на какой-то — в специальную инструкцию вроде xchg, где-то будет замена через временную переменную… но нет, вы всадили единственный способ, не продемонстрировав хороший тон.
- снова перемешаны подходы из C и С++. Если в C под всякое преобразование типов нужна конструкция "(новый_тип)значение", что порождает путаницу (а что будет, если сделать (double)i, где i — переменная типа int? Будет создано новое значение типа double, или double побитово натянется на int? А ничего что размер в битах разный?). Специально, чтобы путаницу исключить, в С++ есть именованные преобразования, когда становится кристально ясно, что происходит. Почему бы сразу не учить хорошему подходу, который снижает показатель WTF в секунду?
- путаница стилей C и C++ относится и к макросу INT_MAX. Для этого в C++ есть std::numeric_limits
- вы не используете const, не демонстрируете учащимся хороший тон (const должен быть на всем, что не меняется!)
Напоминаю про кодстайл:
- дурацкий кодстайл Кернигана и Ричи, также известный как "египетские скобки", также известный как "строки на мониторе выдаются строго по талонам" — не делает C++ доступнее для изучающих язык новичков. Если скобки выровнять по вертикали, можно легко отлавливать границы блока простым пробегом глаз по вертикали, без необходимости носиться по концам всех строк, в поисках парной скобки. Даже подсветка от IDE не спасает.
И огород
На случай если Крот прийдёт
;-)
Подписываюсь под каждым словом. Такие статьи вредны́. Замечу также, что не увидел контейнеров, которые в заголовок вынесены. Один только
В настоящее время очень редко нужна возможность итерироваться по контейнеру индексом. Практически всё можно выразить алгоритмами и итераторами. В статье же не то что Your Father's C++, а какой-то Your Grandfather C++. Да и вообще наполовину C.
vector, без упоминания хотя бы array там, где он отлично бы вписался: float data[] = { 1., 2., 3., 4., 5., 6., 7. };
int n = sizeof( data ) / sizeof( data[ 0 ] );В настоящее время очень редко нужна возможность итерироваться по контейнеру индексом. Практически всё можно выразить алгоритмами и итераторами. В статье же не то что Your Father's C++, а какой-то Your Grandfather C++. Да и вообще наполовину C.
В этом ключе советую авторам взглянуть на Range Library
https://github.com/ericniebler/range-v3
Очень сильно расширяет возможности контейнеров и алгоритмов. Пока предлагается на рассмотрение комитету в стандартную библиотеку:
https://ericniebler.github.io/std/wg21/D4128.html
Хотелось бы увидеть статьи про эти новые вещи.
https://github.com/ericniebler/range-v3
Очень сильно расширяет возможности контейнеров и алгоритмов. Пока предлагается на рассмотрение комитету в стандартную библиотеку:
https://ericniebler.github.io/std/wg21/D4128.html
Хотелось бы увидеть статьи про эти новые вещи.
Посмотрю обязательно для себя, спасибо.
Но никак это в статьи не может войти по нескольким причинам: в совершенно ознакомительной статье (что там есть в STL и чего нет) соверенно не место "предложениям на рассмотрение комитету в стандартную библиотеку", а во-вторых, последовательность этих заметок (даже статьями назвать неуместно) написана не сегодня, показана по случаю если кому интересно будет, и переписывать что-то в планы мои не входит.
Но никак это в статьи не может войти по нескольким причинам: в совершенно ознакомительной статье (что там есть в STL и чего нет) соверенно не место "предложениям на рассмотрение комитету в стандартную библиотеку", а во-вторых, последовательность этих заметок (даже статьями назвать неуместно) написана не сегодня, показана по случаю если кому интересно будет, и переписывать что-то в планы мои не входит.
Подписываюсь под каждым словом. Такие статьи вредны́. Замечу также, что не увидел контейнеров, которые в заголовок вынесены. Один только vector, без упоминания хотя бы array там, где он отлично бы вписался:
Если бы вы ещё и читали, а не только писали, да ещё внимательно, то видели бы, что это только малая начальная часть серии заметок, следующая из которых как раз и предназначалась постепенному и естественному переходу от индексов к итераторам.
(Но куда уж нам: чукча, он, как известно, писатель...)
Так что в следующий раз, «подписываюсь под каждым словом» очередного пустобрёха, читайте внимательно в адрес чего там вы подписываетесь.
В настоящее время очень редко нужна возможность итерироваться по контейнеру индексом. Практически всё можно выразить алгоритмами и итераторами.
И кто же это вам рассказал столько удивительных глупости про «настоящее время»? Использование индексации или итераторов — две независимые формы выразить зачастую одно и то же. И, опять же, если бы вы ещё и читали то, что комментируете (кроме того чтобы спешить писать), то там бы вы отчётливо прочли про круг программистов и задач, с которыми обсуждались и на кого рассчитаны эти заметки: численный анализ, обработка временных рядов, сигналов, ортогональные преобразования, вэйвлеты и авто-регрессионный спектральный анализ… Это области вычислений, где алгоритмы десятилетиями выражались и публиковались исключительно в терминологии массивов и индексов: вектора, матрицы, свёртки, фильтрации. И переписывать их через итераторы часто просто нецелесообразно («из пустого в порожнее»), а когда и нужно, то делать это следует плавным, мягким переходом от индексов к итераторам.
Такие статьи вредны́.
Но если вы так определённо считаете, что таки «вредны́», то я, конечно, не смею не прислушаться к столько авторитетному мнению и не стану продолжать...
Мысли вслух…
Я там ненароком посмотрел всякие плюсы там, минусы … хотя вся эта ваша хабрахабровская лобода, шелупень и рюшечки — лайки, дислайки, кармы, рейтинги …: мне это глубоко всё до задницы. Но вот при ~10К просмотров, тех, кто не поленился отметиться лайком вдвое больше тех, кто отметился минусом. И это при том ещё, что минусят часто и не читая даже текст, испытывая одну только неприязнь к автору … (как это начнётся сейчас после моих вам ответов).
Но если бы даже и не вдвое, и если бы даже вообще не больше — просто есть те, кому такое обсуждение могло бы быть интересно и полезно. Но те, кому это вправду интересно (и читать и обсуждать), найдут продолжения в других местах, где эту серию, с разными вариациями, охотно публикуют.
А с вами, друг мой любезный, мы на этом и распрощаемся.
Идёт врачебный обход:
— До свидания, Иванов. До завтра, Петров. А вы, Сидоров — прощайте.
… и с 8-м марта тебя, убоище ;-)
(как это начнётся сейчас после моих вам ответов).
Ну так вот же ж оно: как начали исподтишка гадить, шавки! ;-)
Но вякнуть вслух — не смеют ...
Но заткнулись то как славно!
Сидят все "эксперты" тихо-тихо… — как мышки ...
И только минусят, минусят и минусят своими паскудными пальчиками. ;-) ;-) ;-)
Сидят все "эксперты" тихо-тихо… — как мышки ...
И только минусят, минусят и минусят своими паскудными пальчиками. ;-) ;-) ;-)
Соглашусь по сути, но отмечу, что стиль расстановки скобок — это все-таки дело вкуса (ну или холивара). Сторонники K&R стиля отмечают, что блок все равно выделяется отступом и визуально заметен ничуть не хуже.
Заголовок спойлера
Но сам я предпочитаю allman style.
И я только что увидел еще одну огромную гадость — вы умудрились переобозначить оператор "присвоение с суммированием" (+=), исказив его смысл.
Это — одна из самых коварных ошибок программиста на C++, потому как ведет к разночтениям ("Что это значит? Увеличить все в массиве на X?!). Вы снова вместо того, чтобы показать хороший тон (вполне очевидное и ясное push_back) увеличили количество WTF.
Это — одна из самых коварных ошибок программиста на C++, потому как ведет к разночтениям ("Что это значит? Увеличить все в массиве на X?!). Вы снова вместо того, чтобы показать хороший тон (вполне очевидное и ясное push_back) увеличили количество WTF.
я только что увидел еще одну огромную гадость
До чего же сильно я люблю этих диванных стратегов!!!
(по преимуществу выползков из начинающих вузовских пЫдагогов).
Я, признаться, был узумлён таким потоком праведного гнева, речью пламенного трибуна… на нейтральные, в общем то, заметки. Сознаюсь, в пороке любопытства заинтересовался даже: что же это за титан духа, светоч мысли такой, что разразился столь праведным гневом? Посмотрел публикации автора — а что ж это за нетленный вклад внёс такой «матёрый человечище» в сокровищницу Хабрахабра?
Ба … да здесь рваные ошмётки от какого-то не удавшегося учебного курса по машиной графике от ещё одного гейм-мейкера. Беда просто…
Мне как-то недосуг обсуждать здесь все высказанные титаном мысли… «аргуенты», с позволения сказать, относящиеся больше к категории бла-бла-бла, и не более того…
Но в отношении некоторых этих озарений я таки … не могу себе отказать в удовольствии постебаться. (Тем более, что согласно интриге, я специально долго молчал, чтоб дать возможность всласть высказаться всем.)
Ну прежде всего, давным-давно известное: Feci quod potui, faciant meliora potentes
Вас, gbg, не устраивают эти скромные заметки ни по стилю ни по содержанию? Ну так это ж и есть самое что ни есть время выйти на арену силачам мысли и акробатам духа, и сделать то же самое, но гораздо лучше!
я только что
Ну что? Поехали в стёб? ;-)
Иначе как вы потом объясните людям, что их программа отваливается на 64 разрядной системе после второго гигабайта?
Ваше намерение объявить в программе вектор длиной больше 1 миллиарда — меня искренне повеселило… просто повергло в божественный трепет (вы кстати, думаете что пишете? Или просто пишете что думаете?).
Безумству храбрых поем мы славу!
Безумство храбрых — вот мудрость жизни
Я даже начал благодаря вам вновь обретать совсем уже, было, потерянную веру в человечество...
итерируя массив всякой ерундой вроде unsigned (хорошо еще не int), когда для этого есть size_t
Где-то там я оговорился, что пишу для «цифровиков», занимающихся обработкой сигналов. Мне очень любопытно было бы посмотреть, как бы вы их упорно наставляли везде для индексации массивов (буферов, окон сглаживания, импульсных характеристик фильтров..., весьма ограниченного, в общем, размера: 128, 512, 1024 …), использовать не любый им и привычный int, а size_t или, ещё лучше, container::size_type.
Но с куда ещё большим удовольствием я бы выслушал на (или в?) какой орган бы они вас послали за такие вот ваши советы.
Я уважаю вашу болезненно-маниакальную … «мечту идиота» (здесь ничего личного — это просто такое идиоматическое выражение русского языка) настаивать для индексации повсеместно и исключительно посредством size_t … но нужно же и лицо как-то беречь от грубой силы, когда такое советуешь?
проигнорировав даже элементарные проверки входных параметров
Нужно ли в иллюстрационных фрагментах кода включать проверку параметров, обработку ошибок вызовов и другие подобные прелести?
Ни в кое случае! И никогда!
Иллюстрационный пример должен демонстрировать одну единственную мысль, которой он посвящён, не затемняя её никакими попутными действиями. (А вовсе не для демонстрации того, что вы настолько умны, что даже знаете как ошибки нужно обрабатывать.)
То, что ошибки нужно обрабатывать, ваши читатели знают и без вас, и как-то сами, поверьте, с этим разберутся.
путаница стилей C и C++ относится и к макросу INT_MAX. Для этого в C++ есть std::numeric_limits
А даже если путаница стилей … и есть std::numeric_limits? Ну и что из того? Для многих вещей есть множество способов выполнить одно и то же. А относительно смешения стилей, так вас никак не смущает то:
… что 20% или 30% заголовочных файлов C++ ( и мн.др.) — это только отсылка к заголовочным файлам C API (<stdlib.h> и т. д.);
… что большая часть библиотек C++ API — это всего лишь обёртки над POSIX API;
… что скомпилированный C++ код исполняется только совместно с библиотекой libc.so (стандартная библиотека C, по-народному), и что в отсутствии этой библиотеки, или если путь к ней не удастся найти, все приложения C++ просто окажутся неработоспособными (это я про нормальные операционные системы, не про Windows);
А в отношении стилей, путаницы и прочей шелупени, я могу, друг мой gbg, вот что вам сказать: в программной инженерии есть только 2 стиля: либо тяжело строгать работающий код под реальные внедрения, либо … «строть из себя целку»: кода не производя, но мечтательно рассуждая о тотальной индексации с size_t и о том, где скобочки элегантнее будут выглядеть.
не продемонстрировав хороший тон.
Молодой человек (судя по манерности ваших публикаций я имею все основания так считать), я не учитель бальных танцев, чтобы преподавать хороший тон. Я готов обсуждать технические, инженерные предметы — и понимание этой разницы очень важно.
Демонстрировать хороший тон «без дидактических ошибок» — это я оставляю вам.
Вы слишком много начитались дурных книжек про «идеальный код», и приняли их слишком близко к сердцу.
вы не используете const, не демонстрируете учащимся хороший тон (const должен быть на всем, что не меняется!)
Вот тут у нас принципиальное расхождение: это у вас ученики, а у меня нет учеников, у меня есть коллеги — я никогда не был профессиональным преподавателем, Бог миловал!
А программный код — он никому и ничего не «должен». Он должен только одно единственное: корректно и безукоризненно работать.
Напоминаю про кодстайл:
Ну, тут вообще порадовал… Этого я так ждал…
Мой юный друг, мне ваш кодстайл, или то, что вы думаете, что под ним понимаете — искренне по-хер (это правда, а правда ведь не бывает грубой, так ведь?). Если написанное мной так глубоко ранит ваше нежное эстетическое чувство и клокочущее гражданское достоинство, то … я скорблю вместе с вами: потому как я писал, пишу и буду писать только так, как привык и как считаю удобным для себя, любимого.
Как там у Иосифа Бродского на этот счёт?
Презренье к ближнему у нюхающих розы
пускай не лучше, но честней гражданской позы.
А ваше ущемлённое достоинство может спасти теперь только одно — неукоснительное следование правилу «трёх не» … ну, в данном конкретном случае: плюнул — повернулся — и не читай.
P.S. Пыжиться отвечать на мои наблюдения не надо...
Не говори никому. Не надо.
Потому что я всё-равно не стану это читать, да и не буду я дебатировать о вещах, которые для меня давно уже очевидны.
Менг Ли — женщина.
Ещё на баг в тексте наткнулся: "хэш-таблицы (map и multimap)". Контейнеры map и multimap - это ни разу не хеш-таблицы, у них внутри сбалансированные деревья. А на хеш-таблицах реализованы unordered_map и unordered_multimap.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Снова про STL: контейнеры