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

Цитата the_Shadow @ 20.04.06, 11:35

После AutoLISP у меня от него изжога... :D:D

Сочуствую. Если так долго мучает, так может стоит к врачу обратиться?

Цитата the_Shadow @ 20.04.06, 11:35

Да не всё так просто -- на "раз-два-три". Блин, либо мы действительно знаем систему, либо мы пытаемся делать вид, что мы умные.

Ну так продемонстрируй, как у тебя без хаканяь асмовского вывода gcc получился свехмаленький бинарник, а? Если мы такие умные, то как мы избежали линковки с crt1.o, crti.o, crtbegin.o, crtend.o, crtn.o и динамической линковки с libgcc_s.so?

Цитата the_Shadow @ 20.04.06, 11:35

Вышеприводимый мой код для qsort был залит в свежеустановленный lcc-win32, под wine.
...
Почему так не может M$, несмотря на то, что авторы компилятора имеют e-mail@microsoft.com?

Ну а вот что выдает MSVC7.1:

?comp_func@@YAHPAH0@Z PROC NEAR             ; comp_func, COMDAT
 
; 9    :     if( *a < *b )
 
    mov eax, DWORD PTR _a$[esp-4]
    mov ecx, DWORD PTR _b$[esp-4]
    mov eax, DWORD PTR [eax]
    mov ecx, DWORD PTR [ecx]
    cmp eax, ecx
    jge SHORT $L638
 
; 10   :     {
; 11   :     return( -1 );
 
    or  eax, -1
 
; 14   :     {
; 15   :     return( 1 );
; 16   :     }
; 17   :     return( 0 );
; 18   : }
 
    ret 0
$L638:
 
; 12   :     }
; 13   :     else if( *b < *a )
 
    xor edx, edx
    cmp ecx, eax
    setl    dl
    mov eax, edx
 
; 14   :     {
; 15   :     return( 1 );
; 16   :     }
; 17   :     return( 0 );
; 18   : }
 
    ret 0
?comp_func@@YAHPAH0@Z ENDP              ; comp_func
_TEXT   ENDS
PUBLIC  _main
EXTRN   _qsort:NEAR
; Function compile flags: /Ogty
;   COMDAT _main
_TEXT   SEGMENT
_argc$ = 8                      ; size = 4
_argv$ = 12                     ; size = 4
_main   PROC NEAR                   ; COMDAT
 
; 22   :     qsort( arr, n, sizeof( int ), (int(__cdecl *)(const void *, const void *))comp_func );
 
    mov eax, DWORD PTR ?n@@3HA          ; n
    push    OFFSET FLAT:?comp_func@@YAHPAH0@Z   ; comp_func
    push    4
    push    eax
    push    OFFSET FLAT:?arr@@3PAHA         ; arr
    call    _qsort
    add esp, 16                 ; 00000010H
 
; 23   :     return 0;
 
    xor eax, eax
 
; 24   : }
 
    ret 0
_main   ENDP

Будем искать принципиальные отличия?

Цитата

Какой именно код?

Да я про сортировку...

Цитата

С моими опциями компиляции exe-шник занял 4704 байта.

А я отметил, что я поставил просто -O и всё. Позже по-играю с опциями компиляции и линковки.

Цитата

Расскажи - как я могу это сделать, если сортировка разным массивов мне нужна в пределах одной функции?

#include my_sort_int.h
#include my_sort_char.h
#include my_sort_чего_там_ещё_сортируем.h
 
/* Здесь туева хуча кода. */
 
void my_func( )
{
   my_sort_int( );
   my_sort_char( );
   ...
   my_sort_чего_там_ещё_сортируем( );
}

Я что-то не так делаю?

Цитата

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

"Трансильванская ересь" была после, а не до того, как стали использовать информативную запись имён функций и переменных (пардон, в букварях это так и именуется). Кстати, использование typedef позволяет даже в "структурном программировании" использовать адекватные задаче имена переменных и типов. Это надо продемонстрировать?

