Я хотел бы примкнуть к разработке какого нить c++ проекта..

есть, например я.

но только глупость это: "я присоединюсь".

найди того чего тебе не хватает и сделай,
вот и все.

да чё то самому ничё особого в голову не приходит, всё что только могло бы понадобиться почти есть... :)

и какой проект у вас? :)

доброго времени суток!

хэх.. работы на самом деле просто до !@# :)

> но только глупость это: "я присоединюсь".

Верно, это всего лишь слова... пустые слова. :)

Могу "ткнуть носом", так сказать, в работу, которая в самый раз для начинающего.

http://www.hostnotfound.it/kbilliards.php

Это, как вы уже догадались, линка на довольно забавный симулятор бильярда. Чего там действительно, на мой взгляд, не хватает, это модуля для игры по сети. Попробуйте :)

PS: Удачи

из тех проектов представителей, которых вы можете
найти здесь и о которых я слышал, и которые написаны на C++
это
1)KБелка - просмоторщик изображений для KDE. Сам автор
судя по постам сюда не очень большого ума человек и технологии
используемые в этом ПО очень странные для поставленное
задачи, но это мое ИМХО.

из того что требуется - это написание плагинов для чтения
разных форматов, автор в этом вопросе просил помощи

2)Просмоторщик книг (QBookShelf кажется так называется)
Автор этого приложения судя по вопросам на этом форуме,
вообще не умеет программировать на C++, так что ваша помощь
ему очень пригодится.

3)stardict без гноме. я некоторое время общался с автором этого приложения,
когда перегонял несколько словарей в формат stardict,
там есть несколько "фич запросов", которые автор не может воплотить
за неимением времени.

-------------------------------------

из того что мне бы было интересно сделать на вашем месте
4)поддержка многопоточной закачки в wget, выделение всей
его функциональности в библиотеку
5)правка пары багов в icewm.
вот этот баг меня особенно напрягает
http://sourceforge.net/tracker/index.php?func=detail&aid=1092593&grou...
icewm написан на довольно хорошем C++
6)ну и конечно всем большим проектам нужна помощь.
стоит сначала взять и пофиксить пару багов, а потом...
из таких проектов можно выделить:
OO, Firefox, KDE
Например, в OO можно заняться интегрированием aspell в него.

ЗЫ
из тех проектов участие в которых может тебе принести пользу
по-моему, это 3-6

>1)KБелка - просмоторщик изображений для KDE. Сам автор судя по постам сюда не очень большого ума человек и технологии используемые в этом ПО очень странные для поставленное задачи, но это мое ИМХО.

Если быть точным он предлагал кому-нибудь сделать аналог его программы под Gnome (подробности здесь: http://www.linux.org.ru/profile/_white/view-message.jsp?msgid=804122#810715)

лана, я гляну для начала в сторону wget может как нить ручки дойдут до icewm, хотя постоянно им не пользуюсь.... кстати вы в 3 пункте имели ввиду консольный stardict? может пока и его гляну...

>кстати вы в 3 пункте имели ввиду консольный stardict?

нет обычный,
см. архив новостей.

А зачем разрабатывать проекты? Это что-то сродни онанизму? Может лучше разрабатывать программные продукты?

>> технологии используемые в этом ПО очень странные для поставленное
задачи

может просветите, какие "странные" ?

>может просветите, какие "странные" ?

KDE библиотеки, хватило бы qt.
OpenGL

ну, KDE библиотеки странностями назвать нельзя. Нормальный навигатор без KFileIconView не построишь :(

OpenGL. Да. Согласен. Странное решение. Но меня категорически не устраивает то, как можно показывать/масштабировать изображения другими средствами (а назови хоть одно достойное). Про то, что зажимать Ctrl+'+', в таких программах, как ShowImg и Gwenview не стоит, я напоминать не буду ? :))

ShowImg один раз во время таких потуг вызвал перезагрузку Иксов.

P.S. Если бы был QPixBuf, я бы с радостью использовал его.

>>OpenGL

От кого: Thomas Beinicke <...@web.de>
Отправитель: ...@web.de
Дата: Mon, 21 Feb 2005 23:25:06 +0700
Кому: ksquirrel@tut.by
Тема: KSquirrel

