LINUX.ORG.RU

Нужна помощь в подборке инструментов/библоиотек


0

0

Ищу инструменты для реализации следующей задачи (смысл описан http://www.linux.org.ru/jump-message.jsp?msgid=4513156&cid=4513366, для Ъ кратко ниже):

Демон. периодически (раз в минуту, час, год) запускает определённое событие, после этого общается со сторонней библиотекой (она отвечает за обработку события), забирает оттуда данные и пишет в свой кеш. Клиент через dbus запрашивает эти данные, может попросить запустить то самое определённое событие. Демон имеет свои настройки и хранит их в файле. Надо их читать/писать. Платформа - GNU/Linux, язык (желательно C++, можно C).

Для Ъ - демон реализован мной на Qt, хочется переписать его без. Плотно программированием занялся недавно, поэтому есть некие проблемы с выбором инструментов.

Пока что нашёл:
libconfig - для чтения/записи конфигурационных файлов;
libdbusc++ - C++ биндинги для dbus.

для периодического вызова функций попытался использовать boost::asio, но для
совместной работы с libdbusc++ придётся разносить их по разным потокам, ибо для работы у каждого свой eventloop.

Для обмена данных между тредами нашёл libSigCX - но там тоже какой-то свой eventloop, и боюсь, как бы мне не попасть в рекурсию в попытке как-то от них (eventloop'ов) избавиться.

Порылся в документации glib, но так и не нашёл там ничего про таймеры (GTimer, как я понял - отсчитывает время с момента своего старта).

Какие инструменты посоветуете для реализации проекта?

>Порылся в документации glib, но так и не нашёл там ничего про таймеры (GTimer, как я понял - отсчитывает время с момента своего старта).

Если использовать GLib, то может посмотреть в сторону g_timeout_add (). Или я не прав?

pathfinder ★★★ ()
Ответ на: комментарий от archimag

Re: Нужна помощь в подборке инструментов/библоиотек

а зачем common lisp?

t184256 ★★★★★ ()
Ответ на: комментарий от pathfinder

Топикстартер ясно сказал:

Платформа - GNU/Linux, язык (желательно C++, можно C).

pathfinder ★★★ ()
Ответ на: комментарий от pathfinder

Топикстартер ясно сказал:

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

mv ★★★★★ ()
Ответ на: комментарий от mv

Я не хочу никакой паровоз, это неправильное у вас ощущение.

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

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

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

Unnamed_Hero ★★★ ()
Ответ на: комментарий от Unnamed_Hero

Юзай какую-нибудь жирную библиотеку, где всё есть, и всё работает друг с другом. Умеешь qt - пиши на qt. Хочешь boost - юзай boost. Брать в плюсовом миру по биту, имхо, моветон.

Если гонишься за размером, то цпп - не идеальный выбор.

mv ★★★★★ ()
Ответ на: комментарий от mv

> Юзай какую-нибудь жирную библиотеку, где всё есть, и всё работает друг с другом. Умеешь qt - пиши на qt. Хочешь boost - юзай boost. Брать в плюсовом миру по биту, имхо, моветон.

если программы на лиспе «едят» в 20 раз больше памяти чем на С++ - то не стоит компенсировать это самовнушением, что в С++ надо обязательно юзать жирные библиотеки ;)

lester ★★★★ ()
Ответ на: комментарий от mv

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

Если не трудно, поясни - чем в плане «размера» цпп будет уступать?

pathfinder ★★★ ()
Ответ на: комментарий от lester

если программы на лиспе «едят» в 20 раз больше памяти чем на С++ - то не стоит компенсировать это самовнушением, что в С++ надо обязательно юзать жирные библиотеки ;)

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

mv ★★★★★ ()
Ответ на: комментарий от pathfinder

Если не трудно, поясни - чем в плане «размера» цпп будет уступать?

В порядке троллинга а-ля «перл лучше лиспа на примере однострочника» из соседнего треда:

#include <stdio.h>

int main(int argc, char* argv[])
{
	printf("Hello world!\n");
	return 0;
}
$ gcc -o hello_c hello.c
$ size hello_c
   text    data     bss     dec     hex filename
   1156     492      16    1664     680 hello_c
