LINUX.ORG.RU

Написал небольшую книгу для C/C++ программистов

 , , , ,


13

8

Здравствуйте. Меня зовут Андрей Карпов. Сфера моих интересов - язык C/C++ и продвижение методологии статического анализа кода. На протяжении пяти лет я являюсь Microsoft MVP в номинации Visual C++. Основная цель моих статей и работы, сделать код программ немножко безопасней и качественней. Буду рад, если эта мини-книга научит вас писать более надежный код и предостережет от некоторых типовых ошибок. Немало полезного здесь можно будет почерпнуть и тем, кто занимается написанием стандартов кодирования для своих компаний.

Немного истории. Не так давно я создал ресурс, на котором делился различными полезными советами по программированию на языке С++. Ресурс не собрал ожидаемое количество подписчиков, поэтому я не вижу смысла приводить здесь на него ссылку. Сайт просуществует какое-то время, после чего уйдет в небытие. А вот советы достойны сохранения. Поэтому я доработал, пополнил эти советы и объединил их в единый текст. Желаю приятного чтения.

UPD: PDF-версия: https://yadi.sk/i/RCHauHFBr2cSs

P.S. Пользуясь случаем приглашаю всех желающих последовать за мной в Twitter: @Code_Analysis.

>>> Главный вопрос программирования, рефакторинга и всего такого



Проверено: beastie ()
Последнее исправление: Aceler (всего исправлений: 3)

А вообще очень странно видеть книгу про венду на главной ресурса по линуксу. Удалить надобно отсюда и автора забанить.

Quasar ★★★★★
()
Последнее исправление: Quasar (всего исправлений: 1)

На протяжении пяти лет я являюсь Microsoft MVP в номинации Visual C++

пять балов, отлично набросил. От MS MVP уже получили теперь ждете Most Valuable Troll от лора?

st4l1k ★★
()
Ответ на: комментарий от Aceler

Во. Кстати основная критика KDE в том, что даже простенький блокнот там тянет 250МБ либ. Из-за этого KDE-софт считается второсортным, так как захламляет систему.

Лучше бы они действительно костыли писали, а не либы на каждый сих тянули.

EXL ★★★★★
()
Ответ на: комментарий от Deleted

При наличии SSD, i7 и 32 Гб оперативки молниеносно работать будет любой код. xD

Кроме Java. Она кажется вообще не способна быстро работать.

EXL ★★★★★
()
Ответ на: комментарий от znenyegvkby

М.б. именно эта разветка – результат долгих и кропотливых тестов и стараний целой команды.

Какое результат долгих тестов... Гнать тогда надо программистов, которые потратили уйму времени на оптимизацию некорректного кода.

Что толку тестировать и использовать, если там индексы перепутаны?

return (int) a[1] - (int) b[5];

P.S. Кстати, проврека выхода за границу массива здесь не поможет. Нет тут никакого выхода за границу. Есть ляп, из-за невнимательности при написании длинного однотипного кода.

Andrey_Karpov_2009
() автор топика
Ответ на: комментарий от Deleted

Лол, как низко.
Собстно, раз на то пошло, то уже 2 года как не школьник. Или студентов тут тоже принято грязью поливать, а возраст — наиважнейший критерий?

mersinvald ★★★★★
()
Ответ на: комментарий от znenyegvkby

Не факт, я может бы не в теме, какую именно версию анализировал товарищ Карпов, но в 5.7.12 уже давно

Вот и скажите мне спасибо. Благодаря мне мир стал чуть лучше.

Andrey_Karpov_2009
() автор топика
Ответ на: комментарий от fluorite

вы текст сначала на русском пишете, а потом на английский переводите, или наоборот?

В начале на русском. Затем переводчик переводит, я проверяю (как могу).

Andrey_Karpov_2009
() автор топика
Ответ на: комментарий от red75prim

Просто тактичное напоминание вроде «Не льсти себе, подойди поближе».

Отлично сказано!

Andrey_Karpov_2009
() автор топика
Ответ на: комментарий от st4l1k

Кто ж спорит то, но вот такой вопрос:
Кто будет опытнее:

1. 20-летний вьюноша, увлекшийся программировнием лет эдак в 13 и с 16 работающий по специальности
2. Или 40-летний админ, перепрофилировавшийся программиста с опытом, скажем, 2 года, коих персонажей с непомерным ЧСВ развелось слишком много.

UPD: Да и о каком опыте идет речь?
Если речь про жизненный, то несомненно.
А программерский опыт, по моему, не с возрастом наживается, а с практикой.

