C++ *

Есть много вариаций на тему данного паттерна, но большинство примеров не подходит для многопоточных приложений.
В этой статье я хочу поделится опытом применения паттерна в многопоточных приложениях и опишу основные проблемы, с которыми мне приходилось сталкиваться.
Цель данной стати — обратить внимание разработчиков на проблемы, с которыми можно столкнуться при создании многопоточных приложений. Выявить подводные камни в реализации коммуникации между компонентами в многопоточном приложении.
Если Вам необходимо готовое решение, обратите внимание на библиотеку Signals2, котрая включена в boost с мая 2009-го года.
Я не пытаюсь предоставить решение, которое можно было бы использовать в готовом виде. Но тем не менее, ознакомившись с материалом, можно обойтись без использования сторонних библиотек, в тех проектах, в которых они по каким-либо причинам не доступны или нежелательны (драйвера, низкоуровневые приложения и т.п.).

Приветствую, хабровчане!

Я хочу предложить к обсуждению идеи о том, как упростить написание серверных программ на C введением дополнительных языковых средств. Полагаю, что эта тема может быть интересна всем разработчикам, которым приходилось иметь дело с написанием многопоточного или асинхронного кода.

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

Вечер добрый
В последние дни оживился блог С++ и появилась масса новых тем и споров по поводу места С++ в нашей жизни, о его будущем и прошлом. Хочу и я кое что сказать по этому поводу. Пишу я в основном на С под всякие железки типа PIC18 от Микрочипа, но и с С++ тоже знаком. И считаю, что рассматривать С++ в отрыве от возможностей С никак нельзя, хотя-бы потому, что все же он проектировался как наследник С.
В связи с этим хотелось бы задать вопрос всем тем, кто говорит о том что С++ умрет и что аналогичные задачи можно с лёгкостью решать на Python/Java/Haskel итд. Покажите как на вашем любимом языке программирования можно получить старший байт 32х разрядного(к примеру) числа за один такт процессора.
Моё решение на С/C++:
int number;
char mByte=*(((char*)&number)+3);

гарантированно компилируется в однотактную инструкцию практически на любом процессоре «а что у Вас»? Добро пожаловать в комментарии.

С++ or not C++, C++ или Java/Python/Ruby? Как часто вы задаёте или слышите подобные вопросы? Не хотелось бы поднимать очередной холивар — по моему мнению, умные люди давно должны были бы прийти к выводу, что при выборе языка нет той серебряной пули, которая бы поставила окончательную точку, — у каждого языка есть свои плюсы и минусы и чаще всего проблемы в прокладке между клавиатурой и стулом.

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

Доброго времени суток, уважаемые Xабровчане!

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

Пример:

int nType = ...;
 
if( boost::is_base_of< ISettable, /* ... magically resolve type hidden by nType here ... */ >::value )
{
    // Do something
}
else
{
    // Do something else
}

Весь этот топик направлен на то, чтобы понять, что же надо написать вместо «magically resolve type hidden by nType here».

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


Материал разбит на части, от самых общих практических правил, интересных начинающим, до конкретных вопросов, актуальных опытным программистам.
В первой части я на практике дам свой ответ на самые базовые вопросы. Как вообще писать программу, в особенности — сложную программу? Что следует сделать в самом начале, чтобы потом не переделывать с нуля? Как создать оптимальную структуру программы?

Недавно разглядывал вакансии одной известной конторы, задумывался над вопросам (которые, кстати, на всех их вакансиях одинаковые). И решил написать заметку по самому интересному (на мой взгляд) аспекту первого же вопроса. Может быть доберусь и до других, а пока предлагаю задуматься, надо ли делать деструкторы виртуальными?

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

Каким же должен быть полный ответ на вопрос про деструкторы?

Статья освещает реализацию бинарного web-протокола Hessian на стеке библиотек Qt. Целевая платформа С++.

Данная статья – результат моего первого опыта статического анализа достаточно большой программы (1665 файлов с исходными текстами на данный момент). Кроме того, это мой первый опыт использования среды Microsoft Visual Studio. Разработка анализируемой программы велась исключительно в Ubuntu, Eclipse CDT, компилятор GCC.

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

В новом стандарте C++0x появились зымыкания. Не вдаваясь в подробности, замыкания — это такие объекты, которые позволяют создавать функции прямо в теле других функций. Если подробнее — замыкания позволяют создавать функциональные объекты — то есть объекты, для которых определён operator(). На хабре уже писали о них: например тут.

Мне очень понравилось нововведение и я начал им пользоваться. Но только вот незадача: по смыслу, замыкания и функции — почти одно и то же, а использовать замыкания там, где должны использоваться указатели на функции, сходу не получается. По стандарту, замыкания без списка захвата должны свободно конвертироваться в указатели на функции, но на практике такого не наблюдалось, видимо ещё не реализовано. И я задался вопросом, можно ли использовать замыкания там, где используются указатели на функции?

Всем рано или поздно приходится работать с различными кодировками. Заметив в коде своей команды различные, порой странные, подходы к решению этих проблем, пришлось провести разъяснительную беседу. Ниже поделюсь своим видением правильной работы с не-ASCII символами в коде. Буду рад конструктивной критике.

Рассказывая про 64-битные ошибки, поджидающие программистов при миграции их программ, я часто слышу упреки: «Ну да, этот ваш Windows, он такой… Хорошо, что в Linux с 64-битным кодом проблем да-а-а-авно уже нет».

«А вот и нет, мой любознательный читатель».

Сегодняшний пост про 64-битную ошибку в ядре Linux.

