C++ *

Недавно на Хабре промелькнула пара статей о библиотеках логирования для С++. Статьи хорошие и доходчивые, автору респект. Но лично я не понимаю следующих вещей:

• Как можно пользоваться библиотекой, разработка которой заброшена много лет назад (log4cxx)?
• Зачем библиотеке логирования зависимости от других библиотек (log4cxx, Pantheios) ?
• Как можно не иметь такого базового функционала, как Rolling Files? (Pantheios)
• Зачем библиотеке логирования такие размеры (log4cxx — в сумме 4.1 Мб в архиве, Pantheios — 9.3 Мб в архиве )?
• Почему при компиляции библиотеки логирования я должен разгребать ~300 ошибок (log4cxx) ?

Поэтому я решил рассказать о такой библиотеке, как log4cplus, у которой:

• Последний стабильный релиз вышел в 2011 году, имеется активный трекер и постоянные коммиты в репозиторий
• Имеется куча механизмов вывода логов (одних только Rolling Files — 2 вида)
• Никаких внешних зависимостей
• Общий размер исходников в архиве — 420 Кб (это с документацией, тестами и примерами)
• В комплекте готовые проекты под разные платформы, которые компилируются без ошибок
• Прикручивается к проекту менее, чем за 5 минут

В первой части статьи рассматривается классическая идиома Pimpl (pointer-to-implementation, указатель на реализацию), показываются её преимущества и рассматривается дальнейшее развитие идиом на её основе. Вторая часть будет сосредоточена на том, как уменьшить недостатки, которые неизбежно возникают при использовании Pimpl.

Чуть ранее мы рассмотрели библиотеку логирования Pantheios. Пришла очередь ознакомится с более известной Apache log4cxx. Библиотека является имплементаций принципов и механизмов из log4j (библиотека логирования Java) на языке C++. Проект выглядит «мертвым», по крайней мере круных изменений в течение последнего года не наблюдается, впрочем это не повод не посмотреть (а может быть и использовать) эту библиотеку.

Здравствуйте!

Те, кто занимается программированием рано или поздно сталкивается с необходимостью прохождения технического собеседования у потенциального работодателя.

О том, что спрашивают на собеседовании у C++ программистов, а также об ответах на эти вопросы и пойдет речь в данном посте.

Всем так или иначе приходилось встраивать в свою программу систему логирования. Многие пишут свою, т.к. считают что умнее других её наиболее оптимальной. Другие же используют готовые библиотеки, которые могут сильно упростить жизнь.

Сегодня я хотел бы рассказать про библиотеку логирования Pantheios, которая обладает по заверению создателей большой скорость работы, мультипоточностью, поддержкой unicode и одновременного вывода в разные получатели логов.

В популярном компиляторе gcc, а конкретнее — в его оптимизаторе, была обнаружена очередная ошибка, приводящая к Runtime error в процессе выполнения программы. При включённой опции компилятора O2, оптимизатор неверно обрабатывает определённый шаблон программы, что приводит к фатальным последствиям.

Хабраюзер burdakovd задал в Q&A задачку про C++, vector и запись в чужую память. Задачка, кроме всего прочего, хороша тем, что на ней можно удобно продемонстрировать, как пользоваться инструментом Application Verifier и находить, кто же портит память.

Application Verifier — очень мощный инструмент, кроме диагностики работы с хипом он умеет уйму всего другого, например определять неправильную работу с хендлами, ошибки реализации многопоточности, эмулировать нехватку ресурсов, чтобы проверить корректную работу программы в таких условиях, но об этом как-нибудь в другой раз.

Вопрос на пять: что напечатает эта простая программа:

    #include <stdio.h>

    typedef int a;
    a b = 5;

    int main()
    {
       a(b);
       printf("%d\n", b);
       return 0;
    }

Уже натерпевшиеся от своего любимого языка, но ещё не прошерстившие всех бизонов gcc, почувствуют подвох — и правильно. Подсказка номер ноль: это скушает С++, но и простой С не подавится.

 

Начать статью я хотел бы с констатации того факта, что прямо за окном находится 2011 год (пруфлинк), середина апреля. Напоминаю я это в первую очередь себе, поскольку меня периодически посещают в этом сомнения. Дело в том, что как по работе, так и ради хобби я часто читаю код на С++, написанный лет 10-20 назад (но поддерживаемый и поныне) или код написанный совсем недавно, но людьми, которые учились программировать на С++ те же 20 лет назад. И вот после этого у меня и возникает ощущение, что никакого прогресса за эти годы не было, ничего не менялось и не развивалось, а по Земле до сих пор бродят мамонты.

Если в коде на C++ был создан массив объектов с помощью «new[]», удалять этот массив нужно с помощью «delete[]» и ни в коем случае не с помощью «delete» (без скобок). Разумный вопрос: а не то что?

