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

Цитата Ho Im @ 20.04.06, 18:38

Был один чел, посмотрел тему, понюхал исходники ядра, фыркнул «Фи! Как запущено... Си, препроц... А вот мы тут с шаблонами \m/ \m/», после чего благополучно смахался из темы. И вот тогда, как в том анекдоте про Штирлица, «началась драка».

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

Цитата

Ок. Тогда я тоже упрусь рогом. Объясни мне, почему стандартные опции оптимизации в gcc (любые) не делают omit frame pointer. Ведь это здорово раздувает код и просаживает производительность! После того, как ты мне это объяснишь, я объясню тебе - почему в линкере по умолчанию используется выравнивание сегментов на границу странцы.

Объясняю. Стандартно (по умолчанию) в gcc используется именно обратная опция -- -fno-omit-frame-pointer. Почему так. По причине того, что в регистре (в случае -fomit-frame-pointer) не сохраняется указатель стека. Код сохранения и восстановления адреса пропускается, "экономится" ровным счётом один регистр. Казалось бы, всё реально здоровски. Но. Во-первых, gcc -- кросс-компиль. И не на всех платформах используется механизм сохранения|восстановления указателя стека просто потому, что в ряде архитектур нет такого понятия. А gcc там есть. Далее. Что может произойти в таком случае, на любом приложении, мало кто знает. По этой причине, генерируется более безопасный вариант кода.

Вообще говоря, такое определение, скорее относится к "аналогу" механизма, применяемого в M$ -- к определению функции как naked. Я говорю не о полном аналоге, а об определённой функциональности, схожей в обоих случаях. И, пожалуй, замечу, что это -- аналог (по идеологии) предложенного мной грязного трюка.

Теперь по поводу С++ в Linux. Ты правильно заметил, что генерировать код нужно было через g++. Но позволь -- что происходит-то? Такой вызов вполне можно зменить случаем gcc с явным указанием опции -lsdc++. Т.е., вместо stdc использовать stdc++. Зачем это?

Цитата

А какая разница? И почему ты делаешь такое различие? Есть язык, есть международный стандарт на него. Для меня этого вполне достаточно. Что такое "основной" и что такое "дополнительный" - я не знаю, и, честно говоря, не особо хочу знать.

А разница в том, что на С изначально были написаны и С++ и Java. Более того. Любой язык (см. JNI) и практически любой программный пакет (я имею ввиду к примеру, Oracle и PostgreSQL) имеют интерфейсы к С (в первую очередь). Да. Они имеют интерфейсы и к другим языкам, но, заметь, если мы возьмём Oracle и PostgreSQL, то там есть препроцессоры к языку С. Почему так? Потому, что авторы данного ПО так же застряли в 80-х годах прошлого века?

Для решения ряда задач я могу использовать только С и обходиться тем, что в системе есть и без чего система просто не будет работать. Как видишь, я чётко оговорился -- ряда задач. Если мы вернёмся к идеологии, то есть задачи полностью определённые (большая часть) и весьма малая -- слабоопределённые. Как пример -- если я описываю работу протокола или жёсткого диска, то как там могут быть, скажем так, не целочисленные значения? Число секторов в виде double? Число байт, переданных|принятых -- float? Оригинально! Вот данные которые там передаются -- нам в данном случае не важны. Хотя, еслиподумать, то и там... Детерминизм полнейший.

Для таких задач С и существует. Ещё пример -- Win32 API, GNOME, PalmOS (к примеру). Всё это объединяется довольно простой парадигмой -- это -- event-driven applications (по своей сути). И для такого рода задач С, пардон, но "рулит" по причине того, что event всегда определён. И я не могу приветствовать того, как ставится M$ DevStudio 2005, к примеру. "All-in-one". Вариант решения я привёл.

