есть ли хоть одна причина усложнять себе жизнь?

т.е. вы тоже за plain c?

Qt же :)

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

На с++ и, по желанию, Qt.

[offtop] Что-где-когда

Кто угадает, что я об этом думаю? ☺

зачем мучатся. То есть qt

[offtop] Что-где-когда

Кто угадает, что я об этом думаю? ☺

[vanga]Plain C[/vanga]

Тогда plain c.

c++/Qt or c++/stl/boost for hard guys :)

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

консольную

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

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

Или библиотека экспортирует C символы, а ты будешь делать dlopen?

Да.

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

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

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

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

чистый Ц. инфа 146%

Правильно!

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

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

Аргумент в пользу использования Qt.

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

А нафига вам эти кути дрянные сдались? Есть же GTK!

Библиотека, консольное приложение, да, воистину, gtk там и не хватало. :)

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

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

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

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

Аргумент в пользу использования Qt

скорость разработки и качество кода

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

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

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

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

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

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

#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");

Хотя, re2 уже C++ либа.

это не похоже на однострочник

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

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

Вот так и получаем говнософт, когда из-за пары функций тащат Qt/glib/подставить нужное.

С.

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

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

И чего там такого хорошего?

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

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

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

Это unix way.

И это с четырьмя звёздами. Не позорься тут лучше.

Решил писать на Qt.

Решил??? Я думал что ты уже вчера по полной начал

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

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

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

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

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

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

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

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

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

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

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

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