Скорость работы с использованием классов и без
От: Kokoban  
Дата: 03.08.06 02:00
Оценка: :))) :))
Типичное мнение старых С-программистов — то, что использование С++ классов тормозит работу программы.
Понятно, что использование таблиц виртуальных функций влияет на производительность программ, но как сильно?
Интересно как дело обстоит когда мы используем только наследование?
Влияет ли на работу использование обособленых классов (т.е. без наследования, виртуальных функций и других прелестей ООП) просто как структур для инкапсуляции полей и методов?

Очень хотелось бы услышать мнение людей по этому поводу. Может кто-нибудь даст ссылки. Заранее спасибо.
Re: Скорость работы с использованием классов и без
От: FR  
Дата: 03.08.06 04:56
Оценка: 5 (3)
Здравствуйте, Kokoban, Вы писали:

K>Интересно как дело обстоит когда мы используем только наследование?

K>Влияет ли на работу использование обособленых классов (т.е. без наследования, виртуальных функций и других прелестей ООП) просто как структур для инкапсуляции полей и методов?

#include <stdio.h>

class Base
{
public:
    Base() : add_(123)
     {
     }

    int add(int x, int y)
     {
     return x + y + add_;
     }
     
protected:
    int add_;
};

class Test : public Base
{
};

int main(int argc, char *argv[])
{
printf("%d\n", Test().add(1, 2));
return 0;
}


PUBLIC    _main
EXTRN    _printf:NEAR
; Function compile flags: /Ogty
_TEXT    SEGMENT
_argc$ = 8                        ; size = 4
_argv$ = 12                        ; size = 4
_main    PROC NEAR

; 25   : printf("%d\n", Test().add(1, 2));

    push    126                    ; 0000007eH
    push    OFFSET FLAT:$SG633
    call    _printf
    add    esp, 8

; 26   : return 0;

    xor    eax, eax

; 27   : }

    ret    0
_main    ENDP


(c) VC8
Re[2]: Скорость работы с использованием классов и без
От: Kokoban  
Дата: 03.08.06 05:58
Оценка:
Наверно это компилятор С++ оптимизировал так код, что даже числа сам сложил!
А в целом логично что методы классов ничем не отличаются от обычных функций, а поля от глобальных переменных. Вообщем этого я и ожидал.
Re: Скорость работы с использованием классов и без
От: Cyberax Марс  
Дата: 03.08.06 06:50
Оценка: 1 (1) +2
Kokoban wrote:
> Типичное мнение старых С-программистов — то, что использование С++
> классов тормозит работу программы.
Не надо слушать таких программистов.

Во-первых, значительную часть виртуальных вызовов компилятор
замечательно соптимизирует в статические.
Во-вторых, в новых процессорах есть специальные аппаратные оптимизации
косвенного вызова.
В-третьих, можно замечательно использовать ООП без виртуальных функций.
В качестве примера можно взять STL.

> Понятно, что использование таблиц виртуальных функций влияет на

> производительность программ, но как сильно?
Очень незначительно.
Posted via RSDN NNTP Server 2.0
Sapienti sat!
Re: Скорость работы с использованием классов и без
От: bkat  
Дата: 03.08.06 07:03
Оценка: 1 (1) +2
Здравствуйте, Kokoban, Вы писали:

K>Типичное мнение старых С-программистов — то, что использование С++ классов тормозит работу программы.

K>Понятно, что использование таблиц виртуальных функций влияет на производительность программ, но как сильно?

Сравнивать языки есть смысл только на общем подмножестве конструкций языка.
Нету в С виртуальный методов, потому нет смысла сравнивать виртуальные методы в С++
с тем, чего нету в С. Иначе надо сравнивать виртуальные методы в С++
с некой самопольной эмуляцией виртуальных методов средствами голого С.
Re: Скорость работы с использованием классов и без
От: DerBober США  
Дата: 03.08.06 09:38
Оценка:
Здравствуйте, Kokoban, Вы писали:

K>Типичное мнение старых С-программистов — то, что использование С++ классов тормозит работу программы.


K>Очень хотелось бы услышать мнение людей по этому поводу. Может кто-нибудь даст ссылки. Заранее спасибо.


