C++ *

В далекие времена, для IT-индустрии это 70-е годы прошлого века, ученые-математики (так раньше назывались программисты) сражались как Дон-Кихоты в неравном бою с компьютерами, которые тогда были размером с маленькие ветряные мельницы. Задачи ставились серьезные: поиск вражеских подлодок в океане по снимкам с орбиты, расчет баллистики ракет дальнего действия, и прочее. Для их решения компьютер должен оперировать действительными числами, которых, как известно, континуум, тогда как память конечна. Поэтому приходится отображать этот континуум на конечное множество нулей и единиц. В поисках компромисса между скоростью, размером и точностью представления ученые предложили числа с плавающей запятой (или плавающей точкой, если по-буржуйски).

Арифметика с плавающей запятой почему-то считается экзотической областью компьютерных наук, учитывая, что соответствующие типы данных присутствуют в каждом языке программирования. Я сам, если честно, никогда не придавал особого значения компьютерной арифметике, пока решая одну и ту же задачу на CPU и GPU получил разный результат. Оказалось, что в потайных углах этой области скрываются очень любопытные и странные явления: некоммутативность и неассоциативность арифметических операций, ноль со знаком, разность неравных чисел дает ноль, и прочее. Корни этого айсберга уходят глубоко в математику, а я под катом постараюсь обрисовать лишь то, что лежит на поверхности.

   Шаблон vector библиотеки STL выигрывает почти по всем параметрам у обычного С++ массива. Он позволяет добавлять и удалять элементы, освобождает выделенную память при уничтожении, позволяет контролировать выход за пределы массива и т.д. Тем не менее, у него есть один недостаток – для его работы требуется дополнительная память, небольшая, но в ряде случаев существенная. Ниже рассмотрена реализация контейнера, позволяющая немного снизить затраты памяти и повысить производительность.

Доброго времени суток, уважаемое Хабрасообщество.

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

Пример:

/* Определяем метафункцию HasF, которая позволяет определить наличие функции f() у любого класса. */
DECLARE_IS_VALID_EXPRESSION(
    HasF,
    ( ( U * ) NULL )->f() /* Это выражение компилируемо только если присутствует U::f() */ );
 
struct Foo{ void f(); };    
struct Bar{};
 
BOOST_STATIC_ASSERT( HasF< A >::value );  /* Тут константа HasF< A >::value будет true */
BOOST_STATIC_ASSERT( !HasF< B >::value ); /* Тут константа HasF< A >::value будет false */

Как Вы уже, наверное, догадались мы будем думать как написать макрос DECLARE_IS_VALID_EXPRESSION.

Мой прошлый пост вызвал огромный резонанс. Комментариев было не много, но я получил множество писем, а некоторые читатели выступили даже с открытыми заявлениями (там, правда, преобладают наезды на меня лично и на хабр в целом, но есть и мысли по существу вопроса). Поэтому я решил продолжить писать в жанре «мои мысли по поводу вопросов известной компании». Этим постом я постараюсь решить две задачи: (i) ответить на вопросы и возражения читателей предыдущего поста и (ii) толкнуть в некотором смысле философскую мысль о безIFовом программировании. Букв получилось довольно много, но те, кому интересно только что-то одно из поста, могут пропустить половину.

И ещё: этот топик (как и прошлый) — не наезд ни на кого. Просто интересно порассуждать об интересных вопросах. Здесь нет подтекста, намёка, вызова. Параноиков и сторонников теорий заговоров попрошу расслабиться.

В этот раз хотел бы взглянуть на вопрос 4.

Истории нескольких проблем, связанных с утечками памяти. Большинство таких проблем являются достаточно тривиальными, легко воспроизводятся, легко обнаруживаются соответствуюшим инструментарием, и исправляются. Но, временами, проблемы оказываются необычными, и требуют необычного подхода или решения…

Доброго времени суток!
Было дело — делал я интерфейс для работы с модулями для USB от FTDI. Пришлось изрядно повозиться с подключением DLL-интерфейса. Разочаровавшись в возможностях автоматической линковки Microsoft Visual Studio 2008 (UPD: потом я разобрался с этой темой), я решил это делать вручную. По ходу дела задолбался очень надоело вручную подключать несколько десятков функций. И тогда я обратился к Google, C++ и шаблонам. И если подключение DLL в стиле C++ вопросов не вызвало, то удобный вызов подключенных функций в стиле «Error = FT_Open (Num, &_Handler)», где FT_Open- объект, удался не сразу. Итог (для таких вот функций) — под катом. Если вкратце — я сделал обертку вокруг указателя на функцию.

Есть много вариаций на тему данного паттерна, но большинство примеров не подходит для многопоточных приложений.
В этой статье я хочу поделится опытом применения паттерна в многопоточных приложениях и опишу основные проблемы, с которыми мне приходилось сталкиваться.
Цель данной стати — обратить внимание разработчиков на проблемы, с которыми можно столкнуться при создании многопоточных приложений. Выявить подводные камни в реализации коммуникации между компонентами в многопоточном приложении.
Если Вам необходимо готовое решение, обратите внимание на библиотеку 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 были и остаются настольными, и бережно сохраняются в личных библиотеках.
Я не смог пройти мимо этой новости, надеюсь многим будет интересно принять участие в конференции.