Hi,
I just tested your program and I really like it. I was using GwenView before but yours is a bit FASTER I think so I would like to stick with it.
...<skipped>

посмотрел я kбелку.

1)нафига C интерфейс билиотеке, которую будет использовать C++ программа?
2)автор наверное не догадывается что функция C++
вида some_type f(); и функция C
some_type f(); это разные вещи
3)использование calloc.
Обнуление это не всегда праильные значения типа NULL и 0.0, да вообще
не проще ли воспозьоваться конструкором
4)asprintf - начерта его использовать его, страдает переносимость
5)sprintf а не snprintf
6)зачем-то приведение типа перед "some string", она и так const char*

вопрос автору в школе ушишься или уже в институт поступил?

это я просто по верхам посмотрел,
лень было внутрь лезть.

Молодец, много хорошего подметил.

1) И ЧТО ?!
2) да нет, догадываюсь. Также догадываюсь, что либы ты даже не компилил
3) malloc+memset - это способ для истинных гуру ?
5) где snprintf увидел ? Нет нигде.

>>вопрос автору в школе уШишься или уже в институт поступил?
аналогичный и тебе ?

Hello,

тебе сюда http://www.microsoft.com/careers/careerpath/technical/softwaredevelopment.mspx

>1) И ЧТО ?!

это называется ошибка проектирования

2)скомпилил и что?
почитай какую-нибудь конфиренцию по c/c++. как смешивать эти два языка

3)
> malloc+memset

ты читать умеешь?

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

> где snprintf увидел ? Нет нигде.

налицо проблеммы с чтением,
только перешел во второй класс?

вот именно что нету, а есть sprintf

>>это называется ошибка проектирования

Значит половина существующих просмотрщиков - плохо спроектирована. Напиши авторам на мыло и обвини их в некомпетентности.

>>присвоить NULL присвоить 0.0, т.к. забивание всего нулями не
всегда и не на всех платформах даст правильный результат

Вот только это забивание нулями ни на что в итоге не влияет. А cslloc используется для удобства.

>>налицо проблеммы с чтением,

Может у тебя проблемы с высказыванием мыслей ?
"sprintf а не snprintf" - твой пост, означающий что вместо snprintf нужно использовать sprintf.

> KDE библиотеки странностями назвать нельзя. Нормальный навигатор без >KFileIconView не построишь

да совсем совсем не построишь? :)

скачал, вроде работает,
1)только довольно дурацкий
интерфейс(нафига еще один Konqueror в системе),
в KDE команде вроде есть дизайнеры поговори с ними.

2)посомотрел код под давлением высказываний анонимуса -
да...

на будещее: любые вызовы системных функций должны проверятся на наличие
ошибки - от fread до malloc. Это не правило хорошего тона или что-то типа
этого. Просто если ты не хочешь чтобы твоя программа падала в неожиданных местах и твои пользователи говори вот это глюкалово.

>от только это забивание нулями ни на что в итоге не влияет.

да тогда почему malloc не использовать, процессорное время не жалко?

>Значит половина существующих просмотрщиков - плохо спроектирована.

ой, ой. Взрослые дяди так сделали - значит все правильно.

Половина из них только на C и пишут, поэтому у них и интерфейс на C.

На дворе уже какой век? А вы все с malloc возитесь - сочуствую :)

Вот выдержка из:
http://russian.joelonsoftware.com/Articles/HowMicrosoftLosttheWaronA.html

В начале девяностых многие из нас полагали, что главная битва произойдет между процедурным и объектно-ориентированным стилем программирования, и воспринимали объектно-ориентированное программирование как средство резкого повышения продуктивности программистов. Я тоже так думал. Некоторые до сих пор так думают. Получается, мы ошибались. Объектно-ориентированное программирование прикольная штука, но не повышает продуктивность, как это обещалось. Реальное и значительное повышение производительности мы получили от программирования на языках, автоматически управляющих памятью вместо вас. Это может быть подсчет ссылок или &#171;сборка мусора&#187;, это может быть Java, Lisp, Perl, Smalltalk, .NET или любой язык написания скриптов. Если ваш язык программирования позволяет выделять кусок памяти без раздумий о его последующем освобождении, то вы используете язык с управляемой памятью, и вы будете значительно эффективней программиста, использующего язык, где управление памятью производится в явном виде. Всякий раз, когда вы слышите чье-то хвастовство о том, насколько продуктивен их язык, вероятно, большую часть продуктивности они достигают за счет автоматического управления памятью, даже если не признаются в этом.