Основной проблемой считались не тормоза виртуальных функций, а увеличение объемов программы. Размер почити каждого объекта увеличивается на одно слово в котором хранится указатель на таблицу виртуальных функций. Ну и еще там всякием мелочи. Сейчас память сильно подешевела и этой проблемы вроде как нет.
Скорость больше зависит от того как напишешь, а не на чем.
Re: Скорость работы с использованием классов и без
От: Андрей Хропов Россия  
Дата: 03.08.06 10:39
Оценка: 33 (3) +1
Здравствуйте, Kokoban, Вы писали:

K>Типичное мнение старых С-программистов — то, что использование С++ классов тормозит работу программы.

K>Понятно, что использование таблиц виртуальных функций влияет на производительность программ, но как сильно?
K>Интересно как дело обстоит когда мы используем только наследование?
K>Влияет ли на работу использование обособленых классов (т.е. без наследования, виртуальных функций и других прелестей ООП) просто как структур для инкапсуляции полей и методов?

K>Очень хотелось бы услышать мнение людей по этому поводу. Может кто-нибудь даст ссылки. Заранее спасибо.


Почитай что ли здесь.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[2]: Скорость работы с использованием классов и без
От: MShura  
Дата: 03.08.06 11:08
Оценка: 12 (1)
B>Сравнивать языки есть смысл только на общем подмножестве конструкций языка.
B>Нету в С виртуальный методов, потому нет смысла сравнивать виртуальные методы в С++
B>с тем, чего нету в С. Иначе надо сравнивать виртуальные методы в С++
B>с некой самопольной эмуляцией виртуальных методов средствами голого С.

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

Например возьмем интерфейс IMalloc, который реализует Alloc,Realloc,Free.
Предположим, что в какой-то его реализации (например ядро Linux) нетривиально написать функцию Realloc.
Что делать клиенту, если перед ним стоит задача увеличить размер буффера?
Сравните:

// виртуальные функции. Realloc обязан быть реализован
void Func( IMalloc* I )
{
  void* p  = I->Alloc( 100 );
  void* p2 = I->Realloc( p, 200 );
  if ( NULL != p2 )
    p = p2;
  ...
}

// таблицы функций. Realloc не обязан быть реализован
// Попробуйте реализовать такой C++ интерфейс, у которого I->Realloc будет NULL
void Func( IMalloc* I )
{
  void* p  = I->Alloc( 100 );
  if ( NULL != I->Realloc )
  {
     void* p2 = I->Realloc( p, 200 );
     if ( NULL != p2 )
       p = p2;
  }
  else
  {
     void* p2 = I->Alloc( 200 );
     if ( NULL != p2 )
     {
       memcpy( p2, p, 100 );
       I->Free( p );
       p = p2;
     }
  }
  ...
}


Точно также с помощью таблиц легко реализовать подмену "виртуальной" функции уже на лету.
Попробуйте в C++ виртуальности подменить виртуальную функцию.
Re[3]: Скорость работы с использованием классов и без
От: bkat  
Дата: 03.08.06 11:28
Оценка:
Здравствуйте, MShura, Вы писали:

Не вопрос, что это все можно реализовывать ручками...
Но, как и любая ручная реализация, это решение будет подвержено ошибкам и будут тратиться усилия на поддержку
всей этой ручной инфраструктуры в нормальном состоянии.
В С++ это делает компилятор...

MS>Точно также с помощью таблиц легко реализовать подмену "виртуальной" функции уже на лету.

MS>Попробуйте в C++ виртуальности подменить виртуальную функцию.

У меня видимо не такие задачи как у тебя.
Мне еще ни разу не требовалось подменять виртуальные функции на лету.
Ну либо это решалось какими-то более явными методами.
Re[3]: Скорость работы с использованием классов и без
От: Cyberax Марс  
Дата: 03.08.06 11:29
Оценка: +1
MShura wrote:
> // таблицы функций. Realloc не обязан быть реализован
> // Попробуйте реализовать такой C++ интерфейс, у которого I->Realloc будет NULL
Можно вопрос? А зачем функции Func знать о том как работает IMalloc?

Если у меня есть только malloc/free, то просто просто в своей реализации
IMalloc делаем его через memcpy+malloc. Если о подробностях работы
IMalloc надо знать клиентскому коду (например, для включения
оптимизаций), то делаем интерфейс IMallocInfo с методом GetReallocCaps.

> Точно также с помощью таблиц легко реализовать подмену "виртуальной"