"Зачем указывать"? Хэх! Ну, тогда, по всей видимocти, ты работаешь компилятором... :D:D:D
Или твой код ни кто кроме тебя не читает. А прикинь -- каково разбираться в коде, который написан даже не твоим коллегой, а вообще -- иным человеком и с другой стороны планеты. Уж извини, но я предпочту видеть -- какая функция за что отвечает, а не валить всё в одну кучу, предполагая что потом кто-то будет тратить время на то, чтобы разобраться в моём бреде. Вот тут-то и начинается веселье -- тут играем, тут не играем, для этого класса данный метод вообще не реализован...

Цитата

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

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

Цитата

Если так долго мучает, так может стоит к врачу обратиться?

Дешевле не заниматься Бог весть чем.
Мне он просто не нужен -- ни в виде CommonLISP, ни как. И, кстати, я не пользуюсь Emaks. Ни как вообще.

Цитата

Ну так продемонстрируй, как у тебя без хаканяь асмовского вывода gcc получился свехмаленький бинарник, а? Если мы такие умные, то как мы избежали линковки с crt1.o, crti.o, crtbegin.o, crtend.o, crtn.o и динамической линковки с libgcc_s.so?

Молча. А ты сам подумай (понимаю, что болезненные ощущения с непривычки, но всё же). Вестимо -- без хаканья не обошлось...
Далее (просто как дополнение). А что, окромя glibc решений уже не существует? Правда? как интересно -- непременно запомню.

Кстати, тут приводился листинг от gcc. Код был довольно похожий. Также юзалась инструкция setx (не помню, l или g). Так что не так уж и плох gcc

Добавлено 20.04.06, 12:54

Цитата the_Shadow @ 20.04.06, 12:46

А ты сам подумай (понимаю, что болезненные ощущения с непривычки, но всё же).

Хамите, парниша! Здесь не ЛОР и я не анонимус.

Цитата the_Shadow @ 20.04.06, 12:46

Вестимо -- без хаканья не обошлось...

Так нафига такое решение? Не проще сразу на асме через int 0x80? Или так необходимо действовать по схеме gcc -S -> патчим результат -> as -> ld? Для продакшена такое не покатит.

Цитата the_Shadow @ 20.04.06, 12:46

А что, окромя glibc решений уже не существует?

А что, мы сейчас говорим о встраиваемых системах? Так может и VC надо взять для таких систем, чтобы честнее было?

Цитата the_Shadow @ 20.04.06, 12:46

Да я про сортировку...

Надо было компилировать с помощью g++. А вообще - это вопрос, скоре, к разработчикам STL, которая идет вместе с gcc. А не к используемым конструкциям. Ты же не удивляешься, что для того, что бы работал puts, нужет CRTL?

Цитата the_Shadow @ 20.04.06, 12:46

А я отметил, что я поставил просто -O и всё. Позже по-играю с опциями компиляции и линковки.

Цитата the_Shadow @ 20.04.06, 12:46

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

Из всей игры с опциями я к O4 добавил только ALIGN, который изменяет дефолтное выравнивание сегментов. А на вопрос: "почему оно по умолчанию равно 4KB?" я тебе не отвечу. Может быть потому, что иначе экзешник не будет совместим с 98-ыми виндами, например. Так что спор, по сути, выродился, ибо нет предмета спора.
Да и напрягает это, по-моему, только тебя.

Цитата the_Shadow @ 20.04.06, 12:46

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

Чем такой код неинформативен:

std::vector<int> vec1(...);
std::vector<char> vec2(...);
 
//...
//...
std::sort(vec1.begin(), vec1.end());
std::sort(vec2.begin(), vec2.end());

Или по имени функции тебе не понятно, что должна быть выполнена сортировка?

Цитата the_Shadow @ 20.04.06, 12:46

Или твой код ни кто кроме тебя не читает. А прикинь -- каково разбираться в коде, который написан даже не твоим коллегой, а вообще -- иным человеком и с другой стороны планеты. Уж извини, но я предпочту видеть -- какая функция за что отвечает, а не валить всё в одну кучу, предполагая что потом кто-то будет тратить время на то, чтобы разобраться в моём бреде. Вот тут-то и начинается веселье -- тут играем, тут не играем, для этого класса данный метод вообще не реализован...

Так вот, я прекрасно вижу - вызывается функция sort, которая выполняет сортировку. Что мне еще надо увидить? Все достаточно просто и прозрачно. Ничего лишниго.