Запомните это слово "эффективней" раз и навсегда.

>Запомните это слово "эффективней" раз и навсегда.

да автор этой статьи, являющийся истиным поклоником VB,
представляет собой несомненый авторитет.

кого интересует мнение америкоского кодера, который и писать то тольком не умеет.

Как вы могли заметить, автор не совсем кодер, а владелец собственной компании. Его мысли очень точно описывают текущую ситуацию.

>к вы могли заметить, автор не совсем кодер

ага, вся компания состоит из одного его.

>Его мысли очень точно описывают текущую ситуацию.

описывают, но не оценивают.

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

поэтом приходится нанимать "обезьян" стучать по клавишам - типа этого автора.

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

потому что им не хватает мозгов вызвать free после malloc,
и не хватает мозгов обойти эти ограничения.

например недавно закончил проект на C++, и среди полутора милионов
строчек только пару раз встречался new и delete.

Он есть, но ты его не видишь (C)

благодаря разумной организации кода.

Самое печальное, что самый зачуханный индиец или китаец напишет то, что ты пишешь на C/C++ в разы быстрее на той-же Java или .NET и получит свои
килобаксы, в то время как ты будешь думать над "разумной организацией кода с new,delete,malloc,free" - это реальная жизнь.

>>и твои пользователи говори вот это глюкалово

странно, они говорят, что она стабильна.

anonymous (*) (25.02.2005 13:44:29):

> это реальная жизнь.

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

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

Эффетивность языков со сборщиком мусора очевидна и это позволяет меньше отвлекаться на детали, тем самым освобождая время на продумывание основного алгоритма. На C же быстрее писать чем на Asm-е - тут нет вопросов? :) Сборщики мусора - это просто новый уровень абстракции.

anonymous (*) (25.02.2005 16:39:56):

>Эффетивность языков со сборщиком мусора очевидна и это позволяет меньше отвлекаться на детали, тем самым освобождая время на продумывание основного алгоритма.

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

Мы все и так знаем, что ты - ламер. Мог бы не утруждать себя очередными доказательствами сего прискорбного факта.

2anonymous (*) (25.02.2005 16:39:56)

Кстати, вот образец умственного развития потенциальных пользователей автоматического управления памятью (пассаж от anonymous (*) (25.02.2005 17:03:16)). Очевидно, обязательным условием функционирования подобных "гениев" является наличие языка типа Васика, желательно, выжуального (они на нем ИИ лабают, чтобы техподдержку себе интеллектуальную обеспечить). Соответственно, повышение эффективности разработки от использования языка со сборщиком мусора у таких разработчиков стремиться к бесконечности.

>Языки с автоматическим управлением памятью провоцируют на разработку >плохо продуманного алгоритма

Вот несогласен я с этим, а вот "гении" могут чушь на любом языке налабать, при чем тут сборщики мусора то?

Можно подумать, что программирование на C тоже провоцирует плохо продуманные алгоритмы с точки зрения Asm-a :)

Мне в C++ приходится извращаться с умными указателями и считать ссылки - все как пишет Элджер в книжке, почему я должен время то тратить на это , когда в той-же Java, Perl это все есть. А на Perl то как все легко и непринужденно пишется за минуты, в отличии от часов на C/C++, причем кода заметно меньше и красивей получается.

2anonymous (*) (25.02.2005 17:58:32):

Конечно, все в достаточной степени индивидуально.

Просто я хотел подчеркнуть, что ОЧЕНЬ распространенная точка зрения на то, что автоматическое управление памятью ведет к _автоматическому_ повышению эффективности разработки, по меньшей мере спорна.

>странно, они говорят, что она стабильна.

значит их слишком мало,
когда их станет достаточно много, если станет,
тогда все что может сломаться - сломается.

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

ЗЫ
твои аргументы мягко говоря на уровне десткого сада

2linux_guru :

