Вопрос к программистам на C , Исходники ядра Linux

Цитата

Ведь ты не хочешь, чтобы позволить, чтобы тебя переубедили?

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

Цитата the_Shadow @ 21.04.06, 09:25

Цитата

сорри, но без проблем.
мало того, предпочитаю именно С++ для пальмы (STL не юзаю)

А мне "хватило"... Спасибо. Примерно 2 к бинарь против примерно 16к -- сильное колдунство. Причём, замечу, для палмоводов такие размеры кода во-все не новость. Особенно, если сравнить с предлагаемыми by M$ решениями... :D:D Причём, я не говорю о настольных системах...

для программ типа "хелло ворд", возможно, так оно и есть. для более менее больших программ (ну скажем, от 50 К) соотношение размеров немного другое. мой опыт показывает, примерно 2:1 (С++ v С). причем, по скорости работы хорошо спроектированное приложение на С++ ничуть не уступает тому, что написано на С. могу даже для проверки выслать плюсовое переписанное приложение и оригинальное сишное. а вот надежность, расширяемость и поддержка плюсовых приложений выше на порядок, чем на С, имхо.
кстати, решения, которые предлагает майкрософт я не юзал. но знаю, что у них есть вижуал бэйсик (по моему он) для программирования пальм. согласен, что извращение и что так можно только интерфейс программить.

и еще момент. по моему ты приводил в качестве аргумента, что оси не пишут на плюсах. уже пишут - это симбиан.

Цитата the_Shadow @ 21.04.06, 10:25

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

Шад, родной мой. Знание особенностей конкретных систем мне необходимо ровно для того, чтобы писать под них корректно работающие программы. Не больше. Делать из этого себе религию мне нет необходимости. Для меня уже достаточно давно не стоият вопрос о том: "какой компилятор лучше", "какая система лучше" и т. п. Ибо я знаю (в необходимом мне объеме) особенности работы тех или иных компиляторов, а также необходимые мне аспекты программирования под системы, для которых разрабатываю ПО. Для меня есть стандарты - стандарты на языки, POSIX, стандарты, специфичные для конкретной прикладной области. Есть используемый инструментарий. Есть целевые платформы. Аргументы "в windows/linux так не делается потомушта это windows/linux" - также в прошлом, ибо есть API операционных систем, есть соглашения, накладываемые этими API и/или их архитектурами. Эти соглашения мне также в необходимом объеме известы. Почему это должно влиять на то, какой я инструмент выбираю - мне совершенно не понятно. Если инструмент для меня удобный, и позволяет решить поставленную задачу, то я буду им пользоваться вне зависимости от того, что по этому поводу думают апологеты соответствующих платформ. Инструмент может быть изменен, если будет сочтен неудовлетворящим неким формальным требованиям, предъявляемым к решению задачи (эффективность кода/размер, занимаемый результатом и т. п.). Но только в этом случае.
По этому мне не совсем понятно - о каких стереотипах ты говоришь?

Цитата

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

У них ещё есть С для КПК. Если помнишь что такое M$ C 6.0 + Win 3.1 SDK, то... похоже, уверяю тебя. Или Win32 API на С.

Цитата

уже пишут - это симбиан.

Да. Единственный случай. Наблюдаю во что это всё выльется. Покамест, если честно, то наблюдения довольно тягостные. Как пример -- разница между 60 и последующими сериями... Не очень-то всё это втыкает.

Кстати, весьма вероятно, что Palm оценит Linux по достоинству и, как и Motorola, сделает её основной ОС для своих девайсов. Кстати, "моторы" уже выпустили девайсы на Linux и признали, что данная ОС "более управляема, нежели Windows Mobile". Ещё из производителей (но это уже чисто мобилы) -- Haeir или как-то так. Я с их мобилами не сталкивался, по этой причине, не уверен, что пишется именно так.
А! Вот они:
http://mobiguru.ru/phones/haier/haier_m1000.html
http://mobiguru.ru/phones/haier/haier_n60.html
http://mobiguru.ru/phones/haier/haier_m2000.html

