Станислав Макаров

Пока вижу вот что.
1. a += buff[i]; Вы суммируете коды символов, а не их числовые значения. Правильно a += buff[i] - '0';

2. Эти строки дублируют друг друга.

fin >> buff;
  fin.getline(buff, 11);

Сначала получаем 0123456789, потом файл кончился и на место 0 записываем нулевой символ (NUL).

3. for (int i = 0; i < 11; i++) — неуниверсальная конструкция. Плюс цифр в строчке всего 10, поэтому надо i < 10.

4. Так сумму чисел или сумму цифр?

У Вас быстро закончится память, т.к. вся таблица (а скорей всего не одна) будет сохраняться в ОЗУ.

Object* find (const Object& o)
{
    /* Поиск, если нашли */
   return link;
   /* Если не нашли? */
   return NULL; // Теперь можно
}

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

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

1) Разбиваем по категориям, каждую категорию - в свою папку. Если надо - еще подпапки.
2) Общий или старый код вынести в библиотеку, подключать только .h + .lib
3) Использовать систему контроля версий.
4) Ввести лимит по количеству строк на файл, перераспределять код таким образом, чтобы в одном .c файле было не больше 1000 строк (имхо даже 500 на с уже много. )

Qt

ruhighload.com

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

На большинстве (всех?) современных ОС получение времени - это функция ядра. Следовательно для пользовательского процесса в userspace это требует ровно один вызов в ядро, который представляет собой syscall, то есть программное прерывание. На стороне ядра код обычно тривиальный и заключается в получении значения переменной, в которой хранится время (эта переменная инкрементируется из обработчика прерывания таймера), и возврате этого значения через sysret, то есть возврат из прерывания. Поэтому основные временные затраты сводятся к исполнению syscall/sysret и сохранению/восстановлению контекста пользовательского процесса при входе/выходе в/из ядра.
От единиц измерения (нано/мирко/милли) скорость вызова практически не зависит. Конвертация одних единиц в другие происходит на стороне пользовательского процесса, за это отвечают библиотеки и окружение конкретного языка, но эти вычисления составляют всего несколько машинных инструкций и не вносят значительный вклад общее время вызова.

В Linux существуют несколько таймеров в ядре: высокого/обычного разрешения и переводимые/непереводимые назад, но получение времени происходит через одну функцию clock_gettime как бы по-разному это не выглядело в разных ЯВУ.

В Windows стандартные механизмы GetSystemTime и GetTickCount выдают время только с миллисекундной точностью. А таймер высокого разрешения QueryPerformanceCounter предназначен только для измерения временных интервалов, его абсолютное значение не имеет смысла.

Историческая справка: В реальном режиме работы x86 до тех пор, пока BIOS владеет аппаратным прерыванием таймера и таймер настроен по умолчанию (его еще можно перенастраивать), то есть с интервалом в 55ms и частотой в 18.2 герц, на каждый тик таймера инкрементируется четырехбайтное значение по абсолютному адресу 0:046C. Так что пользовательская программа (термин процесс тут не совсем применим) может получить значение времени мгновенно простым считыванием этого значения из памяти без каких-либо вызовов.
Стоит отметить, что данный функционал не имеет никакого отношения к DOS или какой-либо ОС вообще, а прошит в BIOS любого x86-совместимого (даже современного) компьютера и действителен каждый раз при загрузке машины вплоть до момента перевода процессора в защищенный режим в момент загрузки ядра современной ОС.