> ...и не проверка возращаемых malloc значений, ... даст себя знать.

Кстати, Гуру, а как часто ты видел _в_Линуксе_ юзабельный откат после malloc() == NULL?

2Krasu:

Кстати, linux_guru, в общем. прав. Хотя бы потому, что всегда надо думать о том, что рано или поздно кому-нибудь понадобится портануть твою прогу на не-Линукс систему, где последствия неудачи системных вызовов будут иными...

да ладно, забей. Каковы причины наездов на руки и всё остальное ? Использовал calloc ... мдя. использовал sprintf, а не snprintf ... мдя (хотя размер буфера заведомо больше заносимых в него значений). какие-то стоны про Си функция a() != C++ функция a(). мдя.

Die-Hard: т.е. будет намного лучше проверять _каждый_ вызов fread/fgetc на предмет ferror() и feof() ? И ещё - setjmp это переносимая функция ?

2Krasu:

> использовал sprintf, а не snprintf

IMHO правильно. snprintf vs. sprintf -- СОВЕРШЕННО не тот случай, что gets() vs. fgets().

snprintf -- непереносимое Линукс-специфик расширение, совершенно не необходимое.

> т.е. будет намного лучше проверять _каждый_ вызов fread/fgetc на предмет ferror() и feof()

Ну, я бы проверял КАЖДЫЙ вызов fread на предмет if( fread(ptr, size, nmemb, stream) != nmemb); это - классика. Имеется МАССА причин это делать, даже под Линуксом.

> setjmp это переносимая функция ?

Теоретически -- да. Но практически -- нет. Ну, как boolean в ЦеПП. В стандарте оно есть, а на половине работающих компьютеров -- нет.

2Krasu:

А, вообще, я не понимаю, чего ты на linux_guru взъелся. За такое обычно благодарят...

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

>>IMHO правильно. snprintf vs. sprintf -- СОВЕРШЕННО не тот случай, что gets() vs. fgets().

Т.е. лучше использовать всё-таки sprintf ?

контрольный выстрел: это правильный код ?

