Здравствуйте, lazyden, Вы писали:
C>> В текущей Mac OS X в ядре тоже используется С++. L>Да, IOKit это с++, точнее говоря embedded c++, который по сути дела си-с-классами с кучей ограничений — стл, бустом и темплейтами там не пахнет. L>Отдельная песня — это описание класса который позволяет изменения (добавление новых полей и виртуальных методов), при этом бинарно совместим L>с предыдущей версией этого класса.
В Линуксе, например, бинарной совместимости вообще нет. И что? А вообще, лучше всего для бинарной совместимости на С++ использовать систему типа COM-интерфейсов.
L>
L>In other words, the only way to do good, efficient, and system-level and portable C++ ends up to limit yourself to all the things that are basically available in C.
Не согласен. Например, мне непонятен запрет template'ов — они реально помогают увеличить быстродействие без особого оверхеда. STL — это, по сути, библиотека контейнеров, и они все равно нужны. В том же Линуксе, контейнеры делаются с помощью макросов (т.е. творчество на тему "темплейты своими руками").
MSS>>Я добавлю — в ядре виндов тоже практически нет Си++, и как-то они не горят желанием его туда тянуть. А аргументы Александреску против Линуса (что это опенсорс, никем толком не руководимый) к ядру виндов не относятся. C>Ну почему же? Вполне есть — многие драйвера его успешно используют.
До появления KDMF из микрософтного — только PortCls, FtDisk и 2мерный графический движок.
Си++ных АПИ в ядре нет и сейчас, даже с KMDF. KMDF и GRE обернуты в Сишный АПИ. Собственно, GREшный CLIPOBJ_bEnum — да, это CLIPOBJ::bEnum.
Pzz>Я не сказал бы, что это "обертка" — ядро BSD там присутствует в полном составе. Я не очень в курсе, как они делят машину между mach'ем и BSD.
Я слышал такое: Mach — это прерывания, объект "нить", объект "адресное пространство", половина системы VM — не хватает pager objects, которые туда можно полиморфно воткнуть, таймеры, kmalloc.
Вокруг Mach там BSD-совместимая обертка, в которой BSDшный объект "процесс", права доступа, тела сисколлов, pagerы для свопа и для mmap, и якобы еще и сеть там BSDшная и файловые системы.
Отдельно есть API для обычных драйверов, тех, что block и char, там есть, в частности, аналог динамической devfs/procfs или виндового IoRegisterDeviceInteface.
Настаивать не буду, слышал краем уха, возможно, у вас больше информации.
Pzz>Там есть еще фрамеворк для писания ядреных драйверов, на C++. Часть драйверов втыкается именно в него — например, сетевые драйвера.
Если на Си++ сделан АПИ для сетевых драйверов — то, похоже, там и IP стек не BSDшный. Я слышал другое, но совсем краем уха.
Здравствуйте, Pzz, Вы писали:
E>>А разве сейчас обсуждаются результаты трудов Торвальда и Александреску? Имхо, обсуждаются сказанные ими вещи. И Александреску правильно говорит, что у Торвальдса команда из сотен очень таланливых разработчиков, они занимаются достаточно специфическими задачами, у них нет жестко оговоренных сроков и бюджетов. В таких условиях C может быть отличным языком. Тем не менее вокруг полно задач, для которых есть сроки, бюджеты и гораздо меньшие команды. В таких условиях C вряд ли много лучше C++, скорее наоборот.
Pzz>Насчет сроков и бюджетов, это немножко подленькая точка зрения.
"Немножко подленькая" -- это как "немножко беременная".
Pzz>Она как бы намекает на то, что ядерные разработчики работают медленнее и неэффективнее, чем индустриальные, из-за того, что они могут себе это позволить.
Она не намекает, она прямо говорит -- если ты сам Вася Пупкин и с тобой работает Федя Иванов, и срок сдачи вчера, и зарплата фиксированная, и заказчик мозги компостирует, и к проекту у тебя душа не лежит, то это совсем другая ситуация, чем когда ты вечерком в mailing-list обсуждаешь с Коксом и Торвальдсом детали очередного патча к очередной версии ядра которое еще не понятно когда зарелизят.
Pzz>Но на самом деле, всем бы работать с такой производительностью, с какой работают разработчики ядра линиха.
Вот и славно. Клепают ребята себе ядро Linux-а на C -- всем хорошо. Другие ребята на C++ KDE для этого ядра сделали. Кому от этого хуже стало?
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
C>В Линуксе, например, бинарной совместимости вообще нет. И что? А вообще, лучше всего для бинарной совместимости на С++ использовать систему типа COM-интерфейсов.
Это и есть описанное Линусом подмножество Си++. У микрософта в PortCls оно используется.
C>Не согласен. Например, мне непонятен запрет template'ов — они реально помогают увеличить быстродействие без особого оверхеда. STL — это, по сути, библиотека контейнеров, и они все равно нужны. В том же Линуксе, контейнеры делаются с помощью макросов (т.е. творчество на тему "темплейты своими руками").
Темплейты — не самое худшее в Си++, хотя и их проабъюзить можно. Это как раз полезная фича языка.
Ссылки и operator+ всякие, и особенно operator T — процентов на 90 есть абъюз. Толковых мест, где ими можно пользоваться, раз, два, и обчелся — только библиотеки строк и контейнеров.
Не по делу примененный overloading — отвратительно. Даже cout << нечто — и то отвратительно. operator T отвратителен вдвойне — для него даже закорючки в синтаксисе не надо.
Ссылки нужны на деле только для того, чтобы поддержать operator++, operator[] и прочее, где операнд или результат есть lvalue. Соответственно, ссылки вне параметров и возвращаемых значений — просто ненужная фича, и причем дурацкая, ибо неполноценно дублирует указатели. Неполноценно потому, что не бывает указателей на ссылки и массивов ссылок.
Ссылки в параметрах и возвращаемых значениях оправданы только в operator XX, в обычной функции пойнтер лучше — в вызовах явно пишется &, что подсказывает, что параметр меняется в результате вызова. Запись f(a), от которой а изменилось, да еще и у f имя по-дурацки выбрано — мерзость.
Здравствуйте, Maxim S. Shatskih, Вы писали:
Pzz>>Там есть еще фрамеворк для писания ядреных драйверов, на C++. Часть драйверов втыкается именно в него — например, сетевые драйвера.
MSS>Если на Си++ сделан АПИ для сетевых драйверов — то, похоже, там и IP стек не BSDшный. Я слышал другое, но совсем краем уха.
Этот C++'ный фрамеворк, похоже, втыкается в BSD. Сеть у Мака BSD'ная.
Здравствуйте, Maxim S. Shatskih, Вы писали:
MSS>>>Я добавлю — в ядре виндов тоже практически нет Си++, и как-то они не горят желанием его туда тянуть. А аргументы Александреску против Линуса (что это опенсорс, никем толком не руководимый) к ядру виндов не относятся. C>>Ну почему же? Вполне есть — многие драйвера его успешно используют. MSS>До появления KDMF из микрософтного — только PortCls, FtDisk и 2мерный графический движок.
Я имею в виду third-party драйвера.
MSS>Си++ных АПИ в ядре нет и сейчас, даже с KMDF. KMDF и GRE обернуты в Сишный АПИ. Собственно, GREшный CLIPOBJ_bEnum — да, это CLIPOBJ::bEnum.
А C++ные API и не нужны. Я бы даже сказал, что они вредные из-за зависимости от версии компилятора. Пока что, лучше всего подходят API в С-шном стиле или COM-объекты.
Здравствуйте, Maxim S. Shatskih, Вы писали:
C>>В Линуксе, например, бинарной совместимости вообще нет. И что? А вообще, лучше всего для бинарной совместимости на С++ использовать систему типа COM-интерфейсов. MSS>Это и есть описанное Линусом подмножество Си++. У микрософта в PortCls оно используется.
Если добавить темплейты, умные указатели и контейнеры — получится почти весь С++.
MSS>Ссылки и operator+ всякие, и особенно operator T — процентов на 90 есть абъюз. Толковых мест, где ими можно пользоваться, раз, два, и обчелся — только библиотеки строк и контейнеров.
Операторы +-/... — это да, их очень редко нужно. operator() — это хорошо для функторов подходит, которыми вполне можно и в ядре пользоваться.
Что еще? Умные указатели тоже очень неплохо во многие места вписываются. Ну и исключения тоже не помешали бы — как показывает опыт Windows, они вполне работают и в ядре.
MSS>Ссылки нужны на деле только для того, чтобы поддержать operator++, operator[] и прочее, где операнд или результат есть lvalue. Соответственно, ссылки вне параметров и возвращаемых значений — просто ненужная фича, и причем дурацкая, ибо неполноценно дублирует указатели. Неполноценно потому, что не бывает указателей на ссылки и массивов ссылок.
Нет. Ссылки, особенно константные ссылки, — это способ самодокументации кода. Если метод принимает константную ссылку — вызывающий может быть уверен, что метод не будет менять объект по этой ссылке (в разумном коде, естественно).
Многие ядерные разработчики вообще не понимают смысла константности — типа "и без const'а же работает". Вот сравнительно свежий пример: http://thread.gmane.org/gmane.linux.kernel/595956/focus=596197
MSS>Ссылки в параметрах и возвращаемых значениях оправданы только в operator XX, в обычной функции пойнтер лучше — в вызовах явно пишется &, что подсказывает, что параметр меняется в результате вызова. Запись f(a), от которой а изменилось, да еще и у f имя по-дурацки выбрано — мерзость.
Неконстантные ссылки — это вообще как раз редкость, именно по этой причине. Я вообще не могу вспомнить, когда я их в последний раз использовал. Хотя константные ссылки я использую везде.
Точнее нет, вру. Могу вспомнить — в реализации вывода в поток. Что еще раз подтверждает плохой дизайн системы потоков в С++.
Здравствуйте, Cyberax, Вы писали:
C>Нет. Ссылки, особенно константные ссылки, — это способ самодокументации кода. Если метод принимает константную ссылку — вызывающий может быть уверен, что метод не будет менять объект по этой ссылке (в разумном коде, естественно).
Константные ссылки в этом плане ничем не лучше константных указателей.
При этом если я в Си передаю чего-нибудь по значению, это видно сразу в точке вызова. А в C++ надо посмотреть еще на прототип функции, чтобы узнать, не берет ли она от объекта ссылку вместо значения.
Заметим также, что есть вещи, связанные с сылками, которые вообще остаются невидимыми. Например, функция, получившая адрес объекта, может за какой-нибудь надобностью его засейвить на будущее, что накладывает на меня обязательства не освобождать память, занятую этим объектом. В этом смысле, передача константной ссылки семантически очень отличается от передачи объекта по значению. Столь глубокое семантическое различие на мой взгляд заслуживает различия и в синтаксисе, причем в том месте, где объект передается, а не в том, где его принимают.
Здравствуйте, Pzz, Вы писали:
C>>Нет. Ссылки, особенно константные ссылки, — это способ самодокументации кода. Если метод принимает константную ссылку — вызывающий может быть уверен, что метод не будет менять объект по этой ссылке (в разумном коде, естественно). Pzz>Константные ссылки в этом плане ничем не лучше константных указателей.
Лучше. Константные ссылки — это по сути оптимизация передачи по значению. В частности, очень частно это делается при передаче временных объектов. Если же брать на них указатель — то мы не можем знать сохранит ли вызываемый код где-то у себя. В случае со ссылками мы знаем, что вызываемый код не будет сохранять переданое ему значение (ну если его не идиоты пишут, конечно).
Язык нам дает гарантию, что если мы не будем делать идиотских поступков — то у нас не будет проблем.
Здравствуйте, Cyberax, Вы писали:
Pzz>>Константные ссылки в этом плане ничем не лучше константных указателей. C>Лучше. Константные ссылки — это по сути оптимизация передачи по значению.
Это плохая оптимизация — у нее слишком много тонких эффектов. Если что-то не может быть сделано прозрачно (а дешевая передача объектов в языке типа Си/C++ не может быть сделана прозрачно, в силу очень открытого интерфейса к реальной памяти машины), то лучше не делать этого вовсе.
C>Язык нам дает гарантию, что если мы не будем делать идиотских поступков — то у нас не будет проблем.
При этом грань, отделяющая идиотский поступок от неидиотского столь тонка...
Здравствуйте, Pzz, Вы писали:
Pzz>>>Константные ссылки в этом плане ничем не лучше константных указателей. C>>Лучше. Константные ссылки — это по сути оптимизация передачи по значению. Pzz>Это плохая оптимизация — у нее слишком много тонких эффектов. Если что-то не может быть сделано прозрачно (а дешевая передача объектов в языке типа Си/C++ не может быть сделана прозрачно, в силу очень открытого интерфейса к реальной памяти машины), то лучше не делать этого вовсе.
Можешь явно написать чем она плохая?
C>>Язык нам дает гарантию, что если мы не будем делать идиотских поступков — то у нас не будет проблем. Pzz>При этом грань, отделяющая идиотский поступок от неидиотского столь тонка...
Нет. Нужно достаточно сильно постараться, чтобы ее перейти — создать объект, который в конструкторе принимает эту ссылку, и сохранить его. Это уже достаточно сложно сделать случайно
Здравствуйте, Maxim S. Shatskih, Вы писали:
MSS>Темплейты — не самое худшее в Си++, хотя и их проабъюзить можно. Это как раз полезная фича языка.
MSS>Ссылки и operator+ всякие, и особенно operator T — процентов на 90 есть абъюз. Толковых мест, где ими можно пользоваться, раз, два, и обчелся — только библиотеки строк и контейнеров.
MSS>Не по делу примененный overloading — отвратительно. Даже cout << нечто — и то отвратительно. operator T отвратителен вдвойне — для него даже закорючки в синтаксисе не надо.
Как человек, которому на C++ довелось посчитать математику (в том числе и с матрицами комплексных чисел в 99-2000-й годах) и сделать несколько систем сериализации/десериализации данных могу сказать вам "Фи!" за подобные рассуждения.
Если вам не нужны ссылки и перегрузка операторов при разработке драйверов -- не пользуйтесь. Оставте их тем, кто как я успешно применяет эти фичи языка в user-space.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, Pzz, Вы писали:
Pzz>Здравствуйте, Cyberax, Вы писали:
C>>Нет. Ссылки, особенно константные ссылки, — это способ самодокументации кода. Если метод принимает константную ссылку — вызывающий может быть уверен, что метод не будет менять объект по этой ссылке (в разумном коде, естественно).
Pzz>Константные ссылки в этом плане ничем не лучше константных указателей.
Здравствуйте, Sash_xp, Вы писали:
S_>Помню, как-то один из создателей UNIX (Ричи, кажется). Сказал, что с архетикрутной точки зрения Linux -полный ноль.
Угу. ОРни это говорили, когда Plan9 создавали. Только вот не получила их новая ОС популятности (а жаль, очч приятная штука вышла).
Здравствуйте, Cyberax, Вы писали:
C>В Линуксе, например, бинарной совместимости вообще нет. И что?
Ну макос — коммерческая ОС, а там бинарная совместимость необходима. А вот в линуксе как раз поиграться с с++ в ядре можно было (хотя может уже и игрались)
C>А вообще, лучше всего для бинарной совместимости на С++ использовать систему типа COM-интерфейсов.
Примерно это там и есть: OSObject.retain() == IUnknown.AddRef(), OSObject.release() == IUnknown.Release(), таблица виртуальных методов класса ==
IUnknown.lpVtbl.
C>Не согласен. Например, мне непонятен запрет template'ов — они реально помогают увеличить быстродействие без особого оверхеда.
Они позволяют убыстрить быстродействие когда вызовы инлайняться, так ведь? Это мало поможет для подгружаемых драйверов — хочешь не хочешь там
будут виртуальные вызовы.
C>STL — это, по сути, библиотека контейнеров, и они все равно нужны. В том же Линуксе, контейнеры делаются с помощью макросов (т.е. творчество на тему "темплейты своими руками").
Насколько я понимаю, использование макросов в ядре обусловлено интрузивностью (ну знаю как это по-русски сказать ) контейнеров. Есть специфичные структуры данных, оптимизированние для каких-то ядерных нужд, которых просто нет в стл. Кроме того темлейтные классы — это бинарный велосипед . Т.е. для каждого типа инстанцируется свой бинарный код, что, наверное, для режима ядра не очень хорошо: все же память в ядре — достаточно дорогой ресурс.
Линус прав в том смысле, что С++ в ядре места нет, а если и есть, то только как си-с-классами. В прикладных программах — скорее наоборот , тот же COM без ATL практически неподъеменый. Но там уже с++ следует сравнивать совсем не с "чистым си", а с явой/дотнетовыми языками.
> C>STL — это, по сути, библиотека контейнеров, и они все равно нужны. В том же Линуксе, контейнеры делаются с помощью макросов (т.е. творчество на тему "темплейты своими руками"). > Насколько я понимаю, использование макросов в ядре обусловлено интрузивностью (ну знаю как это по-русски сказать ) контейнеров. Есть специфичные структуры данных, оптимизированние для каких-то ядерных нужд, которых просто нет в стл.
И каким образом из отсутствия нужных структур данных в STL следует необходимость использования макросов, а не шаблонов?
> Кроме того темлейтные классы — это бинарный велосипед . Т.е. для каждого типа инстанцируется свой бинарный код,
Который потом линкером выкидывается — если код и вправду получился одинаковый. Причем это же справедливо и для макросов.
> Линус прав в том смысле, что С++ в ядре места нет, а если и есть, то только как си-с-классами.
Вообще-то он про GIT говорил...
Posted via RSDN NNTP Server 2.1 beta
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