Цитата

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

Знаешь, на самом деле, как писать. Я, к примеру, стараюсь получить код одной функции, умещающийся на одном экране (14'', 1240x1024, чтобы было понятно).
Когда не получается (ну, чего греха таить, бывает такое), то... Ну, не сильно расстраиваюсь. Если код спроектировать грамотно изначально, то и пишется и обслуживается он довольно хорошо.

Цитата

для более менее больших программ (ну скажем, от 50 К) соотношение размеров немного другое. мой опыт показывает, примерно 2:1 (С++ v С).

Ну, примерно, да. Но вот в чём беда -- лично я таких приложений не пишу. Во-первых, далеко не те задачи решаются (я по "сетям" больше). Во-вторых, я стараюсь как можно чаще пользоваться m68k-ассемблером. Когда явно не видно выигрыша, то тогда С.

С другой стороны -- вопрос каким именно С++, какой реализацией STL (из ряда реализаций) пользоваться не стоит во-все (для PalmOS и для меня). Для Linux -- ну, что есть на диске с дистрибом, тем и пользуюсь. Собственно говоря, С-way довольно прост и понятен.

Цитата

Если инструмент для меня удобный, и позволяет решить поставленную задачу, то я буду им пользоваться вне зависимости от того, что по этому поводу думают апологеты соответствующих платформ. Инструмент может быть изменен, если будет сочтен неудовлетворящим неким формальным требованиям, предъявляемым к решению задачи (эффективность кода/размер, занимаемый результатом и т. п.). Но только в этом случае.
По этому мне не совсем понятно - о каких стереотипах ты говоришь?

Знаешь, вообще говоря, от спора у меня сложилось впечатление, что ты не сильно хочешь посмотреть на мир "глазами структурщика", скажем так. Вот и всё. По-моему, я продемонстрировал аналогичную "всеядность", но я только в одном отличаюсь -- я не ищу "обобщёных" путей, т.к. не считаю их правильными. И считаю абсолютно верным то, что С для UNIX -- основа основ.

Цитата the_Shadow @ 21.04.06, 11:54

Знаешь, вообще говоря, от спора у меня сложилось впечатление, что ты не сильно хочешь посмотреть на мир "глазами структурщика", скажем так. Вот и всё. По-моему, я продемонстрировал аналогичную "всеядность", но я только в одном отличаюсь -- я не ищу "обобщёных" путей, т.к. не считаю их правильными. И считаю абсолютно верным то, что С для UNIX -- основа основ.

Шад... Гм... Из 13-ти лет программирования я только последние три года активно использую шаблоны и обощенное. Как ты думаешь, используя какие подходы я программировал 5 лет назад? А 10 лет назад, когда из доступных компиляторов С++ был только борланд 3.1? Ну или тогда раскрой мне смысл структурного программирования (как ты его понимаешь). Вполне возможно я открою его для себя еще раз.

Добавлено 21.04.06, 12:08
Кстати, дабы не быть голословным, приведу решение той задачи, условия которой я предлагал. Вместе с кодом для тестирования.

#include <iostream>
#include <string>
 
template<typename T> struct HasSwap
{
    template<typename U, void (U::*fn)(U&)> struct CheckSwap
    {
        typedef int result;
    };
 
    template<typename U> static typename CheckSwap<U, &U::swap>::result HasSwapFn(U*);
    static char HasSwapFn(...);
 
    static const int value = sizeof(HasSwapFn((T*)NULL)) != 1 ? 1 : 0;
};
 
template<typename T1, typename T2> struct IsSameType
{
    static const int value = false;
};
 
template<typename T> struct IsSameType<T, T>
{
    static const int value = true;
};
 
enum
{
    InPlace,
    ViaMemberFun,
    StandardSwap
};
 
template<typename T, int> struct Swapper;
 
