C++ ld тупит, а может я..

>Нужно весь код смотреть.

4000 строк?:)

Вот код хедера, сильно урезанный. Надеюсь влезет.

#ifndef DB2K_SRV_H
#define DB2K_SRV_H

#include <stdio.h>
#include <time.h>
#include <vector>
#include <map>
#include <string>
#define ERROR_MESSAGE_LENGTH 255
#define MAX_WRITING_DATA 60
#define PART_OF_DATA_SIZE 1000
#define DB2K_NUMOF_MEDIANS_GAUGES 54
#define DB2K_MEDIANS_FILE_DELTA_TIME 10
#define DB2K_LOGS_FILE_DELTA_TIME 86400
#define DB2K_MAX_NUMOF_FILES 5
#define DB2K_FILENAME_LENGTH 15
#define DB2K_SOCK_HEADER_LENGTH 2
#define DB2K_APERT_MAX_FILESIZE 24 // in bytes
//using std::vector;



class Db2k_srv_interact
{

private:
  int sock_descr;
  int finish_work_flag;
  db2k_errorcode err_code;
  char err_message[ERROR_MESSAGE_LENGTH];
  char db2k_database_directory[255];
  char db2k_database_logfilename[255];  
  db2k_byte_order byte_order;
  char current_max_file_name[DB2K_NUMOF_TABLES][64];
  time_t current_max_file_time[DB2K_NUMOF_TABLES];
  char current_min_file_name[DB2K_NUMOF_TABLES][64];
  time_t current_min_file_time[DB2K_NUMOF_TABLES];
  char current_write_file_name[DB2K_NUMOF_TABLES][64];
  time_t current_write_file_time[DB2K_NUMOF_TABLES];
  char *data_to_write;
  int data_to_write_ptr;
  std::map <std::string, std::string> db2k_filetowrite;  !!! Смотреть сюда!!!


  int MakeErrMes();
  int MakeErrMes(char *char_err_message);
  int ConvertToNetOrder(char *dest, char *src, int size);
  int ConvertFromNetOrder(char *dest, char *src, int size);
  int SendPart(const char *data, int datasize);
  int RecvPart(char *data, int datasize);
  int CreateNewDatabaseFile(db2k_tablename tablename, time_t time);
  int GetFilenameFromTimet(time_t file_time, const char *kks, char *new_file_name);
  int GetFilenameFromTimet(time_t time, char *new_filename);
  time_t GetTimetFromFilename(const char *filename);
  int GetLength(char * data);
  int GetExpectedDataSize(db2k_tablename tablename, char **contents, int numof_contents,
                          time_t time_from, time_t time_to, int &expdata_size);
  int GetStringFromChar(const char* data, char* mem, int* data_ptr);
  int GetDigitFromChar(const char *data, time_t *digit, int *data_ptr);
  int GetDigitFromChar(const char *data, double *digit, int *data_ptr);
  int GetDigitFromChar(const char *data, float *digit, int *data_ptr);
  int GetDigitFromChar(const char *data, int *digit, int *data_ptr);
  int WriteDataToFile(const char *kks, time_t datas_time, int msec, float data);
  int WriteDataToFile(db2k_tablename tablename, const char *data, int data_size);
  int ReadDirContents(db2k_tablename tablename, char ***contents, int *numof_contents);
  int ReadDataFromFile(db2k_tablename tablename, char *filename, time_t time_from,
                       time_t time_to, char **data, int *data_ptr);
  int IsCurrentCreated(db2k_tablename tablename, time_t time_to_file);
  bool isDB2KDataFile(const char *filename);
  int RecvPart(char *data, int data_size, int wait_time);
  int SendErr();
  int SendOK();
  int CutZeroes(char *src_data, int src_data_length, int *final_length);
  //int add_param(struct *par_t); // add param to DataBase

public:
  Db2k_srv_interact();
  ~Db2k_srv_interact();
  int CreateServer(int serv_port);
  int CreateDb2kStructure(const char db2kdata[255]);
  int WaitForNewConnection(int msec_timeout);
  int RecvCommand();
  int MediansWriteDataHandler(const char *recv_data);
  //MY
  int ApertWriteDataHandler(const char *recv_data);
  int DBStructureCashing(void);
  
