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

Т. е. так и записываем: в стандартном С (соответствующем ISO 9899-C99) нет средств для реализации описанной задачи. А что там предлагают различные конкретные реализации - суть ересь к стандарту не относящаяся. Приведенное же мною решение лежит полностью в рамках стандарта ISO IEC 14882-1998.

Добавлено 21.05.06, 20:13
Хотя согласен. В изначальной формулировке требования использовать только стандартизованные средства языка нет. Но все равно - приведенное решение покрывает только одно из трех поддтребований задачи.

Цитата

В изначальной формулировке требования использовать только стандартизованные средства языка нет. Но все равно - приведенное решение покрывает только одно из трех поддтребований задачи.

Экий ты, право, привередливый... То то не так, то это не эдак... :D:D:D
Я же не подписывался на создание полнофункционального аналога твоего кода? Или мне делать более не чего? :D:D:D
Я продемонстрировал возможность самого по себе компилятора использовать конструкции, которые позволяют делать жизнь более удобной. Вот и всё...

Если нужно полное соответствие стандарту (хотя, покажите мне продукт полностью и без оговорок соответствующий стандарту?), то пожалте написать несколько вариантов одной ф-ии, как и обсуждалось выше. Или макроса. Думаю (точнее уверен на 100%), что размеры кода вырастут, но незначительно. До 14kB навряд ли дотянем... В принципе, есть возможность вывести резулататы работы парсера и дерево как таковое... Но... оно надо?

Использовать ранее написанное в других проектах -- нет проблем. Всегда есть возможность создать библиотеку. Либо статическую, либо динамическую.

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

Собственно, думаю, что объяснения по вопросам -- "почему макросы" и "зачем именно так оформляются макросы", даны.

DIXI.

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

А что, кто-то qsort смог "переплюнуть" на малом числе значений?

Банальный пузырь.

Цитата

Банальный пузырь.

Ну, разве что... :D:D:D

Цитата e-yes @ 19.07.06, 20:23

Хочется посмотреть на граммотный профессианальный код.

http://safariexamples.informit.com/0201799405/netbsdsrc/sys/sys/file.h
Глянь. Дальше продолжать? Уж на тот бред, на который я нагляделся в деревах кода BSD... Короче, по бредовости кода Linux -- птичка. Правда, его код не прочесть (особенно если вовсе код читать не умеешь), но... что делать...

Меня тут уже шокировали тем, что у Ho Im'а (видимо, супер-бизон программирования на С), работает ввод-вывод арабского и ещё какого-то текста... С такими "познаниями" только по-Smike'овски ядрами и интересоваться. Ни хрена не ясно, но "выводов", особенно "подкреплённых" бешеной практикой -- просто море... :D:D:D

Цитата e-yes @ 19.07.06, 20:12

Кстати, пользуясь случаем, хочу сказать, что код ядра линуха - ООГ. Только Без ОО.

В то время как шедъюлер FreeBSD вставал колом в горле у тех, кто пытался придать этой сюстеме хоть какую-то видимость real-time, в отличие от того же Linux, во-всю используемого как embedded система. Особенно меня воткнул ряд патчиков, после которых получаем полный реал-тайм. Но только код приблуд для модифицированной таким образом системы, придётся свой код оформлять как модули ядра. Причина проста -- меняется дисциплина планировщика и обработка сисколлов (ещё кое-что, но, Бог бы с ним).

Видимо, *BSD-семейство просто полно такими модификациями для real-time... :D:D:D

Цитата e-yes @ 19.07.06, 20:38

Сейчас (в >6.0) в коде ядра FreeBSD примерно около 6% машинно-зависимого кода. При чём около 6% такого кода было выкинуто по сравнению с более ранними версиями (поддержка ISA).

Ну, помнится, демонстрировал ты Linux для своей КПК'шки с GTK+... У меня есть аналогичный для моей palmOne TREO 650... Более того! palmOne подписала контракт с авторами NetFront (японцы из Access) на создание новой PalmOS на базе... Linux.