bool error(FILE *f)
{
    return (ferror(f) || feof(f));
}
...
int fmt_next(fmt_info *finfo)
{
    currentImage++;

    if(currentImage == flic.NumberOfFrames)
        return SQERR_NOTOK;

    if(!finfo->image)
        return SQERR_NOMEMORY;

    memset(&finfo->image[currentImage], 0, sizeof(fmt_image));

    finfo->image[currentImage].passes = 1;
    finfo->image[currentImage].w = flic.Width;
    finfo->image[currentImage].h = flic.Height;
    finfo->image[currentImage].bpp = 8;
    finfo->image[currentImage].delay = (int)((float)flic.FrameDelay * 14.3);
    finfo->animated = (currentImage) ? true : false;

    CHUNKHEADER chunk;
    CHUNKHEADER subchunk;
    unsigned short subchunks;

    int pos = ftell(fptr);

    while(true)
    {
        if(!skip_flood(fptr))
            return SQERR_BADFILE;

        fread(&chunk, sizeof(CHUNKHEADER), 1, fptr);
        if(error(fptr)) return SQERR_BADFILE;

        if(chunk.type != CHUNK_PREFIX_TYPE &&
                    chunk.type != CHUNK_SCRIPT_CHUNK &&
                    chunk.type != CHUNK_FRAME_TYPE &&
                    chunk.type != CHUNK_SEGMENT_TABLE &&
                    chunk.type != CHUNK_HUFFMAN_TABLE)
            return SQERR_BADFILE;

        if(chunk.type != CHUNK_FRAME_TYPE)
            fseek(fptr, chunk.size - sizeof(CHUNKHEADER), SEEK_CUR);
        else
        {
            fread(&subchunks, sizeof(unsigned short), 1, fptr);
            if(error(fptr)) return SQERR_BADFILE;
            printf("Chunk #%X has %d subchunks\n", chunk.type, subchunks);
            fseek(fptr, sizeof(unsigned short) * 4, SEEK_CUR);
            break;
        }
    }

    while(subchunks--)
    {
        pos = ftell(fptr);

        fread(&subchunk, sizeof(CHUNKHEADER), 1, fptr);
        if(error(fptr)) return SQERR_BADFILE;

        switch(subchunk.type)
        {
            case CHUNK_COLOR_64:
            case CHUNK_COLOR_256:
            {
                unsigned char skip, count;
                unsigned short packets;
                RGB e;

                fread(&packets, sizeof(unsigned short), 1, fptr);
                if(error(fptr)) return SQERR_BADFILE;

                for(int i = 0;i < packets;i++)
                {
                    fread(&skip, 1, 1, fptr);
                    fread(&count, 1, 1, fptr);
                    if(error(fptr)) return SQERR_BADFILE;

                    if(count)
                    {
                        for(int j = 0;j < count;j++)
                        {
                            fread(&e, sizeof(RGB), 1, fptr);
                            if(error(fptr)) return SQERR_BADFILE;
                        }
                    }
                    else
                    {
                        fread(pal, sizeof(RGB), 256, fptr);
                        if(error(fptr)) return SQERR_BADFILE;

                        unsigned char *pp = (unsigned char *)pal;

                        if(subchunk.type == CHUNK_COLOR_64)
                            for(int j = 0;j < 768;j++)
                                pp[j] <<= 2;
                    }
                }
            }
            break;

            case CHUNK_RLE:
            {
                unsigned char value;
                signed char c;
                int count;

                for(int j = 0;j < finfo->image[currentImage].h;j++)
                {
                    int index = 0;
                    count = 0;
                    fread(&c, 1, 1, fptr);

                    while(count < finfo->image[currentImage].w)
                    {
                        fread(&c, 1, 1, fptr);
                        if(error(fptr)) return SQERR_BADFILE;

                        if(c < 0)
                        {
                            c = -c;

                            for(int i = 0;i < c;i++)
                            {
                                fread(&value, 1, 1, fptr);
                                if(error(fptr)) return SQERR_BADFILE;
                                buf[j][index] = value;
                                index++;
                            }

                            count += c;
                        }
                        else
                        {
                            fread(&value, 1, 1, fptr);
                            if(error(fptr)) return SQERR_BADFILE;

                            for(int i = 0;i < c;i++)
                            {
                                buf[j][index] = value;
                                index++;
                            }

                            count += c;
                        }
                    }
                }
            }
            break;

            case CHUNK_DELTA_FLI:
            {
                unsigned short starty, totaly, ally, index;
                unsigned char packets, skip, byte;
                signed char size;
                int count;

                fread(&starty, 2, 1, fptr);
                fread(&totaly, 2, 1, fptr);
                if(error(fptr)) return SQERR_BADFILE;

                ally = starty + totaly;

                for(int j = starty;j < ally;j++)
                {
                    count = 0;
                    index = 0;

                    fread(&packets, 1, 1, fptr);
                    if(error(fptr)) return SQERR_BADFILE;

                    while(count < finfo->image[currentImage].w)
                    {
                        for(int k = 0;k < packets;k++)
                        {
                            fread(&skip, 1, 1, fptr);
                            fread(&size, 1, 1, fptr);
                            if(error(fptr)) return SQERR_BADFILE;

                            index += skip;

                            if(size > 0)
                            {
                                fread(buf[j]+index, 1, size, fptr);
                                if(error(fptr)) return SQERR_BADFILE;
                            }
                            else if(size < 0)
                            {
                                size = -size;
                                fread(&byte, 1, 1, fptr);
                                if(error(fptr)) return SQERR_BADFILE;
                                memset(buf[j]+index, byte, size);
                            }

                            index += size;
                            count += size;
                        }

                        break;
                    }
                }
            }
            break;

            case CHUNK_BLACK:
            break;

            case CHUNK_COPY:
            {
//              printf("*** COPY DATA CHUNK\n");

                for(int j = 0;j < finfo->image[currentImage].h;j++)
                {
                    fread(buf[j], finfo->image[currentImage].w, 1, fptr);
                    if(error(fptr)) return SQERR_BADFILE;
                }
            }
            break;

            default:
                fsetpos(fptr, (fpos_t*)&pos);
                fseek(fptr, subchunk.size, SEEK_CUR);
        }
    }

    bytes = finfo->image[currentImage].w * finfo->image[currentImage].h * sizeof(RGBA);

    char type[25];
    strcpy(type, "Color indexed");

    finfo->images++;

    snprintf(finfo->image[currentImage].dump, sizeof(finfo->image[currentImage].dump), "%s\n%dx%d\n%d\n%s\nRLE/DELTA_FLI\n%d\n",
        fmt_quickinfo(),
        finfo->image[currentImage].w,
        finfo->image[currentImage].h,
        finfo->image[currentImage].bpp,
        type,
        bytes);

    return SQERR_OK;
}