  //MY
  int ReadMediansHandler(const char *recv_data);
  int ReadHistoryHandler(const char *recv_data);
  int GetHistoryVolume(const char *recv_data);
  int ProbeHandler(const char *recv_data);
  int OnlineReadDataHandler(const char *recv_data);
  int OnlineWriteDataHandler(const char *recv_data, bool local_op=false);
  int FindEndedFiles(db2k_tablename);
  int GetError();
  char * GetErrorMessage();
  int SetFinishFlag();
  int ClearFinishFlag();
//  int ReadData(db2k_tablename tablename, time_t time_from, time_t time_until, double *list, int sizeoflist);
  
};


#endif /*DB2K_SRV_H_*/

>Фигасе! В отвечал на вопрос: "...если мне нужна переменная класса? Как мне её объявлять и определять?".

Ну да, и сказал писать export. Ладно, я возможно просто не понял тебя.

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

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

>> Его нечем заменить там, где он действительно нужен.

> 4.2 Его везде можно заменить.

Веско. Аргументированно. Чем его заменить в задачах, требующих гарантированного времени отклика? Только не надо говорить "Ада".

> Линкер ругается если я пишу -
> //MyClass.h 
> class MyClass { private: map<string, string> db2k; ... bla-bla-bla... }; 
> ld говорит - multiple definition

$ cat a.h
#include <map>
#include <string>

class MyClass
{ private: std::map<std::string, std::string> db2k;
  public: int i;
};

void foo();

$ cat b.c
#include "a.h"

main()
{
  MyClass *p = new MyClass;
  p->i = 0;
  foo();
  return 0;
}

$ cat c.c
#include "a.h"

void foo()
{
  MyClass *q = new MyClass;
  q->i = 0;
}

$ g++ b.c c.c
$ echo $?
0

Нужно код вокруг смотреть, где-то у тебя нехорошее наворочено.

>Убери опять все объектные файлы и повтори процедуру с private: map <string, string> db2k;

Повторил ещё раз, собралось. Я вроде убирал их и раньше:)) Прошу прощения за тупизм:)))

Надо и правда память освежить, а то за 4 года перла я С++ совсем забыл :(

Всем большое спасибо за помощь.

PS ХОЧУ В ОТПУСК!!!

> Для глобальных переменных самое то.

Глобальные переменные не имеют с синглтоном ничего общего. То есть вообще ничего!

Синглтон -- паттерн проектирования. Его всегда можно заменить в том смысле, что соответствующую функциональность можно реализовать и без "классической" ООП реализации в смысле, прописанном в книжке, но он от этого не перестанет быть синглтоном.

> Я вроде убирал их и раньше:))

:-)

Пропиши зависимости в Мэйкфайле, или так и будешь мучиться!

> Вот код хедера, сильно урезанный. Надеюсь влезет.

хедер на первый взгляд правильный. Где-то используется неправильно.

> Повторил ещё раз, собралось. Я вроде убирал их и раньше:)) Прошу прощения за тупизм:)))

:)

> Надо и правда память освежить, ...

:-)

Во, всем эту книжку пиарю: http://www.icce.rug.nl/documents/cplusplus/

ИМХО лучшее, что есть.

>Пропиши зависимости в Мэйкфайле, или так и будешь мучиться!

Makefile писал не я, щас поковыряюсь, мне проект достался по наследству - уже пол-года с ним вожусь:)))

>Если переменные можно свести в один класс, их можно свести и в один модуль.

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

>Веско. Аргументированно.

У тебя пример беру.

>Чем его заменить в задачах, требующих гарантированного времени отклика?

причём тут язык и realtime ? Не видел ни одного realtime приложения на с++, все были на с.

>Во, всем эту книжку пиарю: http://www.icce.rug.nl/documents/cplusplus/

Спасибо за ссылку.

>Синглтон -- паттерн проектирования. и т.п. херня.

Спасибо открыл мне глаза, а я то не знал.

>Глобальные переменные не имеют с синглтоном ничего общего. То есть вообще ничего!

Ты читал чего я написал ?

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

Не давай им расползаться.

