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

Цитата the_Shadow @ 20.07.06, 10:36

Отчасти. Мы, знаешь ли, в заголовочном файле самой системы колупаемся... :D:D
Таким образом, именно этот файл включается в обязательном порядке в модуль, а не наоборот. Именно отсюда берётся ряд описаний, а не сюда привносятся извне. Отсюда и то, как это написано.

Так вот и был вопрос - в чем существенная разница между описанием констант как enum и как define? Т. е. почему требуется именно #define, а не enum?

Цитата the_Shadow @ 20.07.06, 10:36

Увеличь уровень оптимизации до -O3 и глянь на ассемблерный код. Да. Ещё и установку фрейма стека выруби на фиг.

Ты это к чему?
Ок. Давай на примерах. Берем текст:

#include <stdio.h>
 
#define d_min(a, b) ((a) < (b) ? (a) : (b))
template<typename T> inline T i_min(const T& a, const T& b) {return a < b ? a : b;}
 
int main()
{
    printf("%d", d_min(30, 20));
    printf("%d", i_min(30, 20));
}

С O3 получаем код:

    .type   main, @function
main:
.LFB14:
    pushl   %ebp
.LCFI0:
    movl    %esp, %ebp
.LCFI1:
    subl    $8, %esp
.LCFI2:
    andl    $-16, %esp
    subl    $24, %esp
    pushl   $20
    pushl   $.LC0
.LCFI3:
    call    printf
    popl    %eax
    popl    %edx
    pushl   $20
    pushl   $.LC0
    call    printf
    xorl    %eax, %eax
    leave
    ret

А теперь объясни мне, дорогой Шад, почему вот этот код:

int main()
{
    int a = 10, b = 20;
    printf("%d\n", d_min(++ b, ++ a));
    printf("%d\n", i_min(++ b, ++ a));
}

Вместо "11 12" выдает "12 13"? Т. е. макрос d_min не является эквивалентом функции i_min, т. к. имеет дополнительный и неприятный сайдэффект. Будет еще хуже, если в качестве аргументов в d_min передать вызовы других функций. Для i_min эти функции будут вызваны по одному разу. А для d_min - какая-то - один, какая-то - два. Причем какая именно - предсказать заранее нельзя.

Цитата the_Shadow @ 20.07.06, 10:36

Ииии... Что дальше? На уровне кода ассемблера это мало влияет на что-либо. Особенно, учитывая приколы с оптимизацией (см. выше). Замечу, что в цинде можно использовать naked ф-ии для достижения аналогичного результата.

На уровне ассемблера - да. Мало. А на уровне обработки исходного текста - очень даже сильно. Вот тебе другий пример:

void foo(int (*f)(const int&, const int&))
{
   printf("%d\n", f(10, 20));
}
 
int main()
{
   // я могу написать так:
   int i_min(10);
   // но не могу так:
   int d_min(10);
 
   // могу так:
   foo(i_min<int>);
   // но не могу так:
   foo(d_min);
}

Можно показать еще различия. Но в любом случае - inline-функция и макрос далеко не эквивалентные сущности.

Цитата the_Shadow @ 20.07.06, 10:36

И правильно. Макрос делает только одно -- он просто определяет какой-то код. Не нужно -- не используй, но, если используешь, то подставится всё по месту и, без особых трабл

Вопрос - как определяет. А определяет просто - грубым хирургическим вмешательством в текст программы. Это все равно, что если бы хрург использовал не скальпель, а тупой мясницкий нож.

Цитата the_Shadow @ 20.07.06, 10:36

Первое -- не правда.
Второе -- правда отчасти.

Первое - правда, правда. И второе - тоже правда. Примеры - см. выше.

Добавлено 20.07.06, 11:24

Цитата the_Shadow @ 20.07.06, 10:36

И прежде всего сам стандарт, и сам язык. 100%. по этой причине, для ядра его и не используют. Ты прав. :D:D

