std::random_shuffle

Вы когда-нибудь замечали, что в стандартном калькуляторе windows такой большой циферблат (инженерный вид), а ввести можно так мало? В тоже время нетрудно заметить, что разрядность чисел, с которыми он может работать, превышает 64 бита, а это означает, что длинную арифметику калькулятор реализует. Так почему бы ей не воспользоваться в полной мере? Калькулятор поддерживает от 0 до 64 разрядов (десятичных, в том числе), по умолчанию которых 32. Изменить можно командой: calc -p:#. Например, calc -p:64 позволит уже отобразить 49! полностью.

• Самый младший бит 0. Тогда ясно, что последний элемент в текущей выборке можно увеличить на 1, то есть самый младший установленный бит нужно сместить на одну позицию вправо. Сделать это можно так: n = n ^ (n & -n) | (n & -n) >> 1. Из жж товарища sharpc можно узнать, что кодом n & -n получается число с самым младшим установленным битом. Xor с исходным его снимает, а следующий Or устанавливает его на одну позицию правее.
• Младший бит 1. В этом случае возможна ситуация, что справа какое-то число r единичных битов (если r == k, то это последнее возможное сочетание). Слева до r имеется число, которое полностью соответсвует первому случаю, то есть имеет вид 11..1100... С ним делается тоже самое, а вот r млаших битов нужно сместить на максимально возможное количество положений влево, пока они не перекрывают хоть один бит в нашем числе. Вот эта часть для меня стала самой трудной и для которой я так и не придумал закрытой формулы :) Решение у меня вышло такое. Сначала получаем число, состоящее только из самых младших r единичных битов, формула имеет вид p = ((n + 1) & -(n + 1)) - 1 и основана на уже упоминавшемся фокусе. Далее ясно, что если его вычесть из исходного числа, то задача сводится к первому пункту. И наконец нам нужно число p сдвинуть влево настолько, насколько это возможно без пересечения, а потом сложить с ответом.

Принимаются предложения по оптимизации :)

Есть такая программа. Это суть есть редактор с древовидной структурой. В далеком 2007 году, летом, мы с sharpc пришли к выводу, что пора бы перестать складировать на винчестере кучу текстовых файлов с заметками и написать собственную, удобную и красивую утилитку для решения этой проблемы. И хотя мы люди деловые :), кое-что готово уже сейчас. wqNotes хостится на коде гугла, репозиторий там же. C#. Если кто заинтересуется, доступна бета версия 0.9.3. Комментарии, пожеланиия, угрозы и т.п. приветствуются.

Если вы считаете себя профессиональным программистом, пишете сложнейшие высокопроизводительные программные системы, которые распространяются на DVD, то в этом вам может помочь следующий код (секрет профессионалов!):

P.S. Компилировать в Release, VC++ 2005/2008.

Многие наверно знакомы с курьезом, связанным с трактованием широкораспространенных приставок системы СИ, примененных к единицам информации. Сколько байт в мегабайте? А сколько килобайт? Не смотря на несоответствие десятичных и двоичных величин (10³ и 2¹⁰, 10⁶ и 2²⁰, etc), все твердо помнят, что в килограмме 1024 грамма, а в килобайте 1000 байт. Между тем, производители жестких дисков (а также CD/DVD болванок и дискет) неплохо на этом выигрывают.

Недавно в программе, реализуемой на C#, понадобился тип данных множество. Беглый поиск при помощи IntelliSense в пространстве имен System.Collections.Generic не дал положительных результатов. Священный источник знаний жрецов до-диеза оказался малоинформативным в данном вопросе. Впрочем, вскоре я обнаружил, что в .NET 2.0 такой простой и полезной структуры данных нет, а появится лишь в .NET 3.5. Казалось бы, мелочь, но странно то, что структуры данных носят намного более фундаментальный характер и имеют большую значимость (и необходимость), чем какая-нибудь сериализация или механизм reflection. Так или иначе, быдлокодеры разработчики дотнета не реализовали ни множество, ни удобный STL'ный класс pair, ни многого другого (разнообразных деревьев), касаемого структур данных.

Не забывайте, как с помощью веревки достаточной длины стрелять себе в ногу :)

Создал-таки аккаунт. Надо сказать, раза три собирался это сделать, первый раз еще очень давно. Последний раз (кроме этого) не создал, потому что аккаунт с моим ником уже занят, хотя его автор не написал ни одного поста. Ну ладно, посмотрим, что из этого выйдет...