Wataru

Вы бы хоть ошибку-то привели. У меня возникает:

error: ISO C++ forbids declaration of 'call_func' with no type [-fpermissive]

И чтобы ее иcправить, надо лишь дописать тип возвращаемого значения. Например:

template<typename T>
void call_func(T param) {sin(param);}

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

Сначала перемешайте слова. Возьмите массив длины 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* строковым литералом, или инициализацию массива с рассчетом его размера (учитывая нулевой символ в конце). Оно же потом перекочевало в Си++.

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

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

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

Первая ошибка:
char *marka_ = new char;

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

Вторая ошибка:
char* m = "Renault"

Тут используется значение аргумента по умолчанию, где у вас строковая константа. Тут не происходит копирование строки, просто в переменную m сохраняется адрес вот этой вот константы, которую компилятор куда-то в памяти проложения засунет. Вы не выделяли эту память, поэтому попытка сделать delete на ней - неопределенное поведение, что в данном удачном случае приводет к крэшу.

У вас вообще проблема тут - marka может указывать на выделенную вами в Input() память, а может указывать на переданную из вне память. Кто ее удалять должен-то? Так же в Input() вы можете переписать переданный в конструкторе указатель. А надо ли было его удалять классу?

Я бы сделал в конструкторе всегда копирование переданной строки. Тогда можно будет передавать туда и строковые константы и использовать вот такое вот значение по умолчанию.

В С++ рефлексии нет. Только ручками. Где-то придется писать список всех классов и по всем им пробегаться и сравнивать строку. Ну или map какой-то создать. В качестве ключа вставлять команду, в качестве значения - функцию создающую объект конкретного класса.

Как вариант, можно как-то упростить себе работу с помощью шаблонной магии. Шаблон будет принимать список всех классов, сравнивать первый с заданной командой и или рекурсивно вызваться дальше или создавать объект текущего класса.

Пример можно посмотреть вот тут. Там CreateEncoderInternal делает практически то, что вам надо. Только там не константное поле command проверяется, а проверяется, что заданный формат есть в статическом списке в текущем классе.

И все-равно где-то в коде надо прописать список всех возможных классов, как тут.

Не зачем, а почему. Так получилось. В те времена, когда C созадавался, технологии были не настолько развиты. Первый компилятор даже, по-моему, и код-то оптимизировать особо не мог. Предложенная вами compile-time директива слишком сложна. Даже в C++ что-то подобное завезли только совсем недавно.

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

Еще одна причина - это кросс-платформенный код. Ну вот вызов какой-то функции winapi просто не скомпилируется под linux, потому что ее там тупо нет. Значит надо сказать компилятору вот тот кусок вообще игнорировать. Если это делается на том же этапе, что и сама компиляция, да и с тем же синтакисом, то возникает проблема - в синтаксисе-то ошибка под linux. Как-то разбираться, что эта ошибка не критичская и весь кусок кода можно тупо выкинуть - это компилятору сложно, да и опасно это. Поэтому нужен именно какой-то предварительный этап, который не может использовать тот же самый синтаксис.

Вы точно этот код запустили? Пока очень похоже, что просто одна вершина не рисуется в коде.

По идее надо оформить код в файле в функцию и вызывать ее там где вам надо.

В хедере вы декларируете функцию и включаете этот хедер в начало вашего С++ файла, приведенного в вопросе.
Другой С++ файл будет реализовывать функцию (и тоже включать хедер). Потом какая-то система сборки или IDE скомпилирует оба файла и соберет из получившихся объектных файлов одну dll-ку. Или вы руками скомпилируете каждый из двух C++ файлов и потом отдельным вызовом слинкуете все.

Вы, видимо, предполагаете просто тупо написать код функции в файле и включить его в тело функции через #include. Вообще говоря, это даже скомпилируется, но это такой лютый говнокод получается, что так делать никогда и ни при каких обстоятельствах нельзя. Сообщения об ошибках будут со съехавшими номерами строк, сам файл с кодом будет некорректным С++ кодом, поэтому любой редактор не сможет вам ни подстветить его, ни понять какие там есть штуки, чтобы показывать их вам в подсказках. Такой подход не обобщается на более чем пару файлов - вы потом сами запутаетесь что где и куда включено.