C++ *

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

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

Доброго времени суток!

Какое Ваше отношение к оператору goto в языках С/С++? Скорее всего, когда Вы учились программировать, Вы его использовали. Потом Вы узнали, что это плохо, и Вы о нем позабыли. Хотя иногда при сложной обработке ошибок… нет-нет, там try … throw … catch. Или же для выхода из вложенных циклов … не-ет, там флаги и куча сложностей. Или когда вложенные switch … нет-нет-нет, там те же флаги.
И все-таки, иногда в ночной тиши Вы допускали в свое подсознание грешную мысль – «а почему бы не использовать вот тут goto? И программа вроде как стройней будет, и оптимально выходит. Да-а, было бы хорошо… Но нет – нельзя, забыли!».
А почему так оно?
Под катом – небольшое расследование и мое, основанное на многолетней практике и разных платформах, отношение к этому вопросу
UPD: тут статья рассматривает С и С++, программирование для PC и слегка для микроконтроллеров. Конкретно о микроконтроллерах есть другая статья.

С удивлением обнаружил, что про явление алиасинга (aliasing) здесь постов нет. Ситуацию нужно исправить, тк. алиасинг в любой сколько-то сложной C++ программе обязательно хоть где-нибудь, да есть. Это может быть хорошо, давая возможность ловких оптимизаций, а может быть плохо, внося повышенной паршивости баги. Под катом вкратце про оба случая (ну и неизменное «компилятор бьет спина», конечно; для разнообразия сегодня это gcc).

Получить годные цифры бенчмарка это полдела, однако вторая половина их правильно интерпретировать, узнать что-то новое, и суметь применить. 100x отличия промеж дебажным и нормальным билдом удивили, решил копнуть глубже. По итогам получше узнал, что происходит в дебаге; поискал отличия между 2005 и 2008 студией (не нашел); выяснил, как ускорить дебажный билд в 3 раза за пару минут (ставим блок против удара в спину); методом «взять и запустить» получил результаты, отличающиеся от авторских в 3.5 раза (адская сила x64 в действии!); и для смеха замерил плохой, негодный недовектор против хорошего (плохой оказался до 100 раз быстрее). Подробности под катом.

Скачал пример из предыдущего постинга, от запуска к запуску время дрожало до 1.5 раз, от 0.76 до 1.09 секунд. Как можно оценивать результаты подобных бенчмарков, неясно. Проблема знакомая, столкнулся и решал буквально вчера. Вкратце, виноват CPU throttling, а так же странный affinity в коде. Под катом борьба (успешная) и обсуждение.

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

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

В этой короткой заметке хочу рассказать о прекрасной программе для поиска утечек памяти под Visual Studio--Visual Leak Detector.
Она удивительно проста в использовании и выдает подробную информацию о найденных утечках, а на хабре пока не упоминалась.

В процессе чтения статьи «Облегчённая» реализация контейнера vector вспомнился свой опыт борьбы с вектором. Собственно этим опытом я и хотел бы поделиться.

Да, при размерности массива 10000 элементов, лишний указатель в реализации элемента доставит ощутимые неудобства, но настоящая проблема памяти при использовании vector в полной мере проявляется несколько иначе.

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

std::string filepath("C:\\тест");
std::ofstream file(filepath.c_str());

В далекие времена, для 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? Как часто вы задаёте или слышите подобные вопросы? Не хотелось бы поднимать очередной холивар — по моему мнению, умные люди давно должны были бы прийти к выводу, что при выборе языка нет той серебряной пули, которая бы поставила окончательную точку, — у каждого языка есть свои плюсы и минусы и чаще всего проблемы в прокладке между клавиатурой и стулом.