Другой момент -- место С++. Допустим, есть задача -- у меня есть ОО и БД, содержащая некую инфу. Я желаю зарядить инфу из БД в таблицу. Могу поступить двояко -- я могу слить инфу в файл, потом подцепить его в табличном редакторе. Могу. Но я не смогу откорректировать данные в таблице в БД. Есть более красивое решение -- механизм расширений для ОО. Причём, учитывая то, что авторы ОО не могли полностью определить всю систему, во всём многообразии её модулей расширений, они заложили механизм UNO, который предоставляет мне право писать на С++ или Java. И здесь я готов пойти на использование доп. библиотек, т.к. критичность десктопного софта на порядки ниже, нежели критичность демона (к примеру).

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

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

Цитата the_Shadow @ 21.04.06, 07:24

Объясняю. Стандартно (по умолчанию) в gcc используется именно обратная опция -- -fno-omit-frame-pointer. Почему так. По причине того, что в регистре (в случае -fomit-frame-pointer) не сохраняется указатель стека. Код сохранения и восстановления адреса пропускается, "экономится" ровным счётом один регистр. Казалось бы, всё реально здоровски. Но.
Что может произойти в таком случае, на любом приложении, мало кто знает. По этой причине, генерируется более безопасный вариант кода.

Неубедительно. Совершенно неубедительно. Пустые страхи и домыслы. А результат - лишние инструкции в коде и занятый регистр. Но дело в другом. Почему в таком случае объяснение: "для того, чтобы исполняемый файл можно было без лишних проблем запускать на предыдущих версиях системы" для тебя не подходит? Я к тому, что ты легко понимаешь аргумент "никто не знает, что может произойти в приложении в противном случае", но совершенно не принимаешь аргумент "ради обеспечения обратной совместимости". Странно, однако...

Цитата the_Shadow @ 21.04.06, 07:24

А разница в том, что на С изначально были написаны и С++ и Java. Более того. Любой язык (см. JNI) и практически любой программный пакет (я имею ввиду к примеру, Oracle и PostgreSQL) имеют интерфейсы к С (в первую очередь). Да. Они имеют интерфейсы и к другим языкам, но, заметь, если мы возьмём Oracle и PostgreSQL, то там есть препроцессоры к языку С. Почему так? Потому, что авторы данного ПО так же застряли в 80-х годах прошлого века?

Тогда уже надо говорить, что вначале всего - ассемблер, и давайте все писать на нем. А все остальное - это малоэффективные производные, обеспечивающие никому не нужное облегчение жизни.
Почему в упомянутых тобою продуктах есть интерфейс на С, но нет на С++, легко объяснимо. Потому что нет единой спецификации на бинарный интерфейс для языка С++, и в этом случае каждый компилятор - сам себе голова. С С - проще, т. к. все, что там можно экспортировать, это глобальные переменные и функции, и делать это можно по их имени без всяческих дополнительных выкрутасов.

А на счет детерминизма/недетерминизма - ты не прав. Не знаю, откуда у тебя сложилось мнение, что на С++ нельзя писать event-driven application, а также сильно-определенные программы, но это мнение ошибочно. На С++ можно писать не менее эффективные event-driven-приложения, чем на С.

Цитата

А тя кто-то спрашивал как это делать?

грубить начал?.. значит ты неправ.

Цитата

По какому критерию сравнивать будем?

вопрос, конечно, интересный
Шад, шаблончики помогают не писать один и тот же код по двадцать раз
посмотри, например, в сторону std::vector, std::list и т.д.

Цитата

Был один чел, посмотрел тему, понюхал исходники ядра, фыркнул «Фи! Как запущено... Си, препроц... А вот мы тут с шаблонами \m/ \m/», после чего благополучно смахался из темы. И вот тогда, как в том анекдоте про Штирлица, «началась драка».

мне за холивары бабки не платят, а так всё в порядке. Я ещё тут

Цитата

А на счет детерминизма/недетерминизма - ты не прав. Не знаю, откуда у тебя сложилось мнение, что на С++ нельзя писать event-driven application, а также сильно-определенные программы, но это мнение ошибочно. На С++ можно писать не менее эффективные event-driven-приложения, чем на С.

ясен денЬ, там всё абсолютно детерминировано.

Цитата