template<typename T> struct Swapper<T, InPlace>
{
    static void DoSwap(T& t1, T& t2)
    {
        t1 ^= t2;
        t2 ^= t1;
        t1 ^= t2;
    }
};
template<typename T> struct Swapper<T, ViaMemberFun>
{
    static void DoSwap(T& t1, T& t2)
    {
        t1.swap(t2);
    }
};
template<typename T> struct Swapper<T, StandardSwap>
{
    static void DoSwap(T& t1, T& t2)
    {
        std::swap(t1, t2);
    }
};
 
template<typename T> void swap(T& t1, T& t2)
{
        Swapper<T,
            (
            IsSameType<T, char>::value ||
            IsSameType<T, short int>::value ||
            IsSameType<T, int>::value ||
            IsSameType<T, unsigned char>::value ||
            IsSameType<T, unsigned short int>::value ||
            IsSameType<T, unsigned int>::value
            ) ? InPlace : (HasSwap<T>::value ? ViaMemberFun : StandardSwap)
        >::DoSwap(t1, t2);
};
 
class ClassWithoutSwap
{
public:
    std::string m_Id;
    ClassWithoutSwap(const std::string& id) : m_Id(id) {;}
    void Print() {std::cout << m_Id;}
};
 
class ClassWithSwap
{
public:
    std::string m_Id;
    ClassWithSwap(const std::string& id) : m_Id(id) {;}
    void Print() {std::cout << m_Id;}
 
    void swap(ClassWithSwap& other)
    {
        m_Id.swap(other.m_Id);
        m_Id += " swapped";
    }
};
 
int main(int, char**)
{
    int int_a = 1, int_b = 10;
    char char_a = '0', char_b = 'a';
    double double_a = 1, double_b = 10;
    std::string str_a = "str_a", str_b = "str_b";
    ClassWithSwap c1_a("id_a"), c1_b("id_b");
    ClassWithoutSwap c2_a("id_a"), c2_b("id_b");
 
    swap(int_a, int_b);
    swap(char_a, char_b);
    swap(double_a, double_b);
    swap(str_a, str_b);
    swap(c1_a, c1_b);
    swap(c2_a, c2_b);
 
    std::cout << "int_a:" << int_a << ", int_b:" << int_b << std::endl;
    std::cout << "char_a:" << char_a << ", char_b:" << char_b << std::endl;
    std::cout << "double_a:" << double_a << ", double_b:" << double_b << std::endl;
    std::cout << "str_a:" << str_a << ", str_b:" << str_b << std::endl;
    std::cout << "c1_a:";
    c1_a.Print();
    std::cout << ", c1_b:";
    c1_b.Print();
    std::cout << std::endl;
    std::cout << "c2_a:";
    c2_a.Print();
    std::cout << ", c2_b:";
    c2_b.Print();
    std::cout << std::endl;
 
    return 0;
}

Цитата

Ну или тогда раскрой мне смысл структурного программирования (как ты его понимаешь). Вполне возможно я открою его для себя еще раз.

По причине, изложенной в одной из тем в разделе для Модераторов, отказываюсь это сделать. А вот позвонить тебе -- нет проблем, отче.

Мужики, а давайте просто передохнем немного?

Цитата the_Shadow @ 21.04.06, 14:58

По причине, изложенной в одной из тем в разделе для Модераторов, отказываюсь это сделать

Ну, а сейчас ты чувствуешь себя лучше?

Цитата

Ну, а сейчас ты чувствуешь себя лучше? :)

Угу. Разобрался с 26.6 соток земли под Рязанью, уыпили с Drunk'ом, подали с подругой заявление в ЗАГС. Всё оффигительно.
Теперь надобно будет помочь vot'у. Плюс, рабочие вопросы...

Итак, покамест я развлекаться буду, посмотри на OnBoard C (для palm, отче, для palm :D:D:D). Различия в синтаксисе с gcc минимальны (при написании кода на пальме (именно на ней, т.к. там и асм и С-компиль), задача всего-то -- описать ряд вещей с учётом специфики). Итак, вопрос -- если у меня один язык -- С и для "больших систем" и для мелких, то зачем мне разыскивать что-то подобное, но вот только:
1. Слабосовместимое с уже существующим кодом?
2. Требующее ряд опциональных библиотек? Я про STL, которых есть несколько реализаций, если я не ошибаюсь.

