Удобное место, чтобы написать свою статью или просто почитать


Вот уже год без Dr. Dobb’s Journal

Если Вы никогда не были на сайте www.drdobbs.com, то Вам непременно нужно его посетить. Конечно, если программирование - это Ваш интерес. Ведь этот журнал имел огромное значение для всех нас, он был источник отличных статей от самых известных людей: когда-то в этом журнале опубликовал свой GNU Manifesto  Ричард Столлман, вёл свою колонку Герб Саттер, писал свои статьи Герберт Шилдт, книги которого Вы точно знаете.

Первый выпуск этого журнала состоялся в январе 1976 года. Только представьте себе! И сразу был ориентирован в первую очередь на разработчиков  программного обеспечения.  Dr. Dobb’s Journal был закрыт в декабре 2014 года. После 38 лет плодотворной работы.

Читать полностью | | | | 830



Модульное тестирование  (unit testing) в первую очередь помогает нам получить код, который в будущем "не страшно" будет изменить: внести новую функциональность, переписать ради повышения производительности, исправить ошибки. Разработка таких тестов  - прямая обязанность авторов кода, а сам процесс - это не что иное, как программирование. И, зачастую, разработка модульных тестов сопоставима и по времени и по сложности с разработкой тестируемого кода. Особенно, когда "дизайн" программы плохо продуман (например, запутанные связи между классами). 

Цель модульного тестирования - проверить отдельные "единицы" программы, например, методы класса. При этом тест не должен "выходить за рамки" этих методов. Но это проще сказать, чем сделать.

Классы, очень часто используют в своей реализации другие классы, а те в свою очередь включают еще множество классов. Так как практически все программы используют библиотеки и различные платформы - подобная ситуация закономерна. Редкая функция изолирована полностью от "остального мира" - но этот мир не должен охватываться одним модульным тестом!

Возникает вопрос: как в этом случае писать тесты, как абстрагироваться от зависимостей? Ответ: использовать mock-объекты. Данная статья включает краткий обзор применения mock-объектов в тестировании с использованием библиотеки Google C++ Mocking Framework.

Читать полностью | | | | 13125



Кортеж (std::tuple) появился в стандартной библиотеке начиная с С++11. Это неоднородный список элементов, типы которых задаются или выводятся на этапе компиляции. Кортеж "похож" на пару (std::pair), однако он может содержать произвольное (хотя и конечное) количество элементов. Интерфейс кортежа довольно простой: http://en.cppreference.com/w/cpp/utility/tuple

Создать кортеж можно так:

#include <tuple>

std::tuple<std::string, int, double> tuple_("hello", 42, 3.14);

Про кортеж говорят, что это коллекция гетерогенных значений (разнородных). Поэтому тип элемента (value_type), который определен в любом стандартном контейнере, не имеет смысла в кортеже, и просто отсутствует, ровно как и любой из типов итераторов. Кортеж не является обычным контейнерным классом, и не отвечает концепции контейнеров в С++ (http://en.cppreference.com/w/cpp/concept/Container). Поэтому простого способа обхода элементов кортежа нет. К нему не применимы какие-либо циклы:

for (auto& x : tuple_);  // Ошибка компиляции!

error: no viable 'begin' function available

"Пройтись" по элементам кортежа можно только точно зная количество его аргументов на этапе компиляции. Для этого нужно использовать функцию get:

std::get<0>(tuple_); // индекс элемента в качестве аргумента шаблона
std::get<1>(tuple_);
std::get<2>(tuple_);

При этом передача индекса во время выполнения программы невозможна:

int i = 0;
std::get<i>(tuple_);  // Ошибка компиляции!

Однако, задействовав шаблонное метапрограммирование, можно создать более удобный способ обхода кортежа на этапе компиляции.

Читать полностью | | | | 12327