Почему драйверы и прочую системщину пишут, в основном, на C, а не на C++?

А ООПщину считаю ненужным говном.

Зря ты так. Я вот кое-что пишу на C++ для сетевого симулятора NS-3, и понял, что ООП весьма удобно. На С это был бы кошмар.

Ну так у тебя свои задачи, у меня — свои. У меня тупо нет задач, где C++ было бы реально удобней, чем С.

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

ты нервный штоле?

возми Линус за основу план9 вместо «того что было по факту использованно» Linux бы раньше стал бы таким какой есть.

Линукс со всем справляется - только цена(реализации) больше чем в план9

ps. вообще видимо среда/инструмент для людей удобней когда не логично и требует упражнять память скорее чем логику.

...

и зачем я вообще тебе отвечаю... надо заигнорить нафик

в путь.

есть мнение (и Линус его придерживается), что т.н. академическая чистота и красота существует только для теории, в реале она не жизнеспособна

Потому-что драйвер - это почти всегда всего лишь структура с правильными колбеками. Где там может пригодиться спп?

ну в реале она не необходима обычно.

отличный пример(может лучше предложит кто?)арабскиеVSримский «цифры»

пока нужды не было люди вполне обходились с римскими цифрами.

теперь арабские вообще «в детсаду» ибо народному хозяйству проще обучить даже тех кому это не нужно.

с план9 что-то похожее - оно оказалось «рано»

ну в реале она не необходима обычно

тут дело в другом: в реале она обычно вредна, т.е. ухудшает эффективность (работы, разработки)

с план9 что-то похожее - оно оказалось «рано»

ой ли? по-моему, пример с цифрами неудачный, здесь скорее борьба двух методологий: Линукс исповедует следование реалиям, т.е. бесконечную подгонку под эксперимент, тогда как красивая академика типа Plan9 пытается одним выстрелом создать абсолютную систему, покрывающую всё возможное и невозможное, и это очень похоже на религию

Из-за шаблонной магии ты вполне можешь получить код из третьего кольца

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

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

С каких пор Linux использует первое кольцо?

Я пишу драйвера на visual basic.

внезапно везде.

например как это делают в macosx.

Чем кресты не подходят?

очевидно потому, что в крестах набигают пионеры, со своей «шаблонной магией», которую они сами не понимают, но тем не менее, суют где не попадя. Я уж молчу про новые фишки из c++11, там вообще Адъ и Израиль.

постараемся в дискуссии вычленить зерно истины.

есть инфраструктура[всего общества] и есть know-how( ещё(или никогда) не становящимися её(инфраструктуры) частью)[отдельных фирмы/компаний]

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

реалии таковы - что ещё долго людям не нужно уметь в цифры.

тред полон некомпетентных слабообразованныъ идиотов и невежд

</thread>

реалии таковы - что ещё долго людям не нужно уметь в цифры

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

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

Царя уже вносили?