Блин, Шад, ну ё-моё. Ты используешь в ядре тип double? А массивы с неопределенным количеством элементов? А функции из стандартной библиотеки С? А ведь они описаны в стандарте. Значит С для ядра - такой же избыточный, как и С++. Потом. Русский язык насчитывает многие дясятки тысяч слов. Ты их все используешь? Значит ли это, что русский язык - избыточен для повседневного общения? Короче - аргумент фтопку. Ибо чушь полнейшая.

Цитата the_Shadow @ 20.07.06, 10:36

В контексте "ядер"? В самом понятии "язык С++ для ядер". Посуди сам -- если мы оговориваем сразу то, что мы не используем семантику языка в полном объёме, то тогда зачем нам его синтаксис? Где логика?

Опять аргумент фтопку. Я тебе задал конкретный вопрос - где в приведенных фрагментах наблюдается избыточность языка. А ответ свелся к: "язык избыточен потому, что избыточен".

Цитата the_Shadow @ 20.07.06, 10:36

Сделай милость -- глянь на описание той же kmalloc() (см. /usr/src/linux/include/linux/slab.h). Ничего странного не заметил? :D:D

Ты намекаешь на спецификатор inline? Ну, я рад тому, что ребята таки осознали полезность inline и включили его в реализацию С.

Цитата the_Shadow @ 20.07.06, 10:36

С точки зрения синтаксиса -- да. А с точки зрения семантики языка?

Никак. Еще раз (для тех, кто в танке): никак. Хотя видимость полей - это именно семантика, а не синтаксис.

Это сообщение было перенесено сюда или объединено из темы "Windows vs Linux - Прогаммирование"

Цитата Flex Ferrum @ 20.07.06, 11:15

Вместо "11 12" выдает "12 13"? Т. е. макрос d_min не является эквивалентом функции i_min, т. к. имеет дополнительный и неприятный сайдэффект.

Я выше уже приводил пример с группировкой значений в составной оператор. Ты, правда, заметил, что это -- gcc-specific (я, вообще говоря, этого и не скрывал сразу). Так, говоришь, в чём там грабля-то? :D:D:D

Цитата Flex Ferrum @ 20.07.06, 11:15

Так вот и был вопрос - в чем существенная разница между описанием констант как enum и как define? Т. е. почему требуется именно #define, а не enum?

Это с чего ты взял? 8-/ Я, к примеру, такого вопроса вообще не задавал...

Добавлено 20.07.06, 11:40

Цитата Flex Ferrum @ 20.07.06, 11:15

На уровне ассемблера - да. Мало. А на уровне обработки исходного текста - очень даже сильно.

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

Если писать "легко", то лучше всего форт, лисп или пролог использовать. Но, правда, не для ядра, но... За то "легко". Ещё, правда, Clarion для M$-DOS вспоминается. То же для поклонников "лёгкого написания". Правда, более-менее серьёзные вещи приходилось делать через оверлеи, т.е., через зад, но там вся система такая была...

Цитата Flex Ferrum @ 20.07.06, 11:15

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

"За неимением кухарки, имеем дворника". Извини, задача, мягко говоря, не тривиальная.

Цитата Flex Ferrum @ 20.07.06, 11:15

Блин, Шад, ну ё-моё. Ты используешь в ядре тип double? А массивы с неопределенным количеством элементов? А функции из стандартной библиотеки С? А ведь они описаны в стандарте. Значит С для ядра - такой же избыточный, как и С++. Потом. Русский язык насчитывает многие дясятки тысяч слов. Ты их все используешь? Значит ли это, что русский язык - избыточен для повседневного общения? Короче - аргумент фтопку. Ибо чушь полнейшая.

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

Добавлено 20.07.06, 11:42

Цитата Flex Ferrum @ 20.07.06, 11:15

Ты намекаешь на спецификатор inline? Ну, я рад тому, что ребята таки осознали полезность inline и включили его в реализацию С. :)

Если бы только на это...

Это сообщение было перенесено сюда или объединено из темы "Windows vs Linux - Прогаммирование"

