Закон иерархических компенсаций Седова и

C++ Core Guidelines

Антон Семенченко

Обо мне

Антон Семенченкоавтоматизированное тестирование, низкоуровневая разработка, управление, продажиОснователь DPI.SolutionsМенеджер в EPAM SystemsТренер по автоматизации и

управлению

Евгений Александрович Седов

Советский ученый, инженер-практик, изобретатель, педагог, популяризатор науки

Разработка и внедрение систем в промышленности и военке

Руководил отделом из 11 лабораторий в течение 10 лет

Седов: междисциплинарные исследования

Более 200 публикаций: научных и научно-художественных!

кибернетика, теория информации, самоорганизация, стандартизация, исскусственный интеллект

Ключевая тема: проблема разнообразия

Разнообразие и эволюция

Сокращается ли внутреннее разнообразие систем в процессе эволюции?

Живая и неживая природа, язык, культура, технологии

От хаоса к детерменированности

И К

Хаос, максимальная энтропия

Жесткая детерминация

Путь от И к К - накопление структурной информации

Оптимальное соотношение: 80% детерминации20% хаоса

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

Магическое соотношение 80/20

80% детерминированности: языковая структура20% хаоса: вариабельность, “мутации”, “новости”, ради которых и пишется текст

При увеличении детерминированности теряется адаптивность, и система разрушится при изменении внешних условий

Единственный выход: разрушение, скачок от К к И и создание новой системы

Развитие: новые уровни иерархии

Новые уровни иерархии драматически увеличивают число новых связей между элементами системы

Связи = энергия, и единственный способ сохранить систему - это ограничить число элементов

Закон иерархических компенсаций

Разнообразие на верхних уровнях иерархии может быть обеспечено только за счет ограничения

разнообразия на нижних уровнях

Сложные системы можно строить только из ограниченного числа простых

Стандартизация неизбежна!

или

История С++

1983 - зарождение языка

1998 - стандарт С++ 98

2003 - стандарт С++ 03

2011 - С++ 11

2014 - С++ 14

2015 - C++ Core Guidelines

C++ Core Guidelines

Бьерн Страуструп

Герб Саттер

❖ Опубликованы в сентябре 2015❖ Open source (github)❖MIT-style (contributor) лицензия❖ Открыты для дополнения❖ Сейчас: около 250 страниц А4

https://github.com/isocpp/CppCoreGuidelines

Core Guidelines: идеология

"Within C++ is a smaller, simpler, safer language struggling to get out." - Bjarne Stroustrup

❖ Современный С++ 11/14/17 (прицел на будущее)❖ Автоматизируемые правила, где возможно❖ Безопасность и простота кода❖ Фокус на высокоуровневых вещах:

➢ типы и интерфейсы➢ управление ресурсами (в т.ч. памятью)➢ потокобезопасность

Core Guidelines: цели

❖ Использование накопленных годами знаний

❖ Унификация практик между организациями❖ Получить качественный код:

➢ статически типо-безопасный➢ без утечки ресурсов➢ с ранней диагностикой ошибок в логике

❖ Помочь новичкам в изучении С++

1. Непосредственно правила2. Guideline Support Library (GSL, header-only)

- функции и типы, рекомендуемые Гайдланами https://github.com/Microsoft/GSL

3. Checker Tool (Visual Studio Add-in) - автоматическая проверка правил

https://blogs.msdn.microsoft.com/vcblog/2015/12/03/c-core-guidelines-checkers-available-for-vs-2015-update-1/

Core Guidelines: компоненты

Описание правила

❖ Само правило - к примеру, Use RAII to prevent leaks

❖ Номер правила - например, E.6: 6-е правило об исключениях

❖ Reasons - почему правило именно такое

❖ Examples - примеры, как позитивные так и негативные

❖ Alternatives - альтернативы правилам-запретам

❖ Exceptions - исключения из правил

❖ Enforcement - как автоматизировать проверку правила

Rule Enforcement

❖ code review❖ static analysis❖ compiler❖ run-time checks

Guidelines Checker Tool

Humans are slow, inaccurate, and bore easily

Основные разделы

❖ P: Philosophy❖ C: Classes and class hierarchies❖ R: Resource management❖ E: Error handling❖ Con: Constants and immutability❖ T: Templates and generic programming❖ CP: Concurrency❖ SL: The Standard library❖ CPL: C-style programming

R.5: Don't heap-allocate unnecessarily

Reason

A scoped object is a local object, a global object, or a member. This implies that there is no separate allocation and deallocation cost in excess of that already used for the containing scope or object.

// Bad examplevoid some_function(int n){ auto p = new Gadget{n}; // ... delete p;}

// Good examplevoid some_function(int n){ Gadget g{n}; // ...}

Enforcement

(Simple) Warn if a local unique_ptr or shared_ptr is not moved, copied, reassigned or reset before its lifetime ends.

E.15: Catch exceptions from a hierarchy by reference

ReasonTo prevent slicing.

// Bad examplevoid f()try { // ...}catch (exception e) { // don't: may slice // ...}

// Good examplecatch (exception& e) { /* ... */ }

EnforcementFlag by-value exceptions if their types are part of a hierarchy (could require whole-program analysis to be perfect).

Con.2: By default, make member functions const

ReasonA member function should be marked const unless it changes the object's observable state. This gives a more precise statement of design intent, better readability, more errors caught by the compiler, and sometimes more optimization opportunities.

// Bad example.class Point { int x, y;public: int getx() { return x; } // BAD, should be const as it doesn't modify the object's state // ...};

void f(const Point& pt) { int x = pt.getx(); // ERROR, doesn't compile because getx was not marked const}

EnforcementFlag a member function that is not marked const, but that does not perform a non-const operation on any member variable.

Как поучаствовать?

We need help! - Bjarne

Можно помочь с примерами, подкрепляющими правила

Спасибо! Вопросы?

Антон Семенченко

skype: dpi.semenchenkosemenchenko@dpi.solutions