но совершенно не принимаешь аргумент "ради обеспечения обратной совместимости". Странно, однако...

Послушай, а чего странного? В Linux этих проблем НЕТ! Я же запускаю и Win-приложения (см. шот)... И приложения на Java встроил в систему (путём правки файла, отвечающего в системе за "понимаемые" исполняемые форматы). А уж это во-все не одна и та же логическая организация файла. Правда, для M$-DOS я буду использовать dosemu, но это другой вопрос.

Цитата

А результат - лишние инструкции в коде и занятый регистр.

А есть разные уровни программирования -- где-то важнее стабильность, а где-то... грамотное использование опций при кодогенерации. Я, к примеру, думаю, что при рекуррентном вызове и достаточно большой вложенности вызываемого кода, к примеру, стек лучше оставить в покое. В конце-концов, и naked-функции в M$ не столь распространены...

Цитата

Тогда уже надо говорить, что вначале всего - ассемблер, и давайте все писать на нем.

Может, обойдёмся без аргументации в стиле "в Linux у меня звуковая карта пердит"? :D:D:D

Цитата

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

Не-аааа... :D:D:D
В том же PgSQL я могу обработать препроцессором код на SQL и получить код на С... :D:D:D Зачем тута бинарный интерфейс?

Цитата

На С++ можно писать не менее эффективные event-driven-приложения, чем на С.

Сделай одолжение -- расскажи это программистам для PalmOS... :D:D:D
Хотя, С++ и STL есть и там.

Добавлено 21.04.06, 08:08

Цитата

грубить начал?.. значит ты неправ.

Издеваться, если честно... :D:D:D

Цитата the_Shadow @ 21.04.06, 08:07

Послушай, а чего странного? В Linux этих проблем НЕТ! Я же запускаю и Win-приложения (см. шот)... И приложения на Java встроил в систему (путём правки файла, отвечающего в системе за "понимаемые" исполняемые форматы).

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

Цитата the_Shadow @ 21.04.06, 08:07

А есть разные уровни программирования -- где-то важнее стабильность, а где-то... грамотное использование опций при кодогенерации. Я, к примеру, думаю, что при рекуррентном вызове и достаточно большой вложенности вызываемого кода, к примеру, стек лучше оставить в покое. В конце-концов, и naked-функции в M$ не столь распространены...

Любая оптимизация должна быть инвариантна относительно workflow неоптимизированного кода. По этому если какая-то опция оптимизации нарушает этот инвариант, то, может быть, стоит поправить компилятор? Писанные на асме функции прекрасно работают без специально организованного кадра стека. Так в чем проблема то? Может быть, все таки, пустые домыслы и страхи?

Цитата the_Shadow @ 21.04.06, 08:07

В том же PgSQL я могу обработать препроцессором код на SQL и получить код на С... :D:D Зачем тута бинарный интерфейс?

А как этот код на С будет общаться с PtSQL? Наверное, определенные функции из соответствующей библиотеки дергать?

Цитата the_Shadow @ 21.04.06, 08:07

Сделай одолжение -- расскажи это программистам для PalmOS... :D:D
Хотя, С++ и STL есть и там.

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

Цитата

Может, обойдёмся без аргументации в стиле "в Linux у меня звуковая карта пердит"? :D:D

Не обойдёмся. Потому что поддержка существующего кода - это ключевой вопрос. C++ код поддерживать значительно проще - это я тебе как настоящий багхантер и краевед говорю

Цитата the_Shadow @ 21.04.06, 08:07

Может, обойдёмся без аргументации в стиле "в Linux у меня звуковая карта пердит"? :D:D

Не понял такой реакции. Ты предложил разделить языки на первичные и вторичные. Вот я и разделил - ассемблер/машинные коды и все остальное. Чем плохое деление?

Цитата

C++ код поддерживать значительно проще - это я тебе как настоящий багхантер и краевед говорю

Ха! Я с тобой спорил? Если ты прочитаешь то, что я писал о сложности программирования, то ты заметишь, что я с тобой немного согласен.

