GavriKos

Запись по невалидному указателю - это UB (undefined behavior), т.е. по стандарту произойти может что угодно. На деле просто пишется туда, куда сказали, что может вызвать как структурное исключение (SEH, не путать с обычными исключениями C++) на Windows или SIGSEGV на Unix'ах, а может и не вызвать, если по данному указателю запись возможна. Т.о. try-catch не решение по двум причинам:
1. Исключение даже если и будет, то не C++ (хотя, к примеру, студия позволяет SEH'и ловить "обычным" catch)
2. Исключение не гарантировано

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

Игрушки, обработка видео, графика... это видиокарта. Программирование (сборка, компиляция), вычисления... тут нужен i7 (больше ядер, больше кеш процессора).

Да и на играх и прочем тоже будет прирост производительности, просто не такой существенный.

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

Внутри сервера логика должна быть гораздо сложнее клиентской, т.к. сервер реализует не только правила самой игры, но и всяческие проверки на "дурака", чтобы клиент не мог читерить. Также сервер должен организовать взаимодействие между игроками. В простейшем случае это некая игровая комната, а внутри неё 2 и более игроков создают игровую ситуацию по правилам игры.

Если хотите писать сервер с нуля, то рекомендую посмотреть в сторону Erlang.
Там за каждого клиента может отвечать свой процесс, за игровую комнату тоже. И т.о. вся реализация игры сводится к правильной посылке сообщений от процесса-игрока, к процессу-комнате и обратно с реализацией игровой логики внутри процесса-комнаты.

В целом вот так. Если будет нужна помощью в Erlang, или написании такого сервера могу помочь. В том числе и ответами на данном ресурсе.

Компилятор выводит ошибку.
...
Опять же выводит ошибку.
В чем проблема?

В том, что вы не привели нам текста ошибки.
Наугад, ваш компилятор не поддерживает C++0x

Потому что так сложились звезды. Потенциально, вывод может быть любым, потому он и undefined. Ноль - входит в множество всевозможных вариантов

Может так?
Школа создает свой субдомен и кладет туда обычный iframe.

ифрэйм, либо rest api + клиент на js.

инклуд php файла это довольно плохо в случае с удаленными серверами

Чисто теоритически - возможно но думаю дешевле будет нанять школьников/студентов, которые будут вручную это добро обрабатывать.

updated:
google images умеет искать по изображению.

Такое вполне возможно:
Компилятор создал объект A а в B* b записал "мусор".
"Думая" что по адресу *b находится объект класса B он читает и записывает логическое значение куда-то в памяти (так как простые методы getFlag и setFlag скорее всего оптимизируются на простое обращение к атрибуту flag и это объясняет падение при отладке). При вызове сложной функции, собственно, и возникает SegFault.

В консоль браузера вбиваете

for(var i=1;i<1001;i++){console.log("www.host.com/folder1/"+i+".jpg")}

Потом копируете вывод в файл

char *test[255][100] -- это двумерный массив указателей на char.
А вот char (*test)[255][100] -- это указатель на двумерный массив char, чувствуете разницу?

По вашему вопросу:
char (*test)[100] = (char (*)[100]) 0xDEADBEEF;