> функции уже на лету.
> Попробуйте в C++ виртуальности подменить виртуальную функцию.
Ни разу не было такого желания.
Posted via RSDN NNTP Server 2.0
Sapienti sat!
Re[4]: Скорость работы с использованием классов и без
От: MShura  
Дата: 03.08.06 11:45
Оценка:
C>MShura wrote:
>> // таблицы функций. Realloc не обязан быть реализован
>> // Попробуйте реализовать такой C++ интерфейс, у которого I->Realloc будет NULL
C>Можно вопрос? А зачем функции Func знать о том как работает IMalloc?
Если IMalloc реализует нужный функционал, то воспользоваться им. Если нет, то воспользоваться другим способом.

C>Если у меня есть только malloc/free, то просто просто в своей реализации

C> IMalloc делаем его через memcpy+malloc. Если о подробностях работы
C>IMalloc надо знать клиентскому коду (например, для включения
C>оптимизаций), то делаем интерфейс IMallocInfo с методом GetReallocCaps.

Как раз самую элементарную информацию о методе (реализован/не реализован) легко получить сравнив с NULL указатель на функцию.
Виртульная файловая система Linux (vfs) очень активно использует тиблицы функций.
Например ваша файловая система может поддерживать открытие файла по некоторому номеру, другая только по имени, третья и по тому и по другому признаку. В каждом случае вы зополняете только необходимые элементы таблицы. vfs анализируя эту таблицу пользуется тем или иным способом.

>> Точно также с помощью таблиц легко реализовать подмену "виртуальной"

>> функции уже на лету.
>> Попробуйте в C++ виртуальности подменить виртуальную функцию.
C>Ни разу не было такого желания.
Элементарный hook какого-нибудь метода стороннего COM объекта
Re[5]: Скорость работы с использованием классов и без
От: Cyberax Марс  
Дата: 03.08.06 12:16
Оценка: +3
MShura wrote:
> C>Можно вопрос? А зачем функции Func знать о том как работает IMalloc?
> Если IMalloc реализует нужный функционал, то воспользоваться им. Если
> нет, то воспользоваться другим способом.
Просто IMalloc _обязан_ реализовать нужный функционал. Если изначально
планируется возможность, что некоторые функции не будут реализованы — то
пусть возвращают E_NOTIMPL. Пихать NULL в таблицу функций — это уже
извращение.

> C>Если у меня есть только malloc/free, то просто просто в своей реализации

> C> IMalloc делаем его через memcpy+malloc. Если о подробностях работы
> C>IMalloc надо знать клиентскому коду (например, для включения
> C>оптимизаций), то делаем интерфейс IMallocInfo с методом GetReallocCaps.
> Как раз самую элементарную информацию о методе (реализован/не
> реализован) легко получить сравнив с NULL указатель на функцию.
Ага, это надо сравнивать его НА КАЖДЫЙ вызов. В результате вместо кода
получим макароны.

> Например ваша файловая система может поддерживать открытие файла по

> некоторому номеру, другая только по имени, третья и по тому и по другому
> признаку. В каждом случае вы зополняете только необходимые элементы
> таблицы. vfs анализируя эту таблицу пользуется тем или иным способом.
Похоже на неоправданый хак. Для получения информации проще было бы
создать дополнительный интерфейс.

> C>Ни разу не было такого желания.

> Элементарный hook какого-нибудь метода стороннего COM объекта
Для этого я всегда просто писал прокси-интерфейс. Гораздо удобнее
отлаживать.
Posted via RSDN NNTP Server 2.0
Sapienti sat!
Re[6]: Скорость работы с использованием классов и без
От: MShura  
Дата: 03.08.06 12:45
Оценка:
..
C>Просто IMalloc _обязан_ реализовать нужный функционал. Если изначально
C>планируется возможность, что некоторые функции не будут реализованы — то
C>пусть возвращают E_NOTIMPL. Пихать NULL в таблицу функций — это уже
C>извращение.

...
C>Ага, это надо сравнивать его НА КАЖДЫЙ вызов. В результате вместо кода
C>получим макароны.

Не напоминает ли Вам это спор указатель vs ссылка?
Предлагаю закрыть вопрос.



>> Например ваша файловая система может поддерживать открытие файла по

>> некоторому номеру, другая только по имени, третья и по тому и по другому
>> признаку. В каждом случае вы зополняете только необходимые элементы
>> таблицы. vfs анализируя эту таблицу пользуется тем или иным способом.
C>Похоже на неоправданый хак. Для получения информации проще было бы
C>создать дополнительный интерфейс.
Этот подход — результат эволюции UNIX/Linux OS.
Спорить о том, почему выжил именно этот подход, а не более правильный в теории предлагаю не начинать.