#include <iostream>

int main(int argc, char* argv[])
{
	std::cout << "Hello world!" << std::endl;
	return 0;
}
$ g++ -o hello_cpp hello.cpp
$ size hello_cpp
   text    data     bss     dec     hex filename
   2209     596     296    3101     c1d hello_cpp
mv ★★★★★ ()
Ответ на: комментарий от mv

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

меня почему-то не очень беспокоят особенности внутренней реализации используемых библиотек, если у них удобный API и работают они стабильно

lester ★★★★ ()
Ответ на: комментарий от mv

> В порядке троллинга а-ля «перл лучше лиспа на примере однострочника» из соседнего треда:

g++ -o hello_c hello.c

ы? :)

lester ★★★★ ()
Ответ на: комментарий от lester

ы? :)

$ g++ -o hello_bastard hello.c
$ size hello_bastard 
   text    data     bss     dec     hex filename
   1411     548      16    1975     7b7 hello_bastard

Кресты всё только портят.

mv ★★★★★ ()

Очень дельный и добрый совет

Не заморачивайся и пиши на Qt или GLib. И там и там все есть. Написал на Qt - и хорошо, будет нормальный софт, не съезжай на те поделки. В Linux проблем нет и количество зависимостей ничего не значит. А вот на винде и на других системах эти библиотеки идут в удобных инсталлерах или архивах. С теми поделками можешь намучаться, когда будешь портировать

vertexua ★★★☆☆ ()
Ответ на: комментарий от lester

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

К тому же, по скорости примерно одинаково получилось, а вот памяти кресты стабильно в 2 раза больше жрут.

mv ★★★★★ ()

Посмотри еще libconfuse это несколько более навороченный вариант libconfig.

Grindz ()
Ответ на: комментарий от mv

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

но мы то на ЛОР а не в культурном обществе ;)

К тому же, по скорости примерно одинаково получилось, а вот памяти кресты стабильно в 2 раза больше жрут.


ы? :)

http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=icpp&lang2=gcc

lester ★★★★ ()
Ответ на: комментарий от lester

ы? :)

Неправославная проприетарщина.

mv ★★★★★ ()
Ответ на: комментарий от mv

> Неправославная проприетарщина.

и это говорит лиспер? вы ж чуть что - так сразу в пример проприетарщину на лиспе показывать бросаетесь ;)

lester ★★★★ ()
Ответ на: комментарий от lester

и это говорит лиспер? вы ж чуть что - так сразу в пример проприетарщину на лиспе показывать бросаетесь ;)

Существование Лиспа не служит оправданием для жирных плюсовых секций text.

mv ★★★★★ ()
Ответ на: комментарий от mv

> Существование Лиспа не служит оправданием для жирных плюсовых секций text.

я уже привел ссылку - вы кажется путаете отдельную реализацию и язык ;)

lester ★★★★ ()
Ответ на: комментарий от lester

> Существование Лиспа не служит оправданием для жирных плюсовых секций text.

я уже привел ссылку - вы кажется путаете отдельную реализацию и язык ;)

По приведённой ссылке из 12 тестов у Intel C++ в 10 бОльше размер .text, чем у GNU C.

mv ★★★★★ ()
Ответ на: комментарий от mv

> По приведённой ссылке из 12 тестов у Intel C++ в 10 бОльше размер .text, чем у GNU C.

это ты про размер кода в байтах?

lester ★★★★ ()
Ответ на: комментарий от lester

фшоке

это ты про размер кода в байтах?

Ты не знаешь, что такое .text? o_O

mv ★★★★★ ()
Ответ на: фшоке от mv

> Ты не знаешь, что такое .text? o_O

по-моему наоборот - инчае как объяснить, что ты размер исходного кода на С++ считаешь развнозначным размеру .text

lester ★★★★ ()
Ответ на: комментарий от lester

по-моему наоборот - инчае как объяснить, что ты размер исходного кода на С++ считаешь развнозначным размеру .text

Я сейчас немножко на elf зациклен, на code size неадекватно реагирую.

mv ★★★★★ ()
Ответ на: комментарий от mv

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

anonymous ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.