По-позже я предложу аналогичное твоему решение на С. Причём, замечу, как полностью портируемую реализацию (ну, что поделать -- не люблю я "набивать" текст).

Цитата the_Shadow @ 25.04.06, 06:26

OnBoard C (для palm, отче, для palm :D:D). Различия в синтаксисе с gcc минимальны (при написании кода на пальме (именно на ней, т.к. там и асм и С-компиль), задача всего-то -- описать ряд вещей с учётом специфики). Итак, вопрос -- если у меня один язык -- С и для "больших систем" и для мелких, то зачем мне разыскивать что-то подобное, но вот только:

Зачем? Когда вознамерюсь писать под пальму тогда и посмотрю. В настоящий же момент меня имеющиеся средства устраивают.

Цитата the_Shadow @ 25.04.06, 06:26

Требующее ряд опциональных библиотек? Я про STL, которых есть несколько реализаций, если я не ошибаюсь.

Реализаций то несколько, да вот только стандарт один. Это как с CRTL - у каждого компилятора своя реализация, но набор функций, гарантированной стандартом, они обеспечивают.

Цитата

Реализаций то несколько, да вот только стандарт один. ;)

Угу... Угу... Угу...
Согласен (почти).

Цитата

Зачем? Когда вознамерюсь писать под пальму тогда и посмотрю. В настоящий же момент меня имеющиеся средства устраивают.

Не. Ты меня не понял. :D:D:D
Проблема в том, что используемые мною средства есть и под пальмой (в том числе), причём, заметь без тех или иных "довесков". Слава Богу, я гарантирован от мучительных размышлений -- а то ли я использую.

Посуди сам -- выше я писал об "уровнях соответсвия". Таким образом, я имею дело с синтаксисом С (явно и без извратов) и доп. библиотеками от производителя кода|жести. Всё.

Некоторое неудобство в написании (ну, действительно бред с моей точки зрения использовать одну функцию для сортировки и char и int и без разницы чего компиль там думает) слихвой компенсируется рядом преимуществ:
- простота и небольшое число конечных средств (как пример -- malloc/free, которые могут быть использованы в С++ наряду с new/delete, что приводит зачастую к путанице).
- чёткость их описания (стандарты).
- "отработанность" проблем. Блин... Ну ни кто же не думает (я надеюсь) что "программирование" началось с С++? Задачи решались и до этого языка... Что мешат использовать готовые решения? Или, хотя бы сунуть нос, да посмотреть как делалось...
- постоянное развитие инструментария. Ныне в С можно использовать комплексные числа, булевы типы данных, etc, причём, на основании С99.
- совместимость большей части ныне используемых средств и библиотек именно с С. Примеры приводил выше. Могу ещё вопросец подкинуть -- а как вы собираетесь на С++ писать код, работающий, к примеру, с COM-портом в windoZe? Нельзя ли по-подробнее? Или, будем баловаться с двумя видами кода -- на С и С++? А в Linux -- точно так же... В принципе. Заявляющие, что COM-порт в Linux -- просто файл правы отчасти -- всё так, за исключением того, что используется ряд структур, которые необходимо грамотно запонить.

Цитата the_Shadow @ 25.04.06, 07:12

Проблема в том, что используемые мною средства есть и под пальмой (в том числе), причём, заметь без тех или иных "довесков". Слава Богу, я гарантирован от мучительных размышлений -- а то ли я использую.

Замечательно, что есть. Я рад за тебя. А у меня пальмы нет. Потому проблема выбора тоже не стоит.

Цитата the_Shadow @ 25.04.06, 07:12

Угу... Угу... Угу...
Согласен (почти).

А что значит это "почит"?

Цитата the_Shadow @ 25.04.06, 07:12

- простота и небольшое число конечных средств (как пример -- malloc/free, которые могут быть использованы в С++ наряду с new/delete, что приводит зачастую к путанице).