mersinvald ★★★★★
()
Последнее исправление: mersinvald (всего исправлений: 2)
Ответ на: комментарий от beastie

Полистал — там в самом деле дельные советы.

Советы дельные, но бОльшая их часть уже описана у Дьюхерста, Мейерса и прочих Саттеров. Плюс откровенная реклама ПМС-студии.

DELIRIUM ☆☆☆☆☆
()
Ответ на: комментарий от Andrey_Karpov_2009

Эх. Это уже 3 хостинг. Не везет нам с хостерами. Ну или мы не доросли до каких-то совсем дорогих и волшебных вариантов.

Откройте для себя торент.

psv1967 ★★★★★
()
Ответ на: комментарий от Andrey_Karpov_2009

Просто идеальная отговорка для MS MVP. Я, конечно, нидолбицца профессионал, но доказать мне нечем, NDA же!

CYB3R ★★★★★
()
Ответ на: комментарий от Andrey_Karpov_2009

Ага, этот профессионал ещё и без знания английского на школьном уровне. Выносите.

CYB3R ★★★★★
()
Ответ на: комментарий от Deleted

Вы просто на рунетовском ютьюбе коменты еще не читали ) По сравнению с ними мы тут просто няшки и верх вежливости )

foror ★★★★★
()
Последнее исправление: foror (всего исправлений: 2)

Тхреад не читал, но почему бы не создать репо на гихтхабе, туда исходники и собранные пдф/епаб, удобно же.

Автор молодец. Пиши еще.

ggrn ★★★★★
()
Последнее исправление: ggrn (всего исправлений: 1)
Ответ на: комментарий от EXL

Вы утверждаете, что добавление в язык скорости обязательно добавляет какую-то из этих 42х проблем?

slonopotamus
()
Ответ на: комментарий от mersinvald

Возраст меня не интересует, а вот тон высказываний, намекающий на обладание большим опытом, когда в действительности таковой не наличествует, может послужить для поливания не только грязью, но и говном.

Больше ответов не будет, не желаю разводить оффтопик-срач.

Deleted
()
Ответ на: комментарий от gag

Логично. Переписывание излишне запутанного кода, это тоже вариант исправления ошибки. И не самый плохой.

AVL2 ★★★★★
()
Ответ на: комментарий от segfault

Поправочка: язык программирования не решает _никаких_ проблем.

Ээээ, ну тогда накодь чего-нибудь полезного на Whitespace для сравнения.

Evgueni ★★★★★
()
Ответ на: комментарий от Evgueni

зачем такой экзотика, просто в машкодах целевой машины с ручным вычислением всех адресов - экий консерватор выискался.

qulinxao ★★☆
()

А Андрюшка неплохой вброс сделал! Уже на целых 6 страниц срача :-))

Desmond_Hume ★★★★★
()
Ответ на: комментарий от EXL

захламляет систему

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

Gonzo ★★★★★
()
Последнее исправление: Gonzo (всего исправлений: 1)
Ответ на: комментарий от segfault

> Ну критикоать много ума не надо.

1. Обоснуйте. Покритикуете ОТО?
2. C++ отвратительный язык вне зависимости от количества у меня ума. Пример: проблема (номер 39) с NULL, который задефайнен как 0, не существовала бы, если бы C++ задефайнил NULL так же как pure C: (void*)0. И попытка ее починить путем добавления nullptr десять лет спустя - костыль, NULL от этого не починился.
3. Rust

slonopotamus
()

Дочитал до конца, спасибо!

Если хотите сделать действительно книгу, а не брошюру типа прочёл и выбросил, выкиньте большую часть рекламы своего продукта, перегруппируйте примеры по разделам, вынесите всё Win Only в отдельную главу, поработайте над стилем. Может получиться что-то толковое, а может и не получиться, будет зависеть от вас. (Пишу не от балды и не чтобы вас обидеть, а как автор пары учебников на полторы и три сотни страниц).

Что касается сути происходящего, то в существующем виде брошюра является красноречивою антирекламою С++. Почти все описанные проблемы фактически можно разделить на три типа: 1) отсутствие строгой типизации и неявное приведение типов; 2) вложенные операторы инкремента (декремента) и присваивания, в том числе внутри условия; 3) копипаста. Третий случай, с которого всё начинается, самый редкий и здесь однозначных советов нет, хотя как правило, лучше всё завернуть в функцию или цикл, производительность в большинстве случаев не просядет или просядет незначительно. Первый и второй случаи просто эпичны тем, что это почти исключительно Си/Си++ проблемы (иногда, как показывают некоторые комментарии) даже чисто Си++ проблемы (некоторые упоротые товарищи продолжают считать их возможностями). В современном языке при разработке прикладного софта, будь то базы данных, аудиоредактор или офисный пакет эти «возможности» только вредят. Поэтому использование Си++ ни разу не оправдано.

