7
правок
Изменения
→зачем это нужно
== type erasure ==
http://prograholic.blogspot.ru/2011/11/type-erasure.html
Поправьте, если я не прав!
type erasure это нешаблонный объект, который позволяет в себе хранить объекты любого типа, которые удовлетворяют заданному интерфейсу.
#include <gtest/gtest.h>
#include <boost/function.hpp>
#include "type_erasure.h"
typedef boost::function<int ()> sample_signature;
TEST(TypeErasure, DeclareInterface)
{
type_erasure t;
sample_signature s(t);
}
any_iterator – подобие boost::function, но для итераторов. Позволяет одному итератору етерироваться по разным типам данных
typedef adobe::any_iterator<int, std::bidirectional_iterator_tag> any_iterator_to_int;
А потом в любом случае если нужно итерироваться по интам мы можем использовать его.
=== polymorphic function wrapper (aka {boost,std}::function) ===
http://habrahabr.ru/post/159389/
=== any_iterator ===
http://thbecker.net/free_software_utilities/type_erasure_for_cpp_iterators/any_iterator.html
=== понятие reentrancy ===
http://en.wikipedia.org/wiki/Reentrancy_(computing)
http://doc.qt.digia.com/qt/threads-reentrancy.html
=== пару слов про существующие реализации (boost::signals, boost::signals2, Qt Signals) ===
signals2 - thread-safe реализация signals
http://habrahabr.ru/post/50812/
http://www.rsdn.ru/article/cpp/signals2.xml
http://www.boost.org/doc/libs/1_39_0/doc/html/signals2/porting.html
== exception safety ==
Надо обязательно ловить ошибки в слотах, ибо иначе при испускании сигнала будут выполняться только те слоты, которые до пустившего исключение.
some link: [http://www.stroustrup.com/except.pdf] - слишком много
=== зачем это нужно ===
== multithreading ==
=== зачем это нужно ===
Ну вроде бы очевидно: увеличить скорость выполнения программы. Однако, стоит понимать, что иногда скорость может даже уменьшиться (в интернете есть куча примеров).
Более подробно - — это способ задействовать больше аппаратуры для выполнения алгоритма в современных компьютерах, которые хвастаются многоядерностью/многопроцессорностью - так достигается увеличение скорости выполнения. Это очень важно в бизнес-приложениях, а так как программист бизнес-приложений зарабатывает в два раза больше программистов других приложений, просто необходимо. Есть множество задач, которые хорошо делятся на несколько независимых друг от друга. Например, quicksort - после разделения элементов на группы, каждую из них можно сортировать независимо. Но тут важно не переборщить с его использованием, поскольку создание отдельного потока (thread, треда) тоже требует некоторых ресурсов, и сортировать в отдельном треде группы, скажем, по 2 элемента уже очень нерационально, это может как раз замедлить сортировку.
=== понятие race condition ===
Стандартный пример, как не нужно использовать multithreading. Пусть есть некоторые общие данные, а два потоки одновременно пытаются выполнить с ними какие-то операции. Например, есть переменная x = 0, два потока пытаются увеличить ее на 1. В итоге может получится получиться как 1, так и 2 (так и вообще непонятно что, см. [http://en.wikipedia.org/wiki/Race_condition]). Вывод: нужно lock'ать данные перед тем, как их использовать.
=== atomic operations ===
В 11х плюсах, чтобы не получались "race condition" есть atomic operations библиотека. Например, можно писать такой код:
http://en.wikipedia.org/wiki/Asynchronous_I/O#Select.28.2Fpoll.29_loops
http://en.wikipedia.org/wiki/IOCP
poll — даём список дескрипторов, из которых хотим читать/писать, он ждёт, пока какой-то будет доступен, и возвращает номер. Также можно по маске.
select — как я понимаю, он ещё хуже, даём n, он просматривает дескрипторы <= n
epoll — улучшение poll, мы можем заранее делать в него add, он хранит очередь из доступных дескрипторов, поэтому побыстрее (видимо, O(1))
kqueue — эквивалент epoll, только FreeBSD и ещё где-то
IOCP — это в Windows, тоже использует очередь
== remote procedure call ==
http://ru.wikipedia.org/wiki/%D0%A1%D0%BE%D0%BF%D1%80%D0%BE%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D0%B0 - короче это просто реализация этого принципа. Была нить ее разхреначили на волокна и идут сначала по одному - потом переключились на другой, поделали чето там, вернулись и продолжили идти по первому, например.
=== зачем это нужно ===
Фиберы - — это мануально переключаемые потоки. Всегда, когда удобнее вместо синхронизации использовать ручное переключение, применяются фиберы. Также, если потоков много и они однотипны, то целесообразно создавать фиберы, ибо они значительно экономят ресурсы. Можно устроить линейный обход по двоичному дереву поиска. Можно использовать генераторы. Например, генерировать простые числа.
=== coroutines ===
=== см. http://gcc.gnu.org/projects/cxx0x.html и http://www.stroustrup.com/C++11FAQ.html ===
RUS:http://sergeyteplyakov.blogspot.ru/2012/05/c-11-faq.html#auto // круто//лол кто-то не знал про auto?
=== про каждую фичу надо говорить, зачем это нужно, как это работает ===
=== static_if ===
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3329.pdf
template <unsigned long n>
struct factorial {
static if (n <= 1) {
enum : unsigned long { value = 1 };
} else {
enum : unsigned long {
value = factorial<n - 1>::value * n
};
}
Можно так же смотреть 64 битный ли у нас компилятор. Эти примеры вроде есть в пдфке.
=== modules ===
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3347.pdf
Профит от этого будет, например, в улучшении времени компиляции программ и в более понятных ошибках.
=== concepts ===
== ranges ==
http://www.boost.org/doc/libs/1_52_0/libs/range/doc/html/index.html -- а может это и не оно, хз
[http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3350.html#classstd_1_1range] — думаю, все же это.
[https://github.com/ericniebler/range-v3] - рабочий прототип, на основе которого пишется [http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/n4569.pdf Ranges TS]
=== зачем это нужно ===
Наверное, чтобы было удобно писать всякие обобщенные алгоритмы. Ranges позволяют взять какую-то часть содержимого произвольного контейнера и применять к ней какие-то операции с одинаковым интерфейсом.
=== как это работает ===
== encodings ==
[http://www.unicode.org/faq/utf_bom.html ясно и понятно]
=== понятие code unit, понятие code point, combining characters ===
Code unit — минимальная(по длине) битовая комбинация, которая может представлять символ. Для UTF-8 code unit равен 8, символы могут представляться одним или несколькими 8-битными последовательностями. В UTF-16 и UTF-32 code unit по 16 и 32 бита соответственно. [http://www.coderanch.com/t/416952/java/java/Unicode-code-unit-Unicode-code]
Code point — любое значение, которое может представлять символ юникода(0x0–0x10FFFF) [http://www.unicode.org/glossary/#code_point]
Combining characters — символы, которые в комбинации с другими дают новые символы (всякие крышечки, точечки, ударения, которые можно нарисовать над буквами).
=== UTF-8, overlong sequence ===
Смотрим, как преставляются символы в UTF-8: [http://en.wikipedia.org/wiki/UTF-8#Description]
Очевидно, что один и тот же символ может представляться разными последовательностями байт. Но по стандарту представление должно использовать минимальное число байт. Все остальные преставления называются overlong sequences.
Утверждают, что это даже бывает полезно. Например, в Modified UTF-8 символ NUL(U+0000) представляют двумя байтами C0 80, чтобы оставить 00 под символ конца строки. <del>Так делает Java для сериализации объектов, добавления строковых констант в .class-файлы и JNI.</del>
=== UTF-16, surrogate pair ===
В UTF-16 можно закодировать символы от 0 до 0xD7FF и от 0xE000 до 0x10FFFF, причем 4-байтные символы представляются как есть, а более длинные — с помощью суррогатных пар, для которых и вырезан диапазон 0xD800–0xDFFF.
В суррогатных парах старшие 10 бит значения идут в лидирующее (первое) слово, а младшие 10 бит — в последующее (второе). При этом в обоих словах старшие 6 бит используются для обозначения суррогата. Биты с 11 по 15 имеют значения 11011, а десятый бит содержит 0 у лидирующего слова и 1 — у последующего.
=== UTF-32 ===
UTF-32 использует ровно 4 байта на каждый символ. Это хорошо, потому что очень просто, и очень плохо, потому что неэффективно по памяти.
=== byte order mark ===
=== endianness, UTF-16BE, UTF-16LE, UTF-32BE, UTF-32LE ===
Два байта, входящие в code unit, при записи можно размещать по-разному. x86 использует little-endian(младшие сначала), а SPARC, ARM и другие — big endian. Чтобы различать их, в начало текста записывают byte order mark(BOM) — U+FEFF. Если считалось FFFE, то порядок little-endian, если FEFF — big. Дополнительный профит BOM — возможность отличить UTF-8 от UTF-16, потому что в UTF-8 FE и FF не используются, а BOM выглядит как EF BB BF(но ни на что не влияет, а просто является меткой). Также можно явно указывать порядок байт в кодировке(UTF-??BE или UTF-??LE), тогда BOM становится не нужен.