фишка в том, что будь вместо Unix7 Plan9 в конце 70ых среди студентов бродячим текстом( http://en.wikipedia.org/wiki/Research_Unix).

было бы тоже самое что и сейчас только в некоторых частях софта не было бы того зоопарка интерфейсов.

однако до Plan9 (который unixXI фактически) догадались только во второй половине 80ых.

ты за него.

включая тебя как.

и не факт, что этот красивый бродячий текст в процессе эволюции не оброс бы зоопарком

к своей радости, уважаемый бессмысленный человек, анонимус не страдает рефлексией

поздравляю, ты насекомое

после такого утверждения, нет никаких овнований усомниться в твоем отличии от этого насекомого

Вот есть у меня массив чаров с данными. Привести его к структуре с учётом алиасинга можно только скопировав этот массив в юнион из массива и структуры

char* алиасится с любыми указателями, его можно безопасно приводить к любой структуре.

Проблема действительно будет в общем случае, например для массива интов. Просто тонкости алиасинга - это такая капля в море ловушек си...

char* алиасится с любыми указателями, его можно безопасно приводить к любой структуре.

К структуре можно безопасно обратиться через char *, а наоборот уже нельзя.

Я познаю strict aliasing (комментарий)

Нужные цитаты из стандарта есть тут: https://stackoverflow.com/a/19236308

Если просто рассуждать логически и принять во внимание несколько фактов:

• существуют платформы, где unaligned access просто запрещён;
• char * может указывать на любой адрес;
• указатель на структуру должен быть выровнен по первому полю;

то становится понятно, почему в общем случае char * нельзя приводить к указателю на структуру. Да, в частных случаях (именно тех, которые будут встречаться на практике) такое приведение будет иметь смысл. Но в общем случае ничего сказать нельзя, наверное, поэтому такая возможность стандартом и запрещена. Обращаться же через char * к произвольным данным нужно для функций типа memset, memcpy, это действительно разрешено.

оброс бы ,

тока хэловордить в большем числе областей было бы проще всего лишь.

т.е. труд программистов был бы чутка дешевле.

в этом смысле мы(все кто в найме в IT) должны быть благодарны без мерно за массовое php ибо это сдерживает падение оплаты труда за качественное программирование.

Виноват, оговорился. В нулевом, конечно.

Тебе виднее. А при чём тут?

Окей, а причем тут третье кольцо? Ядро всегда работает в нулевом кольце. Никакая шаблонная магия не понизит его уровень до третьего.

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

По крайней мере виндовые драйвера, работающие и в режиме ядра, и в режиме юзера, мне случалось не только видеть, но и писать.

А переключения из одного режима в другой из-за шаблонной магии видеть приходилось? Исключения, перелетающие из одного режима в другой?

Тема скользкая, конечно (что уже позволяет оценить «предсказуемость» си), но мне думается, всё чуть-чуть иначе.

Отношение алиасинга симметрично. Если char* может указывать туда же, куда struct Data*, то и обратное верно.

Значит, если функция принимает char*, то за этим чаром может быть любой объект, т. к. к любому объекту можно обращаться как к char (последний пункт 6.5.7). Вот из C99 Rationale:

In principle, then, aliasing only need be allowed for when the lvalues all have the same type. In practice, the C89 Committee recognized certain prevalent exceptions:
...
Character pointer types are often used in the bytewise manipulation of objects; a byte stored through such a character pointer may well end up in an object of any type.

По-моему, это явное разрешение интерпретировать char* как struct Data*.

Насчет выравнивания - все верно, но это не относится к алиасингу, эти проблемы существовали всегда. Strict aliasing rule ввели в 99 только для оптимизации, как дополнительный, «бесплатный» источник информации для семантического анализа программы. Из того же Rationale:

The types of lvalues that may be used to access an object have been restricted so that an optimizer is not required to make worst-case aliasing assumptions

вот не могу нагуглить 😳

но наличие *int_fast*_t и *int_least*_t все равно намекает

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

Хотя вот у меня int_fast8_t - это char... Но int_fast16_t - уже int или long.

Значит, если функция принимает char*, то за этим чаром может быть любой объект, т. к. к любому объекту можно обращаться как к char

Да.

Character pointer types are often used in the bytewise manipulation of objects; a byte stored through such a character pointer may well end up in an object of any type.

Через char * можно рулить байтиками объектов, байтики по этому указателю могут принадлежать любому объекту. Это означает всего лишь, что char * может оказаться указывающим на любой объект, это не значит, что если на что-то указывает char *, мы можем это переинтерпретировать как другой тип. Если бы было так, можно было бы объявить int a, привести (short *)(char *)&a и получить указатель уже на short. У меня есть такой пример, в нём ломается strict aliasing на gcc 4.9.2, x86_64:

#include <stdio.h>

// gcc 5.c -o 5 -O3 -Wall -Wextra -Wstrict-aliasing=3
// no warning

// gcc 5.c -o 5 -O3 -Wall -Wextra -Wstrict-aliasing=2
// no warning

// gcc 5.c -o 5 -O3 -Wall -Wextra -Wstrict-aliasing=1
// no warning

// strict aliasing is broken

int global;

int modify(char *test)
{
        global = 'a';
        *(short *)test = 'b';
        return global;
}

int main()
{
        printf("%c\n", modify((char *)&global));
        return 0;
}

Программа выводит a, а с -fno-strict-aliasing выводит b.

Вот так вот. А объяснение простое — мы обращаемся к объекту эффективного типа int по lvalue типа short, а short не является совместимым типом с int и не подходит под остальные пункты.

Нет, но я об этом и не говорил.

я об этом и не говорил.

Окей. А вот это:

Miguel> Из-за шаблонной магии ты вполне можешь получить код из третьего кольца, выполняющийся в первом, кинуть там эксепшен и упасть вместе с системой.

было в реальности? И чем отличается от, например, случайно вызванного обращения к пользовательской памяти из прерывания?

From: Linus Torvalds <torvalds <at> linux-foundation.org> Subject: Re: [RFC] Convert builin-mailinfo.c to use The Better String Library. Newsgroups: gmane.comp.version-control.git Date: 2007-09-06 17:50:28 GMT (2 years, 14 weeks, 16 hours and 36 minutes ago)

On Wed, 5 Sep 2007, Dmitry Kakurin wrote:

When I first looked at Git source code two things struck me as odd:
1. Pure C as opposed to C++. No idea why. Please don't talk about portability,
it's BS.

*YOU* are full of bullshit.

C++ is a horrible language. It's made more horrible by the fact that a lot of substandard programmers use it, to the point where it's much much easier to generate total and utter crap with it. Quite frankly, even if the choice of C were to do *nothing* but keep the C++ programmers out, that in itself would be a huge reason to use C.

In other words: the choice of C is the only sane choice. I know Miles Bader jokingly said «to piss you off», but it's actually true. I've come to the conclusion that any programmer that would prefer the project to be in C++ over C is likely a programmer that I really *would* prefer to piss off, so that he doesn't come and screw up any project I'm involved with.

C++ leads to really really bad design choices. You invariably start using the «nice» library features of the language like STL and Boost and other total and utter crap, that may «help» you program, but causes:

- infinite amounts of pain when they don't work (and anybody who tells me that STL and especially Boost are stable and portable is just so full of BS that it's not even funny)

