Участник:Yulya3102/Плюсы2сем
Содержание
- 1 i8086
- 2 регистры общего назначения, сегментные регистры, регистр флагов
- 3 некоторые распространенные команды
- 4 команды для работы со стеком
- 5 соглашения вызова функций
- 6 32-битные регистры
- 7 stack frame
- 8 ошибки: возврат указателя на локальную переменную из функции, buffer-overrun для объектов в стеке
- 9 stack-smash protector
- 10 toolchain: препроцессор, транслятор, компоновщик
- 11 модификатор static
- 12 модификатор inline
- 13 one definition rule (ODR)
- 14 классы
- 15 конструкторы
- 16 деструкторы
- 17 const
- 18 ссылки
- 19 разница между ссылками и указателями
- 20 l-value, r-value
- 21 перегрузка операторов
- 22 оператор присваивания
- 23 разница между конструктором копирования и оператором присваивания
- 24 список инициализации
- 25 порядок инициализации/разрушения полей класса
- 26 volatile
- 27 директивы препроцессора
- 28 #include <>
- 29 #include ""
- 30 #define
- 31 #if
- 32 #else
- 33 #endif
- 34 #elif
- 35 #ifdef
- 36 #ifndef
- 37 #undef
- 38 include guards
- 39 #pragma once
- 40 #pragma once vs include guards
- 41 preprocessor pitfalls
- 42 циклический экспанд макросов
- 43 циклические зависимости на хедерах
- 44 неполные типы
- 45 name mangling
- 46 перегрузка функций
- 47 исключения
- 48 RAII
- 49 гарантии безопасности исключений
- 50 extern "C"
- 51 исключения в конструкторах
- 52 исключения в деструкторах
- 53 stack unwinding
- 54 возврат объектов из функции по значению, RVO
- 55 передача аргументов по значению, r-value/l-value
- 56 callback'и, способы фиксации аргументов у callback'ов
- 57 наследование, виртуальные функции, таблицы виртуальных функций
- 58 dynamic_cast
- 59 проблемы сишного typecast'а с неполными типами и несколькими базами, static_cast
- 60 const_cast, reinterpret_cast
- 61 зачем нужно виртуальное наследование (несколько баз с разными адресами у одного класса, typecast'ы, исключения)
- 62 виртуальное наследование
- 63 зачем нужны namespace'ы
- 64 namespace'ы, using declaration, using directive, namespace aliases
- 65 перегрузка операторов, ADL
- 66 зачем нужны шаблоны
- 67 базовое представление о шаблонах
- 68 два способа реализации шаблонов: Cfront-like, Borland-like, преимущества и недостатки обоих
- 69 специализация, частичная специализация
- 70 type_traits'ы
- 71 Контейнеры STL
- 72 Sequences: vector, list, deque
- 73 Associative Containers: [unordered][_multi]{set/map}
- 74 Итераторы, категории итераторов (Input, Output, Forward, Bidirectional, Random Access)
- 75 Примеры алгоритмов
- 76 find, find_if, search
- 77 remove, remove_if, прием с erase/remove_if
- 78 sort, stable_sort, partial_sort, nth_element
- 79 Много разговоров на тему того, что хоть явных ограничений на параметры шаблона нет, это не означает что их нет совсем.
- 80 копируемость/присваиваемость
- 81 требования к operator==
- 82 требования к operator<
- 83 согласованность operator== и operator<
- 84 разница между операторами внутри класса и снаружи (неявное приведение типов)
- 85 safe-bool
- 86 использование type_traits: SFINAE, tag-dispatching на примере STL
- 87 two-phase name lookup
- 88 STL: back-inserter, lower_bound, heap_*, priority_queue
- 89 const на примере STL
- 90 Concepts
- 91 anonymous namespaces
i8086
регистры общего назначения, сегментные регистры, регистр флагов
некоторые распространенные команды
команды для работы со стеком
соглашения вызова функций
32-битные регистры
stack frame
ошибки: возврат указателя на локальную переменную из функции, buffer-overrun для объектов в стеке
stack-smash protector
toolchain: препроцессор, транслятор, компоновщик
модификатор static
Local scope
//область видимости — блок
while (true) { static int i = 0; i++; }
Переменная i будет создана лишь один раз, и её значение будет храниться в течение всего времени выполнения программы, несмотря на выход за пределы области видимости. Тот же пример с выводом для наглядности.
Function scope
//область видимости — функция
void foo() { static int i = 0; i++; }
Аналогично, переменная i сохраняется между вызовами foo(), но видна только в пределах блока, в котором определена.
File scope
//область видимости — файл
static int global_static_local_to_this_file;
Очевидно, эта переменная будет видна повсюду в файле и только в нём.
Class scope
//область видимости — класс
Статические данные можно получить так же, как и нестатические, с помощью операторов . и ->. Но к ним также можно обращаться с помощью оператора ::, используя имя класса. Очевидно, создание объекта данного класса в данном случае не требуется.
Статические данные разделяются между всеми экземплярами класса.
Зачем это нужно? Например, так можно создать синглтон:
class singleton { private: singleton(){} public: static singleton& instance() { static singleton inst; return inst; } };
Объявление статической переменной внутри определения класса не является её определением. Если не инициализировать значение статической переменно, то по умолчанию будет присвоено значение 0. Внутри определения класса можно инициализировать переменные типов int, char, long, bool, а так же типов из пространства std.
Статические переменные не могут содержаться в локальных классах и не могут быть mutable.
Статические методы не имеют указателя this, поэтому в таких методах нельзя обращаться к нестатическим данным класса. К статическим методам можно обращаться через . и -> по имени объекта и по имени класса через ::.
Статические методы не могут быть виртуальными, не могут быть const и volatile. Локальные класса не могут содержать статические методы.
модификатор inline
one definition rule (ODR)
Вкратце, положения ODR выглядят так:
- В пределах любой единицы трансляции шаблон, тип данных, функция, или объект не могут иметь более одного определения. Некоторые могут иметь неограниченное число объявлений. Определение порождает сущность.
- В пределах программы (совокупности всех единиц трансляции) объект или не-inline функция не могут иметь больше одного определения; если объект или функция используются, у каждого из них должно быть строго по единственному определению. Можно объявить объект или функцию, которые не будут использованы в программе, в этом случае не потребуется и их определения. Ни в коем случае не должно быть более одного определения.
- Некоторые сущности, например, типы, шаблоны или внешние inline функции, могут определяться в более чем одной единице трансляции. Для данной сущности, каждое определение должно быть одним и тем же. Объекты или функции, не являющиеся внешними, в разных единицах трансляции имеют разные сущности, даже если их имена и типы совпадают.
Некоторые нарушения ODR могут быть обнаружены компилятором. Остальные, а это в первую очередь касается программ, состоящих из нескольких небольших файлов, пропускаются (программист должен самостоятельно о них позаботиться).
Например:
// file1.c: int a = 1; int b = 1; extern int c;
// file2.c: int a; extern double b; extern int c;
В данном примере 3 ошибки: a определено дважды (int a; является определением, которое означает int a=0;), b описано дважды с разными типами, а c описано дважды, но не определено. Эти виды ошибок (ошибки компоновки) не могут быть обнаружены компилятором, который за один раз видит только один файл. Компоновщик, однако, их обнаруживает.
классы
конструкторы
деструкторы
const
ссылки
разница между ссылками и указателями
l-value, r-value
перегрузка операторов
оператор присваивания
разница между конструктором копирования и оператором присваивания
список инициализации
порядок инициализации/разрушения полей класса
volatile
директивы препроцессора
#include <>
#include ""
#define
#if
#else
#endif
#elif
#ifdef
#ifndef
#undef
include guards
#pragma once
#pragma once vs include guards
preprocessor pitfalls
циклический экспанд макросов
циклические зависимости на хедерах
неполные типы
name mangling
перегрузка функций
исключения
RAII
гарантии безопасности исключений
extern "C"
исключения в конструкторах
исключения в деструкторах
stack unwinding
возврат объектов из функции по значению, RVO
передача аргументов по значению, r-value/l-value
callback'и, способы фиксации аргументов у callback'ов
наследование, виртуальные функции, таблицы виртуальных функций
dynamic_cast
проблемы сишного typecast'а с неполными типами и несколькими базами, static_cast
const_cast, reinterpret_cast
зачем нужно виртуальное наследование (несколько баз с разными адресами у одного класса, typecast'ы, исключения)
виртуальное наследование
зачем нужны namespace'ы
namespace'ы, using declaration, using directive, namespace aliases
перегрузка операторов, ADL
зачем нужны шаблоны
базовое представление о шаблонах
два способа реализации шаблонов: Cfront-like, Borland-like, преимущества и недостатки обоих
специализация, частичная специализация
type_traits'ы
This header defines a series of classes to obtain type information on compile-time.
The header contains: Helper classes: Standard classes to assist in creating compile-time constants. Type traits: Classes to obtain characteristics of types in the form of compile-time constant values. Type transformations: Classes to obtain new types by applying specific transformations to existing types.
Контейнеры STL
Sequences: vector, list, deque
Associative Containers: [unordered][_multi]{set/map}
Итераторы, категории итераторов (Input, Output, Forward, Bidirectional, Random Access)
Примеры алгоритмов
find, find_if, search
remove, remove_if, прием с erase/remove_if
sort, stable_sort, partial_sort, nth_element
Много разговоров на тему того, что хоть явных ограничений на параметры шаблона нет, это не означает что их нет совсем.
копируемость/присваиваемость
требования к operator==
требования к operator<
согласованность operator== и operator<
разница между операторами внутри класса и снаружи (неявное приведение типов)
safe-bool
использование type_traits: SFINAE, tag-dispatching на примере STL
two-phase name lookup
STL: back-inserter, lower_bound, heap_*, priority_queue
const на примере STL
Concepts
anonymous namespaces
You can declare an unnamed namespace as a superior alternative to the use of global static variable declarations.
namespace { namespace-body }
An unnamed-namespace-definition having the syntax shown above behaves as if it were replaced by:
namespace unique { namespace-body } using namespace unique;
Each unnamed namespace has an identifier, assigned and maintained by the program and represented here by unique, that differs from all other identifiers in the entire program. For example:
// unnamed_namespaces.cpp // C2872 expected namespace { int i; } // unique::i void f() { i++; } // unique::i++ namespace A { namespace { int i; // A::unique::i int j; // A::unique::j } } using namespace A; void h() { i++; // C2872: unique::i or A::unique::i A::i++; // C2872: A::i undefined j++; // A::unique::j++ }
Unnamed namespaces are a superior replacement for the static declaration of variables. They allow variables and functions to be visible within an entire translation unit, yet not visible externally. Although entities in an unnamed namespace might have external linkage, they are effectively qualified by a name unique to their translation unit and therefore can never be seen from any other translation unit.