На самом деле, если есть набор данных и функций по их обработке, причём, грамотно написанных, то их обслуживать не сложнее, чем код на С++. Flex так же соглашается, что нет единого алгоритма для "сортировки-всего-на-свете" и требуется ряд правок в коде. Так вот. В случае с С код поделен на "отсеки", каждый из которых достаточно самодостаточен. И, если мы валим всё в кучу, пытаясь создать описанный алгоритм, то... Такой код запаришься обслуживать. И не важно на чём он писан. Непонимание идеологии программирования на С

См. ряд холи-варов по С в Сети -- вплоть до холи-варов по стилям форматирования -- отголоски есть даже в разделе (тема про стили в разделе UNIX).

Цитата

Писанные на асме функции прекрасно работают без специально организованного кадра стека.

Ээээ... Честно? А кто сказал, что без указания спец. опций тот же gas создаёт именно такой код? И кто сказал, что в таком случае всё абсолютно безопасно? И почему тогда в M$ не используются ф-ии, описанные как naked (что уж с нас нищих взять...)? Было бы безопасно -- так бы и было бы.

Цитата

Любая оптимизация должна быть инвариантна относительно workflow неоптимизированного кода. По этому если какая-то опция оптимизации нарушает этот инвариант, то, может быть, стоит поправить компилятор?

Заметь -- на ряде процов такой проблемы (как я описал) вообще нет. Там нет "кадра стека", к примеру.
Другой момент -- у программиста мозги есть? Есть. Знания? То же должны быть. Вот и пусть думает что использовать, а что не стоит. Вообще, в gcc есть порядка 200 опций. Что -- под каждую платформу перезатачивать этот "соборный компилятор"? Или, проще (дешевле) отдать использование опций на откуп конечному (я не про конченного) программисту?

Цитата

А как этот код на С будет общаться с PtSQL? Наверное, определенные функции из соответствующей библиотеки дергать?

Да! Но заметь -- эти библиотеки не являются частью основного набора (stdlib) в С. Таким образом, мы приходим к тому, что есть ряд уровней соответствия -- "чистый С" (С+stdlib), С с либами от интернациональных организаций по стандартам (есть ряд либ от ISO/ESTI), С с либами от национальных организаций пo стандартам (ANSI) и С с либами от производителя ПО (к примеру, Win 32 API, PalmOS API, PgSQL API, ApacheAPI, ... ).

Цитата

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

Пробовал. У меня сейчас 5.4 версия PalmOS, начинал с версии 3.0 и возрадовался, когда в версии 3.5 эта поддержка появлась. Но радость была не долгой.
Вот тебе материальчики-с-с-с (и то не весь "набор", но суть будет понятна). Она выражается одним словом -- size (точнее, не одним всё-таки, size of application).
http://www.palmq.ru/story31.htm (тут просто и для Ханта приведены возможные варианты), а вот тут -- примерный анализ всего этого. Заметь -- разговор идёт о gcc для PalmOS.
http://groups.google.ru/group/pilot.programmer.codewarrior/browse_thread/thread/4d79f155e68f65bb/5d92d2c295c9daaa%235d92d2c295c9daaa
http://groups.google.ru/group/pilot.programmer.gcc/browse_thread/thread/7752eac1d6cedb20/b170047ccbc39984%23b170047ccbc39984
http://groups.google.ru/group/pilot.programmer.codewarrior/browse_thread/thread/5beafdb51b171f45/77c84f28e07c3c3d%2377c84f28e07c3c3d

Цитата Flex Ferrum @ 21.04.06, 07:51

Неубедительно. Совершенно неубедительно. Пустые страхи и домыслы.

А я думаю, что по умолчанию -fno-omit-frame-pointer включен, чтобы пользователи могли отсылать полезные корки разработчикам Не забываем, что весь софт Open Source и скрывать backtrace нет особой необходимости. А дамп может существенно помочь разработчикам, даже если в бинарнике не было отладочной информации, а только отслеживались стековые фреймы.
Кстати, я слышал, что на платформе AMD64 -fomit-frame-pointer и -fno-omit-frame-pointer не имеют эффекта, т.е. там используется какой-то другой мехнизм.