>>Чем его заменить в задачах, требующих гарантированного времени отклика?

>причём тут язык и realtime ?

При том, что сборка мусора (а это Ява и практически все современные языки) вносит непредсказуемые задержки.

> Не видел ни одного realtime приложения на с++

А они есть. ну или на игры взгляни - там дофига Си++.

> Ты читал чего я написал ?

:-)

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

Да, согласен, идея завернуть глобальные переменные в синглтон вполне здравая.

>При том, что сборка мусора

Кто сказал Ява ? Ява не язык программирования.

>Не давай им расползаться.

Ню-ню. Обычно оно так - само. Синглитон даёт ещё много различных плюсов - например, возможность с минимальным гемором втиснуть мультисред доступ и т.п. Плюсов много, а минусов окромя: "фи явой пахнет" пока не увидел.

>А они есть.

Много чего есть. И в играх этот самый С++ можно заменить ( и успешно заменяют ). На текущий момент - нет задач на которых с++ нельзя заменить.

>Извиняюсь -- просто меня дергают постоянно, и в процессе написания я забыл о прочитанном...

Бывает :-).

> Ненужный костыль. Нефиг тащить жабовские привычки в Си++.

Фигасе. Это С++-ники тащат в жабу синглтоны, а мы DI со спрингом юзаем и в ус не дуем.

Антипаттерн "Блоб" детектед. Надо бы отрефакторить на несколько классов. http://www.insidecpp.ru/antipatterns/blob/

http://www.insidecpp.ru/antipatterns/

почитай-ка книжку про антипаттерны (хз, есть ли она на русском)

http://en.wikipedia.org/wiki/AntiPatterns

http://borland.xportal.ru/forum/viewtopic.php?t=19752&sid=3df87806e298648...

> Синглитон даёт ещё много различных плюсов

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

> в играх этот самый С++ можно заменить ( и успешно заменяют ).

И у тебя есть примеры движков не на Си++? (sweeney.pdf я читал)

> На текущий момент - нет задач на которых с++ нельзя заменить.

"Наша песня хороша, начинай сначала" (c)

госпада, простите что встреваю.

Какое отношение имеют игры к реалтайму? Реалтайм это совершенно другое. Играм нужна скорость. Например, в игре по инету никакого реалтайма нету т.к. задержки никем не регламентируются. Изменится маршрут и пинги могут возрасти в десятки раз.

Реалтайм это когда задержки заранее чётко известны. Далее вдаваться в подробности не буду.

> Какое отношение имеют игры к реалтайму?

Игра - это soft realtime.

> Играм нужна скорость.

Реалтайму тоже.

> Реалтайм это когда задержки заранее чётко известны.

Реалтайм бывает сильно разный.

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

tailgunner, по твоей логике выходит что любой язык на котором можно написать игру есть реалтайм. На перле можно написать frozenbubble, значит перл годится для реалтайма? frozenbubble работает на линухе, значит линух реалтайм ос и qnx не нужен?

Надеюсь, выводы из моего поста все правильные сделают.

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

Не выходит. Я ведь написал про то, что реалтайм бывает разный, и про то, что игра - это задача soft realtime. Так что frozenbubble доказывает, что на Перл можно писать soft realtime (правда, хз какие там временные ограничения и сколько в frozenbubble чистого Перла).

> На перле можно написать frozenbubble, значит перл годится для реалтайма?

Если задать гарантированное время отклика в 1 час, то можно сказать, что Перл годится для ж0сткого реалтайма. Сказть можно много глупостей.

> frozenbubble работает на линухе, значит линух реалтайм ос и qnx не нужен?

QNX зачем притянул? Он будет жить еще долго, потому что его пользователи консервативны. А так да, -rt ядро является реалтайм, независимо от frozenbubble.

>И у тебя есть примеры движков не на Си++?

у меня есть. на yampa. исходный движок, способный читать карты формата третьего quake - ~60Kb исходников. гугли "frag yampa haskell"

>Игра - это soft realtime

торжественный вынос тела. в фортунки !

>>И у тебя есть примеры движков не на Си++?

>у меня есть. на yampa

