[опять я] требуются разработчики в проект

AIDA64 занимается еще и сбором информации, кстати великолепно это делая, что свидетельствует о немаловажности этой функции для ее разработчиков.

Вашу мать... Какая разница, что там делает AIDA64 и через какое место. Ты понимаешь, что программы, отвечающие на вопросы «какое железо стоит в этом ящике и что оно умеет?» и «какая производительность у этого железа в попугаях?» — это принципиально разные программы? Объединяет их только то, что второй можно подсовывать список оборудования из первой.

Это не ответ.

Разве не здорово узнать список всего-всего и что оно умеет, и тут же, если надо, проверить производительность этого всего-всего? Хотя, может быть я не прав. Мне просто Everest понравился, я решил такое-же запилить, но под *nix-системы и под GPL.

Здорово. И я уже второй раз пытаюсь тебе объяснить, как этос делать правильно. В прошлом треде ты не понял. Вижу, что и в этом не поймёшь.

Спасибо большое! Так понятно. Идея хороша. Я так и сделаю. А база данных зачем?

А база данных зачем?

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

Тогда понятно. Признаться честно, очень хочется все самому написать. Синдром Поттеринга, что ли.

А что, если все уровни ниже управляющей прослойки выполнить в виде библиотек?

И в этот момент мы возвращаемся к тому, с чего начали:

и меня отправили переписывать его с учетом разделения на две части (ядро, которое выводит информацию в консоль и гуй, который ее парсит)

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

Перечислитель устройств имеет смысл как консольная утилита. Бенчмаркинг имеет смысл как консольная утилита. Обвязка, их объединяющая, не имеет отдельного смысла. Поэтому она будет с гуём в одном процессе. Итого, 3 программы.

за время работы над программой я возненавидел парсинг

xml тебе в помощь.

Консольные программы выводят инфу в формате XML? Нет, к сожалению, не вариант. Мое творение должно выдавать читабельный вывод даже без гуя.

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

я возненавидел парсинг

Учи перл :)

Мысль. Еще подумаю. Мы несколько затянули с полемикой, а работа над программой не ждет. Подождем, вдруг в тред заглянет еще кто-нибудь. Вон, сейчас snefjyent багов поймал - на его x64 моя поделка глючит (у меня же нет 64-битного проца, не тестировал). Вдруг еще кто подтянется и пойдем твои идеи воплощать. А я пока возможность настройки добавлю.

Кстати да. Для программы отлично подходят Perl/Ruby/Python. Но никак не Си. ТС ССЗБ.

А поддержка gtk3 у перла есть?

А pygobject3 может XML-формы загружать(GtkBuilder)? Гугл молчит.

Посмотри сорцы утилиты catfish. Она на питоне и грузит gtk морду из glade-файла.

Эпическая сила, а мемликов-то сколько!

Второй вопрос: glib не используется по религиозным соображениям? Иначе странно как-то: писать прогу на gtk, но не использовать glib.

Имеется. https://metacpan.org/module/Gtk3

А у кого она есть? Ты завязываешься на жтк3, но где твою программу можно будет запустить? Есть куча дистров в которых жтк2 есть, а жтк3 нету. И куча старых компов, которые не будут обновлять софт ради номера версии. Им хватает функционала. И для них твоя прога будет... доступной?

имхо:

для решения поставленной задачи уже есть инструменты - lshw, lspci, lsusb и пр. Если задача состоит в реализации гуя - то нужно сосредоточится на гуе, и использовать уже готовые, отлаженные, проверенные на разных платформах инструменты. Я бы как начинающий программист начинающему программисту посоветовал все же еще раз почитать про ООП и понять суть объектного подхода к программированию. Так значительно проще конструировать программы :) Затраченное время на изучение принесет больше дивидендов, чем педалирование кода с имеющимися знаниями, а затем его постепенное улучшение.

Ты завязываешься на жтк3, но где твою программу можно будет запустить? Есть куча дистров в которых жтк2 есть, а жтк3 нету. И куча старых компов, которые не будут обновлять софт ради номера версии. Им хватает функционала. И для них твоя прога будет... доступной?

Пока он её напишет, сменится еще по нескольку релизов в каждом дистрибутиве. Всё в порядке.

Мужик, не обижайся, но это таки говнокод.

1. Память течёт ручьями.

2.

source_str[strlen (source_str) - 1] = '\0';

3.

/* Functions below are private functions of parse.c file. They are should not
be  used in other parts of hardinform-gui!!! */

1. Проверю 2. Удаление символа конца строки 3. Это как?

теперь я вообще в растерянности. писать бэкенд, не писать...

> static.

3. Это как?

facepalm.mkv

2. Удаление символа конца строки

Неа

я знаю, что дает его использование по отношению к переменным, но как он ограничивает использование функции?

А как надо? Работает же

но как он ограничивает использование функции?

http://www.google.ru/search?q=static function

Первая же ссылка.

А как надо? Работает же

Ну посмотри в дебагере или выведи на печать, что содержится в

source_str[strlen (source_str) - 1]

Удаление символа конца строки

Со строкой нулевой длины получится очень мило.

$1 = 10 '\n'

Что не так?

А, ну если вы об этом... if (source_str) {source_str[strlen (source_str) - 1];} ?

Это не проверка на строку нулевой длины.

if (!strlen (source_str)) { source_str[strlen (source_str) - 1]; }? Вроде так. 0 == false, должно работать.

Опять ошибка.

if (!(strlen (source_str) == 0))?

Это ж надо было условие if (*source_str) так извратить...

Что не так?

Нет, всё правильно. Это меня переклинило. Извини.

талант не пропьешь

Простые переменные переписал, а итераторы то чего забыл?

void print_users_info (data* user_data)
{
 GtkTreeIter* user = (GtkTreeIter*) calloc (1, sizeof (GtkTreeIter));
    GtkTreeIter* uid = (GtkTreeIter*) calloc (1, sizeof (GtkTreeIter));
    GtkTreeIter* gid = (GtkTreeIter*) calloc (1, sizeof (GtkTreeIter));
    GtkTreeIter* home_dir = (GtkTreeIter*) calloc (1, sizeof (GtkTreeIter));
    GtkTreeIter* shell = (GtkTreeIter*) calloc (1, sizeof (GtkTreeIter));
    GtkTreeIter* comment = (GtkTreeIter*) calloc (1, sizeof (GtkTreeIter));
...
}

виноват, щас сделаю

Кстати, если ТС так усиленно юзает кучу, мог бы макрос уже сделать что ли:

#define ALLOC(type, name) type* name = (type*) calloc (1, sizeof (type))

Так я ничего против не имею. Автору поста сказал то же самое

Это я на всякий случай.

Ну, думаю на будущее такой макрос ему пригодится )

все, пофиксил, закоммитил