Цитата the_Shadow @ 20.07.06, 10:09

зачем тогда придуман class? И каковы отличия class и struct?

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

Это сообщение было перенесено сюда или объединено из темы "Windows vs Linux - Прогаммирование"

Цитата bugger @ 20.07.06, 11:54

если не так, то можете забросать меня камнями.

Да полно те, ты просто впервые на таком споре, видимо... :D:D:D
У нас с Flex'ом и Hunter'ом полнейшее понимание. То, что посылаем друг-друга -- не более сем дружеская улыбка... :D:D:D

Добавлено 20.07.06, 12:07
Если честно, то, публикуя ссылку на то, как vnode определено в netbsd, я просто заметил, что отдельные механизмы ООП (не путать с ООГ!) доступны и в "стандартном" С. Но вот на уровне асм-кода оно зачастую малоразличимо. В случае с ядром, в связи с нетипичностью данного случая, оно зачастую играет огромнейшую роль. Выше уже сказал почему.

Кроме того, вполне нетривиальная задача может быть решена (и семантически в том числе!) довльно интересно. GCC к этому располагает.

bugger, более того, при програмировании даже под PalmOS, ряд таких возможностей остаётся. Я слабо знаком с PODS, но знаю что и там -- gcc. Правда, я тем же gcc пользуюсь из-под Linux. Здесь оно естественнее смотрится.

Это сообщение было перенесено сюда или объединено из темы "Windows vs Linux - Прогаммирование"

Цитата the_Shadow @ 20.07.06, 11:31

Я выше уже приводил пример с группировкой значений в составной оператор. Ты, правда, заметил, что это -- gcc-specific (я, вообще говоря, этого и не скрывал сразу). Так, говоришь, в чём там грабля-то? :D:D

Это где?

Цитата the_Shadow @ 20.07.06, 11:31

Это с чего ты взял? 8-/ Я, к примеру, такого вопроса вообще не задавал...

Вот с чего:

Цитата BugHunter @ 20.07.06, 06:14

а вот этого хорошо было бы избавиться. Какой смысл определять эти #define-ы в теле класса/структуры, если они (дефайны) всё равно плюют на C/C++ области видимости? (т.е. доступны и в том классе, который объявлен ЗА текущим)?
enum-ы или (в крайнем случае) статические константы в стиле C++ или тут былы бы хорошим решением.

это именно этот самый вопрос - "зачем использовать дефайны, если есть енумы?

Цитата the_Shadow @ 20.07.06, 11:31

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

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

Цитата the_Shadow @ 20.07.06, 11:31

Если бы только на это...

А что еще?

static inline void *kmalloc(size_t size, int flags)

ты на флаги намекаешь?

Цитата the_Shadow @ 20.07.06, 11:31

Блин, да что ты к С-то привязался? Там от С в чистом виде -- только синтаксис. А по семантике -- ассемблер голимый.

Так а почему не сразу на ассемблере? Зачем нам дополнительный гемморой? Прикрути к ассемблеру препроцессор, реализуй на нем нужные для разработки конструции - и вперед. В чем проблема то? Зачем нужен "портируемый ассемблер" в виде языка С, если уже есть ассемблеры, синтаксис которых не зависят от платформы? Зачем нам всякие массивы, структуры, объединения, inline-функции, да и функции вообще, дефайны, и т. д. и т. п.? Ведь нам же нужен ассемблер? Так и бери его. Чего ты засоряешь свой моск всякой фигней типа языков высокого уровня? Главное ведь - как это будет выглядеть в ассемблере. Ты сам это сказал.

Добавлено 20.07.06, 12:09

Цитата the_Shadow @ 20.07.06, 11:58

Если честно, то, публикуя ссылку на то, как vnode определено в netbsd, я просто заметил, что отдельные механизмы ООП (не путать с ООГ!) доступны и в "стандартном" С. Но вот на уровне асм-кода оно зачастую малоразличимо. В случае с ядром, в связи с нетипичностью данного случая, оно зачастую играет огромнейшую роль. Выше уже сказал почему.

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