>> C>Ни разу не было такого желания.

>> Элементарный hook какого-нибудь метода стороннего COM объекта
C>Для этого я всегда просто писал прокси-интерфейс. Гораздо удобнее
C>отлаживать.

Когда мне это понадобилось было лень писать прокси даже для 5 методов.
(В итоге решил проблему другим способом)
Re[7]: Скорость работы с использованием классов и без
От: Cyberax Марс  
Дата: 03.08.06 12:51
Оценка:
MShura wrote:
> C>Ага, это надо сравнивать его НА КАЖДЫЙ вызов. В результате вместо кода
> C>получим макароны.
> Не напоминает ли Вам это спор указатель vs ссылка?
А какой тут спор?

> Предлагаю закрыть вопрос.

Нет уж. Сам поднял его.

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

А если только некоторые функции могут быть NULL'ами, то почему бы их не
вынести в один интерфейс?

> C>Похоже на неоправданый хак. Для получения информации проще было бы

> C>создать дополнительный интерфейс.
> Этот подход — результат эволюции UNIX/Linux OS.
Вроде бы в Solaris'ной VFS нулевые функции были явно запрещены. Сейчас
лень доставать мануалы.

> Спорить о том, почему выжил именно этот подход, а не более правильный в

> теории предлагаю не начинать.
Ну так давно известно, что не все что написано — идеально.

>> > Элементарный hook какого-нибудь метода стороннего COM объекта

> C>Для этого я всегда просто писал прокси-интерфейс. Гораздо удобнее
> C>отлаживать.
> Когда мне это понадобилось было лень писать прокси даже для 5 методов.
> (В итоге решил проблему другим способом)
Ну так не надо писать руками
Posted via RSDN NNTP Server 2.0
Sapienti sat!
Re[8]: Скорость работы с использованием классов и без
От: MShura  
Дата: 03.08.06 13:48
Оценка:
>> C>Ага, это надо сравнивать его НА КАЖДЫЙ вызов. В результате вместо кода
>> C>получим макароны.
>> Не напоминает ли Вам это спор указатель vs ссылка?
C>А какой тут спор?
Если есть выбор использовать указатель или ссылку, то что лучше использовать.
Кто-то на стороне указателей (я в том числе), кто-то не мыслит без ссылок.
Я вижу такую аналогию, что таблица функций сгенеренная компилятором никогда не содержит пустые элементы, поэтому их можно вызывать без проверки. Ручная таблица и есть ручная.

C>Если элементы в таблице функций по дизайну могут принимать NULLовое

C>значение, то их все перед вызовом надо проверять. А это медленно.
Если предполагается дальнейшее расширение интерфейса, то что быстрее:
— вызвать без проверки виртуальную функцию, проверить значение на "не реализовано", принять решение
— проверить на NULL указатель на функцию, принять решение

C>А если только некоторые функции могут быть NULL'ами, то почему бы их не

C>вынести в один интерфейс?
Такой интерфейс легко расширяется.
Старый код продолжает работать ничего не зная о новых методах.

>> C>Похоже на неоправданый хак. Для получения информации проще было бы

>> C>создать дополнительный интерфейс.
>> Этот подход — результат эволюции UNIX/Linux OS.
C>Вроде бы в Solaris'ной VFS нулевые функции были явно запрещены. Сейчас
C>лень доставать мануалы.
Т.е. все драйвера должны реализовать ВСЕ нужные функции а не нужные заменить на заглушки возвращающие определенный код?
если понадобиться расширить vfs (а оно потихоньку расширяется), то придется переписывать старые драйвера?
(Т.е. добавлять пустые заглушки)
Re[9]: Скорость работы с использованием классов и без
От: Cyberax Марс  
Дата: 03.08.06 14:36
Оценка:
MShura wrote:
> C>А какой тут спор?
> Если есть выбор использовать указатель или ссылку, то что лучше
> использовать.
> Кто-то на стороне указателей (я в том числе), кто-то не мыслит без ссылок.
Ну вообще-то указатель и ссылка — это разные вещи. В частности,
для ссылки гарантируется, что она не NULL и над ней нельзя делать
адресную арифметику.

> C>Если элементы в таблице функций по дизайну могут принимать NULLовое