Цитата

Хамите, парниша! Здесь не ЛОР и я не анонимус.

Да. Вот только и напрягаться особо желания нет. Особенно, учитывая то, что выше писалось (когда Flex предложил по-холиварничать по С vs. C++), что для раздела UNIX мне придётся в таком случае написать тему про "мелкий" код (ergo, решения есть?):

Цитата

Так нафига такое решение? Не проще сразу на асме через int 0x80? Или так необходимо действовать по схеме gcc -S -> патчим результат -> as -> ld? Для продакшена такое не покатит.

Чего-чего? Какие к чертям собачьим syscall'ы? При чём здесь это? Что вообще за бред?

Цитата

А что, мы сейчас говорим о встраиваемых системах? Так может и VC надо взять для таких систем, чтобы честнее было?

Какие к чёртовой матери "встраиваемые системы"?!? ГДЕ КОНКРЕТНО Я УПОТРЕБИЛ СЛОВО "ВСТРАИВАЕМЫЕ"?!? >:(

Это все решения, которые постучали в Вашу голову? Бедно. Мне жаль. Был лучшего мнения.

Цитата

Надо было компилировать с помощью g++. А вообще - это вопрос, скоре, к разработчикам STL, которая идет вместе с gcc. А не к используемым конструкциям. Ты же не удивляешься, что для того, что бы работал puts, нужет CRTL?

Так. А вот теперь, отче, давай по-порядку.
1. Угу. Я знаю. Вот теперь внимательно пожалуйста -- почему мне пришлось их поставить? И почему в Win я не могу поступить точно так же (при использовании M$ DEvStudio)? Более того -- учитывая то, что библиотеки поддержки С++ (времени исполнения в том числе) у меня в lin. не были установлены, я хочу по-просить тебя обойтись со своей win-системой точно так же. И дать ясный и чёткий ответ -- возможно ли это в принципе? Если, как я подозреваю, "нет", то каким же это образом Visual находится не в тесной связи с самой win и её механизмами? И как это мы можем быть уверены в чём-то при написании кода на чём-то, отличном от Visual? Или у M$ на 100% открыты все интерфейсы?

Могу привести примеры обратного. Чтобы долго не ходить -- реализация SMB-протокола. Сколько их? Как минимум -- три -- сама M$, LanManager и SAMBA. причина только одна -- M$ никогда не публиковала описание данного протокола. Вообще. Ещё примеров?

По "реализации" алгоритма на чём-то, отличном от Visual -- о примере с апплетом конторольной панели я уже говорил.

2. По вопросу к разработчикам. Если мы изначально зарубились на ядро, то тогда разработчики STL обязаны быть членами не только STL-group (условно назовём это сообщество так), но и входить в состав разработчиков gcc и, до кучи, в kernel hackers... В итоге (если мы настаиваем на внедрении) С++ и STL в частности в ядро (повторяю -- с этого всё и началось), то перед нами реальная перспектива лишиться этого самого ядра, т.к. не думаю, что все механизмы, входящие в С++ столь же тщательно оттестированы и стандартизированы, как и то, что используется в данный момент.

3. Не удивляюсь. Но могу (вопреки уважаемому мною лично мнению linuxfan'а), использовать отличные от рекомендуемых GNU реализации. Это просто как минимум того, что я могу сделать. Таким образом, во-все не факт, что puts реализован только в glibc. Всем ли делиться или нет -- уже вопрос совершенно иной. ;) На уровне исходного кода (требование POSIX) я остаюсь "совместим", а вот про бинарную реализацию -- во-все нет такого требования).

Цитата

А на вопрос: "почему оно по умолчанию равно 4KB?" я тебе не отвечу. Может быть потому, что иначе экзешник не будет совместим с 98-ыми виндами, например. Так что спор, по сути, выродился, ибо нет предмета спора.
Да и напрягает это, по-моему, только тебя.

Не напрягает во-все, ибо нечему. Мне уже всё довольно давно ясно. Просто, я обещал тебе эксперимент -- я сдержал своё обещание.
Вопросы совместимости кода для M$ с чем-то ещё, мне во-все малоинтересны. Если учитывать общую тенденцию, то под Win9x мало кто работает. А те, кто до сих пор сидит под 9х, мне как-то малоинтересны как сегмент рынка.

Цитата

Или по имени функции тебе не понятно, что должна быть выполнена сортировка?

По имени функции мне, как преимущественно "структурщику" мало понятно что именно мы сортируем.

Цитата

Так вот, я прекрасно вижу - вызывается функция sort, которая выполняет сортировку. Что мне еще надо увидить? Все достаточно просто и прозрачно. Ничего лишниго.

Угу. Так что именно мы там сортируем-то? Вот ты привёл отрывок кода. Класс! Но я не могу по данному отрывку понять -- что именно и каким образом мы сортируем. Далее. Ты мне скажешь сейчас, что сортируем мы то, что определяется конкретным случаем сортировки. И здесь я с тобой соглашусь.

Но вот кто тебе сказал, что один случай сортировки будет оптимален для любых данных, передаваемых на вход этого алгоритма? И чем тебе не нравится подход с описанием каждого случая сортировки, применяя те механизмы, которые нужны для данного конкретного случая? Или, во имя того, чтобы можно было написать один алгоритм, ты призываешь меня "свалить в одну кучу" и char и float? А, извини, зачем? Да, ещё учитывая и многое из вышеизложенного?

А можно ли на темплейтах решить задачку такого плана: есть сортировка char'ов, которая учитывает collation, и сортировка, не учитывающая его, но тоже char'ов, а еще у нас есть сортировка int'ов.

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

Цитата the_Shadow @ 20.04.06, 13:48

1. Угу. Я знаю. Вот теперь внимательно пожалуйста -- почему мне пришлось их поставить? И почему в Win я не могу поступить точно так же (при использовании M$ DEvStudio)? Более того -- учитывая то, что библиотеки поддержки С++ (времени исполнения в том числе) у меня в lin. не были установлены, я хочу по-просить тебя обойтись со своей win-системой точно так же. И дать ясный и чёткий ответ -- возможно ли это в принципе? Если, как я подозреваю, "нет", то каким же это образом Visual находится не в тесной связи с самой win и её механизмами? И как это мы можем быть уверены в чём-то при написании кода на чём-то, отличном от Visual? Или у M$ на 100% открыты все интерфейсы?

Поставив gcc ты поставил необходимые библиотеки поддержки. Я так понимаю, что ядру библиотека libglibc.so нафиг не сдалась. Но попробуй ты собрать без нее прикладное приложение, использующее стандартные средства языка, а я посмотрю на результат. Я подчеркиваю слово стандартные. Зафиксированные в стандартах C89 и C99. Если я все правильно понимаю, то в ядре есть часть, в которой реализуются всяческие malloc'и, memset'ы и прочие подобные вещи, которые входят в стандарт языка. У С++ тоже есть свои стандартные средства, которые требуют соответствующей поддержки со стороны runtime-окружения. Эти средства также зафиксированы в стандарте (C++98, C++03). Ты не удивляешься, что в ядре есть реализация методов malloc или memset. Ведь так? Тогда почему у тебя вызывает удивление возможность реализации в ядре других методов?

А всяческие отсылки к Microsoft я в данном случае считаю неуместными. К STL мелкомягкие не имеют никакого отношения.

Цитата the_Shadow @ 20.04.06, 13:48

По вопросу к разработчикам. Если мы изначально зарубились на ядро, то тогда разработчики STL обязаны быть членами не только STL-group (условно назовём это сообщество так), но и входить в состав разработчиков gcc и, до кучи, в kernel hackers... В итоге (если мы настаиваем на внедрении) С++ и STL в частности в ядро (повторяю -- с этого всё и началось), то перед нами реальная перспектива лишиться этого самого ядра, т.к. не думаю, что все механизмы, входящие в С++ столь же тщательно оттестированы и стандартизированы, как и то, что используется в данный момент.

STL - это стандартное средство языка. См. разделы стандарта ISO/IEC 14882 c 17 по 27-ой. Или словосочетание "Internation Standard" для kernel hackers - это пустой звук? И требуется еще какая-то стандартизация?

Цитата the_Shadow @ 20.04.06, 13:48

Не удивляюсь. Но могу (вопреки уважаемому мною лично мнению linuxfan'а), использовать отличные от рекомендуемых GNU реализации. Это просто как минимум того, что я могу сделать. Таким образом, во-все не факт, что puts реализован только в glibc. Всем ли делиться или нет -- уже вопрос совершенно иной. На уровне исходного кода (требование POSIX) я остаюсь "совместим", а вот про бинарную реализацию -- во-все нет такого требования).

Я тоже. Реализаций STL существует превеликое множество. Выбирай любую на вкус. Я предпочитаю STLPort.

Цитата the_Shadow @ 20.04.06, 13:48

Мне уже всё довольно давно ясно. Просто, я обещал тебе эксперимент -- я сдержал своё обещание.

Я твое обещание принял и тоже привел результаты свого эксперемента. Тебе их не удалось превзойти. Какой делаем вывод?

Цитата the_Shadow @ 20.04.06, 13:48

По имени функции мне, как преимущественно "структурщику" мало понятно что именно мы сортируем.

??? Т. е. по записи sort(some_sequence.begin(), some_sequence.end()); тебе не понятно, что сортируется последовательность some_sequence?

Цитата the_Shadow @ 20.04.06, 13:48

Угу. Так что именно мы там сортируем-то? Вот ты привёл отрывок кода. Класс! Но я не могу по данному отрывку понять -- что именно и каким образом мы сортируем. Далее. Ты мне скажешь сейчас, что сортируем мы то, что определяется конкретным случаем сортировки. И здесь я с тобой соглашусь.

Как что? То, что передано в качестве аргументов. Информации - более чем достаточно. Нужно только ее увидеть.

Цитата the_Shadow @ 20.04.06, 13:48

Но вот кто тебе сказал, что один случай сортировки будет оптимален для любых данных, передаваемых на вход этого алгоритма? И чем тебе не нравится подход с описанием каждого случая сортировки, применяя те механизмы, которые нужны для данного конкретного случая? Или, во имя того, чтобы можно было написать один алгоритм, ты призываешь меня "свалить в одну кучу" и char и float? А, извини, зачем? Да, ещё учитывая и многое из вышеизложенного?

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

Добавлено 20.04.06, 14:35

Цитата Ho Im @ 20.04.06, 14:24

А можно ли на темплейтах решить задачку такого плана: есть сортировка char'ов, которая учитывает collation, и сортировка, не учитывающая его, но тоже char'ов, а еще у нас есть сортировка int'ов.

Ну, гм, как тебе сказаь... Что-то типа такого:

template<typename RndIt, typename Pr> void sort(RndIt first, RndIt last, Pr cmpFn = std::less<RndIt::value_type>())
{
//...
//... тут реализация
//...
// для сравнения элементов используем cmpFn:
if (cmpFn(i1, i2) < 0) // что-то делаем
//...
};
 
// реализация less (упрощенно)
template<typename T> struct less
{
bool operator()(const T& e1, const T& e2)
{
return e1 < e2 ? true : false;
}
};
 
int SpecialCompare(char c1, char c2)
{
return c2 < c1;
}
 
// использование
char* str = "abcdef";
int seq[] = {1, 2, 3, 4, 5, 6, 7};
 
sort(str, str + 6, SpecialCompare);
sort(str, str + 6);
sort(seq, seq + 7);

Думаю, идея понятна.

Цитата

ты поставил необходимые библиотеки поддержки.

Нет. Если я не указал этого явно.
Поставив gcc, я просто поставил себе С + его либы, которые, как я уже устал повторять, первичны.

Цитата

Ты не удивляешься, что в ядре есть реализация методов malloc или memset. Ведь так? Тогда почему у тебя вызывает удивление возможность реализации в ядре других методов?

В ядре? memset? Нет!!! При компиляции происходит просто то, о чём мы говорили выше. memset/malloc/etc -- всё это реализовано в библиотеках. Просто, при компиляции, данный код заменяется объёктным и всё. Ни каких реализаций в ядре самого по себе memset'а или malloc'а просто нет и быть не может. Собственно, обсуждение можно просто закрывать. После этого утверждения.

Цитата

А всяческие отсылки к Microsoft я в данном случае считаю неуместными. К STL мелкомягкие не имеют никакого отношения.

А я считаю. По причине того, что провожу аналогии между двумя мирами. И знаю, что в случае с STL M$ не при делах, но вотподходы в win и lin сравнить можно... И, говоря об M$, я бы не стал утверждать, что для него можно писать код на любом компиляторе с одинаковой эффективностью кода.

Цитата

STL - это стандартное средство языка. См. разделы стандарта ISO/IEC 14882 c 17 по 27-ой. Или словосочетание "Internation Standard" для kernel hackers - это пустой звук? И требуется еще какая-то стандартизация?

Позволь -- какого языка -- того, который является основным или того, который реализован как дополнительный?

Цитата

Я твое обещание принял и тоже привел результаты свого эксперемента. Тебе их не удалось превзойти. Какой делаем вывод?

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

Цитата

??? Т. е. по записи sort(some_sequence.begin(), some_sequence.end()); тебе не понятно, что сортируется последовательность some_sequence?

Это понятно. Но что это за some_sequence? Тип обрабатываемых данных какой?
Или я работаю компилятором?

Цитата

Нужно только ее увидеть.

int и char. Но тогда скажи мне -- если ты пишешь в другом синтаксисе, то зачем мне делать то же самое?
Меня удовлетворяют другие описания -- int some_func(), char some_func(). Почему я должен (особенно, учитывая пассажик про memset в ядре) переходить на такой синтаксис, если мне это не даст ни каких преимуществ, кроме как изоляции от меня внутренностей системы?

Цитата

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

Так. Мне не нравится "подавляющее большинство случаев". Раз.
Мне не нравится "настраиваемый в этих точках". Два. Тот же массив типа char я могу сравнивать и реализовать обмен значениями аналогично тому, как я реализовал это для int. Зачем мне "настройки"?

Цитата Ho Im @ 20.04.06, 14:24

А можно ли на темплейтах решить задачку такого плана: есть сортировка char'ов, которая учитывает collation, и сортировка, не учитывающая его, но тоже char'ов, а еще у нас есть сортировка int'ов.

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

Кхм..

#include <string>
#include <vector>
#include <algorithm>
struct CollateCompare_Less
{
  const char* collate_name;
  CollateCompare(const char* name = "en_US"): collate_name(name){}
  bool operator()(const char* s1, const char* s2)
  {
    //сравнение двух строк
  }
  bool operator(){const std::string& s1, const std::string& s2)
  {
    //сравнение двух строк
  }
};
 
std::vector<string> sequence;
 
//просто сортировка
sort(sequence.begin(),sequence.end());
//с учетом collate
sort(sequence.begin(),sequence.end(),CollateCompare_Less());
sort(sequence.begin(),sequence.end(),CollateCompare_Less("ru_RU"));

Цитата Flex Ferrum @ 20.04.06, 14:27

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

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

Цитата

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

Упсссс... :D:D:D
Знаешь, Flex, уж лучше я как-нибудь по-старинке... Так надёжней, так скромней.
Кстати, библиотеки сниплетов ещё то же не отменили (и там можно найти уже готовый код).

Цитата the_Shadow @ 20.04.06, 15:32

А я считаю. По причине того, что провожу аналогии между двумя мирами. И знаю, что в случае с STL M$ не при делах, но вотподходы в win и lin сравнить можно... И, говоря об M$, я бы не стал утверждать, что для него можно писать код на любом компиляторе с одинаковой эффективностью кода.

Шад, единственно, что мне остается в таком случае ответить - считай дальше. Что либо объяснить я тебе не смогу по определению. По той простой причине, что ты не желаешь слушать ни чьих объяснений. У тебя есть gcc + linux и есть все остальное. Я уважаю твой выбор, по этому выхожу из дискуссии. Тебе действительно проще по старинке.

Цитата

то либо объяснить я тебе не смогу по определению. По той простой причине, что ты не желаешь слушать ни чьих объяснений. У тебя есть gcc + linux и есть все остальное. Я уважаю твой выбор, по этому выхожу из дискуссии.

Flex, желаю. Но достаточно детальные. Извини, я не могу пропустить вещи типа "реализаций memset'а в ядре". Это уже не технический спор. При таком раскладе спорить действительно не очем.

Пока, окромя доказательств того, что в случае с Linux я имею дело с домыслами и догадками со стороны коллег, я иных доказательств не увидел. Все предложения "починить" то, что работает, просто несостоятельны по причине того, что до начала починки, не худо бы понимать -- что же мы чиним-то.

Цитата the_Shadow @ 20.04.06, 15:47

Flex, желаю.

Разве? Ок.

Цитата the_Shadow @ 20.04.06, 15:47

Извини, я не могу пропустить вещи типа "реализаций memset'а в ядре".

Ок. Я могу допустить (и это скорее всего), что вместо вызова memset компилятор делает inline-подстановку. Я могу это допустить также для функций типа strcmp, strcpy и проч. Но все ли функции из стандартной библиотеки C можно заменить такими вот подстановками?
Да, согласен. Я не копался в ядре, и не вхожу в команду kernel hackers. По этому вполне логично, что я могу чего-то не знать. Это - вполне нормально. И не может служить поводом для негодования.

Цитата the_Shadow @ 20.04.06, 15:47

Пока, окромя доказательств того, что в случае с Linux я имею дело с домыслами и догадками со стороны коллег, я иных доказательств не увидел.

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

Цитата the_Shadow @ 20.04.06, 15:32

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

Достаточно голословное утверждение. Не подтвержденное ничем.

Цитата the_Shadow @ 20.04.06, 15:32

Позволь -- какого языка -- того, который является основным или того, который реализован как дополнительный?

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

Цитата the_Shadow @ 20.04.06, 15:32

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

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

Цитата the_Shadow @ 20.04.06, 15:32

Это понятно. Но что это за some_sequence? Тип обрабатываемых данных какой?
Или я работаю компилятором?

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

Цитата the_Shadow @ 20.04.06, 15:32

int и char. Но тогда скажи мне -- если ты пишешь в другом синтаксисе, то зачем мне делать то же самое?
Меня удовлетворяют другие описания -- int some_func(), char some_func(). Почему я должен (особенно, учитывая пассажик про memset в ядре) переходить на такой синтаксис, если мне это не даст ни каких преимуществ, кроме как изоляции от меня внутренностей системы?

Шад, точно также и я не должен принимать чей-то стиль. Ведь так?

Цитата the_Shadow @ 20.04.06, 15:32

Так. Мне не нравится "подавляющее большинство случаев". Раз.

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

Цитата the_Shadow @ 20.04.06, 15:32

Мне не нравится "настраиваемый в этих точках". Два. Тот же массив типа char я могу сравнивать и реализовать обмен значениями аналогично тому, как я реализовал это для int. Зачем мне "настройки"?

Давай теперь уже я начну возмущаться, что

Цитата the_Shadow @ 20.04.06, 15:47

имею дело с домыслами и догадками со стороны коллег

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

Цитата mo3r @ 20.04.06, 15:32

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

Ну, всего же ведь учесть нельзя? Тем более, что в stl есть ряд альтернатив, которые можно вполне себе использовать вместо std::sort.

Добавлено 20.04.06, 16:19

Цитата the_Shadow @ 20.04.06, 15:47

Все предложения "починить" то, что работает, просто несостоятельны по причине того, что до начала починки, не худо бы понимать -- что же мы чиним-то.

А кто-то предалагал что-то чинить?

Цитата

А кто-то предалагал что-то чинить?

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

Добавлено 20.04.06, 18:50
Ну и, Флекс, в конце концов, добрый дядя Кнут посвятил сортировке и поиску весь третий том своего фундаментального труда. Небрежное «фи» было высказано только в сторону пузырьковой сортировки, причем была указана ее ниша, где оптимальнее алгоритм найти трудно. Это значит, что сортировка Хоара, хотя и является неплохим общим знаменателем, может пролететь для нужной в данном конкретном случае задачи, и с ней пролетит «стандартное» решение.

...И тогда мы мало-помалу вернемся к «методу Шада», но у нас будет уже два разных подхода — продемонстрированный им и продемонстрированный тобой. Две сущности вместо одной.

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

Сообщение отредактировано: Ho Im - 20.04.06, 18:50