Не так давно Скотт Майерс (англ. Scott Meyers) — эксперт по языку программирования C++, автор многих известных книг — опубликовал статью, описывающую подробности использования rvalue ссылок в C++11.
На Хабре эта тема еще не поднималась, и как мне кажется, статья будет интересна сообществу.
Оригинал статьи: «Universal References in C++11—Scott Meyers»

«Универсальные» ссылки в C++11

T&& не всегда означает “Rvalue Reference”

Автор: Scott Meyers

Возможно, наиболее важным нововведением в C++11 являются rvalue ссылки. Они служат тем фундаментом, на котором строятся «семантика переноса (англ. move semantics)» и «perfect forwarding». (Вы можете ознакомится с основами данных механизмов в обзоре Thomas’а Becker’а).

Синтаксически rvalue ссылки объявляются также, как и «нормальные» ссылки (теперь называемые lvalue ссылками), за исключением того, что вы используете два амперсанда вместо одного. Таким образом, эта функция принимает параметр типа rvalue-reference-to-Widget:

void f(Widget&& param);

Учитывая, что rvalue ссылки объявляются с помощью “&&”, было бы разумно предположить, что присутствие “&&” в объявлении типа указывает на rvalue ссылку. Но это не так:

Widget&& var1 = someWidget;         // здесь “&&” означает rvalue ссылку

auto&& var2 = var1;                 // здесь “&&” НЕ означает rvalue ссылку

template<typename T>
void f(std::vector<T>&& param);     // здесь “&&” означает rvalue ссылку

template<typename T>
void f(T&& param);                  // здесь “&&” НЕ означает rvalue ссылку

  Вступление большое, так как подробно объясняет зачем нужен cmake. Можете сразу под кат, если уже знаете.

Вступление

  Компилирование проекта руками — пустая трата времени. Это фактически аксиома и об этом знают те, кто программирует. Но чтобы всё скомпилировалось автоматически необходимо задать правила, так ведь? Часто и по-старинке используют makefile для *nix или какой-нибудь nmake для windows.
  Я хоть и не первый год программирую, и руками составлял простые автосборщики проектов на основе makefile, но стоит немного подзабыть и приходится заново изучать как же составить эту хитрую схему. В основном приходится делать проекты расчитанные на какую-то одну систему, будь то linux или windows, и часто между собой не кросскомпилируемые. Для переносимости makefile используется automake и autogen, но их синтаксис ещё более запутан. Не скажу, что выбор идеальный, но для себя я решил перейти на cmake, благо он портирован под всё доступное. Мне он показался более человекопонятным. Попробую объяснить основы. Вы пишите словами правила, а из них генерируется makefile, который вы уже запускаете стандартным способом.

Ликбез

  Зачем он нужен? Чтобы при переносе на другую машину, с другими путями вы двумя командами собрали проект ничего не исправляя в файле makefile. Но есть же configure? Это альтернатива. И configure не кросплатформенный, для его генерации нужен autoconf/autogen, для которых идёт ещё свой набор правил. Только преимущества? Компиляция автосгенерированным makefile получается немного медленнее старого способа. Например, в KDE-4 является официальным инструментом выпуска.

Вступление

Все мы, время от времени, используем дебаггер для отладки программ. Отладчик может использоваться с C++, C#, Java и ещё сотней других языков. Он может быть как внешним (WinDbg), так и встроенным в среду разработки (Visual Studio). Но вы хоть раз задавались вопросом, как же работает отладчик?
И вам повезло. В этом цикле статей мы разберёмся от и до, как же работает отладка изнутри. В этой статье рассматривается только написание отладчика под Windows. Без компиляторов, линковщиков и других сложных систем. Таким образом, мы сможем отлаживать только исполняемые файлы, так как мы напишем внешний отладчик. Эта статья потребует от читателя понимание основ многопоточности.

Существует множество задач, для которых требуется пересборка ядра и операционной системы Android в целом. Например, создание и отладка собственных модулей, включение поддержки профилирования системы и просто тестирование своих приложений на новой версии Android.
Возможность запуска Android x86 внутри виртуальной машины VirtualBox позволяет энтузиастам и создателям прошивок покопаться в настройках системы, настроить и пересобрать ядро и при этом не «кирпичизировать» настоящее устройство. VirtualBox предоставляет возможность использования привычных для Linux-разработчика средств отладки ОС. Для рядовых разработчиков Android-приложений отлично подходит эмулятор, использующий технологию Intel Hardware Accelerated Execution Manager. (подробнее можно прочесть здесь)
В статье приведен ряд практических советов по сборке образа Android x86 для запуска под виртуальной машиной VirtualBox и сборке эмулятора. Исходный код Android взят из официального репозитория проекта AOSP (Android Open Source Project), в качестве ядра использована адаптированная версия ядра Linux 2.6 от Intel.

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

