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

да, кстати, в boost::algorithms в BGL есть алгоритм Connected Components. но тут надо подумать, удобно ли тебе будет под него подстраиваться или быстрее "на коленке" написать.

дык, под Си оно не намного сложнее. просто пишется чуть менее красиво, но сложного там нет ничего.
всё аналогично (у меня в примере проект называется dce и основной файл плюсовый):

собственно, дерево построено и дальше можно это дерево юзать. например, вот так:


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

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

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

У меня система Linux Debian, в основном Squeeze, плюс всякие новые экспериментальные пакеты.
ANTLR 1.3.1
Жаба:
java version "1.6.0_17"
Java™ SE Runtime Environment (build 1.6.0_17-b04)
Java HotSpot™ Server VM (build 14.3-b01, mixed mode)

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

что знаю, то выделю:

bus service
- сервис канала
- служба шины

window decorations
- украшений окон
- декорации окна

Communication capabilities
- Возможность связи
- Возможности взаимодействия

underlying hardware
- аппаратная (часть)
- {ниже|под}лежащее оборудование

Easing curves
- Легкие кривые (это точно неправильно)
- Упрощение кривых

Opacity effect
- Эффект непрозрачности
- Матовый эффект (это точно неправильно)

pending call
- задержанный вызов
- вызов ожидающий обработку


anchor (between...)
- привязка (между...)
- якорь (между...)

transformation matrix
- матрица преобразований
- матрица преобразования

foo are bar
- foo является bar
- foo - bar
- foo - это bar (вообще говоря, это множественное число, так что можно написать "являются")

открыла для себя Shub-Niggurath (не тот, который современный метал, а старый французский авангард).
потрясающе. напоминает ранний Univers Zero, но местами агрессивнее.
если кто любит мрачный эмбиент и жёсткий экспериментал с классическими инструментами - рекомендую!

мне один раз удалось это сделать копать надо в сторону статической линковки, разрешения статических линков на уровне библиотек (у 2005 студии флажок /Gz, если правильно помню) и иногда вроде надо ещё точку входа явно указывать, чтобы msvcrt не подцеплялся. про точки входа можно почитать в MSDN. правда, там очень мало написано про них и как-то невнятно, в общем, избавиться от этих библиотек можно, но очень геморройное занятие. гораздо проще просто добавить их дурацкий Redist в свой инсталлятор и не париться

абсолютно
пруфлинк: http://www.linux.org/info/linus.html

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

 // это инициализация
  #ifndef __linux__
       ::QueryPerformanceFrequency(&frequency);
       simplistic_synchronize(ref_point);
  #endif

 // это использование
        #ifdef __linux__
        // pt - типа boost::posix_time::ptime
        pt = microsec_clock::universal_time();  // это из boost - там под линём всё OK с таймерами
        #else
        pt = get_total_microseconds(); // под вендой начинаем извращаться через QueryPerformanceCounter
        #endif

детали реализации счётчика под венду:

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

typedef ptime time_type; // это boost::posix_time::ptime
struct reference_point
{
  FILETIME file_time;
  LARGE_INTEGER counter;
};

reference_point ref_point;
LARGE_INTEGER   frequency;
mutex           mtx;

void simplistic_synchronize(reference_point& ref_point)
{
  FILETIME      ft0 = { 0, 0 },
                ft1 = { 0, 0 };
  LARGE_INTEGER li;

  //
  // Spin waiting for a change in system time. Get the matching
  // performance counter value for that time.
  //
  ::GetSystemTimeAsFileTime(&ft0);
  do
  {
    ::GetSystemTimeAsFileTime(&ft1);
    ::QueryPerformanceCounter(&li);
  }
  while ((ft0.dwHighDateTime == ft1.dwHighDateTime) &&
         (ft0.dwLowDateTime == ft1.dwLowDateTime));

  ref_point.file_time = ft1;
  ref_point.counter = li;
}

void get_time(LARGE_INTEGER frequency, const reference_point&
    reference, FILETIME& current_time)
{
  LARGE_INTEGER li;

  ::QueryPerformanceCounter(&li);

  //
  // Calculate performance counter ticks elapsed
  //
  LARGE_INTEGER ticks_elapsed;

  ticks_elapsed.QuadPart = li.QuadPart -
      reference.counter.QuadPart;

  //
  // Translate to 100-nanoseconds intervals (FILETIME
  // resolution) and add to
  // reference FILETIME to get current FILETIME.
  //
  ULARGE_INTEGER filetime_ticks,
                 filetime_ref_as_ul;

  filetime_ticks.QuadPart =
      (ULONGLONG)((((double)ticks_elapsed.QuadPart/(double)
      frequency.QuadPart)*10000000.0)+0.5);
  filetime_ref_as_ul.HighPart = reference.file_time.dwHighDateTime;
  filetime_ref_as_ul.LowPart = reference.file_time.dwLowDateTime;
  filetime_ref_as_ul.QuadPart += filetime_ticks.QuadPart;

  //
  // Copy to result
  //
  current_time.dwHighDateTime = filetime_ref_as_ul.HighPart;
  current_time.dwLowDateTime = filetime_ref_as_ul.LowPart;
}

