Mercury13

Поскольку MAC-адрес — это 6-байтовое число, проще всего преобразовать его в 8-байтовый INTEGER. Например, 12:34:56:78:9A:BC превращается в 0x1234'5678'9ABC. Это эффективно и вопрос лишь в ручном редактировании БД.

1. Откомпилировать с отладкой.
2. Либо наставить контрольных точек; Debug → Start/Continue;
либо поставить курсор куда надо; Debug → Run to cursor

И ещё одна штука. Две-семь точек надо располагать по-другому (одна в центре, остальные по кругу на расстоянии dSafe от неё; ну или на худой конец подобрать коэффициент a, чтобы спираль расходилась лишь чуть-чуть). Для восьми-одиннадцати точек надо подбирать индивидуальные a. И только для двенадцати и более подходит a = −0,3·dSafe.

Думаю, проще всего делать не спираль Архимеда, а её приближение методом Эйлера. Пусть у нас есть некое расстояние dSafe, на котором должны быть кружочки друг от друга.

Чтобы поставить второй кружочек, отойдём от центрального на вектор (dSafe, 0). Для третьего и дальше поступим так.

Найдём угол касательной к спирали Архимеда. Касательный вектор будет a единиц по радиус-вектору (a — коэффициент спирали r=aф) и r единиц по нормали. Таким образом, если мы в точке (x, y), у нас получается касательный вектор вот такой.
t = (a·x + r·y; a·y − r·x), r = sqrt(x² + y²)

Нормируем этот вектор до длины dSafe и добавляем к (x, y).
Штука номер один. Параметр спирали прямо пропорционален безопасному расстоянию (вы это увидите ниже в коде). И штука номер два — только «бесконечно малые» шаги (при нулевом a, т. е. окружность) будут держать нас на окружности, шаги побольше будут выносить нас наружу, для компенсации сделаем a отрицательным.

Вот действующий код (на C++ Builder’е)

namespace {

const double dSafe = 30;
const int rSafe = dSafe / 2;
const double a = -0.3 * dSafe;

int toPixel(double x)
{
    return floor(x + 0.5) + 200;
}

}

void TfmMain::drawPoint(double x, double y)
{
    int xx = toPixel(x);
    int yy = toPixel(y);
    Canvas->Ellipse(xx - rSafe, yy - rSafe, xx + rSafe, yy + rSafe);
}

void __fastcall TfmMain::FormPaint(TObject *Sender)
{
    Canvas->Brush->Style = bsClear;
    Canvas->Pen->Color = clBlack;

    double x = 0, y = 0;
    drawPoint(x, y);
    x += dSafe;
    drawPoint(x, y);

    for (int i = 0; i < 120; ++i) {
        double r = sqrt(x*x + y*y);
        double tx = a*x + r*y;
        double ty = a*y - r*x;
        double tLen = sqrt(tx*tx + ty*ty);
        double k = dSafe / tLen;
        x += tx * k;
        y += ty * k;
        drawPoint(x, y);
    }
}

Всё, что я знаю: GCC — самый «въедливый» компилятор. После Intel и Embarcadero (про M$ не знаю) на «зашаблоненном» коде GCC найдёт ещё два десятка ошибок.

Это к Sony или StarForce. И те, и другие делали заSHITу и прокалывались на подобном.

Разрешите вставить и свои 5e−2 Р…

Известно ли что-то о том, какой тип будет иметь наш auto? Если известно, то может, сработает просто

dynamic_cast<Type>(object).field1.field2 = NULL;

Если подвижных мостов мало, можно каждую вершину размножить в 2^b экземплярах (b — кол-во мостов). Тогда пойдёт даже не Дейкстра, а обычный поиск в ширину.

Если два моста «сцеплены» друг с другом и наводятся/разводятся одновременно, то в b они идут одной штукой.

А если мостов много и 2^b — непозволительная трата, тогда интересно. Думаю, ничего, кроме эвристик, не поможет. Например, может случиться так, что кратчайший путь от включателя до всех мостов, которыми он управляет, посуху. Или мосты (в смысле управляемые) — это мосты (в смысле теории графов). Или что-нибудь ещё.

Для чего вообще нужна соль? А для того, чтобы md5(password)+salt было достаточно длинным, чтобы его нельзя было получить из хэша по предвычисленным таблицам. Таблица-то даст что-то, но нет никакой гарантии, что в конце будет именно ваша соль.

По-моему, криптостойкость одна и та же: тот же уровень противодействия перебору и та же защита от таблиц.

Это делается динамическим программированием за сложность O(nk) по процессору и памяти.

Меньше, чем за шесть нельзя, и вот почему.
Задача эквивалентна такой. Поднимаем колпачок. Есть шарик — отлично; если нет — снимаем правый, и если шарик под ним, тот перекатывается под оставшийся правый. Очевидно, после четырёх проверок четыре колпачка исчезнут, а значит, как минимум два непроверенных останутся.

Автоповтор кнопок, к сожалению, придётся реализовывать самому.