Это сообщение было перенесено сюда или объединено из темы "Windows vs Linux - Прогаммирование"

Цитата bugger @ 20.07.06, 11:54

class относится к миру ООП, а struct - к миру без ООП.

На самом деле, с точки зрения синтаксиса, Flex абсолютно прав. С точки зрения семантики -- прав и ты и я. Дело в том, что по логике вещей, приведённый выше file.h, следовало бы переписать семантически более корректно. Тогда можно было бы говорить об удобстве чтения кода. А так... Ни два, ни полтора.

Это сообщение было перенесено сюда или объединено из темы "Windows vs Linux - Прогаммирование"

Цитата the_Shadow @ 20.07.06, 11:58

bugger, более того, при програмировании даже под PalmOS, ряд таких возможностей остаётся. Я слабо знаком с PODS, но знаю что и там -- gcc. Правда, я тем же gcc пользуюсь из-под Linux. Здесь оно естественнее смотрится.

gcc и в симбиане тоже используется. это я так, к слову.

Это сообщение было перенесено сюда или объединено из темы "Windows vs Linux - Прогаммирование"

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

С точки зрения семантики -- прав и ты и я. Дело в том, что по логике вещей, приведённый выше file.h, следовало бы переписать семантически более корректно.

Как?

Это сообщение было перенесено сюда или объединено из темы "Windows vs Linux - Прогаммирование"

Цитата Flex Ferrum @ 20.07.06, 12:07

Зачем нужен "портируемый ассемблер" в виде языка С, если уже есть ассемблеры, синтаксис которых не зависят от платформы?

Ты, по-моему, намекаешь на NASM? В топку его. К терапевту по-соседству. Спасибо. Я это уже проходил.

Цитата Flex Ferrum @ 20.07.06, 12:07

Зачем нам всякие массивы, структуры, объединения, inline-функции, да и функции вообще, дефайны, и т. д. и т. п.? Ведь нам же нужен ассемблер? Так и бери его. Чего ты засоряешь свой моск всякой фигней типа языков высокого уровня? Главное ведь - как это будет выглядеть в ассемблере. Ты сам это сказал.

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

Цитата Flex Ferrum @ 20.07.06, 12:07

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

Поздно, батенька, NetBSD снесена. Начисто. Просто, колупался с ней, увидел, да и привёл примерчик. Мн еоттуда одно решение было нужно. Не это... Для этого в Linux более толковые методы есть (я про VFS et al).

Добавлено 20.07.06, 12:28

Цитата Flex Ferrum @ 20.07.06, 12:10

Как?

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

Цитата bugger @ 20.07.06, 12:10

gcc и в симбиане тоже используется. это я так, к слову.

Да... Под Linux есть, если не ошибаюсь, toolchain.

Это сообщение было перенесено сюда или объединено из темы "Windows vs Linux - Прогаммирование"

Цитата the_Shadow @ 20.07.06, 12:24

Ты, по-моему, намекаешь на NASM? В топку его. К терапевту по-соседству. Спасибо. Я это уже проходил.

Ну так ведь ассемблер? Портируемый? Значит должен подходить. Ведь тебе нужен (по твоим словам) именно "портируемый ассемблер" Или не все портируемые ассемблеры одинаково хороши? Значит, нужно что-то еще? Ты уж определись...

Цитата the_Shadow @ 20.07.06, 12:24

Тогда, извини, а зачем производится ассемблирование кода, после того, как всяко-разные анализаторы его проанализируют? Или, сон на потолке способствует чему-то? Или есть другие пути? С пользуется довольно малым набором "кнопочек" и "рычажков", но позволяет пользоваться ими удобно...

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

Цитата the_Shadow @ 20.07.06, 12:24

Поздно, батенька, NetBSD снесена.

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

Добавлено 20.07.06, 12:34
ЗЫ: А флаги я и в new могу передать. Так что, батенька, наблюдается явный недостаток аргументов с вашей стороны. Прямо таки полное их отсутствие.