Экспериментальная реализация Q3 на Хаскеле, сделаная через несколько лет после оригинала, и достигающая половины его производительности на железе, в разы более мощном? Убедительно. В каких играх использовалась?

>> Игра - это soft realtime

> торжественный вынос тела. в фортунки !

Загляни хотя бы в википедию, шутник. Не позорься.

"Live audio-video systems are also usually soft real-time; violation of constraints results in degraded quality, but the system can continue to operate".

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

>Экспериментальная реализация

речь о технологиях, а не о продакшене. эксперимент-то прошёл успешно

>Убедительно

ты сначала сравни исходники Frag и исходного Q3. а потом говори что-то насчёт убедительности

>Загляни хотя бы в википедию, шутник. Не позорься

насчёт шутника ты немножко ошибся. насчёт позора тоже. ну давай-давай, покажи мне soft real-time в nethack, например. или в fantasy general, disciples, что там ещё есть. термин "реальное время" вообще к играм применим только в очень общем смысле (исключающем применение уточнений вроде "мягкого" и "жёсткого"), и только к определённому подмножеству игр - action, RTS, что ещё ?.. да и в тех это как правило всего лишь небольшая подсистема, требующая максимальной оптимизации; игровая логика к какому-либо realtime отношения не имеет

>Впрочем, что-то мне подсказывает, что ты слишком хорош для презренной википедии :D

спасибо на добром слове

> речь о технологиях, а не о продакшене

Ну это кто о чем. Я говорил о применимости технологий к реальным задачам (ты, наверное, назовешь это "продакшеном").

> ты сначала сравни исходники Frag и исходного Q3

Зачем? Я говорил о функциональности, которые они обеспечивают. А то, что это не является построчным переводом на Хаскель, я вполне верю.

> ну давай-давай, покажи мне soft real-time в nethack, например. или в fantasy general, disciples, что там ещё есть.

Ты всё же не прочитал вики :) На этот раз я не стану приводить цитату, захочешь - найдешь сам. Hint: даже шахматы могут быть игрой реального времени :)

> термин "реальное время" вообще к играм применим только в очень общем смысле

Но применим? Об этом и речь.

> (исключающем применение уточнений вроде "мягкого" и "жёсткого"),

Почему это? Несоблюдение директивного срока ухудшает характеристики системы, но не является фатальным сбоем - классическое "мягкое реальное время".

> и только к определённому подмножеству игр - action, RTS, что ещё ?

Аркады вроде FrozenBubble. с которого начался разговор об играх.

> игровая логика к какому-либо realtime отношения не имеет

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

>Я говорил о применимости технологий к реальным задачам (ты, наверное, назовешь это "продакшеном").

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

"продакшеном" я называю переход от прототипа (в данном случае Frag) к успешному применению в сторонних проектах

>Ты всё же не прочитал вики

просмотрел. я не согласен с тем, что они пишут. используя настолько общие критерии любую систему можно притянуть к "реальному времени". с моей точки зрения система реального времени та, которая оперирует временной шкалой, сопоставимой с <дискретной> реальной временной шкалой (с некоторым запаздыванием). музыка - да, это soft real-time, ибо замедление воспроизведения искажает звук. для игры же в большинстве случаев это не критично, временная шкала может быть как угодно отмасштабирована, иметь какие угодно вариации (кроме, пожалуй, MMO-игр, в которых синхронизация важна)

>Несоблюдение директивного срока ухудшает характеристики системы, но не является фатальным сбоем - классическое "мягкое реальное время".

по твоим определениям "система, не являющаяся системой реального времени" это та, в которой несоблюдение директивного срока вообще ни на что не влияет - так, что ли ?

>Глубокая мысль. Правда, не припомню, чтобы я говорил об игровой логике (блин, я и игры-то привел как пример).

неудачный пример, вот в чём дело-то. и C++ там не при чём, и soft real-time, в общем-то, тоже. а уж их объединение и подавно

>>Я говорил о применимости технологий к реальным задачам (ты, наверное, назовешь это "продакшеном").

>я тоже. я знаю, как пишутся игры на C++ - и мне вариант на Yampa нравится куда сильней

> "продакшеном" я называю переход от прототипа (в данном случае Frag) к успешному применению в сторонних проектах