Скажу сразу, спортивного программирования у меня было не очень много: 10 класс — сборы (подвело незнание стандартной задачи на динамическое программирование, да и в одном месте надо было не Real применить, а Extended: проверяли шесть знаков, а у меня, при формально правильном алгоритме, было три или четыре). 11-й — по своей же глупости вообще не попал в призёры. В университете с командой как-то не заладилось, но это не мешало в одиночку быть второй ACM-«командой» факультета.

Во-первых, олимпиада позволила мне попасть в университет на собеседование. Как я его проходил — отдельная история, но всё вышло как надо.

Во-вторых, выработались некоторые приёмы малоглючного программирования. И сейчас посторонние мне часто говорят: «Ты код как на камне высекаешь».

В третьих, алгоритмы есть алгоритмы. Всегда думаешь: а есть ли способ «наскоком» повысить скорость того или иного метода? Можно ли тут приплести, скажем, std::map?

Степень интеграции — это а) количество элементов в микросхеме и б) количество потребной «обвязки». Сверхбольшая степень интеграции — это значит, на одной микросхеме какое-то сложное устройство, и «обвязки» этой микросхеме нужен минимум.

Надо прощупать, однозначного ответа нет. Моя «боевая» клавиатура — Microsoft ComfortCurve 2000. Slim, но кнопочки очень рельефные.

Да, я люблю английский GUI за то, что он легко схватывается. Но GUI как таковой — этого мало, т.к. штука специфичная. Лучше английские игры. Кстати, это в своё время меня и подтолкнуло к изучению языка.

Впрочем, если по служебным обязанностям надо бегло читать техлитературу — почему бы не читать техлитературу?

Что я могу сказать про проблемы C++?
1. Слишком слабая типизация. Например, int x = 0.0;
2. Система хедерных файлов крайне медленна, «предкомпилированные хедеры» и extern template — полумеры.
3. Запутано подключение чужого откомпилированного кода (DLL, к примеру). Мало написать хедер, надо ещё откомпилировать lib — в общем, интересного мало.
4. Библиотека STL крайне жирна. Хотя и libc тоже «хороша» — минимальная программа на Паскале занимала несколько килобайт, в зависимости от компилятора, на Си — приближается к сотне килобайт. Я не говорю про Linux/MSVC, где libc динамически подключаемая.
5. Строковый литерал на C++ — это та же нуль-терминированная строка. Когда эту строку приходится оборачивать в какой-нибудь std::string, уже при выполнении вычисляется её длина. Зачем? Почему бы не вкомпилировать её в exe'шник?
6. Нет ключевых слов override/reintroduce. При изменении сигнатуры виртуального метода приходится вспоминать, где он переопределялся.
7. Нет виртуальных конструкторов. «Фабрика» — полумера.
8. Коряво реализовано право доступа «читай кто угодно, пишу только я».
9. Явное определение методов как inline или не-inline в сочетании с шаблонами приводит к странным эффектам. Когда расшаблонивание приводит к сложному коду, inline вреден (сжирает кэш процессора), когда к простенькой операции с указателем — наоборот, нужен. В общем, это давно уже должно стать парафией оптимизатора.
10. В разного рода callback'ах замыкание приходится реализовывать собственными силами. Что-то типа: typedef void (*ProcDoSomething)(int aParam, void* aClosure). То же самое в Delphi: type ProcDoSomething = procedure(int aParam) of object;
11. Если вдруг случайно два разных модуля реализуют одно и то же, но один препроцессором, а второй — синтаксисом C++, будет ОЧЕНЬ много геморроя с поиском ошибки.
12. В обычном цикле for счётчик упоминается трижды. В общем, место очень ошибкоопасное. Для самых простых циклов у меня вообще есть макрос FOR_S (i, 0, n); суффикс S означает size_t.
13. Когда из-за рефакторинга «внутренней кухни» объекта меняется способ хранения ссылки, меняется и код, который этой ссылкой пользуется. Например: object.buddy.field, object->buddy.field, object.buddy().field — в зависимости от того, buddy реализовано как Buddy& buddy, Buddy* buddy или Buddy buddy().

Пока, засиделся. Мне бежать.

В html5 примерно одинаково. Тэги и переопределили так, что — малозаметное выделение, — сильное выделение.

Microsoft Comfort Curve 2000 (USB).

У меня два года. Клавиатура очень хорошая.
+ Нравится отклик кнопок. Нечто среднее между классической и ноутбучной.
+ Компромисс, пригодный под всё: и под зрячую печать, и под слепую, и под игры.
+ Хорошо моется без разборки, обычной стиральной щёткой.
+ Кнопка «Калькулятор» около цифрового блока.
+ Продуманные светодиоды Num/Caps/Scroll: хорошо видны и не бросаются в глаза.
+ Нет спорных нововведений наподобие маленького Shift'а и большого Delete. До «классики» не хватает только большого Enter'а — мне не критично.
— В стеснённом пространстве лучше взять другую.
— За два года с наиболее используемых кнопок стёрся шершавый рельеф. Маркировка, закрепленная слоем лака, держится отлично.
— Не самый лучший пробел.
— Кнопки Ctrl, которые я приспособил для переключения раскладок, маловаты.