Wataru

Если вам не надо чтобы каждый человек одинаково часто работал с каждым другим, то подойдет обощение решения, предложенного в комментариях Alexandroppolus и Сергей Сергей.

Допустим количество работ (N) и количество людей (M) взаимно просты.

Тогда сгенерируйте M строчек беря людей подряд:
1, 2, 3
4, 5, 1
2, 3, 4
5, 1, 2
3, 4, 5

Тут каждый человек одинаковое количество раз (по одному разу) будет на каждой работе. И дни, когда он будет работать будут максимально равномерно распределены (минимальное расстояние и максимальное между соседними работами будут различаться максимум на 1 и равны floor(N/M) и ceil(N/M)). Это идеальное с точки зрения равенства расписание. Но у него минус - частоты пар работников будут не одинаковыми. 1 гораздо чаще будет работать с 2 и 5, чем с 3 и 4.

Теперь, если N и M не взяимно просты. Пусть D = GCD(N,M) - наибольший общий делитель.

Разбейте всех людей на D групп по N'=N/D человек. N' и M взяимно просты, поэтому можно применить алгоритм выше к каждой группе.

Дальше эти D расписаний надо перемешать. Для максимальной равномерности - сначала взять все первые строки всех расписаний, потом все вторые, и т.д.

На i-ом месте будет день i / N' из расписания i % N' (если индексация с 0).

Так, например, решение для 2 работ и 6 людей:

N' = 3. 2 группы.
В первой:
1 2
3 1
2 3

Во второй:
4 5
6 4
5 6

В итоге:
1 2
4 5
3 1
6 4
2 3
5 6

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

Можно запоминать предыдущие поля. Хотя бы в виде хешей для экономия памяти. Чтобы из-за коллизии не заврешаться раньше времени, можно считать несколько принципиально разных хешей (допустим, sha256 и какой-то полиномиальный хеш), и плюс брать "слепок" от поля (какие-то 256 разбросанных по полю клеток).

Или, если поле не большое, то можно вместе с хешом хранить все поле. Если где-то хеши совпали, то дальше нужнол сравнивать уже поля целиком поклеточно.

У вас каждый раз выполняется MoveToEx() в начало координат. Надо вам куда-то сохранить координаты последней точки и делать MoveToEx туда, потом LineTo в новые координаты и запомнить их.

Там не происходиит копирование данных. Просто среда выаолнения запоминает, что переменная a лежит вон там внутри "массива" кучи. При чтении оттуда данных все происходит за одну асскмблерную операцию, как если бы вы читали из int.

Пишущим на си++ из-за концепции указателей это все должно быть понятнее. При выделении данных на куче просто какой-то указатель указывает куда-то в кучу и все.

Откройте его с отключенным js. Возможно страница динамически изменяется, поэтому те теги, что вы ищите - их нету в html коде, который вы загружаете.

Сначала перемешайте слова. Возьмите массив длины NUM_WORDS чисел и заполните его изначально индексами от 0 до NUM_WORDS-1. Перемешайте. Потом сделайте цикл по словам, который будет загадывать слово с индексом вот из этого массива. Внутри while(true) будет спрашивать пользователя, пока он не угадает. Т.е. вот этот ваш код весь выносится в отдельную функцию и вместо случайной генерации choice, получает его в качестве параметра. Можно через возвращаемое значение сообщать о том, что пользователь попросил выйти.

И еще, чтобы перемешать случайно слово/массив индексов надо делать вот так (а не так, как у вас):

for(int i = 0; i < length; ++i) //меняет буквы местами
    {
        int prev = (rand() % (i+1));
        char temp = jumble[prev];
        jumble[prev] = jumble[i];
        jumble[i] = temp;
    }

Надо не менять местами два случайных символа, а менять i-ый со случайным предыдущим. А то у вас не все перестановки генерируются одинаково равновероятно.

Различия обусловнены тем, что строки - особый вид массивов. Весьма частый и использующийся повсеместно. Плюс, в отличии от обычных массивов, в строках есть нулевой завершающий байт. Поэтому некоторые вещи стандартом Си были добавлены в язык отдельно для строк. Как, например, инициализацию const char* строковым литералом, или инициализацию массива с рассчетом его размера (учитывая нулевой символ в конце). Оно же потом перекочевало в Си++.

Если ваш двумерный массив сделан как указатель-на-массив-указателей-на-строки - то да. Если же вы завели массив вроде int a[100][200]; - то нет.

vgray, Удаляются ли записи?

Так-то, поиск на полное совпадение по строке не самое сложное. Какое-нибудь B-Tree или Trie - отлично подойдут тут. Проблема только в том, что оно в память не влезает, поэтому придется повозиться с хранением этого всего кусками в файлах. B-Tree как раз для этого и сделано, но оно будет медленнее работать со строками. Аккуратно порезанный на куски Trie будет быстрее.

Тут похоже ошибка в архитектуре. Логичнее было бы сделать чтобы Lane::Place(Unit *) вызывало какие-то методы у Unit, если это надо для конкретной реализации Lane (Эта логика будет в виртуальном методе, переопределенном в конкретных реализациях интерфейса).

Или Unit::OnPlaced(Lane*) всегда вызвает какие-то методы у Lane и вот они могут сказать, что Unit-у не надо ничего делать.

Ну, или раз вам вот так хочется сделать, то пишите шаблонный метод Unit::OnPlaced(T*), И ручками прописывайне инстанциировки с кокретными SkyLane, GroundLane и т.д. Ну и "дефолтную" реализацию пропишите пустую - вообще ничего не делающую для типа T*

Все, что вы перечислили - можно сделать удляя/изменяя некие файлы на компьютере, а также измененяя реестр windows. Все это можно сделать практически в любом языке из которого можно вызывать функции windows API.

C++, наверно, не самый удобный для этого язык, хотя бы из-за его скудности работы со строчками и возможностей выстрелить себе в ногу.

Вам тут в первую очередь надо изучать не C++, а настройки windows и документацию о нем же.