> C>значение, то их все перед вызовом надо проверять. А это медленно.
> Если предполагается дальнейшее расширение интерфейса, то что быстрее:
> — вызвать без проверки виртуальную функцию, проверить значение на "не
> реализовано", принять решение
> — проверить на NULL указатель на функцию, принять решение
Вероятно, одинаково. Новые процессоры оптимизируют косвенные вызовы.

Ты еще не забудь, что тебе надо проверять ВСЕ функции. Либо надеяться,
что они будут реализованы.

> C>А если только некоторые функции могут быть NULL'ами, то почему бы их не

> C>вынести в один интерфейс?
> Такой интерфейс легко расширяется.
> Старый код продолжает работать ничего не зная о новых методах.
Не понял.
struct IMalloc
{
    virtual void* alloc(size_t)=0;
    virtual void  free(void*)=0;
    virtual void* realloc(void*, size_t)=0;
};
struct IMapingMalloc : public IMalloc
{
    virtual void mmap(...)=0;
};

Старые клиенты будут замечательно работать со старым IMalloc'ом (даже
если это IMapingMalloc), ничего не зная, про новый интерфейс.

> C>Вроде бы в Solaris'ной VFS нулевые функции были явно запрещены. Сейчас

> C>лень доставать мануалы.
> Т.е. все драйвера должны реализовать ВСЕ нужные функции а не нужные
> заменить на заглушки возвращающие определенный код?
Нет, там у драйвера была функция, которая возвращала битовую маску с
возможностями драйвера.

> если понадобиться расширить vfs (а оно потихоньку расширяется), то

> придется переписывать старые драйвера?
> (Т.е. добавлять пустые заглушки)
Вообще-то, для новых функций обычно делают новые интерфейсы.
Posted via RSDN NNTP Server 2.0
Sapienti sat!
Re[10]: Скорость работы с использованием классов и без
От: MShura  
Дата: 03.08.06 15:07
Оценка:
>> C>А какой тут спор?
>> Если есть выбор использовать указатель или ссылку, то что лучше
>> использовать.
>> Кто-то на стороне указателей (я в том числе), кто-то не мыслит без ссылок.
C>Ну вообще-то указатель и ссылка — это разные вещи. В частности,
C>для ссылки гарантируется, что она не NULL и над ней нельзя делать
C>адресную арифметику.
Ссылка реализуется через указатель точно также, как виртуальные функции реализуются через таблицу функций.
указатель может быть NULL ссылка нет, указатель в таблице функций может быть NULL, указатель в таблице виртуальных функций нет.
По аналогии можно считать что в таблице виртуальных функций хранятся ссылки на функции.


>> C>Если элементы в таблице функций по дизайну могут принимать NULLовое

>> C>значение, то их все перед вызовом надо проверять. А это медленно.
>> Если предполагается дальнейшее расширение интерфейса, то что быстрее:
>> — вызвать без проверки виртуальную функцию, проверить значение на "не
>> реализовано", принять решение
>> — проверить на NULL указатель на функцию, принять решение
C>Вероятно, одинаково. Новые процессоры оптимизируют косвенные вызовы.
Не согласен.
Как можно оптимизировать вызов виртуальной функции не зная точно типа объекта (конструкторы/деструкторы не рассматриваем)
Т.е. нужно сформировать аргументы, сделать call, проверить с определенным (скорее всего ненулевым) значением (проверка на нуль — самая простая).
Однозначно дольше.

C>Ты еще не забудь, что тебе надо проверять ВСЕ функции. Либо надеяться,

C>что они будут реализованы.
Это верно.


>> C>А если только некоторые функции могут быть NULL'ами, то почему бы их не

>> C>вынести в один интерфейс?
>> Такой интерфейс легко расширяется.
>> Старый код продолжает работать ничего не зная о новых методах.
C>Не понял.
C>
C>struct IMalloc
C>{
C>    virtual void* alloc(size_t)=0;
C>    virtual void  free(void*)=0;
C>    virtual void* realloc(void*, size_t)=0;
C>};
C>struct IMapingMalloc : public IMalloc
C>{
C>    virtual void mmap(...)=0;
C>};
C>

C>Старые клиенты будут замечательно работать со старым IMalloc'ом (даже
C>если это IMapingMalloc), ничего не зная, про новый интерфейс.

>> C>Вроде бы в Solaris'ной VFS нулевые функции были явно запрещены. Сейчас