Как ты думаешь, как механизмы самой ОС, требуемые для работы этой самой ОС "завязаны" на машинно-зависимый код? Если не понял вопроса, поясню -- от чего больше зависит, к примеру, планировщик -- от алгоритмов, составляющих основу его реализации или от жести, на которой он работает?

Hint -- для ответа на вопрос перечитай, сделай милость то, что я выше написал по поводу планировщика во FreeBSD. И всё станет ясно.

А вот теперь я приколюсь. Ты говоришь, выкинули на фиг работу с пассивной шиной ISA? Великолепно! Гениально!
Точнее, всё-таки, "генитально", т.к. как эти идиоты теперь будут пытаться создавать embedded-FreeBSD для, к примеру, Micro-PC, где у ISA -- основная роль, мне вообще не ясно...

Мдяяя... Наблюдая за фрёй с версии 1.0, ("наблюдая" = "эпизодически с ней сталкиваясь в работе"), могу заметить, что пациент скорее мёртв, чем жив. И, вот уже в который раз понимаю, что Linux, что бы ни говорили "серьёзные" гы-гы программисты, об их мнении не знает. По-этому и работает.

Добавлено 20.07.06, 00:34
Ни кто ни чего странного в этом коде не видит?

/*
 * Kernel descriptor table.
 * One entry for each open kernel vnode and socket.
 */
struct file {
    LIST_ENTRY(file) f_list;/* list of active files */
    short   f_flag;     /* see fcntl.h */
#define DTYPE_VNODE 1   /* file */
#define DTYPE_SOCKET    2   /* communications endpoint */
    short   f_type;     /* descriptor type */
    short   f_count;    /* reference count */
    short   f_msgcount; /* references from message queue */
    struct  ucred *f_cred;  /* credentials associated with descriptor */
    struct  fileops {
        int (*fo_read)  __P((struct file *fp, struct uio *uio,
                        struct ucred *cred));
        int (*fo_write) __P((struct file *fp, struct uio *uio,
                        struct ucred *cred));
        int (*fo_ioctl) __P((struct file *fp, u_long com,
                        caddr_t data, struct proc *p));
        int (*fo_poll)  __P((struct file *fp, int events,
                        struct proc *p));
        int (*fo_close) __P((struct file *fp, struct proc *p));
    } *f_ops;
    off_t   f_offset;
    caddr_t f_data;     /* vnode or socket */
};