>Здесь есть представители таких проектов?

Если все еще не нашел, могу предложить один вариант.

2Krasu :

> это правильный код ?

Я бы не стал учить детей, приводя такой код в качестве образца для подражания. Я коротко взглянул -- много такого, от чего обычно предостерегают. Не так, чтобы прямо ужасно (я и хуже видел, и в коммерческом супер-пупер софте), но -- не шедевр. Замечания по ходу:

Главное -- все таки, это Це или ЦеПП? На вид -- чисто Цешный код, зачем-то разбавленный ЦеППшными конструкциями.

Довольно странный способ контроля fread: вызывать после _почти_ каждого fread обертку над статусом потока... Не проще ли обернуть fread? Или вообще: if (fread()!=nmemb)return SQERR_BADFILE; (кстати, а правильно ли это?) Вообще, обилие таких странных конструкций, как fread(&packets, 1, 1, fptr); режет глаз (fread никак не оптимизирован для побайтного чтения!)

Бесконецный цикл, оформленный как while(true){}, очевидно является циклом с постусловием do{....}while(subchunks==0); (кстати, если по какой-либо причине из файла в subchunks прочитается 0, программа начнет чушь пороть). Вообще черезчур вольное обращение с целыми (типа int pos = ftell(fptr)), пара довольно смелых предположений о том, что sizeof(short int) = 2. (кстати, а зачем вообще нужен вызов ftell?)

Полное отсутствие комментариев.

2Krasu:

> Т.е. лучше использовать всё-таки sprintf ?

<IMHO>

Конечно, лучше использовать sprintf.

Насчет snprintf:

Кто-нибудь может мне пояснить глобальный смысл в использовании этого расширения C99, противоречивым образом описанного в различных стандартах и отсутствующего в старых Линуксах?

Прошу заметить, использование ограничения в fgets вполне оправдано (а как иначе избежать переполнения?) strncpy() часто нужна для алгоритма. Но зачем нужна snprintf()?

Пока что я мне не встречались случаи, в которых такая функция была бы полезной.

</IMHO>

Полезно про sprintf вообще забыть и использовать iostream, sstream

anonymous (*) (26.02.2005 22:55:50)

> Полезно про sprintf вообще забыть и использовать iostream, sstream

Дык, и я об чем!

Если программа на ЦеПП написана, то зачем чисто Цешные stdio?

>Если программа на ЦеПП написана, то зачем чисто Цешные stdio?

годишные или двух годишные бенчмарки показывали что stdio быстрее
iostream

>Если программа на ЦеПП написана, то зачем чисто Цешные stdio?

или вот еще пример,
допустим ты хочешь сделать программу многонациональной
(gettext),

код выглядит так например:

printf(_("my super prog, number of version is %s, compiled with bzip2 support\n"), "0.001");

или

std::cout<<_("my super prog, number of version is ")<<"0.0001"<<_(", compiled with
bzip2 support\n")<<std::endl;

что как думаете будет проще и легче переводить?

строчку в pot файле типа:
"my super prog, number of version is %s, compiled with bzip2 support\n"
или две
"my super prog, number of version is "
", compiled with bzip2 support\n"

это первое, а
второе может быть в языке на который переводят
другой порядок слов, в первом случаее можно сделать все что угодно,
приткнув в нужное место %s,
а во-втором,

так что поэтому я почти никогда не использую iostream

>Кто-нибудь может мне пояснить глобальный смысл в использовании этого >расширения C99, противоречивым образом описанного в различных стандартах и >отсутствующего в старых Линуксах?

а об атаках переполнением буфера ты слышал?

вот из-за таких чудо программистов и появляются всякие sendmail и прочяя