Армянское Радио

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

Очередной "я не читал мануалы, памагити" вопрос.

Читайте Снейдер, Й. "Эффективное программирование TCP/IP".

Кратко - функции send() и recv() не гарантируют, что будет записано или прочитано столько байт, сколько вы в них передали. Нужно анализировать возвращенное этими функциями значение - если оно 0 или < 0 - что-то поломалось и нужно анализировать errorno, в противном случае, вот столько байт и передалось.

Главное, чему нужно следовать при размещении инклюдов - принцип наибольшей закрытости - в *.h файл должно торчать как можно меньше сущностей.

Например, за размещение в *.h файле матюка типа using namespace std; разместившему грозит неприятный разнос на code review c вердиктом УБРАТЬ ДОЛОЙ

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

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

Например, если у вас в классе есть указатель на какой-то другой класс, не нужно тащить инклюд этого класса, достаточно сделать forward declaration.

"Понимать взаимосвязи" позволяет IDE. Там можно прекрасно посмотреть, что куда включено.

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

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

1) Не следует допускать торчания из классов полей с данными - все поля, кроме, быть может, констант, следует делать приватными.
2) В таком случае, у ваших классов появятся методы для доступа к этим полям, которые нужно будет объявить виртуальными
3) Вместо хранения экземпляров в векторе объектов, следует сделать вектор из умных указателей на эти объекты
4) Базовый класс для этих объектов желательно сделать абстрактным, на худой конец - интерфейсным.

После этого, ваша гомологическая иерархия классов станет вести себя так, как вы этого хотите.

Затем, что a - это int (*)[3], a b - int*

Да и да.

Очень зависит от решаемой задачи. Как правило, неплохо подходит std::string.
Но если вам нужно работать с текстом в utf-8, начинаются интересные нюансы.

Использовать для строк массивы - это подход из языка C. Он годится в тех редких случаях, когда у вас, например, максимальная длина строки ограничена и подобных. В общем случае, если вы начнете использовать для строк массивы, вы просто заново напишите плохо отлаженную, неоптимальную, и едва ли хорошо оттестированную реализацию std::string еще раз.

C++ builder - это сильно устаревший компилятор с багами в оптимизаторе и неполной поддержкой даже C++ 98

Выбросьте его куда подальше.

Используйте вендовые типы и вендовый прототип для функции, которую тащите из DLL.

typedef BOOL (WINAPI *LPFN_ISWOW64PROCESS) (HANDLE, PBOOL);
BOOL isWow64 = FALSE;

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

Вы забываете о большом пласте истории техники, который был сильно до этого - 8 битные домашние ЭВМ (десятки их) и язык Бейсик.

Так вот, ЭВМ того времени были катастрофически разными - разные носители (кассеты, дискеты, картриджи), разная аппаратура (засунуть еще один центральный процессор в дисковод? да нивапрос! разная скорость для PAL и NTSC версий - легко!). Но вот бейсик был везде и позволял, с некоторыми переделками, таскать программы с машины на машину.

Таким образом, авторы находились в этом историческом контексте (у них все детство прошло в обнимку с каким-нибудь VIC-20). Тут уже становится логичным желание сотворить то же самое, только круче - берем современный язык, стандартизируем синтаксис - и делаем аналогично - производитель железа предоставляет нам Java-машину с нужным уровнем абстракции - и все программы бегают с архитектуры на архитектуру без переделок.

Отчасти, это сработало на старых мобилках, в эпоху j2me - это как раз Java, засунутая в телефон - игры, браузеры, карты (были даже ЯндексКарты), читалки, чатилки - куча всего.

Еще один виток эволюции, которые вы, видимо, не застали - (чорд, я - стар, я очень стар) - попытки сотворить интерактивные веб страницы.
"У нас же есть всюду переносимая Java - давайте влупим ее поддержку в браузер в виде апплетов - небольших приложений". Тут резко активировались вирусописатели и прочий сброд - благодаря развесистой и дырявой архитектуре, апплеты могли творить всякую дичь.

Сейчас апплет на java можно встретить во всяком старом железе, на нем там сделано GUI для удаленного администрирования серверов, коммутаторов и СХД. Вы браузером заходите на железку, и тут на вас вываливается ворох предупреждений о том, что сейчас будет запущено какое-то ужасное дырявое ПО, держите штаны, а то слетят. Уверены? Точно уверены? А с этим согласны? А так?

А уже потом начали активно применять JavaScript, главным образом, изобретя Ajax - продолжая люто натягивать сову (систему для создания электронных библиотек для ученых/HTML) на глобус (задачу создания интерактивного гуя с красивой версткой).

И это вы еще бэк на Perle не рефакторили

Так как это функция WinApi, да можно.

Назначаете разные текстурные координаты разным граням - и готово.

Тут ошибка:
if(zi[i].DirVint==direction)
Так нужно исправить
if(strcmp(zi[i].DirVint,direction) == 0)