Vudod ★★★★★
()
Последнее исправление: Vudod (всего исправлений: 2)
Ответ на: комментарий от Harald

зачем так сразу толсто набрасывать?

Я помню, что раньше в Development примерно так и начинали.

cipher ★★★★★
()
Ответ на: комментарий от Vudod

В современном языке при разработке прикладного софта, будь то базы данных, аудиоредактор или офисный пакет эти «возможности» только вредят. Поэтому использование Си++ ни разу не оправдано.
Поэтому использование Си++ ни разу не оправдано.

А мужики-то не знают. Поэтому весь прикладной софт на C++. Вот это парадокс!

RazrFalcon ★★★★★
()

В шестом пункте Вы предлагаете заменить

img = (Ipp32f*)((unsigned long)(img) + iStep);
на
img += iStep / sizeof(*img);
что очевидно неверно, так как сдвиг должен быть на байты а не на элементы размера sizeof(Ipp32f). Вернее будет написать
img = (Ipp32f*)((char*)(img) + iStep);
Или вообще упростить
(char*)img += iStep;

A-234 ★★★★★
()
Последнее исправление: A-234 (всего исправлений: 1)

Почитал мини книгу. Хм...
Неправильно Вы ее назвали. Надо было примерно так:
«Как пройти по минному полю С/С++ и остаться хотя бы с одной ногой».

Выбирая С/С++ ты ведешь себя как комсомолец - сам создаешь трудности, сам потом их преодолеваешь.

vada ★★★★★
()
Ответ на: комментарий от RazrFalcon

Вы можете возразить по сути или будете крыть полудостоверными аргументами в стиле: «миллионы мух не могут ошибаться» и «динозавры срали по тонне в час, их какашки находим и сейчас».

Vudod ★★★★★
()
Ответ на: комментарий от A-234

что очевидно неверно, так как сдвиг должен быть на байты а не на элементы размера sizeof(Ipp32f)

На байты сдвигать нельзя. Результат будет верен только если сдвиг кратен размеру элемента. Поэтому вариант «img += iStep / sizeof(*img);» вполне допустим. В противном случае, если захотим сдвинуть, например на 1 байт, все равно работать не будет. Получим UB.

Andrey_Karpov_2009
() автор топика
Ответ на: комментарий от vada

Это из истории про ёжиков, которые плакали, но продолжали колоться. Уже много раз было доказано, что проблемы Си++ не решаются в основе своей новыми стандартами и библиотеками, так как это не позволяет запретить использование старых, забагованных, но «эффективных» подходов.

Си++ спасает огромное количество написанного кода и родная поддержка со стороны ОС и основных библиотек. Если завтра окажется, что ОС переписаны на другом языке или хотя бы написана новая библиотека графического интерфейса не на Си/Си++, народ станет массово мигрировать на новую экосистему. В подтверждение моего мнения нужно вспомнить, что несмотря на уродство и сложность Обжектив-Си он оказался очень востребован, а переход на Свифт ещё более упрощает писание программ для Макоса и там отказ от Си++ уже является нормою.

Vudod ★★★★★
()
Последнее исправление: Vudod (всего исправлений: 1)
Ответ на: комментарий от Vudod

Если хотите сделать действительно книгу, а....

Спасибо за комментарий. Планов делать настоящую книгу у меня сейчас нет. Надо понимать, что этот текст является побочным продуктом работы над проектом PVS-Studio и его рекламы.

Andrey_Karpov_2009
() автор топика
Ответ на: комментарий от Vudod

м-да, сколько ненужного выросло за полста лет, а всего-то требовалось выучиться использовать паскаль(модулу, оберон). Не появился бы сонм тупиковых языков типа питона, джавы, c++ - легион их! Ну и всяких средств для борьбы в них c ними.

Pm7vLB
()
Последнее исправление: Pm7vLB (всего исправлений: 2)
Ответ на: комментарий от Vudod

полудостоверными аргументами

WUT? Это же вроде как лор, а значит линукс, в котором 95% софта написано на C и C++. Или тут я тоже не прав?

