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

вот вам кстати, и ОС, написаная на C++.
http://l4ka.org/projects/pistachio/

Цитата

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

Конечно! А что, кто-то qsort смог "переплюнуть" на малом числе значений? Или для того, чтобы отранжироавать 5-10 значений, о которых ивестно только то, что они, к примеру, int, нужно писать свой алгоритм? Какая странная логика... А я использую qsort и не парюсь, т.к. мне гарантировано, что на уровне исходного кода энтот самый qsort будет в любой UNIX-системе одинаков... В то же время, сли передо мной стоит задача отсортировать туеву хучу значений, я задумаюсь. Вплоть до создания абстрактного типа данных. Если оно будет нужно для решения задачи.

Остальное народ уже откомментировал.

2 linuxfan, по-моему...
По поводу AMD-процов. Довольно интересная картинка выстраивается, однако... Я долго ломал репу по поводу того, а почему, собственно, не используется "хранение кадра стека" и каким образом Intel и AMD совместимы. Ведь, тогда получается, что Intel-проги на AMD крайне не стабильны будут...

Ломал-ломал... Пока не выяснил, что на AMD применяется 128-и битная "red zone" в самом процессоре, куда кадр стека и сохраняется. Т.е., хочешь-не хочешь, а оно сработает. Как там в деталях оно сделано -- не выяснял. Мне гораздо важнее то, что я могу блокировать генерацию соотв. кода для AMD и не заниматься сексом со своими мозгами... :D:D:D Я, всё-таки программист, а не компилятор... :D:D:D

2 Flex.
Ну, как мы и говорили...
Вот пример равнозначного кое в чём твоему кода. Так же, во время компиляции макрос swap( a, b ) разворачивается... Но места стока не кушает...

#define swap( a, b )\
({ \
typedef _tp = a; \
_tp tmp = a; \
a = b; \
b = tmp; \
})

Работает это вне зависимости от передаваемого типа. По ходу "пьесы" тип определяется и... срабатывает.

Да. Я использую нестандартное средство -- "сложный макрос" (на самом деле, это просто -- "составной оператор" (блок команд, заключаемый в скобки)). Более того! Это всё гарантированно работает в gcc. За другие компиляторы -- не знаю. Лень было проверять. Просто, мне хотелось получить решение, которе было бы столь же универсальным, сколь и твоё. Вот и всё.

Цитата the_Shadow @ 21.05.06, 08:05

За другие компиляторы -- не знаю. Лень было проверять.

Можешь и не проверять - это уникальное расширение GCC.

typedef? Или "составные операторы"?
:D:D:D

Цитата the_Shadow @ 21.05.06, 08:05

Ну, как мы и говорили...
Вот пример равнозначного кое в чём твоему кода. Так же, во время компиляции макрос swap( a, b ) разворачивается... Но места стока не кушает...

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

void swap(int a, int b)
{
// тут какая-то реализация...
}

если перед ним определен твой макрос.

3. Увы и ах, но непереносимо. Т. е. не соответствует стандарту языка, т. к. использует расширения, специфичные для конкретного компилятора.

Цитата

1. Несколько не соответствует моему варианту решения (в нем для целых типов был предусмотрен специальный способ обмена).

В констексте решения... А зачем? Я упростил решение.

Цитата

2. Не позволяет реализовывать собственную функцию обмена для конкретных типов. Давай вместе подумаем, что будет с таким кодом:

Цитата

если перед ним определен твой макрос.

Ничего не будет. Можно переименовать макрос или ф-ю? И какой смысл (окромя путаницы) в обноимённом макросе и функции?

Далее. Вообще-то, имена макросов рекомендуется писать не как swap( a, b ), а как SWAP( a, b ) для того, чтобы видеть при вызове -- что именно будет вызвано. Иначе, запутается не столько компилятор, сколько программист.
Замечу, что я сознательно написал макрос в нижнем регистре, т.к. хотелось узнать -- сделает Flex этот комментарий или нет? Узнал. :D:D:D

Цитата

3. Увы и ах, но непереносимо. Т. е. не соответствует стандарту языка, т. к. использует расширения, специфичные для конкретного компилятора.

Что именно? typedef? С каких это пор?
Или "составной оператор"? Отлично! А что, в VC++ вдруг отменили запись многострочных макросов? Когда? Т.е., различие не более, чем "косметическое"?

Далее. А зачем мне это переносить в VC++ (например), если более толковый в части кросс-компиляции именно GCC? Разве его на Solaris нет? Или под M$?

Цитата the_Shadow @ 21.05.06, 09:19

В констексте решения... А зачем? Я упростил решение.