Цитата Flex Ferrum @ 21.04.06, 08:27

А как этот код на С будет общаться с PtSQL? Наверное, определенные функции из соответствующей библиотеки дергать?

Конечно. Ведь речь идет об embedded SQL.

Цитата BugHunter @ 21.04.06, 08:31

C++ код поддерживать значительно проще - это я тебе как настоящий багхантер и краевед говорю

Проще всего поддерживать хорошо написанный структурированный код с досточным количеством комментариев. Такой код позволяет написать практически любой язык (даже Perl, если не увлекаться regexp'ами), и код C++, ровно как и C -- не самый лучший вариант с точки зрения поддержки. Java, например, поддерживать проще, т. к. там нет постоянных забот о вызовах деструктора, преобразованиях типов, освобождении памяти и т. п.

Цитата the_Shadow @ 21.04.06, 08:07

Цитата

На С++ можно писать не менее эффективные event-driven-приложения, чем на С.

Сделай одолжение -- расскажи это программистам для PalmOS... :D:D
Хотя, С++ и STL есть и там.

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

Цитата

Ты предложил разделить языки на первичные и вторичные.

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

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

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

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

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

Flex так же соглашается, что нет единого алгоритма для "сортировки-всего-на-свете" и требуется ряд правок в коде.

Это ты так понял понятие "точка настройки алгоритма"? А попросить объяснить незнакомое понятие - не судьба?

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

Честно? А кто сказал, что без указания спец. опций тот же gas создаёт именно такой код? И кто сказал, что в таком случае всё абсолютно безопасно? И почему тогда в M$ не используются ф-ии, описанные как naked (что уж с нас нищих взять...)? Было бы безопасно -- так бы и было бы.

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

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

Другой момент -- у программиста мозги есть? Есть. Знания? То же должны быть. Вот и пусть думает что использовать, а что не стоит. Вообще, в gcc есть порядка 200 опций. Что -- под каждую платформу перезатачивать этот "соборный компилятор"? Или, проще (дешевле) отдать использование опций на откуп конечному (я не про конченного) программисту?

О! Теперь я знаю, как ответить на вопрос "почему VC генерирует такой код с опциями по умолчанию". Мозги есть? Есть. Знания есть? Есть. Вот и думай - какие опции компиляции/ликовки включать, а какие нет. Ведь ты сам призал, что проще отдать опции на откуп конечному программисту.

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

Да! Но заметь -- эти библиотеки не являются частью основного набора (stdlib) в С. Таким образом, мы приходим к тому, что есть ряд уровней соответствия -- "чистый С" (С+stdlib), С с либами от интернациональных организаций по стандартам (есть ряд либ от ISO/ESTI), С с либами от национальных организаций пo стандартам (ANSI) и С с либами от производителя ПО (к примеру, Win 32 API, PalmOS API, PgSQL API, ApacheAPI, ... ).

Ты это к чему и на какой вопрос ты так ответил? Или ты считаешь, что я не понимаю разницы между библиотекой stdc и библиотекой интерфейса к PgSQL?

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

Пробовал. У меня сейчас 5.4 версия PalmOS, начинал с версии 3.0 и возрадовался, когда в версии 3.5 эта поддержка появлась. Но радость была не долгой.

Шад, а где я конкретизировал вопрос и спрашивал про PalmOS? Или то, что для одной из платформ компилятор настолько неудачен, что генерирует дрянной код позволяет тебе обощать этот результат на все подобные задачи, которые можно решать с помощью языка, для которого этот компилятор написан?

Цитата

Кстати, я слышал, что на платформе AMD64 -fomit-frame-pointer и -fno-omit-frame-pointer не имеют эффекта, т.е. там используется какой-то другой мехнизм.

Да. Возможно, ты прав. Я пока до АМД64 не добрался. Я про то и говорю -- не на всех платформах есть кадр стека вообще. Как понятие.

Цитата

Ведь речь идет об embedded SQL

Именно о нём. Embedded C++ покамест не видел. Увижу -- скажу.

Цитата

Java, например, поддерживать проще, т. к. там нет постоянных забот о вызовах деструктора, преобразованиях типов, освобождении памяти и т. п.

И здесь соглашусь. Именно по этой причине, для GNOME (как пример!!!) сделали Java-bindings. Особенно, учитывая то, что Linux сам по себе в состоянии поддерживать приложения на Java наравне с приложениями, оформленными как ELF.

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

В смысле обслуживания кода мне остаётся только снять шляпу перед авторами Java.

Цитата

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

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

Добавлено 21.04.06, 09:47

Цитата

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

Flex, а моя жизнь просто крайне коротка (и в ней намного больше задач), нежели разборки с компилями. Я применил "естественный отбор". Вот и всё.

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

Цитата

Я вижу два языка - C и C++, каждый из которых специфицирован соответствующим стандартом. А уж как они там реализуются в конкретном компиляторе - это делати реализации конкретного компилятора, и не более того.

И не видишь, или не хочешь видеть того, что происходит в обсуждаемой нами системе. Пожалуй, согласен...

Цитата

Это ты так понял понятие "точка настройки алгоритма"?

Знаешь, если честно, то да. Причём, я во-все не уверен в том, что оно будет корректным (я про объяснение) с моей точки зрения, т.к. я не видел в жизни (с 1986г.) единых алгоритмов для сортировки "всего-чего-угодно-на-свете". ;) Не ты ли это писал:

Цитата

Я лишь предположил, что могут быть случаи, когда требуется совершенно специализированный алгоритм, последовав упомянутому тобой принципу "80/20".

mo3r был честнее:

Цитата

На самом деле, может быть еще одна тонкая настройка алгоритма сортировки. А именно, в некоторых случаях сортировка элементов делается за линейное время. Тот алгоритм sort, который в stl-е, не учитывает этого. Но это можно дописать.

А что мне мешает дописать то, что мне нужно?

Далее. Я предпочитаю не делать каких-либо допущений (при написании ПО), в том числе о типах данных, используемых алгоритмах и т.д. и т.п. И для меня любой случай отличен от любого другого.

Цитата

О! Теперь я знаю, как ответить на вопрос "почему VC генерирует такой код с опциями по умолчанию". Мозги есть? Есть. Знания есть? Есть. Вот и думай - какие опции компиляции/ликовки включать, а какие нет. Ведь ты сам призал, что проще отдать опции на откуп конечному программисту.

Равно как и признал, что gcc работает на множестве платформ в отличие от Visual, работающего на веьма малом количестве платформ. Списки приводить?

Цитата

Ты это к чему и на какой вопрос ты так ответил? Или ты считаешь, что я не понимаю разницы между библиотекой stdc и библиотекой интерфейса к PgSQL?

Отвечать или не надо?
Думаю, понимаешь. Но вот почему-то игнорируешь сей факт.

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

Flex, а моя жизнь просто крайне коротка (и в ней намного больше задач), нежели разборки с компилями. Я применил "естественный отбор". Вот и всё.

Ну так а о чем мы тогда говорим то? Еще вчера я сказал, что любая моя аргументация будет бесполезна по определению, ибо ты свой выбор сделал, и выбирать что-то другое ты не будешь. Ведь это так? Так. Тогда к чему все то, что мы тут наговорили? Ты пытаешься обосновать, почему твой выбор верен? А зачем? Это - твой выбор. У других людей - другой выбор. А поскольку ты свой выбор менять не намерен (ведь ты увенрен в том, что действуешь правильно), то любая аргументация будет разбиваться об кирпичную стену. А потому, в очередной раз предлагаю завершить дискуссию, потому как ни к какому итогу мы не придем. Ведь ты не хочешь, чтобы позволить, чтобы тебя переубедили? Нет. Позволь и другим участникам подобную роскошь - не позволять, чтобы их переубеждали.