>> C>лень доставать мануалы.
>> Т.е. все драйвера должны реализовать ВСЕ нужные функции а не нужные
>> заменить на заглушки возвращающие определенный код?
C>Нет, там у драйвера была функция, которая возвращала битовую маску с
C>возможностями драйвера.

>> если понадобиться расширить vfs (а оно потихоньку расширяется), то

>> придется переписывать старые драйвера?
>> (Т.е. добавлять пустые заглушки)
C>Вообще-то, для новых функций обычно делают новые интерфейсы.

схема немножко другая: Клиент один, серверов много.

Есть интерфес
struct IFs
{
  virtual int open(int) = 0;
  virtual void  close(int) = 0;
};


Ваш код его реализует и регистрирует его в системе так, что клиенту становится доступна функци module_init()
struct IMyFs : public IFs
{
  virtual int open(int);
  virtual void  close(int);
};
IMyFs* module_init();


Код клиента:
// Для каждого зарегистрированного модуля (сервера)
IFs* fs = module_init();
fs->open(3);



Теперь потребовалось расширить IFs
struct IFs
{
  virtual int open(int) = 0;
  virtual void  close(int) = 0;
  virtual int open(char*) = 0;
};


Нет смысла менять код старых реализаций IFs.
Меняем только необходимые реализации.

Код клиента:
// Для каждого зарегистрированного модуля (сервера)
IFs* fs = module_init();
if ( NULL != fs->open2 )
  fs->open2( "/tmp" );
else
  fs->open(3);
Re[11]: Скорость работы с использованием классов и без
От: Cyberax Марс  
Дата: 03.08.06 15:55
Оценка:
MShura wrote:
> Теперь потребовалось расширить IFs
> struct IFs
> {
> virtual int open(int) = 0;
> virtual void close(int) = 0;
> virtual int open(char*) = 0;
> };
Вот для этого создаешь наследника:
struct IFsWithCharStar : public IFs
{
    virtual int open(char*) = 0;
};


> Нет смысла менять код старых реализаций IFs.

> Меняем только необходимые реализации.
Естественно.

> Код клиента:

> // Для каждого зарегистрированного модуля (сервера)
> IFs* fs = module_init();
> if ( NULL != fs->open2 )
> fs->open2( "/tmp" );
> else
> fs->open(3);
IFsWithCharStar *efs=dynamic_cast<IFsWithCharStar *>(fs);
if (efs)
    efs->open2(...);
else
    fs->open(...);

Хотя это уже, скорее,пример плохого проектирования.
Posted via RSDN NNTP Server 2.0
Sapienti sat!
Re[11]: Скорость работы с использованием классов и без
От: Cyberax Марс  
Дата: 03.08.06 15:58
Оценка:
MShura wrote:
> C>Вероятно, одинаково. Новые процессоры оптимизируют косвенные вызовы.
> Не согласен.
> Как можно оптимизировать вызов виртуальной функции не зная точно типа
> объекта (конструкторы/деструкторы не рассматриваем)
> Т.е. нужно сформировать аргументы, сделать call, проверить с
> определенным (скорее всего ненулевым) значением (проверка на нуль —
> самая простая).
> Однозначно дольше.
В новых процессорах есть предсказатель косвенных переходов. Погугли по
словам "indirect branch prediction". Расходы на формирование списка
аргументов — возможны.

Хотя если код критически зависит по скорости от подобного приема — то я
бы использовал битовую маску.
Posted via RSDN NNTP Server 2.0
Sapienti sat!
Re[9]: Скорость работы с использованием классов и без
От: raskin Россия  
Дата: 03.08.06 19:37
Оценка: +1
MShura wrote:
>> > Этот подход — результат эволюции UNIX/Linux OS.
> C>Вроде бы в Solaris'ной VFS нулевые функции были явно запрещены. Сейчас
> C>лень доставать мануалы.
> Т.е. все драйвера должны реализовать ВСЕ нужные функции а не нужные
> заменить на заглушки возвращающие определенный код?
> если понадобиться расширить vfs (а оно потихоньку расширяется), то
> придется переписывать старые драйвера?
> (Т.е. добавлять пустые заглушки)
Не стал бы я защищать решение в ядре Linux тем, что оно избавляет от
необходимости корректировать (простым образом) код старых драйверов в
ядре при эволюции ядра... Эта необходимость есть by design, во всяком
случае, так декларируется.
Posted via RSDN NNTP Server 2.0
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.