Шад, условие задачи было такое. Там я явно написал, что для встроенных типов должен быть предусмотрен специальный способ обмена. Да хоть через asm + xchg (тут уже специфично для компилятора и платформы).

Цитата the_Shadow @ 21.05.06, 09:19

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

Я, наверное, перестал понимать принцип работы макроподстановок. А должно быть примерно следующее:

void
({
typedef _tp = int a;
_tp tmp = int a;
int a = int b;
int b = tmp;
})
{
// тут какая-то реализация...
}

Цитата the_Shadow @ 21.05.06, 09:19

Можно переименовать макрос или ф-ю?

Можно. А (задаю твой любимый вопрос) зачем?

Цитата the_Shadow @ 21.05.06, 09:19

Что именно? typedef? С каких это пор?
Или "составной оператор"? Отлично! А что, в VC++ вдруг отменили запись многострочных макросов? Когда? Т.е., различие не более, чем "косметическое"?

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

Цитата the_Shadow @ 21.05.06, 09:19

Далее. А зачем мне это переносить в VC++ (например), если более толковый в части кросс-компиляции именно GCC? Разве его на Solaris нет? Или под M$?

Шад, мы говорим о языке, или его реализации в конкретном компиляторе? Мне казалось, что о первом. А если о первом (т. е. о языке), то всяческие нестандартные расширения должны отметаться, ибо ересь.

Ты поспешил с ответом, пока я корректировал свой... :D:D:D

Цитата the_Shadow @ 21.05.06, 09:31

Ты поспешил с ответом, пока я корректировал свой...

Ты на остальную часть поста ответь.

Цитата

Ты на остальную часть поста ответь.

Уговорил. Сижу, набираю полный аналог твоего кода. Проверю в gcc (Linux) и WinXP (VC++ 7.0). Тогда и поговорим.

По макросу -- ты не прав. Как раз фишка в том, чтобы не указывать принудительно тип, а получить (это макрос! на этапе компиляции) тип используемый в данном случае и отработать по нему.

А не прав по причине того, что в С и С++ макросы работают, пардон, но по-разному. Здесь играет то, что в С++ более строгая проверка типов. И то проверить нужно... В g++ я этого трюка не пробовал, возможно и не сработает.

Цитата the_Shadow @ 21.05.06, 09:43

А не прав по причине того, что в С и С++ макросы работают, пардон, но по-разному.

По-разному - это, пардон, как? Раскрой, плз, эту разницу детально.

Цитата

По-разному - это, пардон, как? Раскрой, плз, эту разницу детально.

Вообще говоря, С++ строже (и существенно) в части проверки типов, нежели С.

Цитата the_Shadow @ 21.05.06, 09:47

Вообще говоря, С++ строже (и существенно) в части проверки типов, нежели С.

А при чем тут макросы? Читаем раздел 5.1.1.2 (Translation phases) стандарта языка С:

Цитата

4. Preprocessing directives are executed, macro invocations are expanded, and
_Pragma unary operator expressions are executed. If a character sequence that
matches the syntax of a universal character name is produced by token
concatenation (6.10.3.3), the behavior is undefined. A #include preprocessing
directive causes the named header or source file to be processed from phase 1
through phase 4, recursively. All preprocessing directives are then deleted.

Т. е. мы видим, что раскрытие макросов, прагм, инклюдов и прочей препроцессорной братии происходит на 4-ом шаге, а собственно компиляция:

Цитата

7. White-space characters separating tokens are no longer significant. Each
preprocessing token is converted into a token. The resulting tokens are
syntactically and semantically analyzed and translated as a translation unit.

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

Цитата the_Shadow @ 21.05.06, 09:06

typedef? Или "составные операторы"?

И такое использование typedef и составной оператор, возвращающий начение.

Сообщение отредактировано: trainer - 21.05.06, 11:57

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

Могу ещё GCC'шный __extension__ поставить. Для ясности.

Вопрос был? Был. За расширенным описаловом сюда, pls -> http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_4.html по поводу typedef и по поводу "compound expressions".

Возможно, что в следующей версии стандарта оно и будет... Равно как в С99 появилось многое из того, что было ранее "прерогативой" С++. Вот только работать оно будет по-проще. А, пока, у меня есть инструмент, который позволяет мне решать мои задачи. Вот и всё. Если кто-то по каким-то соображениям не желает их решать так же (с использованием возможностей инструмента), то я-то при чём? Или GCC?

P.S. Да, если кому будет интересно, то вывод препроцессора производится через опцию -E... :D:D:D
P.P.S. Замечу дополнительно -- учитывая то, что данное описание расширений дано для версии 2.95.3 и то, что именно эта версия идёт для компиляторов под PalmOS (m68k & arm), то... делайте выводы... :D:D:D