Ну да. А лучше всего - realloc. Универсальное средство на все случаи жизни. И швец, и жнец и на дуде игрец. Добавим к нему printf, gets, strcpy/strcmp и n-ое количетсво других функций из CRTL, использование которых, мягко говоря, рисковано.

Цитата the_Shadow @ 25.04.06, 07:12

отработанность" проблем. Блин... Ну ни кто же не думает (я надеюсь) что "программирование" началось с С++? Задачи решались и до этого языка... Что мешат использовать готовые решения? Или, хотя бы сунуть нос, да посмотреть как делалось...

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

Цитата the_Shadow @ 25.04.06, 07:12

- чёткость их описания (стандарты).

Ты считаешь, что под С++ не существует стандартов кодирования? Тодгда зайди в книжный, и поищи на полочке книжку "Стандарты программирования на С++" Г. Саттера и А. Александреску. Про классическую Голубовскую "Веревку достаточной длины, чтобы выстрелить себе в ногу" я уже не говорю - это, отчасти, классика. И уже несколько, гм, устаревшая. После этого открой для себя знаменитую "Паттерны проектироваетирования" Э. Гаммы со товарищи. Там ты найдешь немалое количетсво готовых решений задач проектирования, встающих перед большинством программистов. Все это считается стандартами де-факто. Или ты про какие-то другие стандарты? Возьми тот же boost - это также уже стандарт de facto, но уже при разработке кода. Как там было в "Особенностях национальной рыбалки"?: "Рыба есть. Ловить надо уметь".

Цитата the_Shadow @ 25.04.06, 07:12

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

Ээээ.... Гм. В С++ это появилось годков на 6-7 пораньше...

Цитата the_Shadow @ 25.04.06, 07:12

совместимость большей части ныне используемых средств и библиотек именно с С. Примеры приводил выше. Могу ещё вопросец подкинуть -- а как вы собираетесь на С++ писать код, работающий, к примеру, с COM-портом в windoZe? Нельзя ли по-подробнее? Или, будем баловаться с двумя видами кода -- на С и С++? А в Linux -- точно так же... В принципе. Заявляющие, что COM-порт в Linux -- просто файл правы отчасти -- всё так, за исключением того, что используется ряд структур, которые необходимо грамотно запонить.

Шад, ну как как... Также как и на С. Если ты берешься утверждать, что на С++ нельзя написать библиотеку, предоставляющую С-шный интерфейс своим клиентам, а также что в С++ нельзя использовать библиотеки с С-шным интерфейсом - ты заблуждаешься. Причины того, что обычно прикладное ПО предоставляет библиотеки с интерфейсом на С, а не на С++ я уже приводил.

Цитата

Замечательно, что есть. Я рад за тебя. А у меня пальмы нет. Потому проблема выбора тоже не стоит.

Ну, положим, ни чего из этого не следует. Положим, radio-ethernet'а у тебя то же нет. Но вот в чём загвоздка -- мне иной раз надобно просчитать потреи в трассе (всего ничего, право). Но не расчехлять же ноут для этого, если я из кармана могу вынуть всё, что мне нужно!

И, заметь, с возможностью "накидать" нужный алгоритм "не сходя с места". Или по-править что-либо в существующем. Мне не интересны "моды" в программировании и, если завтра 100% народа кинется на С#, то всегда останутся вот такие... "немодные".

Цитата

А что значит это "почит"?

"Почти"? А сколько реализаций STL "известно науке" на сегодняшний день? И сколько их ещё будет? Зачем мне разбираться в их "тонкостях" и "толстостях", если у меня есть довольно адекватное средство для изложения алгоритма и без всего этого?

Цитата

Ну да. А лучше всего - realloc. Универсальное средство на все случаи жизни. И швец, и жнец и на дуде игрец. Добавим к нему printf, gets, strcpy/strcmp и n-ое количетсво других функций из CRTL, использование которых, мягко говоря, рисковано.