Это сообщение было перенесено сюда или объединено из темы "Windows vs Linux - Прогаммирование"

Да? Ну и хорошо... :D:D:D

Цитата Flex Ferrum @ 20.07.06, 12:33

Ну так ведь ассемблер? Портируемый? Значит должен подходить. Ведь тебе нужен (по твоим словам) именно "портируемый ассемблер" Или не все портируемые ассемблеры одинаково хороши? Значит, нужно что-то еще? Ты уж определись... :)

Определился, уверяю тебя... И мне хватает С (по ряду причин). Первая и самая главная -- этот язык уже есть, он принят сообществом для тех задач, которые мне интересны. И оно работает. Это раз.
Два. Проверяя код (иной раз надо это делать, всё-таки), я вижу результат. Сравниваю с аналогами -- опять вижу результат. Мне этого довольно.
И последнее. Судя по "тенденциям", как на С++ ядра UNIX не писали, так и не пишут. Полагаю, что если бы всё было так звездасто, как тут супер-бизоны С++ излагают, то всё было бы уже давным-давно на С++. Ан нет... Ну, да ладно. :D:D:D

Цитата Flex Ferrum @ 20.07.06, 12:33

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

И то правда. Правда, мне вовсе не ясно какими заклинаниями из исходника < 1024 байта (выше в данном треде и раньше) ты получил 14KB ассемблерного кода... Это так для меня и тайна... Но, видимо, код не пухнет... :D:D:D Не пухнет... не пухнет... Не забыть бы... :D:D:D

Цитата Flex Ferrum @ 20.07.06, 12:33

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

Я? Наезжаю? Да полноте... Я просто разъясняю почему на С писано, а не на С++... :D:D:D
Конечно, я думаю, что нужно добавить аргументофффф... Изволь:
http://www.eventhelix.com/RealtimeMantra/basics/ComparingCPPAndCPerformance.htm
http://www.eventhelix.com/RealtimeMantra/basics/ComparingCPPAndCPerformance2.htm
http://www.eventhelix.com/RealtimeMantra/basics/object_oriented_programming_in_c.htm
Я начинал отсель... И отсель -> http://unthought.net/c++/c_vs_c++.html

Впрочем, я наезжаю не более, чем отдельные товарисчи, искренне полагающие что именно gettext отрисовывает виджеты. ;)

Цитата Flex Ferrum @ 20.07.06, 12:33

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

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

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

Это сообщение было перенесено сюда или объединено из темы "Windows vs Linux - Прогаммирование"

Цитата the_Shadow @ 20.07.06, 13:10

И то правда. Правда, мне вовсе не ясно какими заклинаниями из исходника < 1024 байта (выше в данном треде и раньше) ты получил 14KB ассемблерного кода... Это так для меня и тайна... Но, видимо, код не пухнет... :D:D Не пухнет... не пухнет... Не забыть бы... :D:D

Гонишь Шад. Ой гонишь. Держи:

// тут было много кода

Этот код скомпилировался в 4881 байт ассемблерного текста. Абсолютно аналогичный алгоритм, но написанный на С скомпилировался в 5981 байт. А ручки то - вот они.

Добавлено 20.07.06, 13:50

Цитата the_Shadow @ 20.07.06, 13:10

Два. Проверяя код (иной раз надо это делать, всё-таки), я вижу результат. Сравниваю с аналогами -- опять вижу результат.

Плохо сравниваешь. У меня другие результаты получаются.

Цитата the_Shadow @ 20.07.06, 13:10

Конечно, я думаю, что нужно добавить аргументофффф... Изволь:

Скинь сюда некоторые из них. А то, понимаешь, проблемы с доступом...

Цитата the_Shadow @ 20.07.06, 13:10

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

Я уже как-то (в паралельных темах) говорил о вреде догматизма...

Это сообщение было перенесено сюда или объединено из темы "Windows vs Linux - Прогаммирование"

Цитата Flex Ferrum @ 20.07.06, 13:48