Ну так как насчет примеров использования YAMPA или подобных/производных движков в реальном деле? Я не интересуюсь геймдевом, а статья Суини оставляет больше вопросов, чем дает ответов.

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

Ога :) Поэтому на уровне здравого смысла считается, что директивные сроки невелики (миллисекунды, десятки миллисекунд максимум).

> с моей точки зрения система реального времени та, которая оперирует временной шкалой, сопоставимой с <дискретной> реальной временной шкалой

Ну да, так и есть. Просто играет роль величина "деления" этой шкалы.

> по твоим определениям "система, не являющаяся системой реального времени" это та, в которой несоблюдение директивного срока вообще ни на что не влияет - так, что ли ?

Да. Я бы сказал, что "последствия несоблюдения директивного срока пренебрежимо незначительны", но это то же самое по сути.

> неудачный пример, вот в чём дело-то. и C++ там не при чём, и soft real-time, в общем-то, тоже

Речь шла о том, что, из распространенных языков, только Си++ обеспечивает предсказуемость _и_ производительность программ (считаем, что реализуются одни и те же алгоритмы, и не рассматриваем Си из-за низкоуровневости). ИМХО, игры в данном случае - хороший пример.

>Ну так как насчет примеров использования YAMPA или подобных/производных движков в реальном деле?

не знаю. у самого руки до сих пор не дошли. будут результаты - обязательно поделюсь

>Просто играет роль величина "деления" этой шкалы

не только. так было бы слишком просто

>Да. Я бы сказал, что "последствия несоблюдения директивного срока пренебрежимо незначительны", но это то же самое по сути

в таком случае <по твоему определению> не являются системами реального времени только нерабочие системы, содержащие в себе один и более вечных циклов. причём они не только нерабочие, но ещё и никому не нужные, ибо их вечным простоем все пренебрегают :)

>только Си++ обеспечивает предсказуемость

пожалуй в наименьшей степени из "распространённых языков"

>_и_ производительность программ

есть много путей создания систем, включающих компоненты критичные к производительности. так или иначе разделять control flow, программную логику и числодробилки будет один или несколько long jump'ов. так ли важно - будет это FFI или линковка в рамках одного C++-проекта. в любой сколь-нибудь сложной игре и так в обязательном порядке идёт встроенный скриптовый движок - почему бы не сделать навыворот, и не поставить язык высокого уровня снаружи ?

красивейший пример такого подхода - FFTW. думается в игрострое его тоже могли бы взять на вооружение. поживём - увидим

>>Да. Я бы сказал, что "последствия несоблюдения директивного срока пренебрежимо незначительны", но это то же самое по сути

>в таком случае <по твоему определению> не являются системами реального времени только нерабочие системы, содержащие в себе один и более вечных циклов

Ы? Если система генерации отчетов выдает результат не в 8:30, а в 8:31, это уже сорванный директивный срок. Но последствия этого - подумаешь, директор ругнется :) Т.е. система работает и полезна. Хотя проблемы с наукообразным определением "реального времени" есть :)

>>только Си++ обеспечивает предсказуемость

>пожалуй в наименьшей степени из "распространённых языков"

Если учесть, что остальные распространенные языки - это Ява, C# (и VB.Net 8)), то именно в наибольшей (modulo bugs, как говориться).

> есть много путей создания систем, включающих компоненты критичные к производительности. так или иначе разделять control flow, программную логику и числодробилки

У этого подхода есть и свои недостатки. Да и в пределе мы всё равно получим необходимость интеграции всего в рамках одного языка (Аду не дураки проектировали).

>Например, в игре по инету никакого реалтайма нету т.к. задержки никем не регламентируются. Изменится маршрут и пинги могут возрасти в десятки раз.

есть, только это не те задержки. В сетевой гре несмотря на недетерминированные задержки сети картинка управляться, и управление отрабатывать должно в течение заданного интервала. Нету реалтайма в задержках сети. Есть реалтайм во времени реакции гры. Логика сетевой работы гры должна учитывать лаги, и подстраивать свой heartbeat по ходу дела, чтобы задержки у всех грающихся были примерно одинаковы.