Автор языка C++, один из идеологов объектно-ориентированной парадигмы программирования, да достаточно просто сказать Бьярн Страуструп — впервые (?) приедет в Москву, на конференцию «Разработка ПО 2010», где примет участие в качестве одного из ключевых докладчиков. Конференция пройдёт c 11 по 15 октября 2010 года.
Для многих программистов его книги The C++ Programming Language, The Design and Evolution of C++, The Annotated C++ Reference Manual были и остаются настольными, и бережно сохраняются в личных библиотеках.
Я не смог пройти мимо этой новости, надеюсь многим будет интересно принять участие в конференции.

Еще давно очень многих интересовал один вопрос: «Эта программа занимает всего 100 кб, что за музыку она воспроизводит? Как это работает?»

Так вот, называется это чудо – Трекерная музыка. И что самое главное – она занимает очень мало места, в отличие от .mp3 или .wav. В современных популярных ОС трекерные файлы (MOD, XM, S3M, IT и пр.) проигрываются большинством медиаплееров, например, Winamp, VLC, Amarok, Audacious и другими.

Скачать такую музыку можно, например отсюда — keygenmusic.net, или отсюда www.modarchive.org. Это отнюдь не единственные ресурсы, стоит только обратиться к поиску.

Для того, чтобы воспроизвести такую музыку в своей программе, нам потребуется минимальное знание C++, а также minifmod, доступный в исходниках. Как заявляют разработчики, minifmod добавит всего 50 кб к вашему exe-файлу (без учета сжатия).

Рано или поздно все сталкиваются с проблемами связанными с языковым и культурным разнообразием при написании программ. Я был сильно удивлен узнав, что часть моих знакомых, пишущих на C++, решают эти проблемы своими велосипедами. Для тех, кто еще не знает что такое std::locale я хотел бы кратко на примере показать как c ним работать и что бывает, если о нем забыть…

Введение

До начала работы с библиотекой Qt я программировал различные задачки на С++ в университете, а на работе использовал Delphi. И конечно же, в процессе работы создавались различные библиотеки. Создавались, можно сказать, с трудом. Не хватало в повседневной жизни тех плюсов, которые давало ООП. Всегда хотелось экспортировать из библиотек целые классы, причем делать это просто, быстро и беззаботно. При этом вопросы о создании библиотек на С++ и дальнейшем их использовании в проектах на Delphi или C возникали очень редко.

В данной статье я расскажу об одном из способов, позволяющих с наименьшими усилиями трансформировать программный код на C/C++ в код, написанный на C#. Впрочем, рассказанные принципы подойдут и для других пар языков. Хочу сразу оговориться, что способ не рассчитан на трансформацию кода, реализующего GUI.

Для чего это делать? К примеру, я таким образом портировал известную графическую библиотеку LibTiff (и LibJpeg заодно) на C#. Это позволило использовать наработки многих людей, создававших LibTiff, в моей программе вместе с библиотекой классов .NET Framework. Примеры кода в статье будут в основном из LibTiff и LibJpeg.

Те, кто читал книгу Андрея Александреску «Современное программирование на C++» знают, что существует обширный класс задач (в области метапрограммирования с использованием шаблонов), когда шаблону при инстанцировании необходимо указать переменное (заранее неизвестное) количество аргументов. Типичные примеры таких задач:
— Описание кортежей (tuples)
— Описание типов наподобие вариантов (variants)
— Описание функторов (в этом случае перечень типов аргументов зависит от сигнатуры функции)
— Классификация типов по заранее заданным множествам
— и т. п.

В каждой такой задаче точное количество типов, передаваемых соответствующему шаблону в качестве аргументов, заранее определить сложно. И, вообще говоря, зависит от желания и потребностей того, кто намеревается использовать соответствующий шаблонный класс.
В рамках действующего стандарта С++ сколь-нибудь удобного решения таких задач не существует. Шаблоны могут принимать строго определённое количество параметров и никак иначе. А. Александреску (в упомянутой выше книге) предлагает общее решение, основанное на т. н. «списках типов», в котором типы представлены в виде односвязного списка, реализованного посредством рекурсивных шаблонов. Альтернативным решением (используемом, например, в boost::variant и boost::tuple) является объявление шаблонного класса с большим количеством параметров, которым (всем, кроме первого) присвоено некоторое значение по умолчанию. Оба этих решения являются половинчатыми и не охватывают весь спектр возможных задач. По этому, для устранения недостатков существующих решений и упрощения кода новый стандарт предлагает С++-разработчикам новый вариант объявления шаблонов? «шаблоны с переменным количеством параметров» или, в оригинале, «variadic templates».

В моделях данных очень часто требуется хранить некоторые переключаемые состояния. Классический способ в С++ для этого — использование перечислимых типов enum.

Например, если у вас в программе пользователь может переключаться между двумя экранами, вы заводите enum screen { screen_one, screen_two }; и переменную screen cur_screen_. Отрисовщик должен получить у модели «текущий выбранный экран», и затем отрисовать его, запрашивая у модели дополнительные данные, относящиеся именно к этому экрану. Что-то вроде:

switch (model.cur_screen())
{
case screen_one:
  model.get_screen_one_elements();
  ...
case screen_two:
  model.get_screen_two_elements();
  ...
}


При использовании такой модели, программист может запрашивать данные, которые для текущего состояния совершенно не актуальны. Например, вызвать метод get_screen_two_elements() для получения списка элементов второго экрана, когда текущий экран — первый. Хорошей практикой является использование ассертов вида ASSERT(cur_screen_ == screen_one) в методах, зависимых от конкретного экрана. Это обеспечивает некоторый контроль времени выполнения.

Но есть способ обеспечить контроль времени компиляции и более явное разделение состояний с помощью boost::variant.