Гонишь Шад. Ой гонишь.

Ну, да... Конечно... Делать мне не хрена больше.

Цитата Flex Ferrum @ 19.04.06, 12:04

после стрипа занял 2932 байта. Ассемблерный листинг - на 14 кб.

Цитата Flex Ferrum @ 20.07.06, 13:48

А ручки то - вот они. :)

Больше не запихивай их ни куда... :D:D:D

Цитата Flex Ferrum @ 20.07.06, 13:48

Плохо сравниваешь. У меня другие результаты получаются.

Ну, видимо, мои доводы (уже приводившиеся) не были замечены. Я чем-то могу помочь?

Цитата Flex Ferrum @ 20.07.06, 13:48

Скинь сюда некоторые из них. А то, понимаешь, проблемы с доступом...

Хрена се... Потом глянь, из дома... Там интересный код на С & C++. Для сравнений, если оооочень хочешь, можем поиграть с этим кодом.

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

Цитата Flex Ferrum @ 20.07.06, 13:48

Я уже как-то (в паралельных темах) говорил о вреде догматизма...

А я -- о подмене одних догматов другими (в том числе).

Цитата the_Shadow @ 20.07.06, 14:25

Цитата (Flex Ferrum @ 19.04.06, 16:04)
после стрипа занял 2932 байта. Ассемблерный листинг - на 14 кб.


Цитата (Flex Ferrum @ Сегодня, 17:48)
А ручки то - вот они.

Больше не запихивай их ни куда... :D:D

Да. При желании можно и больший код получить. А можно и меньший. Тут ведь все от точек приложения и произрастания рук зависит.

Цитата the_Shadow @ 20.07.06, 14:25

Ну, видимо, мои доводы (уже приводившиеся) не были замечены.

Какие именно? Достаточно ссылок на посты. Но лучше цитатами.

Цитата the_Shadow @ 20.07.06, 14:25

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

Ок.

Добавлено 20.07.06, 14:30

Цитата the_Shadow @ 20.07.06, 14:25

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

По причине, опять же, отсутствия доступа к оному.

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

С другой стороны. Да. Есть такой ассемблер как NASM. Вроде, даже кросс-платформенный. Но здесь у него беда в другом -- как и любой асм, он оперирует с данными на уровне регистров. Следовательно, такой асм привязан к регистрам целевой системы, далее он привязан к целевой платформе (тот же NASM живёт неормально только на Intel-архитектуре, уж извините, на SPARC я его не видел, хотя, говорят, есть это чудо и там). И, как только мы сталкиваемся с более-менее серьёзными вопросами кросс-платформенности, мы оказываемся в... правильно. В попе.

С обошёл это ограничение. Да. В основе С лежит в итоге именно ассемблер. Ну, и? Что мне нужно для портирования приложения с платформы на платформу? Здесь все вспомнили про стандарты POSIX, которые позволяют говорить о "совместимости на уровне исходных кодов" при условии чёткого соблюдения требований POSIX, которые накладывают ряд ограничений. И что мне нужно было бы для переноса того же приложения на асме? Как минимум -- подкорректировать исходный код, причём, в ряде случаев -- переписать его от нуля. Здорово!

Так что, я, конечно, не знаю как там с догматикой, но с этой точки зрения всё довольно разумно. Правда, когда мне вспоминают о том, что С++, вроде как надмножество С, я не готов это принимать "ровно". Уж извините, но так говорить может только не программист. Или программист, не понимающий того, что С++ -- отдельный язык, имеющий свои собственные синтаксис и семантику. Если бы всё было именно так, то незачем было бы городить совершенно новый огород -- можно было бы пойти по пути Стива Джоббса и кумпании "NextSTEP" и остановиться на "C c классами", aka Objective-C. Ан нет... Не остановились. И я резко реагирую на hot-mix (с понтом дела, С++, но сплошь и рядом есть "С-вставки"). Чуточку беременной, по всей видимости, быть невозможно -- либо-либо.