Уффф... Да сколько раз говорено, что есть такая весчь как splint? Сомневаешься -- прогони код через него. И, замечу, сравни по принципам работы с Valgrind? Разницы не видно? Мы необоснованно усложняем средства разработки и тестирования, вот в чём проблема. Как алгоритмы описывались, так и описываются. А вот все "сложности" в топочку... В топочку...
Где-то я видел "баян" по поводу того, как программа hello_world усложняется по мере увеличения знаний программистом. Не попадалась тебе? Найдёшь -- приколись.

Правда, для того, чтобы оценить прикол, нужно чётко понимать, что как была прога, так и осталась. Но, право, как изменяются средства, применяемые программистом... "Мода" -- штука сильная.

Цитата

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

Извини, не соглашусь, т.к. по большому счёту, ничего не изменилось -- как были библиотеки, так и остались. Как использовался метод "cut'nd'paste", так и используется... Как можно было отдельные данные и функции выносить в ряд объектных файлов и использовать их по-месту, так и сохраняется эта возможность. Что существенно меняется? Да ни чего. Просто, понтов добавилось... Да... Существенно.

Цитата

Ты считаешь, что под С++ не существует стандартов кодирования?

1. Этого я не говорил.
2. В книжный не пойду -- есть в электронном виде.
3. А что тебе мешает признать, что стандарты POSIX более полно описывают систему?

Цитата

Ээээ.... Гм. В С++ это появилось годков на 6-7 пораньше...

И слава Богу! Я просто отмечаю, что сам по себе стандарт языка не является статичной сущностью. Да. Он меняется. Ну? И?
То, что в С++ многие вещи появились раньше -- да не проблема. Если бы они (эти вещи) нужны были бы основной массе С-проггеров, то они появились бы раньше и в нашем стандарте... Какие проблемы-то?

Цитата

Возьми тот же boost - это также уже стандарт de facto, но уже при разработке кода.

А, пардон, с каких пор de facto = de jure? Да и потом -- для кого? Для меня? Во-все нет...
Для меня стандарт de jure есть и зачем ещё париться по-поводу всех PR-акций? Ну, станет оно de jure, тогда и поговорим...
С#, вон, то же все ому не лень пиарят. А толку?

Цитата

Если ты берешься утверждать, что на С++ нельзя написать библиотеку, предоставляющую С-шный интерфейс своим клиентам, а также что в С++ нельзя использовать библиотеки с С-шным интерфейсом - ты заблуждаешься.

Flex'ушко... Дорогой ты мой -- да я о том же! За одним исключением -- ЗАЧЕМ писать библиотеку, порождая тем самым ещё дополнительный код (со всеми втекающими и вытекающими), если уже есть нормальное и адекватное средство решения данной проблемы?

ЗАЧЕМ переписывать то, что уже работает? Зачем громоздить "абстракцию" над "абстракцией"? Во имя чего? Религия не позволяет?

Цитата the_Shadow @ 25.04.06, 08:53

Ну, положим, ни чего из этого не следует. Положим, radio-ethernet'а у тебя то же нет. Но вот в чём загвоздка -- мне иной раз надобно просчитать потреи в трассе (всего ничего, право). Но не расчехлять же ноут для этого, если я из кармана могу вынуть всё, что мне нужно!

И что ты этим пытаешься сказать? Что у тебя есть задача, под которую идеально подходит имеющийся у тебя инструмент. Ну и замечательно. При чем тут предмет спора?

Цитата the_Shadow @ 25.04.06, 08:53

"Почти"? А сколько реализаций STL "известно науке" на сегодняшний день? И сколько их ещё будет? Зачем мне разбираться в их "тонкостях" и "толстостях", если у меня есть довольно адекватное средство для изложения алгоритма и без всего этого?

Сколько вариаций CRTL известно современной науке? Вариаций STL может быть сколько угодно. Но любая из них в первую очередь подчиняется стандарту ISO/IEK 14882. Приведенная абревиатура ни на какие мысли не наводит? Или одни международные стандарты стандартнее других?

Цитата the_Shadow @ 25.04.06, 08:53

