Стандартизация шагает по планете широким шагом. Почему создание сложных систем невозможно без подведения общего знаменателя и принятия стандартов? Можно ли объяснить этот факт с научной точки зрения? В докладе мы рассмотрим как общие вопросы стандартизации и развития информационных систем (в чём нам поможет великий советский ученый-практик Евгений Александрович Седов), так и погрузимся в стандартизацию практик кодирования нашего любимого языка - C++ Core Guidelines
2. Обо мне
Антон Семенченко
автоматизированное тестирование,
низкоуровневая разработка,
управление, продажи
Основатель DPI.Solutions
Менеджер в EPAM Systems
Тренер по автоматизации и
управлению
3. Евгений Александрович Седов
Советский ученый, инженер-
практик, изобретатель,
педагог, популяризатор науки
Разработка и внедрение
систем в промышленности и
военке
Руководил отделом из 11
лабораторий в течение 10 лет
4. Седов: междисциплинарные
исследования
Более 200 публикаций: научных и научно-
художественных!
кибернетика, теория информации,
самоорганизация, стандартизация,
исскусственный интеллект
Ключевая тема: проблема разнообразия
5. Разнообразие и эволюция
Сокращается ли внутреннее разнообразие
систем в процессе эволюции?
Живая и неживая природа, язык, культура,
технологии
6. От хаоса к детерменированности
И К
Хаос, максимальная
энтропия
Жесткая детерминация
Путь от И к К - накопление структурной
информации
Оптимальное соотношение:
80% детерминации
20% хаоса
Согласно ученым, такой путь
прошло большинство развитых
человеческих языков
7. Магическое соотношение 80/20
80% детерминированности: языковая структура
20% хаоса: вариабельность, “мутации”, “новости”, ради которых
и пишется текст
При увеличении детерминированности теряется
адаптивность, и система разрушится при изменении внешних
условий
Единственный выход: разрушение, скачок от К к И и создание
новой системы
8. Развитие: новые уровни
иерархии
Новые уровни иерархии драматически увеличивают
число новых связей между элементами системы
Связи = энергия, и единственный способ сохранить
систему - это ограничить число элементов
9. Закон иерархических компенсаций
Разнообразие на верхних уровнях иерархии может
быть обеспечено только за счет ограничения
разнообразия на нижних уровнях
Сложные системы можно строить только из
ограниченного числа простых
Стандартизация неизбежна!
или
10. История С++
1983 - зарождение языка
1998 - стандарт С++ 98
2003 - стандарт С++ 03
2011 - С++ 11
2014 - С++ 14
2015 - C++ Core Guidelines
11. C++ Core Guidelines
Бьерн Страуструп
Герб Саттер
❖ Опубликованы в сентябре 2015
❖ Open source (github)
❖ MIT-style (contributor) лицензия
❖ Открыты для дополнения
❖ Сейчас: около 250 страниц А4
https://github.com/isocpp/CppCoreGuidelines
12. Core Guidelines: идеология
"Within C++ is a smaller, simpler, safer language
struggling to get out." - Bjarne Stroustrup
❖ Современный С++ 11/14/17 (прицел на будущее)
❖ Автоматизируемые правила, где возможно
❖ Безопасность и простота кода
❖ Фокус на высокоуровневых вещах:
➢ типы и интерфейсы
➢ управление ресурсами (в т.ч. памятью)
➢ потокобезопасность
13. Core Guidelines: цели
❖ Использование накопленных годами
знаний
❖ Унификация практик между организациями
❖ Получить качественный код:
➢ статически типо-безопасный
➢ без утечки ресурсов
➢ с ранней диагностикой ошибок в логике
❖ Помочь новичкам в изучении С++
14. 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: компоненты
15. Описание правила
❖ Само правило - к примеру, Use RAII to prevent leaks
❖ Номер правила - например, E.6: 6-е правило об исключениях
❖ Reasons - почему правило именно такое
❖ Examples - примеры, как позитивные так и негативные
❖ Alternatives - альтернативы правилам-запретам
❖ Exceptions - исключения из правил
❖ Enforcement - как автоматизировать проверку правила
17. Основные разделы
❖ 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
18. 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 example
void some_function(int n)
{
auto p = new Gadget{n};
// ...
delete p;
}
// Good example
void 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.
19. E.15: Catch exceptions from a hierarchy by
reference
Reason
To prevent slicing.
// Bad example
void f()
try {
// ...
}
catch (exception e) { // don't: may slice
// ...
}
// Good example
catch (exception& e) { /* ... */ }
Enforcement
Flag by-value exceptions if their types are part of a hierarchy (could require
whole-program analysis to be perfect).
20. Con.2: By default, make member functions
const
Reason
A 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
}
Enforcement
Flag a member function that is not marked const, but that does not perform a non-const
operation on any member variable.