Добавлено 20.07.06, 00:37
Hint -- как изменился бы файл, если бы мы вдруг решили использовать запись типа class file { }?
И второй вопрос -- сколько места этот код стал бы занимать в момент исполнения (о том, что С++'офилы, к примеру, заюзали бы для реализации подгружаемые библиотеки, подгружаемые после старта и полной загрузки системы -- вообще молчу). Интересно -- как бы он (этот код) работал, если бы библиотек для его работы на момент загрузки (тогда, когда этот код нужен) просто нет???

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

Сообщение отредактировано: the_Shadow - 20.07.06, 13:59

Цитата

Меня тут уже шокировали тем, что у Ho Im'а (видимо, супер-бизон программирования на С), работает ввод-вывод арабского и ещё какого-то текста... С такими "познаниями" только по-Smike'овски ядрами и интересоваться.

К сожалению, системное администрирование - не мой конёк Или к счастью

Цитата

Опять идет сравненин несравнимого.

Чего несравнимого? Всё вполне сравнимо
Похоже, ядра повсеместно пишут по принципу - "его не трогай, оно и вонять не будет".

Цитата

Hint -- как изменился бы файл, если бы мы вдруг решили использовать запись типа class file { }

Никак. Кроме доп. слова public. Но тут есть один маленький э.. секрет. Ключевое слово class желательно использовать, если хотим чего то скрыть. А слово struct как раз означает, что использование объекта не влечёт за собой скрытой семантики. В данном случае слово struct оправдано и к замене не рекомендовано. Потому что в данном случае структура используется исключительно для хранения "пучка" данных.
Шадыч, если для тебя C++ == ключевое слово class вместо struct - то мне очень э.. странно.

Слово класс было бы тут оправдано, если бы, ну предположим: у тебя есть некий объект с кучей полей, но изменять поля независимо друг от друга (а именно таким образом их можно изменять, когда все члены открыты) нельзя, т.к. можно нарваться на "невалидное состояние объекта" (объект есть, но пользоваться им невозможно.
Тогда парочку членов закрывают и пишут парочку функций на запись/доступ к этим членам.
Или ещё лучше ( у меня такая ситуация частая ) - объект нужно создать один раз, а затем только считывать его поля (изменять их невозможно, т.к. объект соответсвует какой либо сущности из БД). В этом случае просто (опять таки) закрывают пару членов, инициализацию проводят в конструкторе. +парочка методов на досуп к нужным полям.
Обе ситуации здесь неканают, поэтому закрывать члены и писать class бессмысленно.

#define DTYPE_VNODE 1   /* file */
#define DTYPE_SOCKET    2   /* communications endpoint */

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

Цитата

о том, что С++'офилы, к примеру, заюзали бы для реализации подгружаемые библиотеки, подгружаемые после старта и полной загрузки системы -- вообще молчу). Интересно -- как бы он (этот код) работал, если бы библиотек для его работы на момент загрузки (тогда, когда этот код нужен) просто нет???

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

Цитата

т.к. как эти идиоты теперь будут пытаться создавать embedded-FreeBSD для, к примеру, Micro-PC, где у ISA -- основная роль, мне вообще не ясно...

А что, собираются портировать? У тебя есть какая то инсайдерская информашка на эту тему?

Цитата

могу заметить, что пациент скорее мёртв, чем жив.

На сегодняшний день уже да. Он ещё потрепыхается, хотя шаг в могилу уже был сделан.

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

Сообщение отредактировано: BugHunter - 20.07.06, 13:59

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

К сожалению, системное администрирование - не мой конёк :no: Или к счастью :yes:

Хэх! Ну, видать по приведённому тобою анализу, и "программирование" как таковое -- то же "не очень" твой конёк. Уж извини... Но так и получается. Вообще-то, я данный код ещё для Flex'а привёл -- вот шума о "хараме" (грехе) будееееет! :D:D:D

Итак.

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

В данном случае слово struct оправдано и к замене не рекомендовано. Потому что в данном случае структура используется исключительно для хранения "пучка" данных.
Шадыч, если для тебя C++ == ключевое слово class вместо struct - то мне очень э.. странно.

Ээээ... Видишь ли, мне, к примеру, странно:

1. Ты не обратил внимание на комментарий (в самом начале).
vnode -- ничего не говорит? А для меня, к примеру, кричит о том, что это -- описание виртуальной единицы размещения инфы на диске в NetBSD -- (виртуальный inode), применяемый так же для описания сокетов (дружненько вспоминаем то, что в UNIX "всё -- есть файл"). Следовательно, не только "пучок" данных здесь актуален. Дело в том, что для работы в разных файловых системах, потребуются чуточку разные операции над этим самым vnode. Не имеет смысла просто хранить какие-то данные отдельно от... правильно от методов по их обработке. Правда, методы для каждой ФС будут свои, но у нас есть пунктик 2.

2. Ты просто и бесталанно забил на описание структуры fileops, которая и содержит ссылки и формат вызова этих самых методов по обработке... "Методов". Ты... Понял?

Сами по себе методы по работе с vnode определяются в тех модулях ядра, где реализованы конкретные файловые системы и/или сокеты. Учитывая то, что "One entry for each open kernel vnode and socket.", делаем вывод о том, что перед нами то, что в Linux более просто и понятно реализовано через механизм VFS (Virtual FileSystem). Это -- только один из приколов с ядрами *BSD.

В итоге -- я не знаю как именно ты программируешь (видимо, просто "кодишь"), но данные + методы по обработке этих самых данных = КЛАСС! Причём, чистый классический случай. Не надо рассказывать того, что "через struct, вообще говоря, то же можно...". Можно. Но не нужно, т.к. необходимо не извращаться, а использовать адекватный задаче инструментарий.

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

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

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

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

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

Да хрен бы с ними -- с объявлениями и их доступностью. Для моно-ядра, коим является любая *NIX-система, "объявления" на хрен не нужны. Важнее всего именно алгоритмы, реализующие то или иное св-во системы, модули ядра, то, как эти модули будут взаимодействовать с окружающим миром (см. макрос printk(), который выводит инфу из модуля, к примеру).

Так что, не так и страшны макросы, как их малюют. Есть вещи и по-страшнее. Как пример -- использовать библиотеку времени исполнения где-нибудь в ядре.

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

А что, собираются портировать? У тебя есть какая то инсайдерская информашка на эту тему?

http://www.nazim.ru/bsd/ -- сам проджект и "введение". По-моему, во "введении" было.
http://www.amazon.com/gp/product/1589950046/002-0405535-1683267?v=glance&n=283155

e-yes, bugger, SFTP подойдёт?

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

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

Hint -- как изменился бы файл, если бы мы вдруг решили использовать запись типа class file { }?
И второй вопрос -- сколько места этот код стал бы занимать в момент исполнения (о том, что С++'офилы, к примеру, заюзали бы для реализации подгружаемые библиотеки, подгружаемые после старта и полной загрузки системы -- вообще молчу). Интересно -- как бы он (этот код) работал, если бы библиотек для его работы на момент загрузки (тогда, когда этот код нужен) просто нет???

struct file
{
    static std::list<file*, kernel_allocator> f_list;/* list of active files */
    short   f_flag;     /* see fcntl.h */
    enum FileType // descriptor type
    {
        DTYPE_VNODE = 1, // file
        DTYPE_SOCKET = 2 // communication endpoint
    }  f_type;    
    short   f_count;    // refcounter
    short   f_msgcount; // references from message queue
    struct  ucred *f_cred;  // credentials associated with descriptor
    virtual int read(struct uio *uio, struct ucred *cred);
    virtual int write(struct uio *uio, struct ucred *cred);
    virtual int ioctl(u_long com, caddr_t data, struct proc *p);
    virtual int poll(int events, struct proc *p);
    virtual int close(struct proc *p);
    off_t   f_offset;
    caddr_t f_data;     /* vnode or socket */
};

А бред по поводу подгрузки библиотек даже комментировать не буду. Ибо бред.

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

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

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

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

Цитата

Хэх! Ну, видать по приведённому тобою анализу, и "программирование" как таковое -- то же "не очень" твой конёк. Уж извини... Но так и получается. Вообще-то, я данный код ещё для Flex'а привёл -- вот шума о "хараме" (грехе) будееееет! :D:D

У меня складывается впечатление такое же. Только о тебе, батенько.

Цитата

А из чего, позволь узнать, ты сделал такой вывод?

я наоборот сделал противоположный вывод .

Цитата

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

батенько, вы вообще на С++ то писали? видимо, нет. Какой то бред, если честно слышу я в ответ.
Вопрос заключался в следующем:
"Зачем делать #define в теле класса? Т.к. на области видимости он всё равно плюёт. У пользователя класса/структуры может сложиться ложное впечатление, что #define принадлежит классу. А это - НЕ ТАК. Налицо - запутывание семантики и пользователей структуры.
Каким образом достучаться до статической константы или enum-а, объявленого/определённого в классе - кури Стандарт С++. Могу лишь от себя добавить, что такой способ гораздо больше защищён от неоднозначностей. Ну, хотя сишникам этого не понять, т.к. им неведом overloading resolution.

Цитата

Да хрен бы с ними -- с объявлениями и их доступностью.

вот и я о том же - если оно скомпилировалось, то какого чёрта может помешать ей работать?

Цитата

ты просто и бесталанно забил на описание структуры fileops

Мог бы я ещё кой чего написать, но лень. Просто, лень отвечать на бред. I'm clear?

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

Цитата Flex Ferrum @ 20.07.06, 08:16

А из чего, позволь узнать, ты сделал такой вывод?

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

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

А бред по поводу подгрузки библиотек даже комментировать не буду. Ибо бред.

Ага. Точно. Давай проще -- я дам тебе пустой модуль (да, вот хоть этот -> http://www.botik.ru/~rldp/ldp/lkmpg-1/node11.htm, "hello world", но нам много и не надо). А ты "запросто" без библиотек откажешься от макроса printk(), заменив его на что-нибудь "истинно" С++'овское типа std::out...

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

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

Чего-чего? Для модуля ядра??? А, позвольте по-любопытствовать -- откуда модуль ядра или автор, его пишущий могут знать (как в данном случае) о всех возможных файловых системах и сейчас и в будущем? Или, прикажете, при подключении каждой ФС к работающей системе, вначале править соотв. исходный код и, потом, пересобирать всё ядро заново??? И после этого кто-то говорит о сложности пересборки ядра, когда просто подключаются соотв. модули? 8-/
Это что, шутка? Или банальное непонимание архитектуры системы?

В пень. К терапевту.

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

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

Чего-чего? Для модуля ядра??? А, позвольте по-любопытствовать -- откуда модуль ядра или автор, его пишущий могут знать (как в данном случае) о всех возможных файловых системах и сейчас и в будущем? Или, прикажете, при подключении каждой ФС к работающей системе, вначале править соотв. исходный код и, потом, пересобирать всё ядро заново??? И после этого кто-то говорит о сложности пересборки ядра, когда просто подключаются соотв. модули? 8-/
Это что, шутка? Или банальное непонимание архитектуры системы?

Вот и я говорю - к терапевту. Ибо мне в таком случае совершенно не понятно - а как разработчик модуля узнает о define'ах DTYPE_VNODE и DTYPE_SOCKET. Ибо все сказанное тобою верно и для них. Или нет?

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

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

Шадыч, дорогой мой, ты буквари читать умеешь? Если да, то должен знать о существенных отличиях inline-функций от дефайнов. Дабы не затруднять тебя доставанием книги с полки (или копанием в директориях) приведу основные:
- inline обрабатывается на этапе синтаксического анализа кода, define - на этапе препроцессирования.
- inline представляет из себя полноценную функцию, define - лишь макроподстановка.
- inline подчиняется всем правилам видимости, установленным для идентификаторов и объявлений. define плюет на них с высокой колокольни.
- inline подчиняется всем синтаксическим и семантическим правилам, установленным для функций. define'у на них глубоко пложить.
- имя inline функции может быть использовано только в контексте идентификатора функции (и никак иначе). имя define'а плюет на это и может быть использован в любом контексте.
- inline гарантирует побочные эффекты для своих аргументов такие же, какие установлены для вызова обычной функции. Побочные эффекты аргументов, перечисленных в function-like define'е не определены и зависят от того, как этот define раскроется.
Список можно продолжать и продолжать.

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

Ага. Точно. Давай проще -- я дам тебе пустой модуль (да, вот хоть этот -> http://www.botik.ru/~rldp/ldp/lkmpg-1/node11.htm, "hello world", но нам много и не надо). А ты "запросто" без библиотек откажешься от макроса printk(), заменив его на что-нибудь "истинно" С++'овское типа std::out...

Шадыч, перестань бредить и возьми в руки букварь. Не каждая библиотека в С++ - динамическая. Это раз. Второе, у меня не возникнет необходимости отказываться от printk, ибо не зачем. Третье - если такая необходимость таки возникнет - я решу эту задачу без каких-либо доп. библиотек.

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

Цитата bugger @ 20.07.06, 08:52

только для 3ей и 4ой версии. можно свободно скачать с сайта палма.

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

Цитата bugger @ 20.07.06, 08:52

irc не пользуюсь. пользуюсь аськой.

Жаль. Наоборот...

2 BugHunter.

Цитата BugHunter @ 20.07.06, 08:50

У меня складывается впечатление такое же. Только о тебе, батенько.

Тебе виднее, но мне почему-то по-хрену. :D:D:D

Цитата BugHunter @ 20.07.06, 08:50

Каким образом достучаться до статической константы или enum-а, объявленого/определённого в классе - кури Стандарт С++.

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

Цитата BugHunter @ 20.07.06, 08:50

Мог бы я ещё кой чего написать, но лень. Просто, лень отвечать на бред. I'm clear?

Свободен. Я, надеюсь, от твоего "высокоумного" идиотизма, излагаемого со стеклянными глазами -- то же.
Ну... Будучи знаком именно я ядрами, я уже всё понял... И оценил знакомство с "ядром" так же, как и знакомство с интернационализацией и с администрированием в части UNIX точно так же. Как нулевое.

По сумме факторов -- думаю, ты не обидишься, если я просто буду твои эскапады игнорировать. Мне здесь осталось 17 дней, и тратить их на полу-грамотного идиота -- по-просто лень. Уж извини за прямоту. По поводу стандарта С++, кто-то, по-моему, Flex за него поблагодарил. Мне это ценнее, нежели рекомендации его покурить. Курю, как правило, что-то более курибельное. По этой причине и знаю, что если класс не объявлен, но объявлена структура, то к её членам доступ можно организовать и без выкуренного "стандарта С++". Он здесь -- пятое колесо. Тем более -- перечисление, известное тебе как enum.

2 e-yes.

Цитата e-yes @ 20.07.06, 09:09

Ну да... набор патчей блин.

Будь добр -- покажи для real-time набор патчей для фряхи. Или самй реал-тайм фряху. Может, я сделал неверный выбор в пользу Linux? :D:D:D

Цитата e-yes @ 20.07.06, 08:58

ЗЫ. А про линуховый код ваще говорить не буду. От ворнингов сначала избавьтесь.

Ну, с Божией помощью по-тихоньку, по-легоньку... Однако же тебе только что BuhgHunter объяснял -- "скомпилилось -- значит, работает..." :D:D:D Кто-то избавляется по-маленьку, а кто-то звуковые карточки до "пердежа" (это цитата) доводит... Каждому своё... :D:D:D

Цитата e-yes @ 20.07.06, 08:58

Может ты в курсе (если следишь, конечно), что 4-я и 5-я ветка как legacy releases еще долго помечены не будут?

Знаю. Но в последнее время следить стараюсь реже. У меня к фряхе была давняя и, смею тебя заерить, разделённая любовь. Я метался между Слакой и Фрёй. Слака победила. Правда... Ну, думаю, ты в курсе... ;)

Цитата e-yes @ 20.07.06, 08:58

Если честно - ничего странного не вижу. Нормальный подход.
Считай виртуальные методы.

Угу. Я -- про то же. Немного коробит сама по себе запись, точнее, когда-то коробила, но потом мне полегчало -- открыл для себя виртуальные таблицы и указатели в С (gcc) и не парюсь с тех пор.

Flex, #489. Сырец. Зачем тогда классы придумали, если можно вполне обходиться интсрументарием С? Строку с list во внимание не беру. ;) по ряду причин.

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

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

Flex, #489. Сырец. Зачем тогда классы придумали, если можно вполне обходиться интсрументарием С?

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

struct socket_file : public file
{
    virtual int read(struct uio *uio, struct ucred *cred);
    virtual int write(struct uio *uio, struct ucred *cred);
    virtual int ioctl(u_long com, caddr_t data, struct proc *p);
    virtual int poll(int events, struct proc *p);
    virtual int close(struct proc *p);
 
    inet_addr sf_address;
    // тут еще предположим кучу данных, характерных для сокета
};

И я могу пихать указатель на эту структуру в любую функцию, которая хочет file. А как это выглядит в ядре?

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

А, кстати, совсем забыл добавить:

struct file
{
//...
   virtual ~file() {;}
   void* operator new(size_t size) {return kmalloc(size);}
   void operator delete(void* ptr, size_t size) {kfree(ptr);}
//...
};

С этой "небольшой" добавочкой мы забываем про головную боль с динамическим созданием/разрушением объектов этого типа.
ЗЫ: kmalloc/kfree - функции, которые занимаются выделением памяти в ядре. Как они на самом деле называются, я не знаю...

Добавлено 20.07.06, 10:27

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

Но тогда обрати внимание на избыточность в С++ (для ядра) средств.

Ткни мне пальцем (в приведенный код), где ты видишь избыточность. В стандарт тыкать не надо - не все, что написано в стандарте, обязательно к использованию.

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

Только, у меня всё-таки есть вопрос -- зачем тогда придуман class? И каковы отличия class и struct?

В С++ - никаких, кроме двух:
- для struct все поля (по умолчаниюи) public.
- для struct тип наследования от родительского класса/структуры (по умолчанию) - public.

Это все отличия. В остальном эти два ключевых слова - синонимы.

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

Цитата Flex Ferrum @ 20.07.06, 09:20

Ибо мне в таком случае совершенно не понятно - а как разработчик модуля узнает о define'ах DTYPE_VNODE и DTYPE_SOCKET. Ибо все сказанное тобою верно и для них. Или нет?

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

Цитата Flex Ferrum @ 20.07.06, 09:20

Шадыч, дорогой мой, ты буквари читать умеешь?

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

Цитата Flex Ferrum @ 20.07.06, 09:20

- inline представляет из себя полноценную функцию, define - лишь макроподстановка.

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

Цитата Flex Ferrum @ 20.07.06, 09:20

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

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

Цитата Flex Ferrum @ 20.07.06, 09:20

- inline подчиняется всем правилам видимости, установленным для идентификаторов и объявлений. define плюет на них с высокой колокольни.
- inline подчиняется всем синтаксическим и семантическим правилам, установленным для функций. define'у на них глубоко пложить.

И правильно. Макрос делает только одно -- он просто определяет какой-то код. Не нужно -- не используй, но, если используешь, то подставится всё по месту и, без особых трабл. А, учитывая то, что макрос может получать аргументы, в том числе, и переменное их число (см "ISO C99" или gcc extensions -- там одно и то же, но по-разному немного), то... Не факт что макрос невыгоден.

Цитата Flex Ferrum @ 20.07.06, 09:20

- имя inline функции может быть использовано только в контексте идентификатора функции (и никак иначе). имя define'а плюет на это и может быть использован в любом контексте.
- inline гарантирует побочные эффекты для своих аргументов такие же, какие установлены для вызова обычной функции. Побочные эффекты аргументов, перечисленных в function-like define'е не определены и зависят от того, как этот define раскроется.

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

Цитата Flex Ferrum @ 20.07.06, 09:20

Шадыч, перестань бредить и возьми в руки букварь. Не каждая библиотека в С++ - динамическая. Это раз. Второе, у меня не возникнет необходимости отказываться от printk, ибо не зачем. Третье - если такая необходимость таки возникнет - я решу эту задачу без каких-либо доп. библиотек.

Угу. Перестал.
Я ни где не говорил, что каждая библиотека в С++ -- динамическая. Это раз.
Второе -- перестань фигню нести и сделай размер ядра равным 1 542 955 байт, используя статические библиотеки С++. Открою для тебя секрет -- даже статические библиотеки С там... НЕ ИСПОЛЬЗУЮТСЯ. В ядре.
Хочешь -- верь, хочешь -- проверяй.

Добавлено 20.07.06, 10:58

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

В стандарт тыкать не надо - не все, что написано в стандарте, обязательно к использованию.

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

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

Ткни мне пальцем (в приведенный код), где ты видишь избыточность.

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

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

ЗЫ: kmalloc/kfree - функции, которые занимаются выделением памяти в ядре. Как они на самом деле называются, я не знаю...

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

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

В С++ - никаких, кроме двух:
- для struct все поля (по умолчаниюи) public.
- для struct тип наследования от родительского класса/структуры (по умолчанию) - public.

Это все отличия. В остальном эти два ключевых слова - синонимы.

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

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