LINUX.ORG.RU

Qt or plain C


0

2

Привет. Нужно написать небольшую консольную утилитку. Утилитка должна использовать библиотеку для обработки некоторых данных, библиотека написана на Qt. На чём лучше написать утилитку, на Qt или на чистом С.

★★★★★

Ответ на: комментарий от namezys

Так просто ради интереса спросил =)
Просто GUI интерфейс на Qt уже есть, но нужно ещё консольная часть.

UVV ★★★★★ ()

Если qt уже есть, то какие вообще вопросы могут быть? От Qt разумно отказываться, когда размер приложения на порядок меньше размера библиотеки.

note173 ★★★★★ ()

консольную

Раз Qt, то делай гуёвую тогда.

CYB3R ★★★★★ ()

Или я не понял вопроса, или как ты напишешь программу на С, которая не использует Qt, и при этом будет использовать бибилотеку на Qt? O_O Или библиотека экспортирует C символы, а ты будешь делать dlopen?

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

Если Qt сэкономит >= 50% времени, то я бы использовал Qt. Иначе на Си.

alex_custov ★★★★★ ()

Если оно и так зависит от либы зависящей от Qt (т.е. кути в любом случае должны быть установлены), то смысл мучится?

fat_angel ★★★★★ ()

Если Qt нужно - на Qt. Иначе - на plain C++ :)

Deleted ()

если делать быстро - то Qt. Если правильно, то ещё и обёртку на чистом С над библиотекой.

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

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

то, что qt позволит увеличит скорость разработки и качество кода - уже не аргумент ?

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

Странно, еще же должны переписать библиотеку на Plain C, чтобы вообще этот Qt/С++ выкинуть. Вот тогда - правильно.

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

А, иксы не нужны...

Тогда нахрена туда дермокути совать?

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

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

Ну, если отбросить фанатизм, qt же не только гуй, а еще хороший фреймворк на все остальное. Причем кросс.

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

Ты не правильно понял мое сообщение. Я привел возможный вариант, когда от использования qt можно отказаться. Аргументы в пользу использования тоже есть.

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

Все проще, чем в кутях этих дурацких ковыряться

Напиши-ка мне на Си однострочник наподобие

if(QRegExp("\\$[0-9a-cA-C]{2,6}([0-9]+)").exactMatch(str))
    qDebug("Matches");

Мм? И таких примеров в Qt полно, и иксы можно не использовать, QtCore не зависит от иксов.

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

Напиши-ка мне на Си однострочник наподобие

#include <pcreposix.h>

...

int exact_match(const char *pattern, const char *str)
{
    regex_t re;

    if (regcomp(&re, pattern, 0) != 0)
        return -1;

    if (regexec(&re, str, 0, NULL, 0) != 0) {
        regfree(&re);
        return 0;
    }

    regfree(&re);
    return 1;
}

...

    if (exact_match("\\$[0-9a-cA-C]{2,6}([0-9]+)", str) == 1)
        fprintf(stderr, "Matches\n");
quasimoto ★★★★ ()
Ответ на: комментарий от alex_custov

Просто определил функцию exact_match (не знаю, есть ли уже в pcre подобная), в использовании получается то же самое, что и с методом exactMatch.

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

речь о том, что если очень постараться, то можно все функции Qt определить самому через вторые библиотеки. Только это уже не похоже на «в кутях этих дурацких ковыряться», а скорее наоборот.

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

софт размером больше чем десять строк будет завязан на сторонние библиотеки почти наверняка. А если ты не хочешь писать вторую glib и Qt - то будешь линковаться с ними, не вижу никакх проблем. Это unix way.

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

ЛОЛШТО. Намного чаще из-за какой-то боязни подключить то же Qt/Glib и использовать готовые проверенные мейнстримные решения, начинают либо подключать стоппиццот каких-то мелких библиотек, которые уже через год забрасываются и не поддерживаются в свежих ветках дистрибутивов, либо (что ещё хуже) пишутся свои собственные реализации, которые, конечно же, компактнее, глобальней и надежней и в которых потом тоннами вылавливаются ошибки.

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

Во-первых, регулярками я не пользуюсь. Во-вторых, если бы и пользовался, все там есть (regcomp и т.п. из regex.h). И выполняться оно будет отнюдь не медленнее.

Не надо думать, что С такой тупой язык.

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

Просто смирись. Qt как фреймворк очень хорош.

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

Начал то я вчера, просто всем сказал сегодня =)

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

Если ты решил помериться звёздами, то у тебя их пять, а ты рассказываешь, что NIH синдром - это хорошо.

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

Тогда нахрена туда дермокути совать?

Не огорчай панду, Qt хороший фреймворк для многого, не только для гуйни.

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

Во-вторых, если бы и пользовался, все там есть (regcomp и т.п. из regex.h)

Если мне не изменяет память, то regex - это POSIX, а не сам С, и соответственно, не гарантировано, что он будет на других платформах.

Не надо думать, что С такой тупой язык.

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

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

regex - это POSIX, а не сам С, и соответственно, не гарантировано, что он будет на других платформах.

Ну здрассьте. В линуксе он есть везде, а на остальные - насрать.

В больших проектах ты наверняка будешь использовать сторонние библиотеки, если, конечно, не приболел NIH.

Я использую некоторое количество библиотек. Но, к сожалению, много чего просто нет (либо есть, но не так, как надо; либо есть, но платно) - приходится делать самому. Но мне это нравится.

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