- inefficient abstracted programming models where two years down the road you notice that some abstraction wasn't very efficient, but now all your code depends on all the nice object models around it, and you cannot fix it without rewriting your app.

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. And limiting your project to C means that people don't screw that up, and also means that you get a lot of programmers that do actually understand low-level issues and don't screw things up with any idiotic «object model» crap.

So I'm sorry, but for something like git, where efficiency was a primary objective, the «advantages» of C++ is just a huge mistake. The fact that we also piss off people who cannot see that is just a big additional advantage.

If you want a VCS that is written in C++, go play with Monotone. Really. They use a «real database». They use «nice object-oriented libraries». They use «nice C++ abstractions». And quite frankly, as a result of all these design decisions that sound so appealing to some CS people, the end result is a horrible and unmaintainable mess.

But I'm sure you'd like it more than git.

Linus

в amd пишут дрова на плюсах. там есть правила как писать, что писать что не писать и все просто работает. horrible and unmaintainable mess можно и на чистом С писать, я видел примеры такого, с макросами и глобальными переменными. линус дибил

Я в курсе.

int - это машинное слово, под которое скорее всего процессор оптимизирован.

Мм... На x86_64 sizeof(int) == 4 (размер машинного слова понятен).

вы оба «неточны»

sizeof(int) - это ведь компилятор

конечно у компилятора родителей наиболее обосновано int размером наиболее удобное у данной машины.

но есть и куча других влияющих причин одним словом:

эволюция.

постепенно чисто компиляторов под x86_64 c sizeof(int)=8 увеличиться либо байты пропадут.

Да-да, я не уточнил, речь о GCC... а если точнее, то о текущей версии System V ABI для x86_64. Так что сейчас sizeof(int) == 4 — это de facto стандарт для никсов.

Ну да, от первоначальной задумки уже частично отошли, так как типов просто не хватает, поэтому и пишу «скорее всего».

Но на x86-64 размер данных по умолчанию - все равно 32 бита. Он как раз и требует префикса для других типов.

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

Но все равно я думаю, что если изначально у нас был массив char, то безопасно (с точки зрения алиасинга) его переинтерпретировать как мы хотим.

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

Иначе совсем уж фарс получается.

Ну как есть, если просто буквально читать стандарт.

Я вот кое-что пишу на C++ для сетевого симулятора NS-3

Как давно этим занимаешься? Каковы результаты и есть ли код, который можно показать? Мы как раз работаем в области Cross-Layer Wireless Design, и NS-3 идет как одна из симуляционных платформ.