В какой-то момент мне захотелось «научить компьютер» решать японские кроссворды так, как решаю их я сам. Никакой высокой цели, just for fun. Потом уже были добавлены способы, которые сам я применять не могу в силу ограниченных возможностей человеческого мозга, но, справедливости ради, со всеми кроссвордами из журналов программа справляется и без них.

Итак, задача простая: решить кроссворд, а если решений много, то найти их все. Решение написано на Haskell'е, и, хотя код достаточно существенно дополняет словесное описание, даже без знания языка общую суть понять можно. Если хочется пощупать результат вживую, на странице пректа можно скачать исходники (бинарных сборок не выкладывал). Решения экспортируются в Binary PBM, из него же можно извлекать условия.



Несмотря на то, что я пытался писать максимально понятно, это не в полной мере мне удалось. Под катом очень много букв и кода и почти нет картинок.

С незапамятных времен в Visual Studio существовала возможность написания визуализаторов для своих C++ типов, что позволяет изменить способ отображения типов в окнах отображающих содержимое переменных в отладчике (такие как auto, watch, locals и всплывающие подсказки для переменных). В Visual Studio 2012 появилась возможность в расширениях к Visual Studio распространять визуализаторы в новом формате natvis.

Были конвертированы старые визуализаторы для Boost'а и мои старые для TinyXML, а также добавил новые визуализаторы для Boost, wxWidgets и TinyXML2. Получилось в итоге расширение к Visual Studio 2012 — C++ Debugger Visualizers

По результатам исследованиям работы программистов около 20% времени тратиться на непосредственное написание кода и около 80% времени — на просмотр старого, его анализ. Исходя из данной предпосылки текстовый редактор в первую очередь должен предоставить удобные средства навигации по коду. Большая часть описанных фич как раз имеет дело с навигацией и анализом.

В данной статье я постараюсь продемонстрировать максимум удобных в ежедневном применении возможностей редактора Emacs для языка Python, и более конкретно для редактирования Django проектов.

Как говорится в пословице: «обещанного три года ждут». Хотя три года и не прошло, но уже изрядно много с моей предыдущей статьи «Emacs для начинающих: введение». Я не буду «растекаться мысью по древу» а постараюсь максимально кратко показать как работают различные фичи Emacs в применении к Python.

(оригинал — Jasper St. Pierre, разработчик GNOME Shell, взято отсюда)

Это обзорная статья о составных частях графического стека Linux и том, как они уживаются вместе. Изначально я написал её для себя после разговоров об этом стеке с Оуэном Тейлором, Рэем Строудом и Эдэмом Джексоном (Owen Taylor — мэйнтейнер Gnome Shell; Ray Strode — мэйнтейнер большого количества десктопных пакетов сообщества RedHat; Adam Jackson — разработчик графического стека Gnome Shell и интеграции с XOrg; прим. переводчика). 

Я постоянно дёргал их, снова и снова расспрашивал о всяких мелочах, а потом эти мелочи благополучно забывал. В конце концов, я задал им вопрос — а нет ли какого-нибудь обзорного документа, уткнувшись в который я бы избавил ребят от своего назойливого внимания? Не получив утвердительного ответа я решил написать эту статью, которая по завершению была вычитана Эдэмом Джексоном и Дэвидом Эйрли. Они оба работают над этим стеком.

abstract: В статье описаны продвинутые функций OpenSSH, которые позволяют сильно упростить жизнь системным администраторам и программистам, которые не боятся шелла. В отличие от большинства руководств, которые кроме ключей и -L/D/R опций ничего не описывают, я попытался собрать все интересные фичи и удобства, которые с собой несёт ssh.

Предупреждение: пост очень объёмный, но для удобства использования я решил не резать его на части.

Оглавление:

• управление ключами
• копирование файлов через ssh
• Проброс потоков ввода/вывода
• Монтирование удалённой FS через ssh
• Удалённое исполнение кода
• Алиасы и опции для подключений в .ssh/config
• Опции по-умолчанию
• Проброс X-сервера
• ssh в качестве socks-proxy
• Проброс портов — прямой и обратный
• Реверс-сокс-прокси
• туннелирование L2/L3 трафика
• Проброс агента авторизации
• Туннелирование ssh через ssh сквозь недоверенный сервер (с большой вероятностью вы этого не знаете)

Недавно мой студент и я пытались понять одну тонкость в стандарте C. Самый простой способ прояснить подобные вопросы — это узнать, учли ли её разработчики компиляторов, то есть написать код и посмотреть, что с ним будут делать разные компиляторы.

Я написал такую функцию:

int foo (char x) {
  char y = x;
  return ++x > y;
}

Так как ++x увеличивает на 1 значение x, очевидно, что функция должна возвращать "1" для большинства значений x. Вопрос состоит в том, что она вернет для значения CHAR_MAX?

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

Итак, вуаля!


За источник информации была взята статья из вики. В блок-схеме «UTF-16 → CP 866» означает, что исходная кодировка была «UTF-16», а распозналась она как «CP 866».

Как всегда — кликабельно. Исходник в .docx: здесь.

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

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



Zsh красив, приятен, чертовски функционален, но, признаюсь честно, я не смог совладать со всеми его многочисленными настройками. Я хочу работать, а не бороться со своим рабочим окружением. Простой пример: пару раз из-за автодополнения zsh я удалял все директории и файлы в текущей директории — zsh просто ставил пробел между автодополненной директорией и введённой мною звёзочкой (я хотел удалить всё в выбранной папке). Помните тот эпичный баг с пробелом и удалении директории /usr? У меня было то же самое. Спасибо гиту, выручил в который раз.

Впрочем, дело не в zsh — будь я чуточку умнее, я бы с ним обязательно справился бы, и всё было бы хорошо, но мы, суровые программисты, будем использовать bash и vim, а гламурные zsh и textmate оставим хипстерам и прочим модникам ;)

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

Всем привет. Недавно меня тоже настигла переломная веха студенческой жизни — бакалаврская дипломная работа. Среди многих формальных деталей этого замечательного явления особо заметным стоит нормоконтроль. Нет, я понимаю и всячески поддерживаю, что стандарты необходимы, в том числе стандарты на оформление академического текста. Просто наши стандарты, в отличие от западных, достаточно идиотичны. Они не экономят ни чернила, ни бумагу, они не упрощают поиск литературы по номенклатуре, а усложняют чтение названия. Не говоря уже о том, что текст стандарта спроектирован и описан людьми, работающими в редакторе Microsoft Word. Опять-таки, я не имею ничего против Word, это мощнейшая система. Но технический текст в нем набирать неудобно, и по гибкости он во много раз проигрывает бессмертному творению Дональда Кнута — LaTeX.

Итак, мое написание диплома началось с того, что я потратил 4 часа на настройку преамбулы под нормы украинского стандарта оформления ДСТУ 3008-95. Насколько мне известно, он почти полностью соответствует русскому ГОСТу. Я знал, что существуют готовые решения (например, disser), но после пары проб предпочел настроить каждую деталь самостоятельно. Для тренировки. Тренировка удалась — я узнал бездну новых вещей о LaTeX, этого монстра невозможно выучить полностью :-)

Под катом я полностью опишу процесс настройки каждой конкретной детали и использование их при написании, а также разные мелочи, упрощающие написание диплома еще больше. Сразу предупреждаю: где-то мои решения могут показаться костылями. Где-то они не слишком универсальны. Я это знаю, понимаю, принимаю и приветствую критику и предложения в комментариях ;-)

Привет, хабралюди!

Тема консольного скринкастинга уже поднималась на хабре, но я хочу рассказать вам о чем-то лучшем. jeck_landin рекомендует утилиту script и scriptreplay для записи и воспроизведения скринкастов. А я буду рекомендовать вам свой велосипед и объясню чем он лучше :)

Последнее время все чаще можно встретить сайты с необычным дизайном и функциональностью, увидев которые, можно залипнуть на некоторое время. Увидев такие, у меня рука непроизвольно тянется к f12, чтобы открыть firebug и посмотреть, как же реализован тот или иной компонент. Таким образом можно открыть для себя интересные техники и в будущем реализовать их на своих проектах. Некоторые из них стали доступны с приходом новых технологий, например таких, как CSS 3 — то, что раньше было реализовано на флеше, теперь можно воплотить с помощью строк кода в таблице стилей. Дизайнеры тоже не теряют времени, создавая новые тренды и все плотнее взаимодействуя с верстальщиками. В этой статье я хотел бы показать 15 сайтов, которые так или иначе удивили и порадовали меня. Возможно, кого-то они вдохновят на собственный шедевр

