Разыскивается легкий портабельный фреймворк, инкапсулирующий работу с файлами, процессами, потоками, пайпами, синхронизацией. ACE и Poco смотрел, не понравилось — очень много лишнего, ну и банально грязный код .
Кто что может посоветовать по поводу — было бы очень интересно узнать, может, есть что-то легковесное и приятное в общении. Спасибо!
Здравствуйте, Andrew S, Вы писали: AS>Разыскивается легкий портабельный фреймворк, инкапсулирующий работу с файлами, процессами, потоками, пайпами, синхронизацией. ACE и Poco смотрел, не понравилось — очень много лишнего, ну и банально грязный код .
python я серъезно, у него в стандартной поставке всё это есть, он легкий как пууух + много куда портирован. Вызывать можно хоть из сишного кода.
Re[2]: C/C++ file/process/thread api l/w framework
AS>>Разыскивается легкий портабельный фреймворк, инкапсулирующий работу с файлами, процессами, потоками, пайпами, синхронизацией. ACE и Poco смотрел, не понравилось — очень много лишнего, ну и банально грязный код . D>python я серъезно, у него в стандартной поставке всё это есть, он легкий как пууух + много куда портирован. Вызывать можно хоть из сишного кода.
Уважаемый, вопрос задан вполне конкретно. Флеймить не надо
Посмотрел вот еще QT, код, конечно, приличнее, но (на мой взгляд) много лишнего, по-крайней мере, в вин32 реализации. Хочется, чтобы результат после компиляции под конкретную платформу был примерно идентичен аналогичному коду на голом апи данной платформы...
Здравствуйте, Andrew S, Вы писали:
AS>Посмотрел вот еще QT, код, конечно, приличнее, но (на мой взгляд) много лишнего, по-крайней мере, в вин32 реализации. Хочется, чтобы результат после компиляции под конкретную платформу был примерно идентичен аналогичному коду на голом апи данной платформы...
Попробуйте ACE в режиме статической библиотеки.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, Andrew S, Вы писали:
AS>Всем привет.
AS>Разыскивается легкий портабельный фреймворк, инкапсулирующий работу с файлами, процессами, потоками, пайпами, синхронизацией. ACE и Poco смотрел, не понравилось — очень много лишнего, ну и банально грязный код .
AS>Кто что может посоветовать по поводу — было бы очень интересно узнать, может, есть что-то легковесное и приятное в общении. Спасибо!
Я в свое время выбирал между ACE, Apache APR, библиотки из Mozila (Netscape Portable Library, кажется), wxBase (подложка из wxWidgets), gtk (без GUI), GNU CommonCpp.
Выбрал ACE, поскольку работает, развивается и с лицензией нет проблем.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[4]: C/C++ file/process/thread api l/w framework
AS>>Посмотрел вот еще QT, код, конечно, приличнее, но (на мой взгляд) много лишнего, по-крайней мере, в вин32 реализации. Хочется, чтобы результат после компиляции под конкретную платформу был примерно идентичен аналогичному коду на голом апи данной платформы...
E>Попробуйте ACE в режиме статической библиотеки.
А толку? Достаточно посмотреть на ACE_Process, чтобы понять, какой это отстой (извиняюсь, но других слов этой поделке я не нахожу).
А то, что нормальных interlocked операций там нет? Есть какие-то идиотические Atomic переменные, которые даже не умеют InterlockedExchange, не говоря уж о большем... в общем, ощущение, что писали эту библиотеку либо студенты, либо ... врочем, без либо. Студенты. В топку.
Поко в разы приятнее унутре... вот только все-равно многих нужных фич нет
AS>>Всем привет.
AS>>Разыскивается легкий портабельный фреймворк, инкапсулирующий работу с файлами, процессами, потоками, пайпами, синхронизацией. ACE и Poco смотрел, не понравилось — очень много лишнего, ну и банально грязный код .
AS>>Кто что может посоветовать по поводу — было бы очень интересно узнать, может, есть что-то легковесное и приятное в общении. Спасибо!
E>Посмотрите здесь: http://directory.google.com/Top/Computers/Programming/Languages/C%2B%2B/Class_Libraries/ -- список всякой всячены. Но очень много проектов, которые уже заброшены и не развиваются.
E>Я в свое время выбирал между ACE, Apache APR, библиотки из Mozila (Netscape Portable Library, кажется), wxBase (подложка из wxWidgets), gtk (без GUI), GNU CommonCpp.
Apache apr неплох, на самом деле... вполне себе приятная реализация, вот только нет некоторых нужных возможностей, ну и pure C интерфейс, конечно, напряг. GNU Common CPP тоже ничего, но лицензия, и опять же нет некоторых нужных возможностей, да и в целом — мало контроля над фреймворком.
Остальное посмотрел, совсем не впечатлило. Может, еще какие есть либы?
E>Выбрал ACE, поскольку работает, развивается и с лицензией нет проблем.
Да не работает она... если я вижу просто при первом просмотре баги/недостатки — оно должно сразу отправлятся в dev/null. А после тестов производительности ТАО... в общем, не знаю. У меня осталось очень скверное ощущение от ACE/TAO.
Здравствуйте, Andrew S, Вы писали:
AS>Кто что может посоветовать по поводу — было бы очень интересно узнать, может, есть что-то легковесное и приятное в общении. Спасибо!
task.h — mutex, thread со товарищи
file.h — понятно.
mmapfile.h — понятно.
sockio.h — sockets + поддержка local sockets на Windows (interprocess communication)
просто и красиво написано, рекомендую.
Re[2]: C/C++ file/process/thread api l/w framework
AS>>Кто что может посоветовать по поводу — было бы очень интересно узнать, может, есть что-то легковесное и приятное в общении. Спасибо!
CS>System Abstraction Layer (SAL) от Кости Книжника.
CS>http://www.garret.ru/~knizhnik/SAL/ReadMe.htm
CS>task.h — mutex, thread со товарищи CS>file.h — понятно. CS>mmapfile.h — понятно. CS>sockio.h — sockets + поддержка local sockets на Windows (interprocess communication)
CS>просто и красиво написано, рекомендую.
Посмотрел, совсем не впечатлило.
1. Нет interlocked.
2. Очень бедные возможности управления потоками
3. Нет сложных объектов синхронизации — типа rw мьютекса и т.п. Да и простые объекты тоже не наличиствуют.
4. Нет поддержки процессов, редиректа инпута\оутпута.
В общем, что-то у меня ощущение, что эффективный portable бывает только в сказках
В принципе, можно докрутить апачевскую либу, но это, конечно, совсем крайний вариант — ведь тогда это все придется синхронизировать с апдейтами...
Здравствуйте, Andrew S, Вы писали:
CS>>просто и красиво написано, рекомендую.
AS>Посмотрел, совсем не впечатлило. AS>1. Нет interlocked. AS>2. Очень бедные возможности управления потоками AS>3. Нет сложных объектов синхронизации — типа rw мьютекса и т.п. Да и простые объекты тоже не наличиствуют. AS>4. Нет поддержки процессов, редиректа инпута\оутпута.
Ну дык ты ж просил l/w framework.
AS>В общем, что-то у меня ощущение, что эффективный portable бывает только в сказках
Каждый себе пишет сам и под свои нужды по всей видимости.
AS>В принципе, можно докрутить апачевскую либу, но это, конечно, совсем крайний вариант — ведь тогда это все придется синхронизировать с апдейтами...
Имхо APR по твоим запрсам это оно. Но не сильно l/w.
Re[3]: C/C++ file/process/thread api l/w framework
Здравствуйте, Andrew S, Вы писали:
AS>В общем, что-то у меня ощущение, что эффективный portable бывает только в сказках AS>В принципе, можно докрутить апачевскую либу, но это, конечно, совсем крайний вариант — ведь тогда это все придется синхронизировать с апдейтами...
Если собершься что-то свое делать то вот три статьи представляются полезными:
Здравствуйте, Andrew S, Вы писали:
AS>>>Посмотрел вот еще QT, код, конечно, приличнее, но (на мой взгляд) много лишнего, по-крайней мере, в вин32 реализации. Хочется, чтобы результат после компиляции под конкретную платформу был примерно идентичен аналогичному коду на голом апи данной платформы...
E>>Попробуйте ACE в режиме статической библиотеки.
AS>А толку? Достаточно посмотреть на ACE_Process, чтобы понять, какой это отстой (извиняюсь, но других слов этой поделке я не нахожу).
А вам вообще для каких платформ поддержка нужна? Если только Win + Linux, то проще самому написать. Или взять D-шную библиотеку Tango и портировать оттуда аналогичный класс под C++.
Сильно сомневаюсь, что кто-нибудь сделал более функциональный класс для работы с процессами, чем ACE_Process для такого же количества платформ. Да еще отдавал бы его бесплатно.
AS>А то, что нормальных interlocked операций там нет? Есть какие-то идиотические Atomic переменные, которые даже не умеют InterlockedExchange, не говоря уж о большем...
В коде ACE_Atomic_Op для long-а InterlockedExchange как раз используется.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[3]: C/C++ file/process/thread api l/w framework
Здравствуйте, Andrew S, Вы писали:
AS>Apache apr неплох, на самом деле... вполне себе приятная реализация, вот только нет некоторых нужных возможностей, ну и pure C интерфейс, конечно, напряг. GNU Common CPP тоже ничего, но лицензия, и опять же нет некоторых нужных возможностей, да и в целом — мало контроля над фреймворком.
AS>Остальное посмотрел, совсем не впечатлило. Может, еще какие есть либы?
Есть еще PTypes. Можно еще глянуть GUI библиотеки вроде FOX Toolkit и Fltk, какие-то средства для синхронизации и многопоточности там должны быть.
Остальные претенденты из списка Google.Directory либо платные (вроде Source Pro C++ от Rogue Wave), либо уже прекратили свое развитие.
Но, по моим впечатлениям, реально сейчас развиваются только ACE, Poco, Boost, wxWidgets, Qt, Apr (это это чистый C).
E>>Выбрал ACE, поскольку работает, развивается и с лицензией нет проблем.
AS>Да не работает она...
а мужики-то и не знают
AS>если я вижу просто при первом просмотре баги/недостатки — оно должно сразу отправлятся в dev/null.
У ACE есть интересная особенность -- ее сложно оценить с первого раза. Мне потребовалось больше года.
AS>А после тестов производительности ТАО... в общем, не знаю. У меня осталось очень скверное ощущение от ACE/TAO.
TAO -- это вообще-то CORBA. Вам что, CORBA нужна была?
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[6]: C/C++ file/process/thread api l/w framework
AS>>>>Посмотрел вот еще QT, код, конечно, приличнее, но (на мой взгляд) много лишнего, по-крайней мере, в вин32 реализации. Хочется, чтобы результат после компиляции под конкретную платформу был примерно идентичен аналогичному коду на голом апи данной платформы...
E>>>Попробуйте ACE в режиме статической библиотеки.
AS>>А толку? Достаточно посмотреть на ACE_Process, чтобы понять, какой это отстой (извиняюсь, но других слов этой поделке я не нахожу).
E>А вам вообще для каких платформ поддержка нужна? Если только Win + Linux, то проще самому написать. Или взять D-шную библиотеку Tango и портировать оттуда аналогичный класс под C++.
E>Сильно сомневаюсь, что кто-нибудь сделал более функциональный класс для работы с процессами, чем ACE_Process для такого же количества платформ. Да еще отдавал бы его бесплатно.
AS>>А то, что нормальных interlocked операций там нет? Есть какие-то идиотические Atomic переменные, которые даже не умеют InterlockedExchange, не говоря уж о большем...
E> В коде ACE_Atomic_Op для long-а InterlockedExchange как раз используется.
Как атомарно получить предыдущее значение переменной в этом случае? Ведь interlocked функции как раз и нужны для этого. В общем, кг/ам там...
AS>>Apache apr неплох, на самом деле... вполне себе приятная реализация, вот только нет некоторых нужных возможностей, ну и pure C интерфейс, конечно, напряг. GNU Common CPP тоже ничего, но лицензия, и опять же нет некоторых нужных возможностей, да и в целом — мало контроля над фреймворком.
AS>>Остальное посмотрел, совсем не впечатлило. Может, еще какие есть либы?
E>Есть еще PTypes. Можно еще глянуть GUI библиотеки вроде FOX Toolkit и Fltk, какие-то средства для синхронизации и многопоточности там должны быть.
E>Остальные претенденты из списка Google.Directory либо платные (вроде Source Pro C++ от Rogue Wave), либо уже прекратили свое развитие.
E>Но, по моим впечатлениям, реально сейчас развиваются только ACE, Poco, Boost, wxWidgets, Qt, Apr (это это чистый C).
E>>>Выбрал ACE, поскольку работает, развивается и с лицензией нет проблем.
AS>>Да не работает она...
E> а мужики-то и не знают
Ага, не знают. например, ожидание сокетных событий при помощи WFMO. И много другой вкуснятины, типа, дуплицирования и закрытия несуществующих хендлов — это код в стиле ACE. Впрочем, и poco на это тоже богат
AS>>если я вижу просто при первом просмотре баги/недостатки — оно должно сразу отправлятся в dev/null.
E>У ACE есть интересная особенность -- ее сложно оценить с первого раза. Мне потребовалось больше года.
А кто сказал, что я ее в первый раз вижу? Просто раньше эти части особо не нужны были, а вот сейчас посмотрел унутре оно как — и волосы реально дыбом встали...
AS>>А после тестов производительности ТАО... в общем, не знаю. У меня осталось очень скверное ощущение от ACE/TAO.
E>TAO -- это вообще-то CORBA. Вам что, CORBA нужна была?
Вообще то я знаю От ТАО мы отказались (омни орб куда как производительнее), выбрали ICE, но с ICE идет довольно бедный фреймворк, поэтому приходится искать что-то еще.
Здравствуйте, Andrew S, Вы писали:
AS>>>А то, что нормальных interlocked операций там нет? Есть какие-то идиотические Atomic переменные, которые даже не умеют InterlockedExchange, не говоря уж о большем...
E>> В коде ACE_Atomic_Op для long-а InterlockedExchange как раз используется.
AS>Как атомарно получить предыдущее значение переменной в этом случае? Ведь interlocked функции как раз и нужны для этого. В общем, кг/ам там...
Если у вас есть a и b, которые нужно обменять, то:
typedef ACE_Atomic_Op< ACE_Null_Mutex, long > AtomicLong;
AtomicLong a, b;
std::swap(a, b);
А вообще можно в ACE подкинуть реализацию метода swap для Atomic_Op, ведь это же OpenSource как-никак.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[5]: C/C++ file/process/thread api l/w framework
Здравствуйте, Andrew S, Вы писали:
AS>Ага, не знают. например, ожидание сокетных событий при помощи WFMO.
Это где? В ACE_WFMO_Reactor? Так там не только такой реактор есть.
Хотите асинхронности -- есть ACE_Proactor.
AS>Вообще то я знаю От ТАО мы отказались (омни орб куда как производительнее), выбрали ICE, но с ICE идет довольно бедный фреймворк, поэтому приходится искать что-то еще.
У меня есть впечатление, что в начале топика вы не очень точно озвучили требования к необходимому вам фреймворку.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[4]: C/C++ file/process/thread api l/w framework
Здравствуйте, eao197, Вы писали:
AS>>Остальное посмотрел, совсем не впечатлило. Может, еще какие есть либы?
E>Есть еще PTypes. Можно еще глянуть GUI библиотеки вроде FOX Toolkit и Fltk, какие-то средства для синхронизации и многопоточности там должны быть.
E>Остальные претенденты из списка Google.Directory либо платные (вроде Source Pro C++ от Rogue Wave), либо уже прекратили свое развитие.
E>Но, по моим впечатлениям, реально сейчас развиваются только ACE, Poco, Boost, wxWidgets, Qt, Apr (это это чистый C).
Забыл еще добавить одну библиотеку, которая продолжает развиваться: STLSoft. Только вот не знаю, насколько она функциональна в плане поддержки процессов и IPC.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[8]: C/C++ file/process/thread api l/w framework
AS>>>>А то, что нормальных interlocked операций там нет? Есть какие-то идиотические Atomic переменные, которые даже не умеют InterlockedExchange, не говоря уж о большем...
E>>> В коде ACE_Atomic_Op для long-а InterlockedExchange как раз используется.
AS>>Как атомарно получить предыдущее значение переменной в этом случае? Ведь interlocked функции как раз и нужны для этого. В общем, кг/ам там...
E>Если у вас есть a и b, которые нужно обменять, то: E>
E>typedef ACE_Atomic_Op< ACE_Null_Mutex, long > AtomicLong;
E>AtomicLong a, b;
E>std::swap(a, b);
E>
E>А вообще можно в ACE подкинуть реализацию метода swap для Atomic_Op, ведь это же OpenSource как-никак.
Мне нужен аналог операции InterlockedExchange — _атомарно_ поменять значение на новое и получить старое. Это базовая операция синхронизации и то, что в ACE это сделать стандартными средствами нельзя — просто отстой, на мой взгляд. Не может нормальная библиотека иметь такую лажу прямо на поверхности.
.
я серъезно, у него в стандартной поставке всё это есть, он легкий как пууух + много куда портирован. Вызывать можно хоть из сишного кода.
а мужики-то и не знают 
От ТАО мы отказались (омни орб куда как производительнее), выбрали ICE, но с ICE идет довольно бедный фреймворк, поэтому приходится искать что-то еще.
