Mercury13

ВНИМАНИЕ: У вас есть пара тонких мест.
РАЗ. не забудьте, что строковые литералы в Си — это нуль-терминированные строки, и "\0" по факту будет пустой строкой. Строку из одного нулевого символа можно загнать в string — например, конструктором string(begin, end) или s += '\0', но не конструктором string(const char*).
ДВА. Этот static будет инициализирован при первом вызове. Второй вызов вернёт тот же массив.
ТРИ. Строчку лучше передавать как string *func(const string& s) {}

К делу. Массив — это довольно сложный объект, и возникает вопрос: кто этим массивом будет владеть после того, как он покинет пределы функции?
1. Владеет система времени выполнения. Это отлично ответил Роман, дам только ключевую строчку.
string* arr = func(exp);
НЕЛЬЗЯ ИСПОЛЬЗОВАТЬ: если массив используется в чьих-то «конских» конструкторах-деструкторах статических объектов (из-за отсутствия модулей Си++ не позволяет установить на уровне языка порядок создания/уничтожения статических объектов).

2. Владеет какой-то объект.

string *func(string s) {
    static string* ar = nullptr;
    if (ar) delete[] ar;
    ar = new ar[3];
    ar[0] = "qwe";
    ar[1] = s;
    ar[2].clear();
    return ar;
}

НЕЛЬЗЯ ИСПОЛЬЗОВАТЬ: ну, это уж разбирайтесь сами с этим объектом, сколько он будет жить и насколько долго он будет держать массив. В данном случае каждый новый вызов уничтожает старый массив. (Код корявый, потому что последний массив не уничтожается.)

3. Владеет тот, кто вызывает. Лучше для таких целей использовать какой-нибудь std::vector.

vector<string> func(string s) {
    vector<string> r;
    r.reserve(3);
    r.push_back("qwe");
    r.push_back(s);
    r.push_back(std::string());
    return r;
}

А это значит, что манипулируя членами b я буду редактировать память a?

Нет, конечно.

Type& Type::operator=(const Type& x);
Задача операции присваивания — сделать, чтобы объект слева (он же *this) стал копией объекта справа (он же x).

Почему операция присваивания берёт Type& по ссылке? Да потому, что взять по копии — это вызвать конструктор копирования. Вполне можно написать
BigInt& BigInt::operator = (int x);
когда слева «большой» тип, а справа — «маленький», и его конструктор копирования незначителен (а то и равняется накладным расходам на ссылку, как у того же int). Но когда с обеих сторон один и тот же тип — это часто бездумный вызов конструктора копирования (собственные конструктор копирования и операцию = обычно пишут, когда нужна хитрая логика, а не тривиальное копирование).

Почему операция присваивания возвращает Type&? Просто чтобы работали конструкции типа a = b = c. Может и void возвращать, если хочешь.

class C
{
public:
    C() {}
    C (const C&) { std::cout << "Copy ctor" << std::endl; }
    C & operator = (const C&) { std::cout << "Assign" << std::endl; return *this; }
};

int main()
{
    C a;
    C b = a;

Выведет «Copy ctor». То есть ответ на первый вопрос — конструктор копирования.

В литературе что я читаю это называется присваиванием

Не присваивание, а инициализация. Присваиванием было бы…

Type b;
b = a;

Type b = Type(a);

В идеале тут два конструктора копирования и один деструктор, однако компилятору даётся воля уменьшать их количество. Потому только «copy ctor».

Код

int a = 10;
C b = C(a);

также даёт один вызов C(int). А C(const C&) не вызывается ни разу.

UPD. Одно из нововведений Си++11 — чтобы даже без этих негарантированных оптимизаций, когда один объект исчезает, а второй появляется, можно было вместо копирования проводить нечто более простое, не требующее отвода-возврата памяти. Я-то экспериментировал в режиме Си++03, но в Си++11 уже были бы конструктор копирования, конструктор перемещения и деструктор.

Несмотря на то, что массив часто отождествляют с указателем, массив — это НЕ указатель. У него, например, другие операции приводят к неопределённому поведению.

И самое противное в Си — это то, что в коде
void sort(int x[5]);
x — это не массив, а именно что указатель. Чтобы был массив, надо Си++
void sort(int (&x)[5]);
И компилятор даже подсвечивает, что параметр функции, отмеченный как массив — всегда указатель.

typedef int Arr[SIZE];
int sum(Arr arr, int n)
// warning: 'sizeof' on array function parameter 'arr' will return size of 'int *' [-Wsizeof-array-argument]|

Из такого вопроса видно, что человек всё ещё нетвёрдо знает программирование, а уже пытается программить игру.
И тут есть два варианта.

1. Движок с нуля. Тонкая графическая прослойка наподобие SDL, оставляющая 100%-ю свободу движкописателям — это тоже «с нуля» и всячески рекомендуется даже продвинутым (не нужно писать всякие там Alt-Tab’ы и прочую дрянь, далёкую от игры). Тогда пусть начнёт с «питончика» (https://ru.wikipedia.org/wiki/Snake_(игра) ) или текстового квеста.
А потом, когда доберётся до платформера или CRPG, он поймёт, каким образом привязать к монстру характеристики.

Первое приближение (не слишком удобное для скриптования и подходящее для платформеров/action-RPG, но негодное в настоящих RPG) — сделать каждому компьютерному персонажу «класс» (не путать с классом ООП), включающий кол-во HP, внешний вид и прочее. А также «набор скриптов» — для поведения в диалогах, запрограммированного передвижения, превращения из «болванчика» в компьютерного врага, и т.д. Без набора скриптов он просто компьютерный враг, тупо нападающий на ПиСя.

Если скриптовый движок чужой (тут уже не зазорно брать чужое) — вы уж смотрите, что он может и куда его впихнуть. А если хотите написать сами — лучше делайте триггеры, как в StarCraft.

2. На чужом движке. Это уж смотрите, что движок может, какие возможности в нём «в коробке», а какие придётся дописывать своим кодом и чужими модулями. Не знаком ни с одним. Чужой движок — довольно противное дело для начинающего программиста: он автоматически формирует какую-то структуру программы, и программисту приходится не столько творить, сколько разбираться с этой структурой. С одной стороны, можно быстро написать довольно сложную игру, с другой — не так много радости «а у меня заработало».

Попробуйте Brush.Color := $FF000000 or clBlue;. Велика вероятность, что механизмы работы с 32-битными изображениями тут слабоваты.