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

Показаны статьи и заметки из категорий: Библиотеки и фреймворки ×

Приведение типов в С++ часто обсуждается на собеседовании. Эта тема особенно актуальна, когда приходится много работать с унаследованным кодом на С. Операторы приведения в С++ давно стали всем привычны: const_cast, static_cast, dynamic_cast и reinterpret_cast. И, конечно, никуда не делось  "приведение в старом стиле" - оригинальный синтаксис С, согласно которому заключенный в скобках тип переменной применяется к выражению new_type ) expression

Сравнивая операторы приведения между собой, программисты без проблем определяют когда и какой оператор нужно применять. О многом "подсказывают" сами названия этих операторов. reinterpret_cast при этом, всегда сравнивают с приведением типов в стиле С. "Не гарантирует переносимость кода, опасно и нежелательно". Всё это правильно, но вопрос в чём же тогда разница? Что делает reinterpret_cast, а что приведение типов в стиле С ? Частый ответ - это одно и тоже! И тут начинаются дополнительные вопросы...

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



Доводилось ли Вам писать код, который разбирает аргументы, переданные программе в командной строке? Думаю, ответ - да. Одни программисты предпочитают использовать специализированные инструменты, такие как Boost.Program_options в С++, или Commons CLI в Java. Другие же разработчики неустанно пишут свои собственные "парсеры" аргументов командной строки.

Что мы имеем в итоге? Если в компании программисты трудятся на разных языках, то скорее всего они будут использовать разные подходы к решению данной задачи. Хорошо если выработано общее соглашение о том, в каком виде программы должны принимать аргументы. Например, как выглядит короткая (-h) и полная (--help) форма для настройки,  какие ключи за что отвечают, и так далее. Такие требования не всегда существуют, как и документация по допустимым параметрам запуска. Реализации "парсеров" ведут себя по-разному, и не всегда хорошо написаны. Беспорядок и неразбериха...

Оказывается, эту проблему можно элегантно и исключительно быстро решить раз и навсегда. В этом поможет проект docopt. Это унифицированный и эффективный подход к разбору аргументов командной строки для любого языка (практически).

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



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

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

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

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

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

Показаны статьи и заметки из категорий: Библиотеки и фреймворки ×