На этот вопрос можно получить широчайший спектр неразумных ответов. Например, «будет удален только первый объект, остальные утекут» или «будет вызван деструктор только первого объекта». Следующие за этим «объяснения» не выдерживают обычно никакой серьезной критики.

В соответствии со Стандартом C++, в этой ситуации поведение не определено. Все предположения – не более чем популярные городские легенды. Разберем подробно, почему.

 

Введение

Многие уже знакомы с таким термином, как синглтон. Если описать вкратце, то это — паттерн, описывающий объект, у которого имеется единственный экземпляр. Создать такой экземпляр можно разными способами. Но сейчас пойдет речь не про это. Я также опущу вопросы, связанные с многопоточностью, хотя это очень интересный и важный вопрос при использовании данного паттерна. Рассказать бы я хотел о правильном использовании синглтона.

Продолжение первой части статьи.

2. Повторное использование DLL в своей программе

Возможности:

• открытие XLS файла,
• открытие файлов OpenOffice
• возможность открытия в скрытом режиме
• чтение данных из электронной таблицы
• полный спектр манипуляции с данными: вставка текста, числа, форматирование, объединение ячеек, установка границ, установка ширина столбца
• выгрузка xls таблицы на диск
• возмоность работы под WINE, при условий установки OpenOffice под Wine
• использование формул
• генерация версионно зависимого RDB файла налету (при необходимости)

На работе мы используем C++ Builder для написания внутренних программ, так что я делаю еще одну обертку над DLL для удобной работы с API.

По работе мне необходимо было разработать механизм загрузки и выгрузки данных из Excel используя свободные механизмы работающие под разными ОС.
Т.к. необходимо было, чтобы сервис работал под Linux, то механизм взаимодействия через OLE не подходил.
Для реализации был выбран OpenOffice с прямым доступом к API через C++.



Документация оказалась весьма скудная, а примеров работы не через OLE почти не было. Так что я решил объединить все мои исследования в одной статье на хабре.

Примерный план статьи:
1. Начало работы с API OpenOffice через C++
  1.1. Генерация заголовочных файлов
  1.2. Генерация файла типов RDB
  1.3. Настройка Visual Studiо 2008
  1.4. Собираем динамическую DLL
2. Повторное использование DLL в своей программе
  2.1. Пример небольшой программы по выгрузке данных

В принципе, если возможностей DLL достаточно, то повторять действия п. 1 не обязательно.

Пользователь yruslan опубликовал хорошую статью про арифметику с плавающей запятой: «Что нужно знать про арифметику с плавающей запятой».

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

Возможно, я сейчас буду рассказывать прописные истины, но вызывает удивление частота, с которой люди забывают, что числа которые описывает стандарт IEEE754 это не то же самое, что вещественные числа.

Даже совсем зеленые программисты на Си, не испытывают проблем с чтением таких объявлений:
int foo[5]; // foo массив из 5 элементов типа int
char *foo; // foo указатель на char
double foo(); // foo функция возвращающая значение типа double

Но как только объявления становятся немного сложнее, проблематично точно сказать что это. Например:
char *(*(**foo[][8])())[];


Написал Стивен Тови в 2:29 утра по программированию (шутка юмора Google Translate)
Вступление от себя: эта заметка, прорекламированная Алёной C++, предназначена в основном разработчикам игр для консолей, но будет, наверное, полезна и всем, кому приходится сталкиваться с экстремальным аллоцированием динамической памяти. Возможно, любители посравнивать управление памятью в C++ и Java тоже найдут над чем задуматься.

Оригинал с небезынтересной дискуссией в комментариях: altdevblogaday.org/2011/02/12/alternatives-to-malloc-and-new

Обязательная вступительная басня

Мне очень нравятся суши. Это вкусно и удобно. Мне нравится, что можно с бухты-барахты, не тратя целый обеденный час, зайти в суши-ресторан с конвейером, занять место и взять что-то свежее и вкусное с ленты. Но при всём при этом, чего мне реально не хотелось бы, так это быть официантом в суши-ресторане, особенно если бы моей обязанностью было бы рассаживать посетителей по местам.

“Даже если гарантированное логарифмическое время поиска вас устраивает, стандартные ассоциативные контейнеры не всегда являются лучшим выбором. Как ни странно, стандартные ассоциативные контейнеры по быстродействию нередко уступают банальному контейнеру vector” — C. Мейерс «Эффективное использование STL».
Многих возможно интересует практическая сторона этого совета, насколько же в действительности сортированный vector может быть быстрее ассоциативных контейнеров. Меня тоже интересовал данный вопрос и я решил провести небольшой тест и нарисовать пару графиков чтобы все встало на свои места.

Здравствуйте. Я планировал написать большую статью об управлении ресурсами в С++.
Но на практике, тема эта такая сложная и многогранная, что я хочу остановиться на определённой методике, которой пользуюсь сам. Данная методика не является спасением на все случаи жизни, но экономит много времени и нервов при работе с объектами. При этом, не является широко известной.