RazrFalcon ★★★★★
()
Ответ на: комментарий от Pm7vLB

Ну, Паскаль и Модула не идеальны, особенно в их исходном виде. И то, что хорошо для обучения, не всегда удобно в промышленном программировании. Но проблема действительно знаковая, потому что Паскаль не позволит наступить на большинство описанных здесь граблей вследствие достаточно строгой типизации и запрета побочных эффектов в операторах сравнения и циклах.

Ситуация интересна тем, что Си и Си++ (несколько менее) привлекает особую породу людей, настоящих хакеров, этаких джедаев от программирования. Эти люди вроде Торвальдса очень талантливы, но особенно в юности любят всякие хаки и «крутые штуки» на достаточно низком уровне. В реальности эти приёмы в большинстве случаев (не во всех, конечно) ничего не дают, либо их вклад в оптимизацию относительно не велик, но возможность сделать отрицание путём побитового сдвига целого знакового числа, используемого вместо логической переменной, превращая -1 в 0 и наоборот, показывает их крутизну и они ни за что от этого не откажутся. Такие хакеры в силу таланта и активности оказываются очень влиятельны, в том числе и потому, что начинают новые проекты, и начинают их часто на Си или Си++.

Для индустрии это беда, так как баги потом вылавливают годами, в том числе в системных библиотеках, а большинство программистов в индустрии не может подняться на достаточный уровень, чтобы оценить и использовать такой подход. Потому индустрия всеми силами пытается мигрировать на Яву, Си#, Го, Эрланг и согласна даже на Скалу и выносящий большинству быдлокодеров мозг Окамл, лишь бы не использовать Си++.

Vudod ★★★★★
()
Ответ на: комментарий от Deleted

Я думаю, что в 19 лет писал бы такую же пафосную чушь :)

tailgunner ★★★★★
()
Ответ на: комментарий от Andrey_Karpov_2009

Тут все от архитектуры зависит, тем более что Вы сами написали:

Указатель хотят сдвинуть на определённое количество байт.

Но если выравнивание требуется то нужно генерировать исключение в случае неправильного значения сдвига.

A-234 ★★★★★
()
Последнее исправление: A-234 (всего исправлений: 1)
Ответ на: комментарий от RazrFalcon

Большинство, наверное. Хотя это зависит от того, как считать. Вот Unity и Deluge написаны на Питоне и работают себе неплохо, а 3-тий Гном написан на Вале и у него проблемы, но совсем не по причине Валы, а потому что решили дизайн для планшетов распространить на всех. Куча библиотек для учёных и инженеров, доля которых в Линуксе непропорционально велика, написаны до сих пор на Фортране. Потому что так удобнее код поддерживать. И периодически попадаются новые проекты. Double Commander написан на Паскале вообще и ничего, работает себе пристойно, а глючит не чаще, чем Си++ный Крузадер. Вот на вскидку: одна из наиболее популярных игрушек ОпенСорс --- Freecol написана на Яве целиком. Есть куча софта на Перле, Тикле и той же Яве (вспомним oolatex) для анализа и обработки текстов, а Питон и Руби используются даже в системном софте вроде менеджера пакетов в Генте/Федоре/Сусе (не последние дистрибутивы).

Но если вы вылезете из мирка вашего локалхоста, то увидите, что полно прикладного коммерческого софта для того же Линукса и прочих Unix'like пилится на Яве, Эрланге, Го, Питоне, Яваскрипте и даже Скале и Окамле. И оно работает ничуть не хуже, чем написанное на Си++.

Vudod ★★★★★
()
Ответ на: комментарий от Deleted

При наличии SSD, i7 и 32 Гб оперативки молниеносно работать будет любой код. xD

запусти у себя

#include <unistd.h>

int main(void)
{
    while(1) fork();
}

UVV ★★★★★
()
Ответ на: комментарий от Vudod

Питон и Руби используются даже в системном софте вроде менеджера пакетов в Генте/Федоре/Сусе (не последние дистрибутивы).

Не стоило вам про это упоминать. В связи с выбором python'а огребли кучу проблем. При переходе к нормальной архитектуре - куча проблем.

x86_64 ★★★
()

В 9-м примере Вы упускаете из виду, что не все программисты пишут под винду, т.е. макрос _T может быть не определен.

A-234 ★★★★★
()
Ответ на: комментарий от Displacer

Я бы не назвал это технической книгой во первых, а во вторых какие альтернативы будут лучше и почему?

Да как есть или в pdf. fb2 - оно для художественных книг.

praseodim ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.