Emacs'ом я пользуюсь уже довольно давно и в общем-то для всего подряд. Хотя число elisp-пакетов распространяемых вместе с этим текстовым комбайном растет постоянно, иногда все же приходится устанавливать сторонние пакеты. Со временем их количество тоже постепенно растет, для них приходится отслеживать зависимости, их также необходимо (или желательно) обновлять, в общем, стандартный набор задач для менеджера пакетов. До недавнего времени для установки elisp-пакетов я пользовался системными пакет-менеджерами под linux типа apt, portage. Определенные неудобства конечно были, но настоящие проблемы начались когда Emacs пришлось использовать под Windows и Mac OS. Кроме собственно управления пакетами, появилась необходимость синхронизировать все установленные файлы, а не только настройки в ~/.emacs.

В итоге я созрел для использования полноценного менеджера elisp-пакетов, желательно обладающего следующими качествами:

• большая база пакетов
• удобство создания и поддержания собственных пакетов
• легкость синхронизации установленных пакетов между компьютерами
• кросс-платформенность без установки дополнительных приложений

После небольшого исследования существующих возможностей получился этот обзор, в котором я подробно на остановлюсь на elpa и el-get, а также кратко расскажу о других.

Ist das Emacs? Sehr gut!

Начну с небольшой истории. Лет так 15 назад ездил я на подработку сисадмином программистом в славный городе Mannheim, West Germany. Когда я приехал на работу и развернул своё рабочее окружение, большинство дойчей вообще не сильно поняли в чём я работаю, а вот директор конторы сразу мне сказал: «Ist das Emacs? Sehr gut!», добавив также что никто кто из текущих программистов не смог его освоить. А по честному, не такой уж я особенный — мне просто повезло: готовый конфиг мне дал один добрый человек, и помог мне разобраться с редактором на первых шагах. Я, в свою очередь хочу поделиться своим опытом с остальными, и решил сделать серию статей для начинающих и не очень, с рассмотрением разных полезных фич emacs.

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

Так повелось, что фильтр U32 в подсистеме управления трафиком ядра Linux считается простым и понятным, а потому в подробном документировании не нуждается. Например, в LARTC (Linux Advanced Routing and Traffic Control) про него лишь несколько абзацев. Но на самом деле U32 устроен гораздо сложнее и интереснее, но и в использовании он не так прост, как может показаться. Под катом статья по этому фильтру с примерами использования и подробными пояснениями.

Это первая статья из серии «Сети для самых маленьких». Мы с товарищем thegluck долго думали с чего начать: маршрутизация, VLAN'ы, настройка оборудования.
В итоге решили начать с вещи фундаментальной и, можно сказать, самой важной: планирование. Поскольку цикл рассчитан на совсем новичков, то и пройдём весь путь от начала до конца.

Предполагается, что вы, как минимум читали о эталонной модели OSI (то же на англ.), о стеке протоколов TCP/IP (англ.), знаете о типах существующих VLAN’ов (эту статью я настоятельно рекомендую к прочтению), о наиболее популярном сейчас port-based VLAN и о IP адресах (более подробно). Мы понимаем, что для новичков «OSI» и «TCP/IP» — это страшные слова. Но не переживайте, не для того, чтобы запугать вас, мы их используем. Это то, с чем вам придётся встречаться каждый день, поэтому в течение этого цикла мы постараемся раскрыть их смысл и отношение к реальности.



Начнём с постановки задачи. Есть некая фирма, занимающаяся, допустим, производством лифтов, идущих только вверх, и потому называется ООО «Лифт ми ап». Расположены они в старом здании на Арбате, и сгнившие провода, воткнутые в пожжёные и прожжёные коммутаторы времён 10Base-T не ожидают подключения новых серверов по гигабитным карточкам. Итак у них катастрофическая потребность в сетевой инфраструктуре и денег куры не клюют, что даёт вам возможность безграничного выбора. Это чудесный сон любого инженера. А вы вчера выдержали собеседование и в сложной борьбе по праву получили должность сетевого администратора. И теперь вы в ней первый и единственный в своём роде. Поздравляем! Что дальше?