time_type create_time(FILETIME& ft) {
      // offset is difference (in 100-nanoseconds) from
      // 1970-Jan-01 to 1601-Jan-01
      boost::uint64_t c1 = 27111902;
      boost::uint64_t c2 = 3577643008UL; // 'UL' removes compiler warnings
      const boost::uint64_t OFFSET = (c1 << 32) + c2;

      boost::uint64_t filetime = ft.dwHighDateTime;
      filetime = filetime << 32;
      filetime += ft.dwLowDateTime;
      filetime -= OFFSET;
      // filetime now holds 100-nanoseconds since 1970-Jan-01

      // microseconds -- static casts supress warnings
      boost::uint32_t sub_sec = static_cast<boost::uint32_t>((filetime % 10000000) / 10);

      std::time_t t = static_cast<time_t>(filetime / 10000000); // seconds since epoch

      std::tm *curr_ptr = 0;
      curr_ptr = std::gmtime(&t);//, &curr);

      ptime::date_type d(curr_ptr->tm_year + 1900,
                  curr_ptr->tm_mon + 1,
                  curr_ptr->tm_mday);

      //The following line will adjusts the fractional second tick in terms
      //of the current time system.  For example, if the time system
      //doesn't support fractional seconds then res_adjust returns 0
      //and all the fractional seconds return 0.
      int adjust = static_cast<int>(ptime::time_duration_type::rep_type::res_adjust()/1000000);

      ptime::time_duration_type td(curr_ptr->tm_hour,
                            curr_ptr->tm_min,
                            curr_ptr->tm_sec,
                            sub_sec * adjust);
      return time_type(d,td);

    }


time_type get_total_microseconds(void)
{
     FILETIME  ft;
     {
        mutex::scoped_lock l(mtx);
        get_time(frequency, ref_point, ft);
     }
     return create_time(ft);
}

P.S. я тут быстро из кода навыдирала кусочков и комменты маленько добавила, могла чего-нить забыть. но в общем, я думаю, идея понятна.

ну, в самом простом случае примерно так:

bjam --toolset=msvc-8.0 --builddir="D:\Temp\BoostBuild" address-model=32 link=static runtime-link=static threading=multi stage debug release

перед сборкой нужно также запустить bootstrap - он создаст необходимую структуру для сборки.
собрать (исходники для сборки bjam поставляются с бустом и находятся в папке ./tools/jam) или скачать готовый bjam нужной версии.

соответственно, в строке для bjam надо указать необходимые опции линковки (static/shared), версии для debug или release (либо обе), рабочий каталог для сборки, нужную "потокобезопасность" (слово-то какое на русском языке! ) - то есть однопоточные/многопоточные версии библиотек, размерность шины (32-64 бита). 'stage' (значение по умолчанию) в данном случае указывает, что готовые библиотеки будут скопированы в локальную папку ./stage относительно корня исходников (можно указать, куда их складывать)
для скорости можно ещё добавить количество одновременно выполняемых задач (если машина многопроцессорная): -jN, где N- количество задач.

версия компилятора также указывается. для MSVC можно указать просто msvc либо msvc-X.0, если на машине установлено несколько компиляторов. для gcc указывается gcc, для остальных я так не помню, надо читать доки. это всё есть на сайте буста.

однако у буста есть много дополнительных библиотек, включающихся опционально (поддержка regex, mpi, некоторые графические библиотеки), а также есть возможность отключать некоторые модули (я, например, собираю буст без поддержки питона, т.к. я им не пользуюсь). но по деталям надо читать доки на сами библиотеки и либо собирать их отдельно, либо включать необходимые опции в общую строку сборки.

да, вроде бы для некоторых библиотек для MSVC там прилагаются готовые 'солюшены' (я не мастер русскоязычного программирования!) для сборки, но я их не пробовала применять, так что советовать не буду.

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

"бла-бла-бла жаба - В ОТЛИЧИЕ ОТ ВЕНДЫ - центрирует контент батона когда батон с картинкой" (правда, тут вероятна опечатка - нет флексии s у глагола center. но не факт, что слово java имеет единственное число в английском).

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





"Для более удобного программирования QSqlDatabase является ценным классом."
(ну, можно также сказать "важным классом", но подчёркивается именно ценность его как ресурса).







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

instantiate - означает создавать конерктный элемент (или представитель) некоей абстрактной единицы данных (например, класса или структуры).

добрый день всем.
вот, может, кто сталкивался с подобной проблемой:
использую библиотеку thread boost'а для кроссплатформенного программирования. до недавего времени всё было замечательно, но тут возникло одно неприятное открытие:
оказалось, что буст почему-то ограничивает возможное количество потоков. а именно: после создания какого-то числа работающих потоков создание очередного потока проваливается с исключением boost::thread_resource_error и до уменьшения количества работающих потоков создание нового потока невозможно (каждый раз выпадает это исключение). причём это максимальное число потоков не зависит от реальных ресурсов системы, либо зависимость мне непонятна.
для проверки была написана маленькая программа - генератор потоков. потоки просто создаются, спят какое-то время, потом завершаются. потоки пустые, мелкие - то есть, памяти теоретически должно хватать. при этом задавалось разное время жизни потоков и разное количество потоков. результаты по подсчёту количества потоков всегда одинаковы, независимо от времени жизни каждого потока. это число каким-то загадочным образом зависит от машины, но, по видимому, не зависит от количества свободной памяти процесса и системы.
из опытов получилась такая странная картина: дома стоит машина под линюксом, 4 гектара памяти, своп вообще не используется - опытным путём получен предел в 382 потока, на работе машина под вендой, 1 гектар памяти, предел - 2024 потока. увеличение-уменьшение количества других процессов в системе никак не влияет.
откуда берутся такие странные цифры? может, есть возможность определить каким-то образом, как распределять ресурсы, чтобы потоков было больше? по работе необходима возможность одновоеменного выполнения очень большого и заранее неопределённого количества потоков в риал-тайме (пул потоков как бы не подходит по замыслу задачи). непонятно, откуда исходит это ограничение и как с ним бороться (если это вообще возможно).