Разработчики индийского дистрибутива BOSS (http://en.wikipedia.org/wiki/Bharat_Operating_System_Solutions) (Bharat Operating System Solution), являющегося ответвлением от Debian GNU/Linux и финансируемого из государственных фондов, развивают собственный вариант ядра Linux - MOOL (http://bosslinux.in/bossmool) (Minimalistic Object Oriented Linux), примечательный подготовкой фреймворка для разработки драйверов устройств с использованием объектно-ориентированных технологий на языке C++. Более глобальной целью разработки MOOL является приведение общей кодовой базы ядра к форме, близкой к парадигме объектно-ориентированной разработки.
Кроме фреймворка для разработки драйверов на C++, на первом этапе развития проекта также ведётся работа по сокращению использования глобальных переменных в ядре. Типовые глобальные переменные, используемые несколькими модулями, заменяются на передачу значений в виде аргументов функций. Система также поддерживает создание Message Filter, объёктно-ориентированных обвязок для перехвата системных вызовов, которые позволяют наращивать и менять функциональность системных вызовов без изменения существующего кода ядра. Подобные фильтры оформляются в виде модулей ядра, написанных на языке C++.В качестве основного мотива использования C++ называется упрощение сопровождение кода и сокращение связей внутри ядра. На базе ядра MOOL уже подготовлена экспериментальный вариант дистрибутива, который распространяется (ftp://mirror.bosslinux.in/BOSSMOOL/) под именем BOSSMOOL.
URL: http://www.themukt.com/2014/10/03/bossmool-object-oriented-l.../
Новость: http://www.opennet.dev/opennews/art.shtml?num=40745
И получится Оберон
> И получится ОберонЕсли бы. C++ - язык для тех случаев, когда все остальные подходят ещё хуже. Оберон - очень лаконичный и предсказуемый, зато C++ позволяет выжать максимум производительности даже при использовании высокоуровневых техник. Для разного они, в общем.
И, да, C++ в ядре делать практически нечего. Разве что для какой-нибудь очередной Поттеринговской поделки сгодится, которая без ядерной поддержки не взлетает.
А поттеринговые программы - на сях...
Ну вот потому пока и на сях. :)
Не видел чтобы поттер сильно фанател по плюсам. Писать юзермод на плюсах можно уже сейчас, ничему не противоречит.
Да почему же, плюсы отличный язык, сложный конечно (читая книги по которому, возникает только больше вопросов), но он очень хорош во многих отношениях.Он как девушка с идеальной фигурой - ни кто до этого такого не видел, боятся разглядывать, а значит и считают это злом, т.к. привыкли к дефектным. Просто зачем переписывать с сей на плюсы, ради сомнительной цели - особенности языка плюсов? КПД стремится к нулю?
Просто индусам нужно на хлеб зарабатывать, вот и переписывают по очереди на все языки за бюджетные деньги. Не зря же появилась фраза - про их программистов :)
> Да почему же, плюсы отличный язык, сложный конечно (читая книги по которому,
> возникает только больше вопросов), но он очень хорош во многих отношениях.Он
> как девушка с идеальной фигурой - ни кто до этого такого
> не видел, боятся разглядывать, а значит и считают это злом, т.к.
> привыкли к дефектным. Просто зачем переписывать с сей на плюсы, ради
> сомнительной цели - особенности языка плюсов? КПД стремится к нулю?
> Просто индусам нужно на хлеб зарабатывать, вот и переписывают по очереди на
> все языки за бюджетные деньги. Не зря же появилась фраза -
> про их программистов :)Отличный, да. Но сильно специфический. Ruby тоже ведь хороший язык, но драйвера на нём почему-то обычно не пишут. ;) Сложность языка - это мощный фактор, препятствующий надёжности: чем хуже программист знает язык, тем больше делает ошибок. А потенциальные ошибки в критическом коде, в ядре и его обвязке - как-то совсем не радуют. Их и так хватает, чтобы раз в несколько месяцев устраивать админам холодный душ.
Вообще-то С++ - язык мультипарадигменный.
Например, он может использоваться как низкоуровневый язык без ручного управления памятью.
>>[C++]Он как девушка с идеальной фигурой -Это точно! Требует постоянного внимания, никогда не знаешь чего ещё вытворит и постоянно ломаеццо *ать !!! :)
Я про Оберон, которая ОСь
Так эта ОСь хорошо или плохо?
Выжать максимум производительности помогает компилятор. Язык программирования (любой) - всего лишь способ донести свои мысли до компилятора :) И этот миф, что на каком-то языке программирования, в данном случае - С++, получится более быстрый код, чем, скажем, на Паскале - мифом и остается :)
Для паскаля пока нет крутого компилятора :)
крутой нафик не нужен, нужен - правильный
у паскаля он есть
> крутой нафик не нужен, нужен - правильный
> у паскаля он естьТам с оптимизацией оочень не хорошо ;)
На реальных приложениях - всё отлично.Самое важное для современного софта:
-минимум ошибок;
-сопровождаемость кода;
-код на Си и С++ сопровождать не реально.
> На реальных приложениях - всё отлично.
> Самое важное для современного софта:
> -минимум ошибок;
> -сопровождаемость кода;
> -код на Си и С++ сопровождать не реально.Никто не говорит что всё плохо, для чего-то и неоптимизированного js достаточно, понятно что если в реальном приложении основные временные потери идут на обращения по сети/выборки из бд и манипуляции большими блоками памяти, то то в таких приложениях однопроходного компилятора от древней d7 достаточно за глаза.
> однопроходного компилятора от древней d7lol.
> -сопровождаемость кода;
> -код на Си и С++ сопровождать не реально.Да вот что-то за дельфистами код сопровождать никто не хочет, а линуксное ядро сопровождают при немеряном размере...
>> крутой нафик не нужен, нужен - правильный
>> у паскаля он есть
> Там с оптимизацией оочень не хорошо ;)Сосед по парте тебя обманул.
>>> крутой нафик не нужен, нужен - правильный
>>> у паскаля он есть
>> Там с оптимизацией оочень не хорошо ;)
> Сосед по парте тебя обманул.Даже вспомнить не могу как всех соседей звали, а так да может быть...
Нафиг этот регистронечувствительный Паскаль, тогда уж лучше Modula-2. Тем более, что её компилятор теперь есть в составе GCC.
> И получится ОберонНет. С++ - это антиОберон.
Это попытка сделать реактос, только вместо ядра NT - Linux :).
>только вместо ядра NT - LinuxА тут без шуток. Вся эта игра вокруг WSL, в конечном итоге, к этому и приведёт.
Странно, что индусы не пишут дрова на xml. А получится не оберон, а очередной никому не нужный випнет.
Вы почти угадали. У них про это упомянуто: "It also allows implementation of policies in form of (object oriented) code instead of only a static policy data (e.g. policy file written in a DSL or XML)."
> a static policy dataшел-код в принципе тоже static policy data, так что ... кто всё это разгребать будет???
Если напр. спинлок от сетевухи подерётся с другим, у другой сетевухи при многолинковых соединениях...
> of policies in form of (object oriented)И вот это будет проще майнтайнить? По-моему они зубы заговаривают.
Тут смари чо:> объёктно-ориентированных обвязок для перехвата системных вызовов
Там дыреней будет лет на 10 вперёд с запасом.Поэтому можно легко срубить бабла на саппорте :D
>Поэтому можно легко срубить бабла на саппорте :Dблин, павлин за последнее время стал умные вещи говорить
тут ты, батенька, в самое яблочко попал
> блин, павлин за последнее время стал умные вещи говоритьДа павлин как стоящие часы - два раза в сутки показывает правильное время :).
Тогда уж календарный листок.
За 4 октября.
> Тогда уж календарный листок.
> За 4 октября.Не, ну знаешь, павлин хоть и работает в режиме генератора рандомного спама, но угадывает явно чаще раза в год.
> Тогда уж календарный листок.
> За 4 октября.да еще и конкретно в субботу?
А что было 4 октября, кроме запуска первого ИСЗ?
> Странно, что индусы не пишут дрова на xml.Муха-ха-ха!!! Это 100%, 100500 левел троллинга! Их же любимый фетиш - жаба и хмл ...
А что не на Java, Jvm нужна ?
было уже, не взлетело...
Почему же не взлетело? Взлетело. Андроидом зовётся. КПД, правда, у этого полёта...
У андрюши обыкновенное ядро Linux, java там только для рантайма, и то у ВМ своя реализация, а не сановская.Не пишите ересь.
КПД у Андроеда выше 100% и кроме iOS ваще не имеет конкурентов.
Под Windows/MacOS столько программ нет, сколько под Андроид.
И только благодаря Андроид любой может себе все, что раньше
ограничивалось стоимостью железа и софта. Ибо купив кетайский
Ляо MTK за 50$ или Gresso Radical Black R3 за 3000$, результат
использования будет абсолютно одинаковый.
> КПД у Андроеда выше 100% и кроме iOS ваще не имеет конкурентов.Ну, на вкус и цвет, конечно, но как по мне, оба плохи.
> Под Windows/MacOS столько программ нет, сколько под Андроид.
Это, пожалуй, правда. Но толку-то от их количества, если большинство из них - дешёвые поделки нерадивых студентов да вирусописателей?
> И только благодаря Андроид любой может себе все, что раньше
> ограничивалось стоимостью железа и софта. Ибо купив кетайский
> Ляо MTK за 50$ или Gresso Radical Black R3 за 3000$, результат
> использования будет абсолютно одинаковый.Да неужели. Ну, тогда у GNU/Linux тоже потенциал выше 100%, ибо купив китайский ноутбук и накатив на него Debian Вы сможете делать всё то же, что и на новеньком маке.
> КПД у Андроеда выше 100%Значит надо надеть каски и быстренько съе...ть оттуда, издали наблюдая за тем как оно пойдет вразнос.
хоспади ...
вантуз уже индусский чуть меньше чем полностью ...
так они уже и до ведра добрались ...
> хоспади ...
> вантуз уже индусский чуть меньше чем полностью ...
> так они уже и до ведра добрались ...Справедливости ради, индусы индусам рознь. Мой бывший непосредственный начальник - потомственный индус, при этом блестящий специалист, хороший преподаватель и просто потрясающий человек. Собственно, "бывший" - потому что финансово-семейные обстоятельства вынудили его уехать зарабатывать на собственное жильё... В общем, я очень горжусь знакомством и благодарен ему за многое, чему я у него научился.
Вообще у индусов все шансы повторить успех Китая, сколько шуму подняла на тех. ресурсах, сверхдешевая космическая миссия на Марс, удавшаяся полностью и с первого раза.Горы ЙТшников с высокой конкуренцией и соответственно большими требованиями к самосовершенствованию. Да к кстати, посмотрите кто в топах у Гугла, после тройки основателей! ;-)
> Горы ЙТшников с высокой конкуренцией и соответственно большими требованиями
> к самосовершенствованию.Насколько понимаю, с этими браминами всё далеко не так однозначно.
>Насколько понимаю, с этими браминами всё далеко не так однозначно.именно, топовым, опытным кодерам и так работы хватает, они сидят себе и кодят проприетарный софт за нехилые баблосы, им всякие сомнительные недопроекты не нужны.
а вот те которые пытаются изобрести очередной велосипед - обычно неопытные и криворукие по определению.
"Индусский код" плодят индусы на аутсорс собственно в Индии. А толковые ребята у них очень быстро оттуда уезжают.
> "Индусский код" плодят индусы на аутсорс собственно в Индии. А толковые ребята
> у них очень быстро оттуда уезжают.плодят и плодят
тогда уж лучше на rust
жабу им уже предлагали?
лучше на C# ведро переписать или на vbs
> лучше на C# ведро переписать или на vbsУже был какой-то прожЕкт от ms. Понятно насколько всем оказался нужен. Ну и си++ туда же пойдет. Торвальдс стопроцентно этим концептуалам волшебную палочку покажет.
>Торвальдс стопроцентно этим концептуалам волшебную палочку покажет.Врядли.
Он скорее всего даже внимания не обратит, ибо проект мертворождённый.
> Он скорее всего даже внимания не обратит, ибо проект мертворождённый.Он внимания не обратит, если к нему с этой бнопней не полезут. А если полезут - тогда покажет.
> Уже был какой-то прожЕкт от msSingularity.
>> Уже был какой-то прожЕкт от ms
> Singularity.И, кстати, проект этот был исключительно исследовательским, в отличие от.
> И, кстати, проект этот был исключительно исследовательским, в отличие от.А у этих прожЕкт тоже чисто исследовательский, только они пока об этом еще не знают :)
Лучше на CUDA.
> Лучше на CUDA.Да чего мелочиться? Сразу на брейнфаке давайте.
вот же придурки
> Стоит напомнить, что Линус Торвальдс является ярым противником C++ и считает его ужасным языком, сковывающим разработчиков рамками ранее созданных абстракций (например, при желании избавиться от неэффективных абстракций, разработчик сталкивается с тем, что весь код зависит от созданных вокруг этих абстракций объектных моделей и не может исправить ситуацию не переписывая своё приложение).вот же мозгач Линус! молодец, правильно думает..
что же будет когда его не станет (из-за автобуса, того-самого)..?
А если сишнаую структуру захочешь изменить(заменить существующее поле на другое) то что внезапно весь зависимый софт сам перепишется под новую структуру?Вообще в API всегда встают вопросы о поддержке каких-то структур/функций и желании их заменить, переписать. Так что это как-то из пальца высосано. Эта проблема всплывёт как в C++ так и в С.
> Эта проблема всплывёт как в C++ так и в С.Эта проблема всплывет в любом языке. Вопрос в объеме кода, который действительно зависит от таких изменений.
В С и С++ при правильном написании это - только тот код, который реально работает с этими полями. Весь остальной код, касающийся этой структуры, видит только указатель - то есть некое место в памяти определенного размера, но неизвестного назначения.
>> Эта проблема всплывёт как в C++ так и в С.
> Эта проблема всплывет в любом языке. Вопрос в объеме кода, который действительно
> зависит от таких изменений.
> В С и С++ при правильном написании это - только тот код,
> который реально работает с этими полями. Весь остальной код, касающийся этой
> структуры, видит только указатель - то есть некое место в памяти
> определенного размера, но неизвестного назначения.А как эта скомпилированная программа на C/C++ узнает сколько памяти нужно выделить под переменную? Правильно, заголовки подключит. И таким образом всё равно при изменении полей структуры придётся перекомпилировать все пользующиеся этой структурой программы, хотя казалось бы, интерфейсы остались неизменными.
Это известная проблема языка C, которая, к сожалению, не решается просто "правильным" написанием кода. Но что касается наличия данной проблемы в других языках, то квантификатор "любой" тут не к месту. Существуют языки, которые от этого не страдают. Лиспы, например.
Неизменными интерфейсы будут только в том случае, если в интерфейсах используется не структура, а указатель на нее. В этом случае тому коду, который не лезет внутрь структуры, безразлично, что скрывается под void*, а тому, который лезет - ну, тут перекомпиляция при изменениях неизбежна.
> Неизменными интерфейсы будут только в том случае, если в интерфейсах используется не
> структура, а указатель на нее. В этом случае тому коду, который
> не лезет внутрь структуры, безразлично, что скрывается под void*, а тому,
> который лезет - ну, тут перекомпиляция при изменениях неизбежна.Я правильно понимаю, что Вы предлагаете:
1) В заголовках писать только определение интерфейсов,
2) Описание структуры вынести из заголовков в код библиотеки,
3) Интерфейс-конструктор будет выделять память в куче и возвращать указатель на неё, а все остальные интерфейсы будут оперировать указателями структуры,
4) В программе, которая пользуется библиотекой, все переменные, подразумевающие хранение данной структуры, будут иметь тип void.Если я правильно Вас понял и ничего не забыл, то в принципе это выглядит как решение... Но не станет ли код слишком громоздким?
Описание структуры логично вынести из заголовков с API в заголовки, которые будет подключать только тот код, которому это действительно нужно. Остальному перекомпилироваться совершенно необязательно.
А что делать? Либо поля структуры, их размер, порядок, тип и количество являются частью интерфейса — и тогда мы можем сами выделять память, обращаться к отдельным полям не call get_field1, а mov eax, [struct_var+offset_field1], и т.п., — либо не являются, а вместо них есть абстрактный интерфейс к структуре — функции создания/удаления, геттеры-сеттеры, всякие удобные запросы (типа метода size() для связного списка) — но тогда, увы, появляются накладные расходы за счет косвенности, и полностью их никак не убрать.
Накладные расходы - не такая уж большая плата за новый уровень абстракции. Проблема как раз в том, что читать это будет невозможно. Тут возникает логичный вопрос: зачем Вам вообще сдалась жёсткая типизация языка Си, если при работе с библиотеками Вы будете использовать void* для структуры, определённой этой библиотекой? Вы мало того, что читать это замучаетесь, так ещё и потеряете (хоть и не шибко хороший) контроль типов.Я вот чувствую, что если мой собеседник ещё немного поразмышлял бы, то пришёл бы к выводу, что для подобного программирования очень подходят языки с динамической типизацией переменных.
Могу в ответ посоветовать вам поразмышлять: возможно, для подобных задач просто стоит использовать не жесткие структуры, а что-то другое? Глядишь, и не понадобится оверхед на ненужные абстракции типа динамической типизации переменных.
Сейчас по разнице между форматами обмена информацией (бинарным, расширяемым и комбинированным) накоплен колоссальный мировой опыт...
Извините, но я предпочту закончить этот диалог. Он как-то сильно на два монолога смахивает.
Нахрен void*? Или в С нельзя сказать
struct MEGA_STRUCT;
typedef struct MEGA_STRUCT* PMEGA_STRUCT;
? Вот вам PMEGA_STRUCT, вот вам функция FIRST_FIELD_TYPE get_first_field(PMEGA_STRUCT), вот вам PMEGA_STRUCT alloc_struct(void*(*)(size_t)). Правда, я с чистым С никогда не работал, может, там так и нельзя.Хотя, конечно, разница между mega_struct.first_field = 5 и set_first_field(mega_struct, 5) есть, я не спорю - ну так поэтому в С++ часто вместо сеттеров пишут геттеры, которые возвращают ссылки, чтобы можно было писать mega_struct.first_field() = 5.
> А как эта скомпилированная программа на C/C++ узнает сколько памяти нужно выделить под переменную? Правильно, заголовки подключит.Причём здесь заголовки? В Си вы можете написать в заголовке:
/* my_object.h */
struct my_object;
struct my_object * my_object_create();
int my_object_do_something(struct my_object * object);И всё. А саму структуру и работу с ней вы можете расписать в реализации:
/* my_object.с */
struct my_object {
int field1, field2;
...
};struct my_object * my_object_create() {
struct my_object * ret = malloc(sizeof(struct my_object));
...
return ret;
}int my_object_do_something(struct my_object * object) {
object->field1 = ...;
...
}
Таким образом пользователь может вообще ничего не знать об объекте my_object и работать с ним только посредством функций, которые вы ему для этого определите.В С++ такой номер не пройдёт - там, если вы хотите чтобы работали виртуальные методы, нужно иметь прототип класса. И изменить что-то в этом базовом классе без необходимости перекомпиляции всего когда снизу доверху вы не сможете.
>> А как эта скомпилированная программа на C/C++ узнает сколько памяти нужно выделить под переменную? Правильно, заголовки подключит.
> Причём здесь заголовки? В Си вы можете написать в заголовке:
> /* my_object.h */
> struct my_object;Не знал, что можно объявлять структуру, не объявляя сами поля.
Серьёзно, я продолжаю периодически узнавать что-то новое, и это меня всё больше и больше удивляет. Вот документация: http://www.gnu.org/software/gnu-c-manual/gnu-c-manual.html#D...И здесь ни слова о том, что так можно.
Но так, оказывается, действительно можно. Я сейчас специально поискал подобные вещи. Нашёл в stdio.h - именно так, оказывается, определена структура FILE.
Вот логичный вопрос-продолжение: а есть ли где-нибудь более подробная справка, в которой такие моменты обозначены?
> Вот логичный вопрос-продолжение: а есть ли где-нибудь более подробная справка, в которой
> такие моменты обозначены?да. называется «стандарт языка си». стоит недорого.
ниже ответил
>[оверквотинг удален]
>> структуры, видит только указатель - то есть некое место в памяти
>> определенного размера, но неизвестного назначения.
> А как эта скомпилированная программа на C/C++ узнает сколько памяти нужно выделить
> под переменную? Правильно, заголовки подключит. И таким образом всё равно при
> изменении полей структуры придётся перекомпилировать все пользующиеся этой структурой
> программы, хотя казалось бы, интерфейсы остались неизменными.
> Это известная проблема языка C, которая, к сожалению, не решается просто "правильным"
> написанием кода. Но что касается наличия данной проблемы в других языках,
> то квантификатор "любой" тут не к месту. Существуют языки, которые от
> этого не страдают. Лиспы, например.Как бы перекомпилировать ядро с новой версией всё равно необходимо...
В С++ легче чем в C. Templates рулят, правда не для школьников.
> А если сишнаую структуру захочешь изменить(заменить существующее поле на другое) то что внезапно весь зависимый софт сам перепишется под новую структуру?А в чём проблема? Передавайте в функцию указатель на структуру, а какие поля у этой структуры, никого может не волновать, кроме внутренней реализации.
Вы можете вообще даже не объявлять поля структуры:
struct my_object;
struct my_object * my_object_create();
int my_object_do_something(struct my_object * object);И это будет работать. А о внутренней структуре вашего объекта пользователь может вообще ничего не знать, в отличие от плюсов.
>> А если сишнаую структуру захочешь изменить(заменить существующее поле на другое) то что внезапно весь зависимый софт сам перепишется под новую структуру?
> А в чём проблема? Передавайте в функцию указатель на структуру, а какие
> поля у этой структуры, никого может не волновать, кроме внутренней реализации.
> Вы можете вообще даже не объявлять поля структуры:
> struct my_object;
> struct my_object * my_object_create();
> int my_object_do_something(struct my_object * object);
> И это будет работать. А о внутренней структуре вашего объекта пользователь может
> вообще ничего не знать, в отличие от плюсов.И тут как-то внезапно выясняется, что C++ как бы не должен быть хуже C.
Вообще.
struct my_object1;
struct my_object2;int do_something(struct my_object1 *);
int do_something(struct my_object2 *);
:-)
Внезапно выясняется, что если вы хотите использовать какие-то методы класса, класс должен быть определён :)
> Вы можете вообще даже не объявлять поля структуры:
> struct my_object;
> struct my_object * my_object_create();
> int my_object_do_something(struct my_object * object);Уважаемый, не затруднит ли Вас подсказать мне, где это задокументировано, что можно объявлять структуры, не объявляя сами поля?
А то меня очень огорчает тот факт, что о таких вещах я узнаю только сейчас, хотя вроде бы с Си очень давно знаком.
> Уважаемый, не затруднит ли Вас подсказать мне, где это задокументировано, что можно
> объявлять структуры, не объявляя сами поля?в стандарте, однако. forward declaration называется.
>> Уважаемый, не затруднит ли Вас подсказать мне, где это задокументировано, что можно
>> объявлять структуры, не объявляя сами поля?
> в стандарте, однако. forward declaration называется.Я думаю, не с проста Вы не приводите ссылок. Я поискал. И стандарт, и forward declaration. И не нашёл этой документации. Arisu, попробуйте быть снисходительным, ибо вещи, которые Вам так очевидны, мне таковыми очень не кажутся.
> Я думаю, не с проста Вы не приводите ссылок.конечно: я предполагаю минимальные навыки гуглежа.
> Я поискал. И стандарт, и forward declaration. И не нашёл этой документации.
это прискорбно. я по «c struct forward declaration» нашёл сразу много интересного. тебе гугель поломали.
а стандарт денег стоит, да. поэтому на него очень сложно ссылки приводить.
> Arisu, попробуйте
> быть снисходительным, ибо вещи, которые Вам так очевидны, мне таковыми очень
> не кажутся.куда уж дальше-то? и направление поиска дал, и ключевые слова… ни разу не написал, что «это должны знать все, а кто не знает — тот лох». ан нет, мало, надо разжевать и в рот положить. пардон, но это уже только за деньги.
>> Я поискал. И стандарт, и forward declaration. И не нашёл этой документации.
> это прискорбно. я по «c struct forward declaration» нашёл сразу много интересного.
> тебе гугель поломали.Arisu, мне сдаётся, что ты видишь то, что хочешь видеть. Интересного мне не надо. Мне надо чётких определений. Какой смысл посылать человека на stackoverflow и wikipedia, когда тебя спрашивают про документацию?
> а стандарт денег стоит, да. поэтому на него очень сложно ссылки приводить.
Неужели же нет где-нибудь халявной версии? Я вот тоже поискал-поискал, да обломался.
upd: однако нет, нашёл. http://www.open-std.org/jtc1/sc22/wg14/>> Arisu, попробуйте
>> быть снисходительным, ибо вещи, которые Вам так очевидны, мне таковыми очень
>> не кажутся.
> куда уж дальше-то? и направление поиска дал, и ключевые слова… ни разу
> не написал, что «это должны знать все, а кто не знает
> — тот лох». ан нет, мало, надо разжевать и в рот
> положить. пардон, но это уже только за деньги.Arisu, а не звучит ли это странно после такого начала:
>> Я думаю, не с проста Вы не приводите ссылок.
> конечно: я предполагаю минимальные навыки гуглежа.То есть мне гугль поломали, искать я не умею. А ты, значит, умеешь, но ссылки привести не можешь. Гундишь только: "обленились совсем, всё им на блюдечке"... Тоже мне, Д'Артаньян.
> Arisu, мне сдаётся, что ты видишь то, что хочешь видеть. Интересного мне
> не надо. Мне надо чётких определений. Какой смысл посылать человека на
> stackoverflow и wikipedia, когда тебя спрашивают про документацию?что-то я запамятовал: когда мы успели трудовой договор заключить? и где моя зарплата?
> Arisu, а не звучит ли это странно после такого начала:
нет.
> То есть мне гугль поломали, искать я не умею. А ты, значит,
> умеешь, но ссылки привести не можешь. Гундишь только: "обленились совсем,
> всё им на блюдечке"... Тоже мне, Д'Артаньян.Rasch abkochen, dann Vormarsch nach Sokal.
upd: стандарты
http://www.open-std.org/jtc1/sc22/wg14/
> upd: стандарты
> http://www.open-std.org/jtc1/sc22/wg14/Ну вот видишь, Кэп конечно бывает редиской с его наездами, но зачастую оказывается прав. После наезда то нашлось. Вот так волшебные пинки и творят чудеса в обучении пользовании поисковиками :)
только вот стандарты там маленько не качаются, и текстов нет. C11, например, купить предлагают. даже, вроде бы, и драфтов нет.
Это называется tentative definition. Задокументировано в стандарте C99, если вам нужно точно:> 6.9.2 External object definitions
> ...
> A declaration of an identifier for an object that has file scope without an initializer, and without a storage-class specifier or with the storage-class specifier static, constitutes a tentative definition.Ifatranslation unit contains one or more tentative definitions for an identifier, and the translation unit contains no external definition for that identifier, then the behavior is exactly as if the translation unit contains a file scope declaration of that identifier, with the composite type as of the end of the translation unit, with an initializer equal to 0.Это относится не только к структурам, но и, например, к массивам:
int array[];
int * ptr = array;
...
int array[10];
И это правильно :)
> Это называется tentative definition. Задокументировано в стандарте C99, если вам нужно
> точно:
>> 6.9.2 External object definitions
>> ...
>> A declaration of an identifier for an object that has file scope without an initializer, and without a storage-class specifier or with the storage-class specifier static, constitutes a tentative definition.Ifatranslation unit contains one or more tentative definitions for an identifier, and the translation unit contains no external definition for that identifier, then the behavior is exactly as if the translation unit contains a file scope declaration of that identifier, with the composite type as of the end of the translation unit, with an initializer equal to 0.
> Это относится не только к структурам, но и, например, к массивам: ...Спасибо. Я нашёл стандарт и прочитал этот кусок. Там, вроде, не говорится о структурах.
Структуры, вообще говоря, разговор особый. Насколько я могу понять, люди обычно говорят об: объявлении(declare) структуры (struct name;), об определении(define) структуры (struct name {char* field1, char* field2};), об объявлении переменной, типом которой является структура (struct name var;) и об определении этой переменной (struct name var = {"Dmitrii", "Kashin"});
Я на выходных поищу в стандарте определение слов declare и define. Интересно посмотреть, что стандарт говорит по этому поводу.
> Спасибо. Я нашёл стандарт и прочитал этот кусок. Там, вроде, не говорится о структурах.А это, собственно говоря, относится ко всем типам. Можно написать:
int x;
int x = 1;
И это будет правильно :)
> Я на выходных поищу в стандарте определение слов declare и define. Интересно посмотреть, что стандарт говорит по этому поводу.
Интересно, что даже компиляторостроители иногда не отличают эти термины. Например, разные компиляторы называют разными словами одну и ту же ошибку:
> error: 'x' undeclared (first use in this function)
> Undefined symbol 'x' in function main
Идея правильная, но язык выбран крайне неудачно. Справедливости ради, выбора тут нет нет.
Отличная новость! Наконец-то кто-то решился на эту экспериментальную проверку непригодности C++ для ядерного программирования. Запасаемся попкорном и наблюдаем, желая успеха индусам: если C++ окажется удачнее, то у нас будет ядро лучше, чем linux. Ну, а если они ошибаются, то мы, по-крайней мере, сможем поглумиться, повторяя "а Торвальдс предупреждал".
BeOS
Haiku
Symbian
все в жопе.
> все в жопе.Еще ReactOS, где ядро переписывали раза три. Последнее на каком-то урезанном субсете плюсов. А более вменяемые люди не выделывались и просто написали ядро на сях 1 раз, зато нормальное. У реально существующих ОС ядра оптимизированы на то чтобы это работало и желательно быстро и безглючно. А насколько оно концептуально - интересно десятку чудаков на всю планету.
Ну Symbian в опе благодаря усилиям маркетолухов и помощи M$.
> Ну Symbian в опе благодаря усилиям маркетолухов и помощи M$.А также благодаря у...щности системы. Новое разрешение экрана добавить? На симбиане это героизм и достижение. Поэтому смарты на симбиане нокия улучшала в плане экранов очень неохотно. А уж как этот крап работал с сенсорным экраном - это вообще жесть.
> Отличная новость! Наконец-то кто-то решился на эту экспериментальную проверку непригодности
> C++ для ядерного программирования. Запасаемся попкорном и наблюдаем, желая успеха индусам:
> если C++ окажется удачнее, то у нас будет ядро лучше, чем
> linux. Ну, а если они ошибаются, то мы, по-крайней мере, сможем
> поглумиться, повторяя "а Торвальдс предупреждал".Проблема в том, что всегда можно будет указать на совершенно иные причины фейла.
"Внутренние конфликты", "Разное видение у разработчиков", "Сворачивание финансирования" и т.д.
И типа, "но сама идея хорошая, только неосилили".
Хотя, вполне возможно, что внутренние конфликты и сворачивание финансирование произошло из за того, что никак не получалось сделать конфетку.
Но в этом могут и не признаться.
>[оверквотинг удален]
>> linux. Ну, а если они ошибаются, то мы, по-крайней мере, сможем
>> поглумиться, повторяя "а Торвальдс предупреждал".
> Проблема в том, что всегда можно будет указать на совершенно иные причины
> фейла.
> "Внутренние конфликты", "Разное видение у разработчиков", "Сворачивание финансирования"
> и т.д.
> И типа, "но сама идея хорошая, только неосилили".
> Хотя, вполне возможно, что внутренние конфликты и сворачивание финансирование произошло
> из за того, что никак не получалось сделать конфетку.
> Но в этом могут и не признаться.Ну вы же понимаете, что чем больше фейлов C++ на поприще ядерного программирования, тем сложнее отрицать его непригодность. Матлогика в подобных ситуациях бессильна, а вот probabilistic reasoning очень даже может выкрутится, обойдясь тем, что в суде называются "косвенными" доказательствами. Да и в конце-концов -- мне без разницы признают ли C++-фаны фейл C++. Мне интереснее проверить свои убеждения, особенно если эта проверка будет стоит мне лишь попкорна.
> бессильна, а вот probabilistic reasoning очень даже может выкрутится,Ваш probablistic reasoning всего лишь то что люди попроще называют опытом и обобщением. Вот так вот и получается что даже грузчик с тремя классами образования на базовом уровне владеет этим предметом. Только не знает об этом.
>> бессильна, а вот probabilistic reasoning очень даже может выкрутится,
> Ваш probablistic reasoning всего лишь то что люди попроще называют опытом и
> обобщением. Вот так вот и получается что даже грузчик с тремя
> классами образования на базовом уровне владеет этим предметом. Только не знает
> об этом.Да-да. И логикой все владеют от рождения, только не знают об этом.
> Да-да. И логикой все владеют от рождения, только не знают об этом.Ну, допустим, не все. Darwin Awards подтверждает - отклонения случаются и к добру не приводят.
> Отличная новость! Наконец-то кто-то решился на эту экспериментальную проверку непригодности
> C++ для ядерного программирования. Запасаемся попкорном и наблюдаем, желая успеха индусам:
> если C++ окажется удачнее, то у нас будет ядро лучше, чем
> linux. Ну, а если они ошибаются, то мы, по-крайней мере, сможем
> поглумиться, повторяя "а Торвальдс предупреждал".Драйвер fglrx на C++. Недавно был "отвязан" от libstdc++.so.5. Он такой плохой из-за плохого отношения к Linux в ATi, а в AMD потратили денег на его починку (оказалось дешевле, чем переписать) и теперь он нормален. И всё-таки если бы он был на Си, проблем с исправлением не было бы изначально.
> Отличная новость! Наконец-то кто-то решился на эту экспериментальную проверку непригодности
> C++ для ядерного программирования.Вон уже есть реактос. Используйте наздоровье.
> Запасаемся попкорном и наблюдаем, желая успеха индусам:
> если C++ окажется удачнее, то у нас будет ядро лучше, чем linux.Думаю, экспедиция на Марс отправится раньше.
> Ну, а если они ошибаются, то мы, по-крайней мере, сможем
> поглумиться, повторяя "а Торвальдс предупреждал".А Торвальдс - руководитель проекта, который не дрoчит на концепции а достигает результатов. Этим он и отличается от безбашенных концептуалов с горящими глазами, готовыми все разворотить чтобы свои концепции вкостылить, доказывая с пеной у рта что если все падает и глючит - это ничего, так и надо.
> Вон уже есть реактос. Используйте наздоровье.Нет, спасибо
> Думаю, экспедиция на Марс отправится раньше.
Я тоже много чего думаю, но при этом различаю умозрительные выводы и факты. И вам рекомендую.
> Нет, спасибоА чего так? :)
> Я тоже много чего думаю, но при этом различаю умозрительные выводы и факты.
Это моя ставка на то чем это закончится. Наиболее вероятный по моему мнению сценарий. Возник на основе смотрения на успех других систем с ядрами на плюсах.
Не хочу ничего сказать, но "ядро на плюсах" (или чем-то еще) - очень абстрактное преимущество, не представляющее из себя никакой самоценности для большинства людей. А какой-нибудь симбиан например был полным шитом совершенно независимо от плюсов в каждой дырке.
>> Нет, спасибо
> А чего так? :)Не вижу причин. А почему вы спрашиваете? Вы видите какие-либо причины пользоваться ReactOS? С удовольствием ознакомлюсь со списком таких причин.
> Не вижу причин. А почему вы спрашиваете?
> Вы видите какие-либо причины пользоваться ReactOS?Ну мало ли. Отдельные экзотичные личности за "зато на плюсах!" или "зато клон ядра NT!" вон многое прощают. Это конечно очень спорные в плане рациональности подходы, но они бывают.
> С удовольствием ознакомлюсь со списком таких причин.
Честно говоря я их тоже не вижу. Как минимум для себя.
> Наконец-то кто-то решился на эту экспериментальную проверку непригодности C++ для ядерного программирования.Бугага. Таких попыток было... по пояс будет. Самая старая какую могут вспомнить - Chorus.
sed /BOSSMOOL/BSOD/
Весело им будет. В ядре-то только строгая безопасность с исключениями может использоваться (strong exception-safety). Посмотрим, как у них выйдет это сделать. И это только одна из проблем.
Вообще-то устраивать kernel panic и на Сях нельзя.
С++ предоставит возможность хотя бы ловить и обрабатывать проблемы не в каждом возможном месте их возникновения, а общим блоком. То, что в дровах все такие потенциальные проблемы должны обрабатываться, от языка не зависит.
имхо, давно пора. расширение возможностей ядра, как никак. в идеале должна быть возможность разработки модулей ядра на любых языках
> в идеале должна быть возможность разработки модулей ядра на любых языкахНапуркуа?
Вы сами когда в последний раз модули ядра писали?
> возможность разработки модулей ядра на любых языкахНу и как в каком-нибудь бидоне будет выглядеть присвоение адресу 0x100500 значения 0xDEADBEEF? Допустим это memory mapped регистр что-то делающий с вон той железкой. Ну на си - народ прямо так и напишет. Потому что системный ЯП. А вот что будут делать гламурные мальчики-вебдванольчики с высокоуровневым ЯП - не очень понятно. Си используют для системных дел ... потому что он позволяет делать манипуляции, которые по другому только на ассемблере и сделаешь.
Хмм, да также как и в С - операция присваивания переменной(находящейся в памяти по этому адресу) константного значения. Или вы из тех, кто плодит говнокод, насыщенный магическими числами и копипастой?
> Хмм, да также как и в С - операция присваивания переменной(находящейся в
> памяти по этому адресу) константного значения.Так в сях можно указать что вон та переменная - это вот тот адрес.
> плодит гoвнокод, насыщенный магическими числами и копипастой?
Весь код работы с периферией - куча магических чисел. Сюрприз. Правда культурные люди назначают им человекочитаемые определения, но сама по себе возможность сунуться в конкретный адрес памяти - фича сей, там указатели это просто адрес в памяти. Что и позволяет достаточно человекочитаемо работать с магическими адресами и магическими значениями в них. А в питонах и рубях такое изначально вообще не предусмотрено. Там нет никакого метода указать что "а вот эта переменная должна лежать по этому адресу". Да и вообще смысл высокоуровневого ЯП как раз в том чтобы програмер таким себе мозг не грел. Но это обрубает низкоуровневые возможности. По каким-то таким причинам все мало-мальски живые системы писаны на сях. Лучше за столько лет все-равно ничего не сделали.
>Лучше за столько лет все-равно ничего не сделали.http://en.m.wikipedia.org/wiki/Oberon_operating_system
http://www.a2.ethz.ch/
> Весь код работы с периферией - куча магических чисел. Сюрприз.Нет, не сюрприз. Также как не сюрприз, что ты не знаешь значения термина "магические числа" в отношении патернов программирования.
Правда культурные
> А в питонах и рубях
> такое изначально вообще не предусмотрено. Там нет никакого метода указать что
> "а вот эта переменная должна лежать по этому адресу".Тебе буквально следующим постом показали как это сделать на питоне. Ниасилил многабукав?
> вообще смысл высокоуровневого ЯП как раз в том чтобы програмер таким
> себе мозг не грел. Но это обрубает низкоуровневые возможности.С какого перепугу добавление одной возможности обрубает другие? Скажи честно, что в Perl/Ruby/Python не разбираешься.
> термина "магические числа" в отношении патернов программирования.Я его знаю в значении программирования периферии, в данном контексте этого достаточно.
> Тебе буквально следующим постом показали как это сделать на питоне. Ниасилил многабукав?
Действительно, показали - турбокостыль, с реверансом в сторону си. Если уж на то пошло - проще не выделываться и сразу на си писать. Там это симпатичнее выглядит как текст, не требует интерпретера на несколько мегов и вообще компилится в пару машинных команд. Понятно что при сильном желании закостылить можно все. А вон жабисты в ведроиде через JNI дергают нативный код. Только это геморрой на ровном месте неизвестно ради чего.
> С какого перепугу добавление одной возможности обрубает другие?Скорее, такие возможности для высокоуровневых ЯП - как собаке пятая нога, т.к. высокоуровневые ЯП делаются чтобы уйти от низкоуровневых/платформоспецифичных деталей как раз и оперировать всякими высокоуровневыми абстракциями, не заморачиваясь техническими деталями. Если этого не получается - от высокоуровневого ЯП будет больше вреда чем пользы.
> Скажи честно, что в Perl/Ruby/Python не разбираешься.
Абсолютно. У меня нет задач под которые требовался бы этот крап -> нафига мне на них тратить время? А чтобы на этом писать операционки или системные тулзы - надо серьезно ушибиться, имхо.
> Тебе буквально следующим постом показали как это сделать на питоне. Ниасилил многабукав?
>Действительно, показали - турбокостыль, с реверансом в сторону си. Если уж на то пошло - проще не выделываться и сразу на си писать."Слив защитан!"(С)LOR
>Там это симпатичнее выглядит как текст,
Смотри ещё раз, мееееедленно:
import ctypes
g = (ctypes.c_char*N).from_address(addr)
sensor_staus = g[0] # read the first byteЭто выглядит не симпатично и не понятно? А ты не дворник ли случайно? А то мало ли ...
>не требует интерпретера на несколько мегов и вообще компилится в пару машинных команд.
Не передёргивай. Я сразу написал что для писания ядерных модулей и драйверов - С идеален. До сих пор. Период. Ъ. Ы.
Но ты же сам перешел на опрос датчиков \ управление светодиодами :) А тут уже по всякому может оказаться. Для чего большого я бы сочинил С-ный модуль и говорил бы с ним из питона\ватэвэр_ю_дрчш_он лангуаге :) Для мелочи, ну там светодиодами моргнуть - см. выше :)>Понятно что при сильном желании закостылить можно все. А вон жабисты в ведроиде через JNI дергают нативный код. Только это геморрой на ровном месте неизвестно ради чего.
Ну напиши андрод апп на сях 8-) посмотрим что ты после _этого_ начнёшь считать гиммороем и костылём :)
...
>Скорее, такие возможности для высокоуровневых ЯП - как собаке пятая нога, т.к. высокоуровневые ЯП делаются чтобы уйти от низкоуровневых/платформоспецифичных деталей как раз и оперировать всякими высокоуровневыми абстракциями, не заморачиваясь техническими деталями. Если этого не получается - от высокоуровневого ЯП будет больше вреда чем пользы.
Утипуси :) Посмотри что в 3.17 кернеле горячий финский парень вытворил :) Всю твою религию низверг :) Теперь с куску памяти можно лезть ч\з ... файловый дескриптор ... чуешь куда ветер дует ? :) Пока оно конечно неведомое нечто, на ведь допилят.
> Скажи честно, что в Perl/Ruby/Python не разбираешься.
> А чтобы на этом писать операционки или системные тулзы - надо серьезно ушибиться, имхо.ОС - лучше не надо, тут я с тобой союзен, а системные тулзы ... на них и пишут. Или давай определения о чём это ты?
Ых, вот как то так :)
> Это выглядит не симпатично и не понятно? А ты не дворник ли
> случайно? А то мало ли ...Ну да, декларация в 3 раза длиннее чем на чистом си, бинарное значение загнать - почти в 2 раза больше дряни вокруг, с кавычками какими-то. А так все замечательно. Ну и нафига там нужен ваш питон, если работа с периферией в основном в чем-то таком и заключается?
> Но ты же сам перешел на опрос датчиков \ управление светодиодами :)
Я вроде вообще про датчики и светодиоды не говорил. Скорее про memory mapped периферию и то что вокруг - программирование оной в основном и состоит из кучи черной магии с засылкой магических значений и всяких там данных в разнообразные магические адреса.
> бы сочинил С-ный модуль и говорил бы с ним из питона\ватэвэр_ю_дрчш_он
> лангуаге :) Для мелочи, ну там светодиодами моргнуть - см. выше :)Не очень понимаю чего такое "большое" должно быть в работе с периферией. Это должно быть уже где-нибудь в прикладухах, etc. У питона к тому же дикие проблемы с скоростью работы. Так что такая "работа с периферией" будет весьма неторопливой если по пути попадется кусок питонятины. Там конечно есть всякие нестандартные урезки, рвущие зад чтобы это исправить, но в целом это больше похоже на борьбу с искусственными трудностями. А разучивать два наглухо разных ЯПа (что общего у си и питона?) - вообще извращение для утонченных ценителей.
А еще - на сях можно оформить либу которую потом можно дергуть откуда угодно. И из питона, и из жабы и откуда там еще. А вот здоровый шмат на питоне - не реюзабелен ни для кого кроме любителей питона. Ну и с другими высокоуровневыми ЯП такая же фигня - биндиться друг к другу высокоуровневые ЯПы не умеют, что сильно снижает реюзабельность кода.
> Ну напиши андрод апп на сях 8-) посмотрим что ты после _этого_
> начнёшь считать гиммороем и костылём :)Да вообще-то гугле игроделы мозг сгрызли (т.к. для них гимор и костыль - именно ява) и теперь там есть и native sdk. Просто черезж-пно и не очень совместимо с другими. Хотя игроделы c SDL и OpenGL не очень ругаются теперь - там почти без изменений уже. Но например портануть кутевую программу - уже гимор. Что-то такое и бывает когда случается rampant layering violation и базовые компоненты делают слишком высокоуровневыми. Так что фиг с два вы на вашем бидоне поюзаете гуй на жабе без каких-то сильно отдельно турбокостылей. А была б низкоуровневая часть виджетов на си или хотя-бы плюсах - ну вон GTK+ к куче всего биндится, да и куть тоже.
> Всю твою религию низверг :) Теперь с куску памяти можно лезть
> ч\з ... файловый дескриптор ... чуешь куда ветер дует ? :)Можно. И чего? А еще там сто лет как был доступ к всей памяти ядра через файл. Сто лет есть mmaped файлы, которые тоже "память как файл" и прочее. Только вот работа с памятью как файлом имеет кучу оговорок и программить так периферию мало какой псих захочет. А запилено это было под kdbus. Который сам по себе вообще не о работе с периферией и прочим.
> Пока оно конечно неведомое нечто, на ведь допилят.
Допилят до чего? Работать с памятью как файлом - достаточно утонченное извращение. А, гм, в чем "улучшение" когда мы ушли от работы с масссивом к работе с файлом? Это вообще ни разу не проще и имеет кучу особенностей. Периферия может быть чувствительна к таймингам и атомарности доступа, тогда как файлы изначально подразумевают произвольный доступ. Оформлять все это как файловые операции - уйма головняка на ровном месте.
> ОС - лучше не надо, тут я с тобой союзен, а системные
> тулзы ... на них и пишут. Или давай определения о чём это ты?Относительно низкоуровневая обвязка - системные утилиты, etc. То что на этом пишут всякую системную автоматизацию на 1 раз, где скорость пофиг, а руками еще дольше - да и фиг с ним. Плохо когда на таком пишут относительно фундаментальные и долговременные вещи типа пакетных менеджеров. У знакомого гентуйца система портажей отпадала потому что питон не тот. А у убунтуев на половине систем апгрейдер обcиpaется. По все той же причине. И вот это - плохо, да. Хотя апдейтер все-таки системная автоматизация на 1 раз, но все-равно не здорово что он отпадает - переключать репы руками вместо этой "автоматизации" - позор таким автоматизаторам, имхо.
Пока ты совсем не ушел в мир фантазий напомню тебе с чего началось:
>Ну и как в каком-нибудь бидоне будет выглядеть присвоение адресу 0x100500 значения 0xDEADBEEF?Тебе показали как, чего тебе еще? Если не можешь объяснить словами, то покажи свой вариант на С.
А главное заметь, никто не говорил, что питон это хорошо для ядра, это ты сам выдумал и героически опровергаешь.
> покажи свой вариант на С.А я уже показал еще вариантик - переброс выполнения на фиксированный адрес. Что-то питонисты разбежались и отмазываются теперь, хотя мне было и правда интересно как указатель на функцию будет через такой костыль смотреться, и, главное, насколько сие потом еще и работать будет.
>> возможность разработки модулей ядра на любых языкахЗачем это нужно? Чем голый С для этого плох?!?!? До он для этого _идеален_!
> Ну и как в каком-нибудь бидоне будет выглядеть присвоение адресу 0x100500 значения 0xDEADBEEF?
> Допустим это memory mapped регистр что-то делающий с вон той железкой. Ну на си - народ прямо так и напишет.Не надо забивать шурупы и закручивать гвозди!
Но если таки надо:
Writing to arbitrary memory areas is an easy way to cause segmentation
violations which Python and its extensions try to make segmentation
violations (memory violations) as near impossible as they can.If you really need to do this then you can use ctypes to do it.
Let N be the number of bytes you want to access, then
import ctypes
g = (ctypes.c_char*N).from_address(addr)g is now a settable sequence of bytes that you can read and write to
using strings.g[0] # read the first byte
g[1] # read the second byteg[0] = '\x24' # set the first byte to hexadecimal 24
etc...
If you don't have permission to write to addr then you will get memory
violations and your program will crash if you try to read from or write
to the resulting sequence.
Индусы понтарезы. ООП в линуксе уже давно в полный рост на благородном C.
И посмотрел бы как они не POD объекты будут в строгую карту виртуального
пространства, в которое линкуется ядро, интегрить. Хотя, может какой
фреймворк для ядра, для подключения и функционирования С++ модулей, развить и
получится, но не более. Можно будет модули ядра вантузинтками в Вижукалл Cтудиё
писать. Ключевое в ядре всегда будет на C.
Вот что получается когда веб разработчиков нанять ядро разрабатывать. Лучше бы они деньги потратили на написание модулей к существующему ядру.
> деньги потратили на написание модулей к существующему ядру.Не-не, не надо, что вы. На плюсах их код точно в майнлайн не возьмут, а если это будут сишные модули - они чего доброго смогут проскочить.
Плюсы, это ООП все-же. Там где ООП и другие язычки подтянутся.
Вот только вопрос нужно ли это в ядре и будет ли это отзывчиво?Мне кажется, лучше развивать ядро и ближайшее окружение, а в ядре лишним абстракциям и сущностям, делать нечего...
Было-бы интересно и rust там увидеть...
Да они могут хоть уразвиваться. Сами напишут, сами поиграются, сами за**утся поддерживать и выкинут, а в апстрим хрен это чудо кто-то примет :)
Весь этот хай - от непонимания.В вырожденном виде (без полиморфизма) плюсы - это просто пачка хороших немногословных (по сравнению с сями) интерфейсов со строгой типизацией вообще без потерь скорости работы. Ну да, чтобы так писать, мозг нужен. Но он, в общем-то, и вообще для программирования для ядра пригодится. А какой-нибудь USB, с его кучей сущностей, на объектном языке куда удобнее писать, потому что сама спецификация, по сути, объектная. Плюс шаблоны в разумных количествах таки очень упрощают жизнь. Я тут пару раз постил ссылки на шаблонный код для AVR - который оптимизировался лучше, чем руками писанный ассемблер, и при этом давал простоту модификации.
Оно да, ООП можно сделать и на сях. Но - многословно, обычно зависимо от кучи макросов и будет гораздо хуже обрабатываться разными статическими анализаторами.
> это просто пачка хороших немногословных
> (по сравнению с сями) интерфейсов со строгой типизацией вообще без потерь
> скорости работы. Ну да, чтобы так писать, мозг нужен.О чём речь? О STL? линуксовые list_head, rb_node в составе всех структур и container_of-
более производительное решение, чем эти дебильные STL контейнеры, с их инсертом
копированием (вобще говоря && бесполезен для избежания копирований, такое
прокатит только с объектами определённой структуры). А обобщение шаблонами в ядре
не нужно для 99% всех объектов, которые там существуют.
> А обобщение шаблонами в ядре не нужно для 99% всех объектов, которые там существуют.Т.е. списков там на кождом углу нет, неупорядочныых контейнеров нет, FIFO нет, ....
Замена списка на мап на красно-черных деревьях обошелся ядру в 2.5 года и несколько мегабайт правленного кода. "На попробовть" слишком сложно выходит.
Чтобы ядро зависело не только от кривой реализации GCC, но и от кривой реализации списков, контейнеров и FIFO?
> В вырожденном виде (без полиморфизма) плюсы - это просто пачка хороших немногословных
> (по сравнению с сями) интерфейсов со строгой типизацией вообще без потерь
> скорости работы. Ну да, чтобы так писать, мозг нужен.Чтобы хорошо писать на плюсах - нужен мегамозг. А в ядре любой продолб обернется паникой или разрушением данных к тому же. Если крах игрушки с кодом на 10 метров мы переживем, то вот панику ядра... ну иди да юзай реактос, если тебе бсоды раз в 5 минут доставляют. Как раз последнее ядро на каком-то урезанном варианте плюсов.
> Чтобы хорошо писать на плюсах - нужен мегамозг.Первокурсники подтянулись. Вот когда избавитесь от необходимости слушать тот бред,
который впаривают профессора (читай профессиональные делитанты) тщательно изучите стандарт
C++ и C++ ABI, подумаете над сущностью тамошних конструкций и концепций, года два попишете на этом C++,
тогда, когда повится зачатки этого мегамозга, поймёте, что C++-попса и уродливое изобретение праздных
академиков и понтарезов, и все его концепции, явные синтаксические конструкции, обеспечивающие, якобы,
неявные возможности увеличения производительности или надёжности и пр, есть просто набор костылей и подпорок,
маскирующих кривой дизайн самого языка, и необходимых для того, чтоб на нём хоть
что-то писать можно было. После этого будете как Алесандреску, твердить, что не знаете
полностью C++, выпендриваться на праздных конференциях aka modern C++,
а в реальных пректах писать околосишный С++-ый код aka С c классами, как здесь https://github.com/facebook/folly/blob/master/folly/FBString.h
да уж..
я знаю, что ничего не знаю (
> В вырожденном виде (без полиморфизма) плюсы - это просто пачка хороших немногословных (по сравнению с сями) интерфейсов со строгой типизацией вообще без потерь скорости работы.полную херню несёшь. Типизации в плюсах не больше чем в си. Качество оптимизации плюсовго "сахара" очень сильно зависит от настроения и качества компилятора, стандарт разрешает вообще ничего не оптимизировать и не даёт никаких гарантий на zero cost своей 'немногословности'. Кост сишного кода практически всегда ясен и прозрачен.
Ну и конечно же самое главное - плюсы не имеют ABI даже на самые тривиальные фичи.
> Но - многословно, обычно зависимо от кучи макросов и будет гораздо хуже обрабатываться разными статическими анализаторами.
тоже враньё. Многословность не влияет на качество статического анализа, на это влияет сложность семантики языка. А у плюсов на несколько порядков сложнее сишной даже если в си активно пользоваться макросами.
> немногословных (по сравнению с сями)Щито?
Давайте внедрим в ядро boost library ?
qtcore
> qtcorekdelibs :)
неактуально ныне
драйвера должны писаться исключительно на ассемблере. всё таки самый низкоуровневый доступ обеспечивают. а все эти промокашки высокого уровня, с тоннами мутных абстракций и зависимых модулей, только тормоза да утечки памяти плодят лишние.
Вы что-нибудь знаете про ассемблер, кроме того, что он, теоретически, самый-самый маленький и быстрый? А про причины тормозов и утечек памяти? А про поддержку драйверов и их использование для семейства устройств, а не для одного-единственного? Причем драйвера пишутся для первого, а для последующих, с заранее неизвестным функционалом, их придется вдумчиво переписывать... на ассемблере, ага.
А что есть С? А высокоуровневый ассемблер и есть! :) Плюсф _тут_ не нужны. Ъ.
> А что есть С? А высокоуровневый ассемблер и есть!Неправда. C-абстрактная машина, cостоящая, исключительно, из абстрактных
сущностей и их отношений, описываемых соответствующим документом, называемым стандартом.
Асм, по определению, независимо от разновидностей синтаксиса,
определяется спекой на мнемоники набора инструкций конкретной arch.
> независимо от разновидностей синтаксиса, определяется спекой
> на мнемоники набора инструкций конкретной arch.Фсё, приплыли, Java - ассемблер.
Только если каждая команда джавы порождает ровно одну инструкцию джава машины. То есть является мнемоникой для байткода. Я не знаю джаву, но весьма сомневаюсь, что дела в ней обстоят именно так.
> Только если каждая команда джавы порождает ровно одну инструкцию джава машины.То есть, если написать, CMP AX, 0, а гадкий ассемблер переделает это в TEST AX, AX - значит это не ассемблер? А SMP режиме, ваще ж..па. :)
Вы уж определитесь тут...
> То есть, если написать, CMP AX, 0, а гадкий ассемблер переделает
> это в TEST AX, AX - значит это не ассемблер?Это уже оптимизации со стороны транслятора. Также как и макросы типа .IF к самому языку ни разу не относится.
> Асм, по определению, независимо от разновидностей синтаксиса,
> определяется спекой на мнемоники набора инструкций конкретной arch.Попробуй код типа
void _start(void)
{
((void (*)(void))0xffff0020)();
}
выполнить на произвольной платформе :). Не забудь рассказать что получилось.Кстати да, питонисты, а покажите как это с вашим турбокостылем выглядит? :) С технической точки зрения это переход на адрес 0xffff0020 и выполнение того что там находится. Без знания этим кодом что там вообще за фигня :). Такой вот "платформонейтральный, типа" способ записать нечто типа JMP 0xffff0020. Насколько такая штука платформенно нейтральна - ну вы поняли, еще меньше чем ассемблер проца под который этот трюк делается, ибо подразумевает вообще конкретный SoC :)
> Кстати да, питонисты, а покажите как это с вашим турбокостылем выглядит? :)Парень у тебя большие проблемы с головой. Ты таки закручиваешь гвозди и забиваешь шурупы.
> Ты таки закручиваешь гвозди и забиваешь шурупы.Вам не приходила в голову жуткая мысль, что код молотка и отвертки выглядит примерно так?
> Парень у тебя большие проблемы с головой. Ты таки закручиваешь гвозди и
> забиваешь шурупы.Во первых, это не я, а чуваки которые тулсы для allwinner'ов клепают. Во вторых, мне интересно посмотреть как сие выглядит, раз питонисты вещают что с доступом к памяти у них все шоколадно. Вот и покажите как вот такой сорт шоколада изобразить :). В сях доступ к памяти универсален и на предмет данных и на предмет выполнения.
>> Кстати да, питонисты, а покажите как это с вашим турбокостылем выглядит? :)
> Парень у тебя большие проблемы с головой. Ты таки закручиваешь гвозди и
> забиваешь шурупы.Если шуруп забить и провернуть на один оборот, будет тоже самое, только быстрее (см. PHP)
Иль вы сайты на С++ пишете?
>драйвера должны писаться исключительно на ассемблереОткрываем linux-3.XX.YY/arch/ и считаем количество аппаратных архитектур (я 29 насчитал). И это не считая того, что внутри каждой архитектуры могут быть процессоры разных поколений, которые поддерживают или неподдерживают какие-то конкретные машинные инструкции. И что, для всех вариантов на ассемблере написать драйвер одного и того же устройства, например, для сетевухи?
По теме: что там MOOL развивает? Скачать можно пример модуля hello_word и исходники ядра 2.6.23 с C++ include и runtime. Исходники правленные, patch нет. Никакая система на c++ не портирована. Хотя где-то упоминается, что есть портированный сетевой драйвер. Зачем в ядре RTTI и exceptions -- не ясно. Короче: или отсутствует дополнительная информация, или сообщение -- чистый вброс
> Зачем в ядре RTTI и exceptions --Понятно, что сначала нужно будет вcю libsupc++ писать специально для ядра.
Представляю что будет, если индусы решат в новом ядерном _Unwind_RaiseExceptions дёргать INT X.
> Представляю что будет, если индусы решат в новом ядерном _Unwind_RaiseExceptions дёргать INT X.Вы это сказали так, как будто сейчас в C-шной реализации нет ограничений на код в соответствующих обработчиках.
> Зачем в ядре RTTI и exceptions -- не ясно.Да не будет их там.
Логично задействовать метапрограммирование, классы и типизацию. А виртуальные функции использовать, наверное, не надо.
> Логично задействовать метапрограммирование, классы и типизацию.и жаль, что в с++ вместо всего этого неудобные костыли.
>> Логично задействовать метапрограммирование, классы и типизацию.
> и жаль, что в с++ вместо всего этого неудобные костыли.Ты вообще знаешь что такое с++? Если у тебя не хватило серого вещества понять язык, то это не значит что там все плохо.
> Ты вообще знаешь что такое с++?конечно: мерзкий набор неудобоваримых костылей и legacy. употребим только в малых дозах, с водкой или с таблетками от головной боли.
> Если у тебя не хватило серого
> вещества понять язык, то это не значит что там все плохо.видишь ли, дело в том, что ты-то тоже c++ не знаешь. его вообще не так много людей знают, потому что это куча гуано, рядом с которой дизайн даже не сидел. c++ — это отличный инструмент для того, чтобы сделать простые вещи сложными, а сложные — почти невозможными. и зачастую всё это с синтаксисом, глядя на который perl понимает, что ему ещё есть куда стремиться.
конечно, в c++ не всё плохо: то, что страус взял у си — более-менее терпимо. остальное ужасно. особенно ужасны шаблоны, которые делались существами из параллельного мира, и делались для марсианских слизней.
впрочем, фанбои уверены, что язык надо Превозмогать, что инструмент, который легко изучить и понять — не Ъ. но это личные проблемы фанбоев, я использую D и мне хорошо. товарищ Александреску тоже считает, что D лучше c++, можешь ему рассказать, что у него просто мозгов не хватило понять c++.
Единственное противоречие в этой системе - то, что дорожки, ведущие от С++ к Жабе и Шарпу плотно протоптаны, а к D ведет какая-то заросшая тропа.
Если он и лучше, и проще - почему? Признаться, у меня вообще "Александреску" и "проще" решительно не стыкуются...
> Единственное противоречие в этой системе - то, что дорожки, ведущие от С++
> к Жабе и Шарпу плотно протоптаны, а к D ведет какая-то
> заросшая тропа.да, не любим дураков, есть такое. пусть дураки лучше в жабо-шарпо-плюсах кучкуются.
> Если он и лучше, и проще - почему? Признаться, у меня вообще
> "Александреску" и "проще" решительно не стыкуются...винда — лучшая ОС. улавливаешь связь?
D is for D'Artagnan?
> D is for D'Artagnan?D is for «Mars», which was the planned name. alas, Mars is gone, only Phobos left.
> D is for «Mars», which was the planned name.Mars Compilers --- не смогли сделать шаблоны в своем как-бы-плюсовом компиляторе (ну, и многое другое). Дабы скрыть свой epic fail, сыграли в альтернативного царя горы --- гораздо лучший и продвинутый язык D для настоящих ...
Теперь аннонс: AAAAAAAAArisu! Нервных и впечатлительных просьба покинуть зал!
ты прекращай упарываться с начала недели. оно, конечно, никто всё равно не заметит, упоротый ты или с чистого ума чушь несёшь, но всё равно…
> употребим только в малых дозах,Да ладно тебе, Кэп, на сях обычно как раз большие проекты наворачивают. Для мелких и просто сей хватает. А если кто плюсы юзанул - это обычно уйма кода и бинарь на пять мегов.
> Да ладно тебе, Кэп, на сях обычно как раз большие проекты наворачивают.ну так при наличии достаточной мотивации и траншею детской лопаткой можно выкопать. я же не говорю, что не используют, я говорю, что это печальное зрелище. особенно когда какие-нибудь любители бустов вместе собираются — вообще гаси свет.
> А если кто плюсы юзанул
> - это обычно уйма кода и бинарь на пять мегов.совершенно необязательно, кстати сказать. бинари раздуваются от шаблонов — и с этим, увы, ничего не поделаешь. в D тоже бинари раздуваются, например. плата за универсальность кода. точнее, плата за быстрый и универсальный код.
но никто не запрещает ни в c++, ни в D не использовать шаблоны, ограничиться структурами и классами. и будет код вполне маленький. собственно, D на bare metal как-то так и используют. ещё и runtime перетачивают, убирая оттуда всё ненужное. получается такой себе Better C.
> Логично задействовать метапрограммирование, классы и типизацию.Классы там уже есть, где надо. Только за управление ими отвечает сам программист, а не компилятор, что для низкоуровневого системного программирования закономерно.
Зачем там нужно метапрограммирование - не понимаю. Они операционку пишут, а не программу бухучёта, поэтому их код должен быть максимально управляем и предсказуем.
Строгая типизация тоже не нужна. Они же с "железом" работают, которое о типах ничего не знает, поэтому преобразования типов там сплошь и рядом. Можно конечно усложнить жизнь программистам и заставить писать их вместо естественного (type)data заклинания типа reinterpret_cast<...>...
> А виртуальные функции использовать, наверное, не надо.
Ну, вот и получается, что если не использовать всё ненужное от С++, то писать надо на Си...
> Зачем там нужно метапрограммирование - не понимаю.Alexander Stepanov and Paul McJones / Elements of Programming [Addison-Wesley, 2009; ISBN-13 978-0-321-63537-2; ISBN-10 0-321-63537-X]
> Зачем там нужно метапрограммирование - не понимаю.большинство не понимает. потому что никакого метапрограммирования в «мэйнстримных» языках нет, культуры и практики его применения тоже. а жаль.
> Зачем там нужно метапрограммирование - не понимаю. Они операционку пишут, а не
> программу бухучёта, поэтому их код должен быть максимально управляем и предсказуем.Любой код, начинающий местами напоминать самого себя, может быть улучшен при помощи метапрограммирования. В том числе и по критерию сопровождаемости.
Да, а ещё Си не умеет динамических строк, эксепшенов и сборщика мусора. Очень бы пригодились в ядре :)
> Да, а ещё Си не умеет динамических строк, эксепшенов и сборщика мусора.
> Очень бы пригодились в ядре :)конечно, пригодились бы. сборщик мусора вообще очень полезная штука, вместе с динамическими массивами и контролем диапазонов. Oberon всё это умел, и отлично работал на практике.
хорошо, что это индийцы: их говнокод вскорости не сможет поддерживать никто, и в первую очередь они сами. после чего сабжевая мерзость тихо сыграет в ящик.
Как называется проблема ООП когда при малейшем изменении реализации класса-предка неожиданно ломается половина нормально работавших классов-потомков?
> Как называется проблема ООП когда при малейшем изменении реализации класса-предка неожиданно
> ломается половина нормально работавших классов-потомков?хреновая архитектура.
Для чего разработчику базовых классов дали protected и private? Учи матчасть.
Давно пора. Понятно что весь ворох возможностей C++ по части исключений, rtti, множественного наследования, stl тащить не нужно, но на уровни C с классами его не использовать в XXI веке глупо, потому что код это генерит такой же как на C, но писать нужно в разы меньше, и в те же разы меньше вероятность ошибиться.
Если уж браться программировать на С++, то только закончив медитировать над:
Герб Саттер, Андрей Александреску, «Стандарты программирования на C++».
Но насколько видел многие люди на С++ сначала пишут, а потом собирают шишки, но до чтения так и не доходят... Так как этот язык имеет обманчивую кажущуюся простоту, а внутри мало кем освоенную груду нюансов.
вообще с++ это не только ексепшены
и если их отключать для ядра, получается хороший компактный код
виндовый гуи win32.sys полностью на С++
как и многие ядреные модули
Но всё же, почему бы и не написать ядро с парадигмой ООП?
Определить класс ядра и методы к нему:class kernel
{
// private variables and functionspublic:
ctrl_memory(); // управление памятью
ctrl_processes(); // управление процессами
manager_drivers(); // интерфейс для драйверов
manager_hardware(); // интерфейс для работы с железом
// etc...
};что-то в таком роде)) Конечно же, это всё условно.
иди в гайку, там хорошо и классы.
> иди в гайку, там хорошо и классы.что за гайка?
>> иди в гайку, там хорошо и классы.
> что за гайка?Haiku, открытый наследник BeOS.
Лицензия у ней некошерная.