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

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

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

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


Введение

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

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

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

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

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

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

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

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

Наверное, все любители языка C++, которые использовали другие языки, такие как C#, удивляются: почему же в плюсах нет property? Ведь это действительно удобное средство, позволяющее полностью контролировать доступ к членам класса. Недавно и я заинтересовался данным вопросом. Подумав, полистав Страуструпа и наконец, погуглив, я пришёл к выводу, что property можно реализовать средствами языка. Думаю многие уже видели разнообразные реализации, например, от microsoft, но для кого-то, надеюсь, это будет интересным открытием.
В статье вы найдёте один из возможных вариантов реализации свойств при помощи шаблонов.

Все уже в курсе выхода нового стандарта С++11, на Хабре уже было несколько статей о его фичах. А я вот решила написать о том, что из С++ в новой версии было исключено и по каким причинам. Оно, может быть, кажется и не таким важным, как новые возможности, но, как говорится: «Тот, кто не знает истории, обречён на повторение ошибок».

“C++11 feels like a new language.” – Bjarne Stroustrup

Не так давно Герб Саттер открыл на своём сайте новую страничку — Elements of Modern C++ Style, где он описывает преимущества нового стандарта и то, как они повлияют на код.

Привет, Хабрасообщество.

Об актуальности DDoS атак в наше время рассказывать не стану. Достаточно взглянуть на статистику. Сталкиваюсь с атаками по роду деятельности довольно часто, возникла идея динамической защиты от DDoS типа SYN-flood на северах Linux и FreeBSD. Также предложена реализация мониторинга SYN-flood по SNMP.

Об этом всём под катом.

В App Store появился редактор Codify — первая среда разработки под iPad, с нативным интерфейсом и поддержкой тачскрина. Очень удобно: нажимаете пальцем на характеристики объекта — и видите всплывающее окно со списком вариантов. Но самое главное, что в любой момент написанный код можно запустить, чтобы на ходу проверить работу акселерометра и мультитача. Никаких больше мучений с эмуляторами!



Codify построен на языке Lua, это простой и элегантный язык программирования, который хорошо подходит для создания игр под iPad.

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

В известном письме 1947 года к математику Норберту Винеру он писал: «Вполне естественно задаться вопросом, можно ли проблему перевода рассматривать как проблему криптографии. Когда я вижу текст на русском языке, я говорю: «На самом деле это написано на английском, но закодировано какими-то странными символами. Сейчас попробую расшифровать»».

Эта догадка привела в итоге к разработке целого поколения программ статистического машинного перевода, таких как Google Translate — и, неслучайно, к появлению новых инструментов для анализа исторических шифров».

Сейчас группа шведских и американских лингвистов применила техники статистического машинного перевода для взлома одного из самых трудных шифров: Copiale Cipher, рукописного 105-страничного манускрипта конца XVIII века. Учёные опубликовали свою работу в преддверии конференции Ассоциации компьютерной лингвистики в Портленде.

Доброе время суток.

Хочу поделиться своим опытом написания скрипта на PHP для поиска по файлам форматов PDF, DOC и DOCX, используя Sphinx. Все ниже изложенное написано для людей, которые уже имели опыт работы с связкой Sphinx и PHP. Если нет, то в свое время мне очень помогла статья Мартина Стрейчера «Создание собственной поисковой системы с помощью PHP», опубликованная на сайте IBM.

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

Задача вроде тривиальная, но погуглив немного, я не смог найти внятную инструкцию с конкретным примером поиска по файлам форматов PDF, DOC и DOCX, что и стало причиной написания этой статьи.

К написанию сей заметки меня сподвигло то, что я устал делать развёрнутые замечания на эту тему в комментариях к статьям, где в качестве части инструкции по сборке и настройке чего-либо для конкретного дистра предлагают выполнить make install.

Суть сводится к тому, что эту команду в виде «make install» или «sudo make install» использовать в современных дистрибутивах нельзя.

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

Добрый день, коллеги!

Хотел поделиться своими наработками в области автоматизации процесса сборки javascript проекта использующего Google Closure Compiler и Google Closure Library при помощи Apache Maven. Страничка проекта https://github.com/urmuzov/closure-maven, там же лежит документация по каждому из компонентов проекта.

О проекте

Главный компонент проекта — это архетип. Архетип объединяет в себя все остальные компоненты проекта, которые при желании могут использоваться отдельно от него.

Архетип предоставляет средства для решения самых часто встречающихся задач при разработке, а именно:

• Запаковывает javascript код в maven артефакты для распространения (такие артефакты содержат помеченные пакеты специальной структуры, названные closure-packages);
• Распаковывает closure-packages из подключенных в <dependencies> артефактов для компиляции;
• Помогает в объединении и оптимизации js и css файлов при помощи Web Resource Optimizer for Java (wro4j);
• Предоставляет 5 профилей компиляции для разных целей:
  
  • compiled — для «боевой» сборки проекта. Уровень компиляции ADVANCED_OPTIMIZATIONS;
  • merged — для склеивания всех исходных js файлов в один, фактически без компиляции. Уровень компиляции WHITESPACE_ONLY, форматирование PRETTY_PRINT;
  • sources — для дебага javascript файлов в бразуере. Компиляция происходит как и в профиле compiled, но в html будут подключены файлы с исходными кодами;
  • sources-no-compile — для дебага html/css файлов. Компиляции не происходит, просто в html подключаются файлы с исходными кодами;
  • jar — для сборки jar-архива для распространения;
  
  
• Генерирует jsdoc и jslint отчеты при выполнении mvn site.