Одно время приходилось постоянно работать с сетевыми данными и в особенности с заголовками сетевого и транспортного уровней модели OSI. Постоянно напрягал тот факт, что многие поля были в Big-Endian, а код выполнялся на архитектуре Little-Endian. Ну невозможно было постоянно вызывать ntohl(), htonl(), ntohs(), htons()...


Автор фото: Ciroduran, источник фото: flickr.

Не так давно на работе встала передо мной задача написать прогу в среде C++ Builder, и был в ней момент, когда нужно парсить командную строку. К задаче прилагалось так же волшебное «можешь юзать все исходники, которые есть. Лежат они тут: ...». Первым делом полез, конечно, по адресу… и нашел там жутко ветвящуюся структуру кода, в которой попытался разобраться и решил, что подгонять ее под себя – ад. Поэтому пришло мне в голову написать что-то подобное Qt-шной системе сигналов и слотов, только для C++ Builder’а и аргументов командной строки.
Итак, начнем. Идея такова: анализ командной строки сводится к проверке, есть ли в аргументе спецсимвол (в моем случае – это «-» – был взять стандарт Linux). В зависимости от этого аргумент читается как имя параметра или его значение. Для вызова функций обработки используется ассоциативный массив, т.е. массив в котором в качестве ключей будут имена доступных параметров, а значений – адреса функций обработки конкретного параметра. Вот, в общем-то, и все. Приступим к реализации?

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

Аннотация

Это третья статья, просвещенная порождающим шаблонам проектирования и связанным с ними вопросами. Здесь мы рассмотрим излюбленные приемы при создании объектов: фабрики, заводы, абстрактные фабрики, строители, прототипы, мультитоны, отложенные инициализации, а также немного коснемся pimpl идиомы или шаблона “мост”. Использование синглтонов было подробно рассмотрено в первой [1] и второй [2] статьях, однако, как вы увидите в дальнейшем, синглтоны часто используются совместно с другими шаблонами проектирования.

Когда вставал вопрос о тестировании кода, я не задумываясь использовал boost::test. Для расширения кругозора попробовал Google Test Framework. Помимо всяких имеющихся в нем плюшек, в отличии от boost::test проект бурно развивается. Хотел бы поделиться приобретенными знаниями. Всем кому интересно прошу

Есть мнение, что алгоритм std::fill() работает столько же эффективно на простых типах, как и старый добрый memset() (так как он его и использует в некоторых специализациях).

Но порой не все так прозрачно, как хотелось бы. Рассмотрим программу.

Доброго времени суток, Хабралюди!

Гуру C++, а также люди смыслящие в шаблонном метапрограммировании могут смело пропускать этот топик, ничего нового для себя они здесь не найдут. Однако, если после прочтения заголовка, у вас в голове еще не возникло решение данной задачи (и даже если оно возникло, но не при помощи шаблонов), то милости просим под кат.

Эта статья является продолжением моей первой статьи “Использование паттерна синглтон” [0]. Сначала я хотел все, что связано со временем жизни, изложить в этой статье, но объем материала оказался велик, поэтому решил разбить ее на несколько частей. Это — продолжение целого цикла статей про использование различных шаблонов и методик. Данная статья посвящена времени жизни и развитию использования синглтона. Перед прочтением второй статьи настоятельно рекомендуется ознакомиться с моей первой статьей [0].

В предыдущей статье была использована следующая реализация для синглтона:

template<typename T>
T& single()
{
    static T t;
    return t;
}

Функция single возвращала нам заветный синглтон. Однако данный подход имеет изъян: в этом случае мы не контролируем время жизни объекта и он может удалиться в тот момент, когда мы хотим этим объектом воспользоваться. Поэтому следует использовать другой механизм создания объекта, используя оператор new.

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

• Как можно пользоваться библиотекой, разработка которой заброшена много лет назад (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++, в этой ситуации поведение не определено. Все предположения – не более чем популярные городские легенды. Разберем подробно, почему.