Уффф... Да сколько раз говорено, что есть такая весчь как splint? Сомневаешься -- прогони код через него. И, замечу, сравни по принципам работы с Valgrind? Разницы не видно? Мы необоснованно усложняем средства разработки и тестирования, вот в чём проблема. Как алгоритмы описывались, так и описываются. А вот все "сложности" в топочку... В топочку...

Ага. Сначала мы расписываем достоинства одного инструмента, а потом выясняется, что для того, что бы было совсем счастье, нужно что-то еще. В данном случае - splint. А что я делаю не так, если у меня компилятор большинство косяков сам ловит и носом в них тычет? Безо всяких сплинтов, и другого подобного утиля?

Цитата the_Shadow @ 25.04.06, 08:53

Извини, не соглашусь, т.к. по большому счёту, ничего не изменилось -- как были библиотеки, так и остались. Как использовался метод "cut'nd'paste", так и используется... Как можно было отдельные данные и функции выносить в ряд объектных файлов и использовать их по-месту, так и сохраняется эта возможность. Что существенно меняется? Да ни чего. Просто, понтов добавилось... Да... Существенно.

Ну, не скажи, не скажи. Но для начала посмотрим на твою реализацию swap'а.

Цитата the_Shadow @ 25.04.06, 08:53

А что тебе мешает признать, что стандарты POSIX более полно описывают систему?

А при чем тут стандарты на API системы? Мы что, системы обсуждаем? Мы обсуждаем языки программирования. Слабо понимаю, как стандарт POSIX связан с обсуждаемой темой.

Цитата the_Shadow @ 25.04.06, 08:53

Я просто отмечаю, что сам по себе стандарт языка не является статичной сущностью. Да. Он меняется. Ну? И?

А где я это отрицал или еще что-то такое? Стандарт C++ тоже не является статической сущностью и тоже меняется. Ближайшее изменение грядет в 2008-ом.

Цитата the_Shadow @ 25.04.06, 08:53

Если бы они (эти вещи) нужны были бы основной массе С-проггеров, то они появились бы раньше и в нашем стандарте... Какие проблемы-то?

Ммм... Подозреваю, что не совсем так. Изменения в стандарт что С, что С++ вносятся раз в 10 лет. По этому говорить "как только, так сразу" тут нельзя, ибо даже если сразу после выхода стандарта появляется крайняя нужда в какой-то фиче, то появление ее в стандарте стоит ожидать не ранее, чем через n лет, где n лежит в промежутке от 1 года до 10-ти лет.

Цитата the_Shadow @ 25.04.06, 08:53

А, пардон, с каких пор de facto = de jure? Да и потом -- для кого? Для меня? Во-все нет...
Для меня стандарт de jure есть и зачем ещё париться по-поводу всех PR-акций? Ну, станет оно de jure, тогда и поговорим...
С#, вон, то же все ому не лень пиарят. А толку?

И какие стандарты de-jure ты имеешь ввиду?

Цитата the_Shadow @ 25.04.06, 08:53

За одним исключением -- ЗАЧЕМ писать библиотеку, порождая тем самым ещё дополнительный код (со всеми втекающими и вытекающими), если уже есть нормальное и адекватное средство решения данной проблемы?

А где, позволь узнать, я предлагал писать библиотеку, изобретая при этом велосипед? Что-то я тебя недопонимаю. Я лишь написал о возможности написания как-либо библиотеки на С++, имеющей С-подобный интерфейс. Только и всего. Не надо мне приписывать того, что я не говорил.

Цитата the_Shadow @ 25.04.06, 08:53

ЗАЧЕМ переписывать то, что уже работает? Зачем громоздить "абстракцию" над "абстракцией"? Во имя чего? Религия не позволяет?

А где я предлагал такое?

Кстати, мужыги! Вы очень умно рассуждаете, но есть животрепещущий вопрос: кто-либо может подсказать библиотеку-фреймворк для написания асинхронно работающего сервера (то есть: главный цикл ловит события и передает коллбэкам, которые можно выстраивать в цепочки), короче, некий аналог питоновского Twisted (можно урезанный), только — ахтунг! — на чистейшем C?