Иначе получится как в CSS с ботами: если ими не командовать, нет тактического перевеса или более мощного оружия, или ты в одиночку пытаешься грать в супергероя, "скорость всей команды в целом" не отслеживаешь, передвигаешься не плотным звеном, прикрывая друг друга, а рембо-ниндзя -- вас положат поодиночке, и никакой "командной игры" не получится.

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

> ну давай-давай, покажи мне soft real-time в nethack, например. или в fantasy general, disciples, что там ещё есть. термин "реальное время" вообще к играм применим только в очень общем смысле (исключающем применение уточнений вроде "мягкого" и "жёсткого"), и только к определённому подмножеству игр - action, RTS, что ещё ?.. да и в тех это как правило всего лишь небольшая подсистема, требующая максимальной оптимизации;

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

>игровая логика к какому-либо realtime отношения не имеет

игровая логика имитирует этот heartbeat и синхронизацию в реалтайме. Без неё (синхронизации) играть становится тупо неинтересно.

>"продакшеном" я называю переход от прототипа (в данном случае Frag) к успешному применению в сторонних проектах

более интересен практически другой момент. Профилирование bottleneck'ов в системе/приложении, масштабируемость, и куда эти ботлнеки уходят, в жёстко заданной (на С++) и в динамически ленивой(Лисп) и более статическими типами (Хаскелль) среде.

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

а если шкала неравномерна? ну типа вот тут лаги возникли, а тут -- попустило.

>Если система генерации отчетов выдает результат не в 8:30, а в 8:31, это уже сорванный директивный срок. Но последствия этого - подумаешь, директор ругнется :) Т.е. система работает

а если в 8:30 проведут накладную и отчет станет невалидным?

8:30.5

>>Если система генерации отчетов выдает результат не в 8:30, а в 8:31, это уже сорванный директивный срок. Но последствия этого - подумаешь, директор ругнется :) Т.е. система работает

> а если в 8:30.5 проведут накладную и отчет станет невалидным?

А если не проведут? Но в любом случае, это не имеет значения. Если отчет попадет на стол директора в 8:30.6 (а это так и будет - он печатается секунд 20), он _уже_ будет невалидным.

>реальное время - это предсказуемое поведение (успевать отрабатывать задачу) в течение заданного временного интервала

речь шла о критичности использования C++ для обеспечения "реального времени" в играх. такое "реальное время", т.е. предсказуемость системы, от использования C++ только страдает

>игровая логика имитирует этот heartbeat и синхронизацию в реалтайме

игровая логика в массе своей нетребовательна к производительности. во всяком случае намного менее требовательна чем отрисовка сцен в динамических играх. так что опять другое "реальное время"

> предсказуемость системы, от использования C++ только страдает

Ну-ну. А от использования какого языка оно _не_ страдает?

>Профилирование bottleneck'ов в системе/приложении

тем лучше, чем легче формализуется система. т.е. Haskell, Clean, OCaml, BitC, ADA - но уж точно не C++ и иже с ним

>масштабируемость

в принципе любой язык с хорошей поддержкой модульности. плюс хорошая поддержка процедурной декомпозиции <и> ООП (либо ФП - зависит от приоритетов изменчивости данных и операций над ними)

и, кстати, почему это LISP ленивый ?

>Ну-ну. А от использования какого языка оно _не_ страдает?

верифицируемого. статически (как в http://programatica.cs.pdx.edu/, например) и динамически (профилирование, покрытие тестами). у C++ очень много тёмных углов стандарта, очень многое дано на отпуск авторам компиляторов, очень многие конструкции приводят к неопределённому поведению. плюс перегрузка операторов, плюс специфика control flow (порядок вызова конструкторов в иерархии с виртуальным наследованием, например - это ведь просто праздник)

>У этого подхода есть и свои недостатки

у подхода "лепим всё в кучу" их намного больше

>Да и в пределе мы всё равно получим необходимость интеграции всего в рамках одного языка

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

>а если шкала неравномерна? ну типа вот тут лаги возникли, а тут -- попустило

в таком примере шкала остаётся той же, просто мы выбрасываем ряд кадров. в полном соответствии с нашим "реальным временем", никак его не искажая при этом