Вариант для распечатки		Пред. тема | След. тема
Форум Разговоры, обсуждение новостей
Изначальное сообщение		[ Отслеживать ]

"Проект MOOL развивает средства разработки драйверов ядра Lin..."	+/–
Сообщение от opennews (ok), 04-Окт-14, 00:33
Разработчики индийского дистрибутива 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.../ Новость: https://www.opennet.ru/opennews/art.shtml?num=40745
Ответить | Правка | Cообщить модератору

Сообщения

[Сортировка по времени | RSS]

1. "Проект MOOL развивает средства разработки драйверов ядра Lin..."	+/–
Сообщение от pavlinux (ok), 04-Окт-14, 00:33
И получится Оберон
Ответить | Правка | Наверх | Cообщить модератору

	13. "Проект MOOL развивает средства разработки драйверов ядра Lin..."	–9 +/–
	Сообщение от Аноним (-), 04-Окт-14, 01:27
	> И получится Оберон Если бы. C++ - язык для тех случаев, когда все остальные подходят ещё хуже. Оберон - очень лаконичный и предсказуемый, зато C++ позволяет выжать максимум производительности даже при использовании высокоуровневых техник. Для разного они, в общем. И, да, C++ в ядре делать практически нечего. Разве что для какой-нибудь очередной Поттеринговской поделки сгодится, которая без ядерной поддержки не взлетает.
	Ответить | Правка | Наверх | Cообщить модератору

	14. "Проект MOOL развивает средства разработки драйверов ядра Lin..."	+5 +/–
	Сообщение от Аноним (-), 04-Окт-14, 01:31
	А поттеринговые программы - на сях...
	Ответить | Правка | Наверх | Cообщить модератору

	46. "Проект MOOL развивает средства разработки драйверов ядра Lin..."	–1 +/–
	Сообщение от Аноним (-), 04-Окт-14, 13:55
	Ну вот потому пока и на сях. :)
	Ответить | Правка | Наверх | Cообщить модератору

	59. "Проект MOOL развивает средства разработки драйверов ядра Lin..."	+/–
	Сообщение от Аноним (-), 04-Окт-14, 15:54
	Не видел чтобы поттер сильно фанател по плюсам. Писать юзермод на плюсах можно уже сейчас, ничему не противоречит.
	Ответить | Правка | Наверх | Cообщить модератору

	32. "Проект MOOL развивает средства разработки драйверов ядра Lin..."	+2 +/–
	Сообщение от _KUL (ok), 04-Окт-14, 03:19
	Да почему же, плюсы отличный язык, сложный конечно (читая книги по которому, возникает только больше вопросов), но он очень хорош во многих отношениях.Он как девушка с идеальной фигурой - ни кто до этого такого не видел, боятся разглядывать, а значит и считают это злом, т.к. привыкли к дефектным. Просто зачем переписывать с сей на плюсы, ради сомнительной цели - особенности языка плюсов? КПД стремится к нулю? Просто индусам нужно на хлеб зарабатывать, вот и переписывают по очереди на все языки за бюджетные деньги. Не зря же появилась фраза - про их программистов :)
	Ответить | Правка | К родителю #13 | Наверх | Cообщить модератору

	47. "Проект MOOL развивает средства разработки драйверов ядра Lin..."	+/–
	Сообщение от Аноним (-), 04-Окт-14, 13:57
	> Да почему же, плюсы отличный язык, сложный конечно (читая книги по которому, > возникает только больше вопросов), но он очень хорош во многих отношениях.Он > как девушка с идеальной фигурой - ни кто до этого такого > не видел, боятся разглядывать, а значит и считают это злом, т.к. > привыкли к дефектным. Просто зачем переписывать с сей на плюсы, ради > сомнительной цели - особенности языка плюсов? КПД стремится к нулю? > Просто индусам нужно на хлеб зарабатывать, вот и переписывают по очереди на > все языки за бюджетные деньги. Не зря же появилась фраза - > про их программистов :) Отличный, да. Но сильно специфический. Ruby тоже ведь хороший язык, но драйвера на нём почему-то обычно не пишут. ;) Сложность языка - это мощный фактор, препятствующий надёжности: чем хуже программист знает язык, тем больше делает ошибок. А потенциальные ошибки в критическом коде, в ядре и его обвязке - как-то совсем не радуют. Их и так хватает, чтобы раз в несколько месяцев устраивать админам холодный душ.
	Ответить | Правка | Наверх | Cообщить модератору

	68. "Проект MOOL развивает средства разработки драйверов ядра Lin..."	+1 +/–
	Сообщение от тоже Аноним (ok), 04-Окт-14, 16:54
	Вообще-то С++ - язык мультипарадигменный. Например, он может использоваться как низкоуровневый язык без ручного управления памятью.
	Ответить | Правка | Наверх | Cообщить модератору

	77. "Проект MOOL развивает средства разработки драйверов ядра Lin..."	+1 +/–
	Сообщение от Аноним (-), 04-Окт-14, 19:59
	>>[C++]Он как девушка с идеальной фигурой - Это точно! Требует постоянного внимания, никогда не знаешь чего ещё вытворит и постоянно ломаеццо *ать !!! :)
	Ответить | Правка | К родителю #32 | Наверх | Cообщить модератору

	57. "Проект MOOL развивает средства разработки драйверов ядра Lin..."	+/–
	Сообщение от pavlinux (ok), 04-Окт-14, 15:32
	Я про Оберон, которая ОСь
	Ответить | Правка | К родителю #13 | Наверх | Cообщить модератору

	195. "Проект MOOL развивает средства разработки драйверов ядра Lin..."	+/–
	Сообщение от Аноним (195), 15-Янв-24, 12:46
	Так эта ОСь хорошо или плохо?
	Ответить | Правка | Наверх | Cообщить модератору

	103. "Проект MOOL развивает средства разработки драйверов ядра Lin..."	+2 +/–
	Сообщение от абырвалГ (?), 05-Окт-14, 22:40
	Выжать максимум производительности помогает компилятор. Язык программирования (любой) - всего лишь способ донести свои мысли до компилятора :) И этот миф, что на каком-то языке программирования, в данном случае  - С++, получится более быстрый код, чем, скажем, на Паскале - мифом и остается :)
	Ответить | Правка | К родителю #13 | Наверх | Cообщить модератору

	119. "Проект MOOL развивает средства разработки драйверов ядра Lin..."	–1 +/–
	Сообщение от Аноним (119), 06-Окт-14, 11:08
	Для паскаля пока нет крутого компилятора :)
	Ответить | Правка | Наверх | Cообщить модератору

	131. "Проект MOOL развивает средства разработки драйверов ядра Lin..."	+2 +/–
	Сообщение от Минона (?), 06-Окт-14, 15:43
	крутой нафик не нужен, нужен - правильный у паскаля он есть
	Ответить | Правка | Наверх | Cообщить модератору

	133. "Проект MOOL развивает средства разработки драйверов ядра Lin..."	–1 +/–
	Сообщение от Аноним (119), 06-Окт-14, 17:11
	> крутой нафик не нужен, нужен - правильный > у паскаля он есть Там с оптимизацией оочень не хорошо ;)
	Ответить | Правка | Наверх | Cообщить модератору

	137. "Проект MOOL развивает средства разработки драйверов ядра Lin..."	–3 +/–
	Сообщение от yantux (??), 06-Окт-14, 19:00
	На реальных приложениях - всё отлично. Самое важное для современного софта: -минимум ошибок; -сопровождаемость кода; -код на Си и С++ сопровождать не реально.
	Ответить | Правка | Наверх | Cообщить модератору

	152. "Проект MOOL развивает средства разработки драйверов ядра Lin..."	+/–
	Сообщение от Аноним (119), 07-Окт-14, 10:02
	> На реальных приложениях - всё отлично. > Самое важное для современного софта: > -минимум ошибок; > -сопровождаемость кода; > -код на Си и С++ сопровождать не реально. Никто не говорит что всё плохо, для чего-то и неоптимизированного js достаточно, понятно что если в реальном приложении основные временные потери идут на обращения по сети/выборки из бд и манипуляции большими блоками памяти, то то в таких приложениях однопроходного компилятора от древней d7 достаточно за глаза.
	Ответить | Правка | Наверх | Cообщить модератору

	153. "Проект MOOL развивает средства разработки драйверов ядра..."	+/–
	Сообщение от arisu (ok), 07-Окт-14, 10:22
	> однопроходного компилятора от древней d7 lol.
	Ответить | Правка | Наверх | Cообщить модератору

	179. "Проект MOOL развивает средства разработки драйверов ядра Lin..."	+1 +/–
	Сообщение от Аноним (-), 08-Окт-14, 06:33
	> -сопровождаемость кода; > -код на Си и С++ сопровождать не реально. Да вот что-то за дельфистами код сопровождать никто не хочет, а линуксное ядро сопровождают при немеряном размере...
	Ответить | Правка | К родителю #137 | Наверх | Cообщить модератору

	146. "Проект MOOL развивает средства разработки драйверов ядра Lin..."	+2 +/–
	Сообщение от Led (ok), 07-Окт-14, 01:48
	>> крутой нафик не нужен, нужен - правильный >> у паскаля он есть > Там с оптимизацией оочень не хорошо ;) Сосед по парте тебя обманул.
	Ответить | Правка | К родителю #133 | Наверх | Cообщить модератору

	151. "Проект MOOL развивает средства разработки драйверов ядра Lin..."	–1 +/–
	Сообщение от Аноним (119), 07-Окт-14, 09:59
	>>> крутой нафик не нужен, нужен - правильный >>> у паскаля он есть >> Там с оптимизацией оочень не хорошо ;) > Сосед по парте тебя обманул. Даже вспомнить не могу как всех соседей звали, а так да может быть...
	Ответить | Правка | Наверх | Cообщить модератору

	196. "Проект MOOL развивает средства разработки драйверов ядра Lin..."	+/–
	Сообщение от Аноним (195), 15-Янв-24, 12:49
	Нафиг этот регистронечувствительный Паскаль, тогда уж лучше Modula-2. Тем более, что её компилятор теперь есть в составе GCC.
	Ответить | Правка | К родителю #103 | Наверх | Cообщить модератору

	20. "Проект MOOL развивает средства разработки драйверов ядра Lin..."	+2 +/–
	Сообщение от Vkni (ok), 04-Окт-14, 01:37
	> И получится Оберон Нет. С++ - это антиОберон.
	Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

	23. "Проект MOOL развивает средства разработки драйверов ядра Lin..."	+/–
	Сообщение от Аноним (-), 04-Окт-14, 01:48
	Это попытка сделать реактос, только вместо ядра NT - Linux :).
	Ответить | Правка | Наверх | Cообщить модератору

	197. "Проект MOOL развивает средства разработки драйверов ядра Lin..."	+/–
	Сообщение от Аноним (195), 15-Янв-24, 12:52
	>только вместо ядра NT - Linux А тут без шуток. Вся эта игра вокруг WSL, в конечном итоге, к этому и приведёт.
	Ответить | Правка | Наверх | Cообщить модератору

2. "Проект MOOL развивает средства разработки драйверов ядра Lin..."	+17 +/–
Сообщение от Аноним (-), 04-Окт-14, 00:41
Странно, что индусы не пишут дрова на xml. А получится не оберон, а очередной никому не нужный випнет.
Ответить | Правка | Наверх | Cообщить модератору

	3. "Проект MOOL развивает средства разработки драйверов ядра Lin..."	+2 +/–
	Сообщение от Аноним (-), 04-Окт-14, 00:45
	Вы почти угадали. У них про это упомянуто: "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)."
	Ответить | Правка | Наверх | Cообщить модератору

	5. "Проект MOOL развивает средства разработки драйверов ядра Lin..."	+/–
	Сообщение от pavlinux (ok), 04-Окт-14, 00:51
	> a static policy data шел-код в принципе тоже static policy data, так что ... кто всё это разгребать будет??? Если напр. спинлок от сетевухи подерётся с другим, у другой сетевухи при многолинковых соединениях...
	Ответить | Правка | Наверх | Cообщить модератору

	28. "Проект MOOL развивает средства разработки драйверов ядра Lin..."	+/–
	Сообщение от Аноним (-), 04-Окт-14, 02:40
	> of policies in form of (object oriented) И вот это будет проще майнтайнить? По-моему они зубы заговаривают.
	Ответить | Правка | К родителю #3 | Наверх | Cообщить модератору

	4. "Проект MOOL развивает средства разработки драйверов ядра Lin..."	+10 +/–
	Сообщение от pavlinux (ok), 04-Окт-14, 00:46
	Тут смари чо: > объёктно-ориентированных обвязок для перехвата системных вызовов Там дыреней будет лет на 10 вперёд с запасом.Поэтому можно легко срубить бабла на саппорте :D
	Ответить | Правка | К родителю #2 | Наверх | Cообщить модератору

	10. "Проект MOOL развивает средства разработки драйверов ядра Lin..."	–2 +/–
	Сообщение от Психиатр (ok), 04-Окт-14, 01:07
	>Поэтому можно легко срубить бабла на саппорте :D блин, павлин за последнее время стал умные вещи говорить тут ты, батенька, в самое яблочко попал
	Ответить | Правка | Наверх | Cообщить модератору

	15. "Проект MOOL развивает средства разработки драйверов ядра Lin..."	+10 +/–
	Сообщение от Аноним (-), 04-Окт-14, 01:31
	> блин, павлин за последнее время стал умные вещи говорить Да павлин как стоящие часы - два раза в сутки показывает правильное время :).
	Ответить | Правка | Наверх | Cообщить модератору

	26. "Проект MOOL развивает средства разработки драйверов ядра Lin..."	+/–
	Сообщение от ананим (?), 04-Окт-14, 02:18
	Тогда уж календарный листок. За 4 октября.
	Ответить | Правка | Наверх | Cообщить модератору

	29. "Проект MOOL развивает средства разработки драйверов ядра Lin..."	+1 +/–
	Сообщение от Аноним (-), 04-Окт-14, 02:41
	> Тогда уж календарный листок. > За 4 октября. Не, ну знаешь, павлин хоть и работает в режиме генератора рандомного спама, но угадывает явно чаще раза в год.
	Ответить | Правка | Наверх | Cообщить модератору

	92. "Проект MOOL развивает средства разработки драйверов ядра Lin..."	+/–
	Сообщение от Аноним (-), 05-Окт-14, 09:01
	> Тогда уж календарный листок. > За 4 октября. да еще и конкретно в субботу?
	Ответить | Правка | К родителю #26 | Наверх | Cообщить модератору

	198. "Проект MOOL развивает средства разработки драйверов ядра Lin..."	+/–
	Сообщение от Аноним (195), 15-Янв-24, 12:55
	А что было 4 октября, кроме запуска первого ИСЗ?
	Ответить | Правка | К родителю #26 | Наверх | Cообщить модератору

	78. "Проект MOOL развивает средства разработки драйверов ядра Lin..."	+2 +/–
	Сообщение от Аноним (-), 04-Окт-14, 20:01
	> Странно, что индусы не пишут дрова на xml. Муха-ха-ха!!! Это 100%, 100500 левел троллинга! Их же любимый фетиш - жаба и хмл ...
	Ответить | Правка | К родителю #2 | Наверх | Cообщить модератору

6. "Проект MOOL развивает средства разработки драйверов ядра Lin..."	+5 +/–
Сообщение от Аноним (-), 04-Окт-14, 00:51
А что не на Java, Jvm нужна ?
Ответить | Правка | Наверх | Cообщить модератору

	7. "Проект MOOL развивает средства разработки драйверов ядра Lin..."	+/–
	Сообщение от Кевин (?), 04-Окт-14, 01:00
	было уже, не взлетело...
	Ответить | Правка | Наверх | Cообщить модератору

	19. "Проект MOOL развивает средства разработки драйверов ядра Lin..."	–1 +/–
	Сообщение от freehck (ok), 04-Окт-14, 01:34
	Почему же не взлетело? Взлетело. Андроидом зовётся. КПД, правда, у этого полёта...
	Ответить | Правка | Наверх | Cообщить модератору

	25. "Проект MOOL развивает средства разработки драйверов ядра Lin..."	+7 +/–
	Сообщение от Аноним (-), 04-Окт-14, 02:14
	У андрюши обыкновенное ядро Linux, java там только для рантайма, и то у ВМ своя реализация, а не сановская. Не пишите ересь.
	Ответить | Правка | Наверх | Cообщить модератору

	84. "Проект MOOL развивает средства разработки драйверов ядра Lin..."	+/–
	Сообщение от pavlinux (ok), 04-Окт-14, 23:31
	КПД у Андроеда выше 100% и кроме iOS ваще не имеет конкурентов. Под Windows/MacOS столько программ нет, сколько под Андроид. И только благодаря Андроид любой может себе все, что раньше ограничивалось стоимостью железа и софта. Ибо купив кетайский Ляо MTK за 50$ или Gresso Radical Black R3 за 3000$, результат использования будет абсолютно одинаковый.
	Ответить | Правка | К родителю #19 | Наверх | Cообщить модератору

	97. "Проект MOOL развивает средства разработки драйверов ядра Lin..."	+/–
	Сообщение от freehck (ok), 05-Окт-14, 18:00
	> КПД у Андроеда выше 100% и кроме iOS ваще не имеет конкурентов. Ну, на вкус и цвет, конечно, но как по мне, оба плохи. > Под Windows/MacOS столько программ нет, сколько под Андроид. Это, пожалуй, правда. Но толку-то от их количества, если большинство из них - дешёвые поделки нерадивых студентов да вирусописателей? > И только благодаря Андроид любой может себе все, что раньше > ограничивалось стоимостью железа и софта. Ибо купив кетайский > Ляо MTK за 50$ или Gresso Radical Black R3 за 3000$, результат > использования будет абсолютно одинаковый. Да неужели. Ну, тогда у GNU/Linux тоже потенциал выше 100%, ибо купив китайский ноутбук и накатив на него Debian Вы сможете делать всё то же, что и на новеньком маке.
	Ответить | Правка | Наверх | Cообщить модератору

	107. "Проект MOOL развивает средства разработки драйверов ядра Lin..."	–1 +/–
	Сообщение от Аноним (-), 06-Окт-14, 04:02
	> КПД у Андроеда выше 100% Значит надо надеть каски и быстренько съе...ть оттуда, издали наблюдая за тем как оно пойдет вразнос.
	Ответить | Правка | К родителю #84 | Наверх | Cообщить модератору

8. "Проект MOOL развивает средства разработки драйверов ядра Lin..."	–3 +/–
Сообщение от Психиатр (ok), 04-Окт-14, 01:05
хоспади ... вантуз уже индусский чуть меньше чем полностью ... так они уже и до ведра добрались ...
Ответить | Правка | Наверх | Cообщить модератору

	16. "Проект MOOL развивает средства разработки драйверов ядра Lin..."	+2 +/–
	Сообщение от Аноним (-), 04-Окт-14, 01:32
	> хоспади ... > вантуз уже индусский чуть меньше чем полностью ... > так они уже и до ведра добрались ... Справедливости ради, индусы индусам рознь. Мой бывший непосредственный начальник - потомственный индус, при этом блестящий специалист, хороший преподаватель и просто потрясающий человек. Собственно, "бывший" - потому что финансово-семейные обстоятельства вынудили его уехать зарабатывать на собственное жильё... В общем, я очень горжусь знакомством и благодарен ему за многое, чему я у него научился.
	Ответить | Правка | Наверх | Cообщить модератору

	24. "Проект MOOL развивает средства разработки драйверов ядра Lin..."	+3 +/–
	Сообщение от Аноним рус (?), 04-Окт-14, 02:00
	Вообще у индусов все шансы повторить успех Китая, сколько шуму подняла на тех. ресурсах, сверхдешевая космическая миссия на Марс, удавшаяся полностью и с первого раза. Горы ЙТшников с высокой конкуренцией и соответственно большими требованиями к самосовершенствованию. Да к кстати, посмотрите кто в топах у Гугла, после тройки основателей! ;-)
	Ответить | Правка | К родителю #8 | Наверх | Cообщить модератору

	35. "Проект MOOL развивает средства разработки драйверов ядра Lin..."	+/–
	Сообщение от Michael Shigorin (ok), 04-Окт-14, 05:38
	> Горы ЙТшников с высокой конкуренцией и соответственно большими требованиями > к самосовершенствованию. Насколько понимаю, с этими браминами всё далеко не так однозначно.
	Ответить | Правка | Наверх | Cообщить модератору

	55. "Проект MOOL развивает средства разработки драйверов ядра Lin..."	–5 +/–
	Сообщение от Психиатр (ok), 04-Окт-14, 15:02
	>Насколько понимаю, с этими браминами всё далеко не так однозначно. именно, топовым, опытным кодерам и так работы хватает, они сидят себе и кодят проприетарный софт за нехилые баблосы, им всякие сомнительные недопроекты не нужны. а вот те которые пытаются изобрести очередной велосипед - обычно неопытные и криворукие по определению.
	Ответить | Правка | Наверх | Cообщить модератору

	38. "Проект MOOL развивает средства разработки драйверов ядра Lin..."	+5 +/–
	Сообщение от Аноним (-), 04-Окт-14, 09:49
	"Индусский код" плодят индусы на аутсорс собственно в Индии. А толковые ребята у них очень быстро оттуда уезжают.
	Ответить | Правка | К родителю #8 | Наверх | Cообщить модератору

	93. "Проект MOOL развивает средства разработки драйверов ядра Lin..."	+/–
	Сообщение от Аноним (-), 05-Окт-14, 09:46
	> "Индусский код" плодят индусы на аутсорс собственно в Индии. А толковые ребята > у них очень быстро оттуда уезжают. плодят и плодят
	Ответить | Правка | Наверх | Cообщить модератору

9. "Проект MOOL развивает средства разработки драйверов ядра Lin..."	+/–
Сообщение от Аноним (-), 04-Окт-14, 01:06
тогда уж лучше на rust
Ответить | Правка | Наверх | Cообщить модератору

11. "Проект MOOL развивает средства разработки драйверов ядра Lin..."	+/–
Сообщение от Аноним (-), 04-Окт-14, 01:22
жабу им уже предлагали?
Ответить | Правка | Наверх | Cообщить модератору

	12. "Проект MOOL развивает средства разработки драйверов ядра Lin..."	–4 +/–
	Сообщение от Психиатр (ok), 04-Окт-14, 01:23
	лучше на C# ведро переписать или на vbs
	Ответить | Правка | Наверх | Cообщить модератору

	17. "Проект MOOL развивает средства разработки драйверов ядра Lin..."	+/–
	Сообщение от Аноним (-), 04-Окт-14, 01:33
	> лучше на C# ведро переписать или на vbs Уже был какой-то прожЕкт от ms. Понятно насколько всем оказался нужен. Ну и си++ туда же пойдет. Торвальдс стопроцентно этим концептуалам волшебную палочку покажет.
	Ответить | Правка | Наверх | Cообщить модератору

	21. "Проект MOOL развивает средства разработки драйверов ядра Lin..."	–3 +/–
	Сообщение от Психиатр (ok), 04-Окт-14, 01:40
	>Торвальдс стопроцентно этим концептуалам волшебную палочку покажет. Врядли. Он скорее всего даже внимания не обратит, ибо проект мертворождённый.
	Ответить | Правка | Наверх | Cообщить модератору

	30. "Проект MOOL развивает средства разработки драйверов ядра Lin..."	+1 +/–
	Сообщение от Аноним (-), 04-Окт-14, 02:42
	> Он скорее всего даже внимания не обратит, ибо проект мертворождённый. Он внимания не обратит, если к нему с этой бнопней не полезут. А если полезут - тогда покажет.
	Ответить | Правка | Наверх | Cообщить модератору

	40. "Проект MOOL развивает средства разработки драйверов ядра Lin..."	+/–
	Сообщение от имя (?), 04-Окт-14, 10:53
	> Уже был какой-то прожЕкт от ms Singularity.
	Ответить | Правка | К родителю #17 | Наверх | Cообщить модератору

	41. "Проект MOOL развивает средства разработки драйверов ядра Lin..."	+/–
	Сообщение от имя (?), 04-Окт-14, 10:54
	>> Уже был какой-то прожЕкт от ms > Singularity. И, кстати, проект этот был исключительно исследовательским, в отличие от.
	Ответить | Правка | Наверх | Cообщить модератору

	60. "Проект MOOL развивает средства разработки драйверов ядра Lin..."	+/–
	Сообщение от Аноним (-), 04-Окт-14, 15:56
	> И, кстати, проект этот был исключительно исследовательским, в отличие от. А у этих прожЕкт тоже чисто исследовательский, только они пока об этом еще не знают :)
	Ответить | Правка | Наверх | Cообщить модератору

	53. "Проект MOOL развивает средства разработки драйверов ядра Lin..."	–2 +/–
	Сообщение от Zenitur (ok), 04-Окт-14, 14:32
	Лучше на CUDA.
	Ответить | Правка | К родителю #12 | Наверх | Cообщить модератору

	61. "Проект MOOL развивает средства разработки драйверов ядра Lin..."	+/–
	Сообщение от Аноним (-), 04-Окт-14, 15:57
	> Лучше на CUDA. Да чего мелочиться? Сразу на брейнфаке давайте.
	Ответить | Правка | Наверх | Cообщить модератору

18. "Проект MOOL развивает средства разработки драйверов ядра Lin..."	+2 +/–
Сообщение от all_glory_to_the_hypnotoad (ok), 04-Окт-14, 01:33
вот же придурки
Ответить | Правка | Наверх | Cообщить модератору

22. "Проект MOOL развивает средства разработки драйверов ядра Lin..."	+/–
Сообщение от Xasd (ok), 04-Окт-14, 01:41
> Стоит напомнить, что Линус Торвальдс является ярым противником C++ и считает его ужасным языком, сковывающим разработчиков рамками ранее созданных абстракций (например, при желании избавиться от неэффективных абстракций, разработчик сталкивается с тем, что весь код зависит от созданных вокруг этих абстракций объектных моделей и не может исправить ситуацию не переписывая своё приложение). вот же мозгач Линус! молодец, правильно думает.. что же будет когда его не станет (из-за автобуса, того-самого)..?
Ответить | Правка | Наверх | Cообщить модератору

	48. "Проект MOOL развивает средства разработки драйверов ядра Lin..."	+1 +/–
	Сообщение от Ан (??), 04-Окт-14, 14:12
	А если сишнаую структуру захочешь изменить(заменить существующее поле на другое) то что внезапно весь зависимый софт сам перепишется под новую структуру? Вообще в API всегда встают вопросы о поддержке каких-то структур/функций и желании их заменить, переписать. Так что это как-то из пальца высосано. Эта проблема всплывёт как в C++ так и в С.
	Ответить | Правка | Наверх | Cообщить модератору

	69. "Проект MOOL развивает средства разработки драйверов ядра Lin..."	+/–
	Сообщение от тоже Аноним (ok), 04-Окт-14, 17:01
	> Эта проблема всплывёт как в C++ так и в С. Эта проблема всплывет в любом языке. Вопрос в объеме кода, который действительно зависит от таких изменений. В С и С++ при правильном написании это - только тот код, который реально работает с этими полями. Весь остальной код, касающийся этой структуры, видит только указатель - то есть некое место в памяти определенного размера, но неизвестного назначения.
	Ответить | Правка | Наверх | Cообщить модератору

	98. "Проект MOOL развивает средства разработки драйверов ядра Lin..."	+/–
	Сообщение от freehck (ok), 05-Окт-14, 18:21
	>> Эта проблема всплывёт как в C++ так и в С. > Эта проблема всплывет в любом языке. Вопрос в объеме кода, который действительно > зависит от таких изменений. > В С и С++ при правильном написании это - только тот код, > который реально работает с этими полями. Весь остальной код, касающийся этой > структуры, видит только указатель - то есть некое место в памяти > определенного размера, но неизвестного назначения. А как эта скомпилированная программа на C/C++ узнает сколько памяти нужно выделить под переменную? Правильно, заголовки подключит. И таким образом всё равно при изменении полей структуры придётся перекомпилировать все пользующиеся этой структурой программы, хотя казалось бы, интерфейсы остались неизменными. Это известная проблема языка C, которая, к сожалению, не решается просто "правильным" написанием кода. Но что касается наличия данной проблемы в других языках, то квантификатор "любой" тут не к месту. Существуют языки, которые от этого не страдают. Лиспы, например.
	Ответить | Правка | Наверх | Cообщить модератору

	102. "Проект MOOL развивает средства разработки драйверов ядра Lin..."	+/–
	Сообщение от тоже Аноним (ok), 05-Окт-14, 22:35
	Неизменными интерфейсы будут только в том случае, если в интерфейсах используется не структура, а указатель на нее. В этом случае тому коду, который не лезет внутрь структуры, безразлично, что скрывается под void*, а тому, который лезет - ну, тут перекомпиляция при изменениях неизбежна.
	Ответить | Правка | Наверх | Cообщить модератору

	104. "Проект MOOL развивает средства разработки драйверов ядра Lin..."	+/–
	Сообщение от freehck (ok), 05-Окт-14, 23:29
	> Неизменными интерфейсы будут только в том случае, если в интерфейсах используется не > структура, а указатель на нее. В этом случае тому коду, который > не лезет внутрь структуры, безразлично, что скрывается под void*, а тому, > который лезет - ну, тут перекомпиляция при изменениях неизбежна. Я правильно понимаю, что Вы предлагаете: 1) В заголовках писать только определение интерфейсов, 2) Описание структуры вынести из заголовков в код библиотеки, 3) Интерфейс-конструктор будет выделять память в куче и возвращать указатель на неё, а все остальные интерфейсы будут оперировать указателями структуры, 4) В программе, которая пользуется библиотекой, все переменные, подразумевающие хранение данной структуры, будут иметь тип void. Если я правильно Вас понял и ничего не забыл, то в принципе это выглядит как решение... Но не станет ли код слишком громоздким?
	Ответить | Правка | Наверх | Cообщить модератору

	116. "Проект MOOL развивает средства разработки драйверов ядра Lin..."	+/–
	Сообщение от тоже Аноним (ok), 06-Окт-14, 08:42
	Описание структуры логично вынести из заголовков с API в заголовки, которые будет подключать только тот код, которому это действительно нужно. Остальному перекомпилироваться совершенно необязательно.
	Ответить | Правка | Наверх | Cообщить модератору

	121. "Проект MOOL развивает средства разработки драйверов ядра Lin..."	+/–
	Сообщение от Аноним (-), 06-Окт-14, 12:01
	А что делать? Либо поля структуры, их размер, порядок, тип и количество являются частью интерфейса — и тогда мы можем сами выделять память, обращаться к отдельным полям не call get_field1, а mov eax, [struct_var+offset_field1], и т.п., — либо не являются, а вместо них есть абстрактный интерфейс к структуре — функции создания/удаления, геттеры-сеттеры, всякие удобные запросы (типа метода size() для связного списка) — но тогда, увы, появляются накладные расходы за счет косвенности, и полностью их никак не убрать.
	Ответить | Правка | К родителю #104 | Наверх | Cообщить модератору

	124. "Проект MOOL развивает средства разработки драйверов ядра Lin..."	+/–
	Сообщение от freehck (ok), 06-Окт-14, 12:36
	Накладные расходы - не такая уж большая плата за новый уровень абстракции. Проблема как раз в том, что читать это будет невозможно. Тут возникает логичный вопрос: зачем Вам вообще сдалась жёсткая типизация языка Си, если при работе с библиотеками Вы будете использовать void* для структуры, определённой этой библиотекой? Вы мало того, что читать это замучаетесь, так ещё и потеряете (хоть и не шибко хороший) контроль типов. Я вот чувствую, что если мой собеседник ещё немного поразмышлял бы, то пришёл бы к выводу, что для подобного программирования очень подходят языки с динамической типизацией переменных.
	Ответить | Правка | Наверх | Cообщить модератору

	126. "Проект MOOL развивает средства разработки драйверов ядра Lin..."	+/–
	Сообщение от тоже Аноним (ok), 06-Окт-14, 13:30
	Могу в ответ посоветовать вам поразмышлять: возможно, для подобных задач просто стоит использовать не жесткие структуры, а что-то другое? Глядишь, и не понадобится оверхед на ненужные абстракции типа динамической типизации переменных. Сейчас по разнице между форматами обмена информацией (бинарным, расширяемым и комбинированным) накоплен колоссальный мировой опыт...
	Ответить | Правка | Наверх | Cообщить модератору

	127. "Проект MOOL развивает средства разработки драйверов ядра Lin..."	+/–
	Сообщение от freehck (ok), 06-Окт-14, 13:37
	Извините, но я предпочту закончить этот диалог. Он как-то сильно на два монолога смахивает.
	Ответить | Правка | Наверх | Cообщить модератору

	128. "Проект MOOL развивает средства разработки драйверов ядра Lin..."	–1 +/–
	Сообщение от Аноним (-), 06-Окт-14, 13:57
	Нахрен 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.
	Ответить | Правка | К родителю #124 | Наверх | Cообщить модератору

	132. "Проект MOOL развивает средства разработки драйверов ядра Lin..."	+/–
	Сообщение от dq0s4y71 (ok), 06-Окт-14, 15:48
	> А как эта скомпилированная программа на 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 и работать с ним только посредством функций, которые вы ему для этого определите. В С++ такой номер не пройдёт - там, если вы хотите чтобы работали виртуальные методы, нужно иметь прототип класса. И изменить что-то в этом базовом классе без необходимости перекомпиляции всего когда снизу доверху вы не сможете.
	Ответить | Правка | К родителю #98 | Наверх | Cообщить модератору

	144. "Проект MOOL развивает средства разработки драйверов ядра Lin..."	–1 +/–
	Сообщение от freehck (ok), 07-Окт-14, 01:32
	>> А как эта скомпилированная программа на 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ообщить модератору

	149. "Проект MOOL развивает средства разработки драйверов ядра..."	+/–
	Сообщение от arisu (ok), 07-Окт-14, 09:09
	> Вот логичный вопрос-продолжение: а есть ли где-нибудь более подробная справка, в которой > такие моменты обозначены? да. называется «стандарт языка си». стоит недорого.
	Ответить | Правка | Наверх | Cообщить модератору

	163. "Проект MOOL развивает средства разработки драйверов ядра Lin..."	+/–
	Сообщение от dq0s4y71 (ok), 07-Окт-14, 12:45
	ниже ответил
	Ответить | Правка | К родителю #144 | Наверх | Cообщить модератору

	142. "Проект MOOL развивает средства разработки драйверов ядра Lin..."	+/–
	Сообщение от Посторонним В (?), 07-Окт-14, 00:30
	>[оверквотинг удален] >> структуры, видит только указатель - то есть некое место в памяти >> определенного размера, но неизвестного назначения. > А как эта скомпилированная программа на C/C++ узнает сколько памяти нужно выделить > под переменную? Правильно, заголовки подключит. И таким образом всё равно при > изменении полей структуры придётся перекомпилировать все пользующиеся этой структурой > программы, хотя казалось бы, интерфейсы остались неизменными. > Это известная проблема языка C, которая, к сожалению, не решается просто "правильным" > написанием кода. Но что касается наличия данной проблемы в других языках, > то квантификатор "любой" тут не к месту. Существуют языки, которые от > этого не страдают. Лиспы, например. Как бы перекомпилировать ядро с новой версией всё равно необходимо...
	Ответить | Правка | К родителю #98 | Наверх | Cообщить модератору

	123. "Проект MOOL развивает средства разработки драйверов ядра Lin..."	–4 +/–
	Сообщение от bOOster (?), 06-Окт-14, 12:20
	В С++ легче чем в C. Templates рулят, правда не для школьников.
	Ответить | Правка | К родителю #48 | Наверх | Cообщить модератору

	130. "Проект MOOL развивает средства разработки драйверов ядра Lin..."	+/–
	Сообщение от dq0s4y71 (ok), 06-Окт-14, 15:31
	> А если сишнаую структуру захочешь изменить(заменить существующее поле на другое) то что внезапно весь зависимый софт сам перепишется под новую структуру? А в чём проблема? Передавайте в функцию указатель на структуру, а какие поля у этой структуры, никого может не волновать, кроме внутренней реализации. Вы можете вообще даже не объявлять поля структуры: struct my_object; struct my_object * my_object_create(); int my_object_do_something(struct my_object * object); И это будет работать. А о внутренней структуре вашего объекта пользователь может вообще ничего не знать, в отличие от плюсов.
	Ответить | Правка | К родителю #48 | Наверх | Cообщить модератору

	143. "Проект MOOL развивает средства разработки драйверов ядра Lin..."	–1 +/–
	Сообщение от Посторонним В (?), 07-Окт-14, 00:38
	>> А если сишнаую структуру захочешь изменить(заменить существующее поле на другое) то что внезапно весь зависимый софт сам перепишется под новую структуру? > А в чём проблема? Передавайте в функцию указатель на структуру, а какие > поля у этой структуры, никого может не волновать, кроме внутренней реализации. > Вы можете вообще даже не объявлять поля структуры: > 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 *); :-)
	Ответить | Правка | Наверх | Cообщить модератору

	162. "Проект MOOL развивает средства разработки драйверов ядра Lin..."	+/–
	Сообщение от dq0s4y71 (ok), 07-Окт-14, 12:43
	Внезапно выясняется, что если вы хотите использовать какие-то методы класса, класс должен быть определён :)
	Ответить | Правка | Наверх | Cообщить модератору

	145. "Проект MOOL развивает средства разработки драйверов ядра Lin..."	–1 +/–
	Сообщение от freehck (ok), 07-Окт-14, 01:34
	> Вы можете вообще даже не объявлять поля структуры: > struct my_object; > struct my_object * my_object_create(); > int my_object_do_something(struct my_object * object); Уважаемый, не затруднит ли Вас подсказать мне, где это задокументировано, что можно объявлять структуры, не объявляя сами поля? А то меня очень огорчает тот факт, что о таких вещах я узнаю только сейчас, хотя вроде бы с Си очень давно знаком.
	Ответить | Правка | К родителю #130 | Наверх | Cообщить модератору

	148. "Проект MOOL развивает средства разработки драйверов ядра..."	–1 +/–
	Сообщение от arisu (ok), 07-Окт-14, 09:08
	> Уважаемый, не затруднит ли Вас подсказать мне, где это задокументировано, что можно > объявлять структуры, не объявляя сами поля? в стандарте, однако. forward declaration называется.
	Ответить | Правка | Наверх | Cообщить модератору

	154. "Проект MOOL развивает средства разработки драйверов ядра..."	–1 +/–
	Сообщение от freehck (ok), 07-Окт-14, 11:09
	>> Уважаемый, не затруднит ли Вас подсказать мне, где это задокументировано, что можно >> объявлять структуры, не объявляя сами поля? > в стандарте, однако. forward declaration называется. Я думаю, не с проста Вы не приводите ссылок. Я поискал. И стандарт, и forward declaration. И не нашёл этой документации. Arisu, попробуйте быть снисходительным, ибо вещи, которые Вам так очевидны, мне таковыми очень не кажутся.
	Ответить | Правка | Наверх | Cообщить модератору

	156. "Проект MOOL развивает средства разработки драйверов ядра..."	+1 +/–
	Сообщение от arisu (ok), 07-Окт-14, 11:23
	> Я думаю, не с проста Вы не приводите ссылок. конечно: я предполагаю минимальные навыки гуглежа. > Я поискал. И стандарт, и forward declaration. И не нашёл этой документации. это прискорбно. я по «c struct forward declaration» нашёл сразу много интересного. тебе гугель поломали. а стандарт денег стоит, да. поэтому на него очень сложно ссылки приводить. > Arisu, попробуйте > быть снисходительным, ибо вещи, которые Вам так очевидны, мне таковыми очень > не кажутся. куда уж дальше-то? и направление поиска дал, и ключевые слова… ни разу не написал, что «это должны знать все, а кто не знает — тот лох». ан нет, мало, надо разжевать и в рот положить. пардон, но это уже только за деньги.
	Ответить | Правка | Наверх | Cообщить модератору

	161. "Проект MOOL развивает средства разработки драйверов ядра..."	+/–
	Сообщение от freehck (ok), 07-Окт-14, 12:43
	>> Я поискал. И стандарт, и forward declaration. И не нашёл этой документации. > это прискорбно. я по «c struct forward declaration» нашёл сразу много интересного. > тебе гугель поломали. Arisu, мне сдаётся, что ты видишь то, что хочешь видеть. Интересного мне не надо. Мне надо чётких определений. Какой смысл посылать человека на stackoverflow и wikipedia, когда тебя спрашивают про документацию? > а стандарт денег стоит, да. поэтому на него очень сложно ссылки приводить. Неужели же нет где-нибудь халявной версии? Я вот тоже поискал-поискал, да обломался. upd: однако нет, нашёл. http://www.open-std.org/jtc1/sc22/wg14/ >> Arisu, попробуйте >> быть снисходительным, ибо вещи, которые Вам так очевидны, мне таковыми очень >> не кажутся. > куда уж дальше-то? и направление поиска дал, и ключевые слова… ни разу > не написал, что «это должны знать все, а кто не знает > — тот лох». ан нет, мало, надо разжевать и в рот > положить. пардон, но это уже только за деньги. Arisu, а не звучит ли это странно после такого начала: >> Я думаю, не с проста Вы не приводите ссылок. > конечно: я предполагаю минимальные навыки гуглежа. То есть мне гугль поломали, искать я не умею. А ты, значит, умеешь, но ссылки привести не можешь. Гундишь только: "обленились совсем,  всё им на блюдечке"...  Тоже мне, Д'Артаньян.
	Ответить | Правка | Наверх | Cообщить модератору

	164. "Проект MOOL развивает средства разработки драйверов ядра..."	+1 +/–
	Сообщение от arisu (ok), 07-Окт-14, 12:45
	> Arisu, мне сдаётся, что ты видишь то, что хочешь видеть. Интересного мне > не надо. Мне надо чётких определений. Какой смысл посылать человека на > stackoverflow и wikipedia, когда тебя спрашивают про документацию? что-то я запамятовал: когда мы успели трудовой договор заключить? и где моя зарплата? > Arisu, а не звучит ли это странно после такого начала: нет. > То есть мне гугль поломали, искать я не умею. А ты, значит, > умеешь, но ссылки привести не можешь. Гундишь только: "обленились совсем,   > всё им на блюдечке"...  Тоже мне, Д'Артаньян. Rasch abkochen, dann Vormarsch nach Sokal.
	Ответить | Правка | Наверх | Cообщить модератору

	166. "Проект MOOL развивает средства разработки драйверов ядра..."	–1 +/–
	Сообщение от freehck (ok), 07-Окт-14, 12:49
	upd: стандарты http://www.open-std.org/jtc1/sc22/wg14/
	Ответить | Правка | Наверх | Cообщить модератору

	180. "Проект MOOL развивает средства разработки драйверов ядра..."	+1 +/–
	Сообщение от Аноним (-), 08-Окт-14, 06:55
	> upd: стандарты > http://www.open-std.org/jtc1/sc22/wg14/ Ну вот видишь, Кэп конечно бывает редиской с его наездами, но зачастую оказывается прав. После наезда то нашлось. Вот так волшебные пинки и творят чудеса в обучении пользовании поисковиками :)
	Ответить | Правка | Наверх | Cообщить модератору

	183. "Проект MOOL развивает средства разработки драйверов ядра..."	+/–
	Сообщение от arisu (ok), 08-Окт-14, 09:37
	только вот стандарты там маленько не качаются, и текстов нет. C11, например, купить предлагают. даже, вроде бы, и драфтов нет.
	Ответить | Правка | Наверх | Cообщить модератору

	160. "Проект MOOL развивает средства разработки драйверов ядра Lin..."	+/–
	Сообщение от dq0s4y71 (ok), 07-Окт-14, 12:40
	Это называется 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]; И это правильно :)
	Ответить | Правка | К родителю #145 | Наверх | Cообщить модератору

	168. "Проект MOOL развивает средства разработки драйверов ядра Lin..."	–1 +/–
	Сообщение от freehck (ok), 07-Окт-14, 13:28
	> Это называется 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. Интересно посмотреть, что стандарт говорит по этому поводу.
	Ответить | Правка | Наверх | Cообщить модератору

	170. "Проект MOOL развивает средства разработки драйверов ядра Lin..."	+/–
	Сообщение от dq0s4y71 (ok), 07-Окт-14, 14:52
	> Спасибо. Я нашёл стандарт и прочитал этот кусок. Там, вроде, не говорится о структурах. А это, собственно говоря, относится ко всем типам. Можно написать: int x; int x = 1; И это будет правильно :) > Я на выходных поищу в стандарте определение слов declare и define. Интересно посмотреть, что стандарт говорит по этому поводу. Интересно, что даже компиляторостроители иногда не отличают эти термины. Например, разные компиляторы называют разными словами одну и ту же ошибку: > error: 'x' undeclared (first use in this function) > Undefined symbol 'x' in function main
	Ответить | Правка | Наверх | Cообщить модератору

27. "Проект MOOL развивает средства разработки драйверов ядра Lin..."	–1 +/–
Сообщение от Аноним (-), 04-Окт-14, 02:19
Идея правильная, но язык выбран крайне неудачно. Справедливости ради, выбора тут нет нет.
Ответить | Правка | Наверх | Cообщить модератору

31. "Проект MOOL развивает средства разработки драйверов ядра Lin..."	+7 +/–
Сообщение от Ordu (ok), 04-Окт-14, 02:45
Отличная новость! Наконец-то кто-то решился на эту экспериментальную проверку непригодности C++ для ядерного программирования. Запасаемся попкорном и наблюдаем, желая успеха индусам: если C++ окажется удачнее, то у нас будет ядро лучше, чем linux. Ну, а если они ошибаются, то мы, по-крайней мере, сможем поглумиться, повторяя "а Торвальдс предупреждал".
Ответить | Правка | Наверх | Cообщить модератору

	34. "Проект MOOL развивает средства разработки драйверов ядра Lin..."	+/–
	Сообщение от Аноним (-), 04-Окт-14, 05:09
	BeOS Haiku Symbian
	Ответить | Правка | Наверх | Cообщить модератору

	49. "Проект MOOL развивает средства разработки драйверов ядра Lin..."	+3 +/–
	Сообщение от Nixman (?), 04-Окт-14, 14:13
	все в жопе.
	Ответить | Правка | Наверх | Cообщить модератору

	63. "Проект MOOL развивает средства разработки драйверов ядра Lin..."	+2 +/–
	Сообщение от Аноним (-), 04-Окт-14, 16:02
	> все в жопе. Еще ReactOS, где ядро переписывали раза три. Последнее на каком-то урезанном субсете плюсов. А более вменяемые люди не выделывались и просто написали ядро на сях 1 раз, зато нормальное. У реально существующих ОС ядра оптимизированы на то чтобы это работало и желательно быстро и безглючно. А насколько оно концептуально - интересно десятку чудаков на всю планету.
	Ответить | Правка | Наверх | Cообщить модератору

	74. "Проект MOOL развивает средства разработки драйверов ядра Lin..."	–1 +/–
	Сообщение от Аноним (-), 04-Окт-14, 18:30
	Ну Symbian в опе благодаря усилиям маркетолухов и помощи M$.
	Ответить | Правка | К родителю #49 | Наверх | Cообщить модератору

	88. "Проект MOOL развивает средства разработки драйверов ядра Lin..."	+1 +/–
	Сообщение от Аноним (-), 05-Окт-14, 08:46
	> Ну Symbian в опе благодаря усилиям маркетолухов и помощи M$. А также благодаря у...щности системы. Новое разрешение экрана добавить? На симбиане это героизм и достижение. Поэтому смарты на симбиане нокия улучшала в плане экранов очень неохотно. А уж как этот крап работал с сенсорным экраном - это вообще жесть.
	Ответить | Правка | Наверх | Cообщить модератору

	42. "Проект MOOL развивает средства разработки драйверов ядра Lin..."	+/–
	Сообщение от XoRe (ok), 04-Окт-14, 11:39
	> Отличная новость! Наконец-то кто-то решился на эту экспериментальную проверку непригодности > C++ для ядерного программирования. Запасаемся попкорном и наблюдаем, желая успеха индусам: > если C++ окажется удачнее, то у нас будет ядро лучше, чем > linux. Ну, а если они ошибаются, то мы, по-крайней мере, сможем > поглумиться, повторяя "а Торвальдс предупреждал". Проблема в том, что всегда можно будет указать на совершенно иные причины фейла. "Внутренние конфликты", "Разное видение у разработчиков", "Сворачивание финансирования" и т.д. И типа, "но сама идея хорошая, только неосилили". Хотя, вполне возможно, что внутренние конфликты и сворачивание финансирование произошло из за того, что никак не получалось сделать конфетку. Но в этом могут и не признаться.
	Ответить | Правка | К родителю #31 | Наверх | Cообщить модератору

	67. "Проект MOOL развивает средства разработки драйверов ядра Lin..."	+1 +/–
	Сообщение от Ordu (ok), 04-Окт-14, 16:50
	>[оверквотинг удален] >> linux. Ну, а если они ошибаются, то мы, по-крайней мере, сможем >> поглумиться, повторяя "а Торвальдс предупреждал". > Проблема в том, что всегда можно будет указать на совершенно иные причины > фейла. > "Внутренние конфликты", "Разное видение у разработчиков", "Сворачивание финансирования" > и т.д. > И типа, "но сама идея хорошая, только неосилили". > Хотя, вполне возможно, что внутренние конфликты и сворачивание финансирование произошло > из за того, что никак не получалось сделать конфетку. > Но в этом могут и не признаться. Ну вы же понимаете, что чем больше фейлов C++ на поприще ядерного программирования, тем сложнее отрицать его непригодность. Матлогика в подобных ситуациях бессильна, а вот probabilistic reasoning очень даже может выкрутится, обойдясь тем, что в суде называются "косвенными" доказательствами. Да и в конце-концов -- мне без разницы признают ли C++-фаны фейл C++. Мне интереснее проверить свои убеждения, особенно если эта проверка будет стоит мне лишь попкорна.
	Ответить | Правка | Наверх | Cообщить модератору

	108. "Проект MOOL развивает средства разработки драйверов ядра Lin..."	+/–
	Сообщение от Аноним (-), 06-Окт-14, 04:29
	> бессильна, а вот probabilistic reasoning очень даже может выкрутится, Ваш probablistic reasoning всего лишь то что люди попроще называют опытом и обобщением. Вот так вот и получается что даже грузчик с тремя классами образования на базовом уровне владеет этим предметом. Только не знает об этом.
	Ответить | Правка | Наверх | Cообщить модератору

	112. "Проект MOOL развивает средства разработки драйверов ядра Lin..."	+/–
	Сообщение от Ordu (ok), 06-Окт-14, 04:52
	>> бессильна, а вот probabilistic reasoning очень даже может выкрутится, > Ваш probablistic reasoning всего лишь то что люди попроще называют опытом и > обобщением. Вот так вот и получается что даже грузчик с тремя > классами образования на базовом уровне владеет этим предметом. Только не знает > об этом. Да-да. И логикой все владеют от рождения, только не знают об этом.
	Ответить | Правка | Наверх | Cообщить модератору

	135. "Проект MOOL развивает средства разработки драйверов ядра Lin..."	+/–
	Сообщение от Аноним (-), 06-Окт-14, 18:46
	> Да-да. И логикой все владеют от рождения, только не знают об этом. Ну, допустим, не все. Darwin Awards подтверждает - отклонения случаются и к добру не приводят.
	Ответить | Правка | Наверх | Cообщить модератору

	54. "Проект MOOL развивает средства разработки драйверов ядра Lin..."	–2 +/–
	Сообщение от Zenitur (ok), 04-Окт-14, 14:36
	> Отличная новость! Наконец-то кто-то решился на эту экспериментальную проверку непригодности > C++ для ядерного программирования. Запасаемся попкорном и наблюдаем, желая успеха индусам: > если C++ окажется удачнее, то у нас будет ядро лучше, чем > linux. Ну, а если они ошибаются, то мы, по-крайней мере, сможем > поглумиться, повторяя "а Торвальдс предупреждал". Драйвер fglrx на C++. Недавно был "отвязан" от libstdc++.so.5. Он такой плохой из-за плохого отношения к Linux в ATi, а в AMD потратили денег на его починку (оказалось дешевле, чем переписать) и теперь он нормален. И всё-таки если бы он был на Си, проблем с исправлением не было бы изначально.
	Ответить | Правка | К родителю #31 | Наверх | Cообщить модератору

	62. "Проект MOOL развивает средства разработки драйверов ядра Lin..."	+/–
	Сообщение от Аноним (-), 04-Окт-14, 16:00
	> Отличная новость! Наконец-то кто-то решился на эту экспериментальную проверку непригодности > C++ для ядерного программирования. Вон уже есть реактос. Используйте наздоровье. > Запасаемся попкорном и наблюдаем, желая успеха индусам: > если C++ окажется удачнее, то у нас будет ядро лучше, чем linux. Думаю, экспедиция на Марс отправится раньше. > Ну, а если они ошибаются, то мы, по-крайней мере, сможем > поглумиться, повторяя "а Торвальдс предупреждал". А Торвальдс - руководитель проекта, который не дрoчит на концепции а достигает результатов. Этим он и отличается от безбашенных концептуалов с горящими глазами, готовыми все разворотить чтобы свои концепции вкостылить, доказывая с пеной у рта что если все падает и глючит - это ничего, так и надо.
	Ответить | Правка | К родителю #31 | Наверх | Cообщить модератору

	73. "Проект MOOL развивает средства разработки драйверов ядра Lin..."	+1 +/–
	Сообщение от Ordu (ok), 04-Окт-14, 18:29
	> Вон уже есть реактос. Используйте наздоровье. Нет, спасибо > Думаю, экспедиция на Марс отправится раньше. Я тоже много чего думаю, но при этом различаю умозрительные выводы и факты. И вам рекомендую.
	Ответить | Правка | Наверх | Cообщить модератору

	89. "Проект MOOL развивает средства разработки драйверов ядра Lin..."	+1 +/–
	Сообщение от Аноним (-), 05-Окт-14, 08:50
	> Нет, спасибо А чего так? :) > Я тоже много чего думаю, но при этом различаю умозрительные выводы и факты. Это моя ставка на то чем это закончится. Наиболее вероятный по моему мнению сценарий. Возник на основе смотрения на успех других систем с ядрами на плюсах. Не хочу ничего сказать, но "ядро на плюсах" (или чем-то еще) - очень абстрактное преимущество, не представляющее из себя никакой самоценности для большинства людей. А какой-нибудь симбиан например был полным шитом совершенно независимо от плюсов в каждой дырке.
	Ответить | Правка | Наверх | Cообщить модератору

	101. "Проект MOOL развивает средства разработки драйверов ядра Lin..."	+1 +/–
	Сообщение от Ordu (ok), 05-Окт-14, 20:41
	>> Нет, спасибо > А чего так? :) Не вижу причин. А почему вы спрашиваете? Вы видите какие-либо причины пользоваться ReactOS? С удовольствием ознакомлюсь со списком таких причин.
	Ответить | Правка | Наверх | Cообщить модератору

	109. "Проект MOOL развивает средства разработки драйверов ядра Lin..."	+/–
	Сообщение от Аноним (-), 06-Окт-14, 04:33
	> Не вижу причин. А почему вы спрашиваете? > Вы видите какие-либо причины пользоваться ReactOS? Ну мало ли. Отдельные экзотичные личности за "зато на плюсах!" или "зато клон ядра NT!" вон многое прощают. Это конечно очень спорные в плане рациональности подходы, но они бывают. > С удовольствием ознакомлюсь со списком таких причин. Честно говоря я их тоже не вижу. Как минимум для себя.
	Ответить | Правка | Наверх | Cообщить модератору

	72. "Проект MOOL развивает средства разработки драйверов ядра Lin..."	+/–
	Сообщение от Аноним (-), 04-Окт-14, 18:18
	> Наконец-то кто-то решился на эту экспериментальную проверку непригодности C++ для ядерного программирования. Бугага. Таких попыток было... по пояс будет. Самая старая какую могут вспомнить - Chorus.
	Ответить | Правка | К родителю #31 | Наверх | Cообщить модератору

36. "Проект BOSSMOOL развивает средства разработки драйверов ядра..."	+/–
Сообщение от Аноним (-), 04-Окт-14, 08:31
sed /BOSSMOOL/BSOD/
Ответить | Правка | Наверх | Cообщить модератору

37. "Проект BOSSMOOL развивает средства разработки драйверов ядра..."	+/–
Сообщение от Аноним (-), 04-Окт-14, 08:34
Весело им будет. В ядре-то только строгая безопасность с исключениями может использоваться (strong exception-safety). Посмотрим, как у них выйдет это сделать. И это только одна из проблем.
Ответить | Правка | Наверх | Cообщить модератору

	70. "Проект BOSSMOOL развивает средства разработки драйверов ядра..."	–1 +/–
	Сообщение от тоже Аноним (ok), 04-Окт-14, 17:08
	Вообще-то устраивать kernel panic и на Сях нельзя. С++ предоставит возможность хотя бы ловить и обрабатывать проблемы не в каждом возможном месте их возникновения, а общим блоком. То, что в дровах все такие потенциальные проблемы должны обрабатываться, от языка не зависит.
	Ответить | Правка | Наверх | Cообщить модератору

39. "Проект BOSSMOOL развивает средства разработки драйверов ядра..."	–3 +/–
Сообщение от Нанобот (ok), 04-Окт-14, 10:13
имхо, давно пора. расширение возможностей ядра, как никак. в идеале должна быть возможность разработки модулей ядра на любых языках
Ответить | Правка | Наверх | Cообщить модератору

	44. "Проект BOSSMOOL развивает средства разработки драйверов ядра..."	+1 +/–
	Сообщение от XoRe (ok), 04-Окт-14, 12:41
	> в идеале должна быть возможность разработки модулей ядра на любых языках Напуркуа? Вы сами когда в последний раз модули ядра писали?
	Ответить | Правка | Наверх | Cообщить модератору

	64. "Проект BOSSMOOL развивает средства разработки драйверов ядра..."	+/–
	Сообщение от Аноним (-), 04-Окт-14, 16:06
	> возможность разработки модулей ядра на любых языках Ну и как в каком-нибудь бидоне будет выглядеть присвоение адресу 0x100500 значения 0xDEADBEEF? Допустим это memory mapped регистр что-то делающий с вон той железкой. Ну на си - народ прямо так и напишет. Потому что системный ЯП. А вот что будут делать гламурные мальчики-вебдванольчики с высокоуровневым ЯП - не очень понятно. Си используют для системных дел ... потому что он позволяет делать манипуляции, которые по другому только на ассемблере и сделаешь.
	Ответить | Правка | К родителю #39 | Наверх | Cообщить модератору

	75. "Проект BOSSMOOL развивает средства разработки драйверов ядра..."	+1 +/–
	Сообщение от angra (ok), 04-Окт-14, 19:22
	Хмм, да также как и в С - операция присваивания переменной(находящейся в памяти по этому адресу) константного значения. Или вы из тех, кто плодит говнокод, насыщенный магическими числами и копипастой?
	Ответить | Правка | Наверх | Cообщить модератору

	90. "Проект BOSSMOOL развивает средства разработки драйверов ядра..."	+/–
	Сообщение от Аноним (-), 05-Окт-14, 08:56
	> Хмм, да также как и в С - операция присваивания переменной(находящейся в > памяти по этому адресу) константного значения. Так в сях можно указать что вон та переменная - это вот тот адрес. > плодит гoвнокод, насыщенный магическими числами и копипастой? Весь код работы с периферией - куча магических чисел. Сюрприз. Правда культурные люди назначают им человекочитаемые определения, но сама по себе возможность сунуться в конкретный адрес памяти - фича сей, там указатели это просто адрес в памяти. Что и позволяет достаточно человекочитаемо работать с магическими адресами и магическими значениями в них. А в питонах и рубях такое изначально вообще не предусмотрено. Там нет никакого метода указать что "а вот эта переменная должна лежать по этому адресу". Да и вообще смысл высокоуровневого ЯП как раз в том чтобы програмер таким себе мозг не грел. Но это обрубает низкоуровневые возможности. По каким-то таким причинам все мало-мальски живые системы писаны на сях. Лучше за столько лет все-равно ничего не сделали.
	Ответить | Правка | Наверх | Cообщить модератору

	100. "Проект BOSSMOOL развивает средства разработки драйверов ядра..."	+/–
	Сообщение от Я (??), 05-Окт-14, 20:21
	>Лучше за столько лет все-равно ничего не сделали. http://en.m.wikipedia.org/wiki/Oberon_operating_system http://www.a2.ethz.ch/
	Ответить | Правка | Наверх | Cообщить модератору

	105. "Проект BOSSMOOL развивает средства разработки драйверов ядра..."	–1 +/–
	Сообщение от angra (ok), 06-Окт-14, 00:14
	> Весь код работы с периферией - куча магических чисел. Сюрприз. Нет, не сюрприз. Также как не сюрприз, что ты не знаешь значения термина "магические числа" в отношении патернов программирования. Правда культурные > А в питонах и рубях > такое изначально вообще не предусмотрено. Там нет никакого метода указать что > "а вот эта переменная должна лежать по этому адресу". Тебе буквально следующим постом показали как это сделать на питоне. Ниасилил многабукав? > вообще смысл высокоуровневого ЯП как раз в том чтобы програмер таким > себе мозг не грел. Но это обрубает низкоуровневые возможности. С какого перепугу добавление одной возможности обрубает другие? Скажи честно, что в Perl/Ruby/Python не разбираешься.
	Ответить | Правка | К родителю #90 | Наверх | Cообщить модератору

	110. "Проект BOSSMOOL развивает средства разработки драйверов ядра..."	–1 +/–
	Сообщение от Аноним (-), 06-Окт-14, 04:42
	> термина "магические числа" в отношении патернов программирования. Я его знаю в значении программирования периферии, в данном контексте этого достаточно. > Тебе буквально следующим постом показали как это сделать на питоне. Ниасилил многабукав? Действительно, показали - турбокостыль, с реверансом в сторону си. Если уж на то пошло - проще не выделываться и сразу на си писать. Там это симпатичнее выглядит как текст, не требует интерпретера на несколько мегов и вообще компилится в пару машинных команд. Понятно что при сильном желании закостылить можно все. А вон жабисты в ведроиде через JNI дергают нативный код. Только это геморрой на ровном месте неизвестно ради чего. > С какого перепугу добавление одной возможности обрубает другие? Скорее, такие возможности для высокоуровневых ЯП - как собаке пятая нога, т.к. высокоуровневые ЯП делаются чтобы уйти от низкоуровневых/платформоспецифичных деталей как раз и оперировать всякими высокоуровневыми абстракциями, не заморачиваясь техническими деталями. Если этого не получается - от высокоуровневого ЯП будет больше вреда чем пользы. > Скажи честно, что в Perl/Ruby/Python не разбираешься. Абсолютно. У меня нет задач под которые требовался бы этот крап -> нафига мне на них тратить время? А чтобы на этом писать операционки или системные тулзы - надо серьезно ушибиться, имхо.
	Ответить | Правка | Наверх | Cообщить модератору

	114. "Проект BOSSMOOL развивает средства разработки драйверов ядра..."	+/–
	Сообщение от Аноним (-), 06-Окт-14, 05:36
	> Тебе буквально следующим постом показали как это сделать на питоне. Ниасилил многабукав? >Действительно, показали - турбокостыль, с реверансом в сторону си. Если уж на то пошло - проще не выделываться и сразу на си писать. "Слив защитан!"(С)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 не разбираешься. > А чтобы на этом писать операционки или системные тулзы - надо серьезно ушибиться, имхо. ОС - лучше не надо, тут я с тобой союзен, а системные тулзы ... на них и пишут. Или давай определения о чём это ты? Ых, вот как то так :)
	Ответить | Правка | Наверх | Cообщить модератору

	138. "Проект BOSSMOOL развивает средства разработки драйверов ядра..."	+1 +/–
	Сообщение от Аноним (-), 06-Окт-14, 19:10
	> Это выглядит не симпатично и не понятно? А ты не дворник ли > случайно? А то мало ли ... Ну да, декларация в 3 раза длиннее чем на чистом си, бинарное значение загнать - почти в 2 раза больше дряни вокруг, с кавычками какими-то. А так все замечательно. Ну и нафига там нужен ваш питон, если работа с периферией в основном в чем-то таком и заключается? > Но ты же сам перешел на опрос датчиков \ управление светодиодами :) Я вроде вообще про датчики и светодиоды не говорил. Скорее про memory mapped периферию и то что вокруг - программирование оной в основном и состоит из кучи черной магии с засылкой магических значений и всяких там данных в разнообразные магические адреса. > бы сочинил С-ный модуль и говорил бы с ним из питона\ватэвэр_ю_дрчш_он > лангуаге :) Для мелочи, ну там светодиодами моргнуть - см. выше :) Не очень понимаю чего такое "большое" должно быть в работе с периферией. Это должно быть уже где-нибудь в прикладухах, etc. У питона к тому же дикие проблемы с скоростью работы. Так что такая "работа с периферией" будет весьма неторопливой если по пути попадется кусок питонятины. Там конечно есть всякие нестандартные урезки, рвущие зад чтобы это исправить, но в целом это больше похоже на борьбу с искусственными трудностями. А разучивать два наглухо разных ЯПа (что общего у си и питона?) - вообще извращение для утонченных ценителей. А еще - на сях можно оформить либу которую потом можно дергуть откуда угодно. И из питона, и из жабы и откуда там еще. А вот здоровый шмат на питоне - не реюзабелен ни для кого кроме любителей питона. Ну и с другими высокоуровневыми ЯП такая же фигня - биндиться друг к другу высокоуровневые ЯПы не умеют, что сильно снижает реюзабельность кода. > Ну напиши андрод апп на сях 8-) посмотрим что ты после _этого_ > начнёшь считать гиммороем и костылём :) Да вообще-то гугле игроделы мозг сгрызли (т.к. для них гимор и костыль - именно ява) и теперь там есть и native sdk. Просто черезж-пно и не очень совместимо с другими. Хотя игроделы c SDL и OpenGL не очень ругаются теперь - там почти без изменений уже. Но например портануть кутевую программу - уже гимор. Что-то такое и бывает когда случается rampant layering violation и базовые компоненты делают слишком высокоуровневыми. Так что фиг с два вы на вашем бидоне поюзаете гуй на жабе без каких-то сильно отдельно турбокостылей. А была б низкоуровневая часть виджетов на си или хотя-бы плюсах - ну вон GTK+ к куче всего биндится, да и куть тоже. > Всю твою религию низверг :) Теперь с куску памяти можно лезть > ч\з ... файловый дескриптор ... чуешь куда ветер дует ? :) Можно. И чего? А еще там сто лет как был доступ к всей памяти ядра через файл. Сто лет есть mmaped файлы, которые тоже "память как файл" и прочее. Только вот работа с памятью как файлом имеет кучу оговорок и программить так периферию мало какой псих захочет. А запилено это было под kdbus. Который сам по себе вообще не о работе с периферией и прочим. > Пока оно конечно неведомое нечто, на ведь допилят. Допилят до чего? Работать с памятью как файлом - достаточно утонченное извращение. А, гм, в чем "улучшение" когда мы ушли от работы с масссивом к работе с файлом? Это вообще ни разу не проще и имеет кучу особенностей. Периферия может быть чувствительна к таймингам и атомарности доступа, тогда как файлы изначально подразумевают произвольный доступ. Оформлять все это как файловые операции - уйма головняка на ровном месте. > ОС - лучше не надо, тут я с тобой союзен, а системные > тулзы ... на них и пишут. Или давай определения о чём это ты? Относительно низкоуровневая обвязка - системные утилиты, etc. То что на этом пишут всякую системную автоматизацию на 1 раз, где скорость пофиг, а руками еще дольше - да и фиг с ним. Плохо когда на таком пишут относительно фундаментальные и долговременные вещи типа пакетных менеджеров. У знакомого гентуйца система портажей отпадала потому что питон не тот. А у убунтуев на половине систем апгрейдер обcиpaется. По все той же причине. И вот это - плохо, да. Хотя апдейтер все-таки системная автоматизация на 1 раз, но все-равно не здорово что он отпадает - переключать репы руками вместо этой "автоматизации" - позор таким автоматизаторам, имхо.
	Ответить | Правка | Наверх | Cообщить модератору

	140. "Проект BOSSMOOL развивает средства разработки драйверов ядра..."	+/–
	Сообщение от angra (ok), 06-Окт-14, 20:05
	Пока ты совсем не ушел в мир фантазий напомню тебе с чего началось: >Ну и как в каком-нибудь бидоне будет выглядеть присвоение адресу 0x100500 значения 0xDEADBEEF? Тебе показали как, чего тебе еще? Если не можешь объяснить словами, то покажи свой вариант на С. А главное заметь, никто не говорил, что питон это хорошо для ядра, это ты сам выдумал и героически опровергаешь.
	Ответить | Правка | Наверх | Cообщить модератору

	181. "Проект BOSSMOOL развивает средства разработки драйверов ядра..."	+/–
	Сообщение от Аноним (-), 08-Окт-14, 07:00
	> покажи свой вариант на С. А я уже показал еще вариантик - переброс выполнения на фиксированный адрес. Что-то питонисты разбежались и отмазываются теперь, хотя мне было и правда интересно как указатель на функцию будет через такой костыль смотреться, и, главное, насколько сие потом еще и работать будет.
	Ответить | Правка | Наверх | Cообщить модератору

	79. "Проект BOSSMOOL развивает средства разработки драйверов ядра..."	+/–
	Сообщение от Аноним (-), 04-Окт-14, 20:50
	>> возможность разработки модулей ядра на любых языках Зачем это нужно? Чем голый С для этого плох?!?!? До он для этого _идеален_! > Ну и как в каком-нибудь бидоне будет выглядеть присвоение адресу 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 byte g[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.
	Ответить | Правка | К родителю #64 | Наверх | Cообщить модератору

43. "Проект BOSSMOOL развивает средства разработки драйверов ядра..."	+2 +/–
Сообщение от metallica (ok), 04-Окт-14, 12:39
Индусы понтарезы. ООП в линуксе уже давно в полный рост на благородном C. И посмотрел бы как они не POD объекты будут в строгую карту виртуального пространства, в которое линкуется ядро, интегрить.  Хотя, может какой фреймворк для ядра, для подключения и функционирования С++ модулей, развить и получится, но не более. Можно будет модули ядра вантузинтками в Вижукалл Cтудиё писать. Ключевое в ядре всегда будет на C.
Ответить | Правка | Наверх | Cообщить модератору

45. "Проект BOSSMOOL развивает средства разработки драйверов ядра..."	+1 +/–
Сообщение от Аноним (-), 04-Окт-14, 13:36
Вот что получается когда веб разработчиков нанять ядро разрабатывать. Лучше бы они деньги потратили на написание модулей к существующему ядру.
Ответить | Правка | Наверх | Cообщить модератору

	111. "Проект BOSSMOOL развивает средства разработки драйверов ядра..."	+/–
	Сообщение от Аноним (-), 06-Окт-14, 04:44
	> деньги потратили на написание модулей к существующему ядру. Не-не, не надо, что вы. На плюсах их код точно в майнлайн не возьмут, а если это будут сишные модули - они чего доброго смогут проскочить.
	Ответить | Правка | Наверх | Cообщить модератору

50. "Проект BOSSMOOL развивает средства разработки драйверов ядра..."	+/–
Сообщение от manster (ok), 04-Окт-14, 14:15
Плюсы, это ООП все-же. Там где ООП и другие язычки подтянутся. Вот только вопрос нужно ли это в ядре и будет ли это отзывчиво? Мне кажется, лучше развивать ядро и ближайшее окружение, а в ядре лишним абстракциям и сущностям, делать нечего...
Ответить | Правка | Наверх | Cообщить модератору

	52. "Проект BOSSMOOL развивает средства разработки драйверов ядра..."	+/–
	Сообщение от manster (ok), 04-Окт-14, 14:16
	Было-бы интересно и rust там увидеть...
	Ответить | Правка | Наверх | Cообщить модератору

51. "Проект BOSSMOOL развивает средства разработки драйверов ядра..."	+/–
Сообщение от vitalif (ok), 04-Окт-14, 14:16
Да они могут хоть уразвиваться. Сами напишут, сами поиграются, сами за**утся поддерживать и выкинут, а в апстрим хрен это чудо кто-то примет :)
Ответить | Правка | Наверх | Cообщить модератору

56. "Проект BOSSMOOL развивает средства разработки драйверов ядра..."	+2 +/–
Сообщение от Crazy Alex (ok), 04-Окт-14, 15:25
Весь этот хай - от непонимания. В вырожденном виде (без полиморфизма) плюсы - это просто пачка хороших немногословных (по сравнению с сями) интерфейсов со строгой типизацией вообще без потерь скорости работы. Ну да, чтобы так писать, мозг нужен. Но он, в общем-то, и вообще для программирования для ядра пригодится. А какой-нибудь USB,  с его кучей сущностей, на объектном языке куда удобнее писать, потому что сама спецификация, по сути, объектная. Плюс шаблоны в разумных количествах таки очень упрощают жизнь. Я тут пару раз постил ссылки на шаблонный код для AVR - который оптимизировался лучше, чем руками писанный ассемблер, и при этом давал простоту модификации. Оно да, ООП можно сделать и на сях. Но - многословно, обычно зависимо от кучи макросов и будет гораздо хуже обрабатываться разными статическими анализаторами.
Ответить | Правка | Наверх | Cообщить модератору

	58. "Проект BOSSMOOL развивает средства разработки драйверов ядра..."	+2 +/–
	Сообщение от metallica (ok), 04-Окт-14, 15:37
	>  это просто пачка хороших немногословных > (по сравнению с сями) интерфейсов со строгой типизацией вообще без потерь > скорости работы. Ну да, чтобы так писать, мозг нужен. О чём речь? О STL? линуксовые list_head, rb_node в составе всех структур и container_of- более производительное решение, чем эти дебильные STL контейнеры, с их инсертом копированием (вобще говоря && бесполезен для избежания копирований, такое прокатит только с объектами определённой структуры). А обобщение шаблонами  в ядре не нужно для 99% всех объектов, которые там существуют.
	Ответить | Правка | Наверх | Cообщить модератору

	118. "Проект BOSSMOOL развивает средства разработки драйверов ядра..."	+/–
	Сообщение от anonymous (??), 06-Окт-14, 08:56
	> А обобщение шаблонами  в ядре не нужно для 99% всех объектов, которые там существуют. Т.е. списков там на кождом углу нет, неупорядочныых контейнеров нет, FIFO нет, .... Замена списка на мап на красно-черных деревьях обошелся ядру в 2.5 года и несколько мегабайт правленного кода. "На попробовть" слишком сложно выходит.
	Ответить | Правка | Наверх | Cообщить модератору

	136. "Проект BOSSMOOL развивает средства разработки драйверов ядра..."	+/–
	Сообщение от dq0s4y71 (ok), 06-Окт-14, 18:58
	Чтобы ядро зависело не только от кривой реализации GCC, но и от кривой реализации списков, контейнеров и FIFO?
	Ответить | Правка | Наверх | Cообщить модератору

	65. "Проект BOSSMOOL развивает средства разработки драйверов ядра..."	+/–
	Сообщение от Аноним (-), 04-Окт-14, 16:09
	> В вырожденном виде (без полиморфизма) плюсы - это просто пачка хороших немногословных > (по сравнению с сями) интерфейсов со строгой типизацией вообще без потерь > скорости работы. Ну да, чтобы так писать, мозг нужен. Чтобы хорошо писать на плюсах - нужен мегамозг. А в ядре любой продолб обернется паникой или разрушением данных к тому же. Если крах игрушки с кодом на 10 метров мы переживем, то вот панику ядра... ну иди да юзай реактос, если тебе бсоды раз в 5 минут доставляют. Как раз последнее ядро на каком-то урезанном варианте плюсов.
	Ответить | Правка | К родителю #56 | Наверх | Cообщить модератору

	66. "Проект BOSSMOOL развивает средства разработки драйверов ядра..."	+/–
	Сообщение от metallica (ok), 04-Окт-14, 16:43
	> Чтобы хорошо писать на плюсах - нужен мегамозг. Первокурсники подтянулись. Вот когда избавитесь от необходимости слушать тот бред, который впаривают профессора (читай профессиональные делитанты) тщательно изучите стандарт C++ и C++ ABI, подумаете над сущностью тамошних конструкций и концепций, года два попишете на этом C++, тогда, когда повится зачатки этого мегамозга, поймёте, что C++-попса и уродливое изобретение праздных академиков и понтарезов, и все его концепции, явные синтаксические конструкции, обеспечивающие, якобы, неявные возможности увеличения производительности или надёжности и пр, есть просто набор костылей и подпорок, маскирующих кривой дизайн самого языка, и необходимых для того, чтоб на нём хоть что-то писать можно было. После этого будете как Алесандреску, твердить, что не знаете полностью C++, выпендриваться на праздных конференциях aka modern C++, а в реальных пректах писать околосишный С++-ый код aka С c классами, как здесь  https://github.com/facebook/folly/blob/master/folly/FBString.h
	Ответить | Правка | Наверх | Cообщить модератору

	96. "Проект BOSSMOOL развивает средства разработки драйверов ядра..."	+/–
	Сообщение от михалыч (ok), 05-Окт-14, 15:57
	да уж.. я знаю, что ничего не знаю (
	Ответить | Правка | Наверх | Cообщить модератору

	120. "Проект BOSSMOOL развивает средства разработки драйверов ядра..."	+3 +/–
	Сообщение от Аноним (-), 06-Окт-14, 11:41
	> В вырожденном виде (без полиморфизма) плюсы - это просто пачка хороших немногословных (по сравнению с сями) интерфейсов со строгой типизацией вообще без потерь скорости работы. полную херню несёшь. Типизации в плюсах не больше чем в си. Качество оптимизации плюсовго "сахара" очень сильно зависит от настроения и качества компилятора, стандарт разрешает вообще ничего не оптимизировать и не даёт никаких гарантий на zero cost своей 'немногословности'. Кост сишного кода практически всегда ясен и прозрачен. Ну и конечно же самое главное - плюсы не имеют ABI даже на самые тривиальные фичи. > Но - многословно, обычно зависимо от кучи макросов и будет гораздо хуже обрабатываться разными статическими анализаторами. тоже враньё. Многословность не влияет на качество статического анализа, на это влияет сложность семантики языка. А у плюсов на несколько порядков сложнее сишной даже если в си активно пользоваться макросами.
	Ответить | Правка | К родителю #56 | Наверх | Cообщить модератору

	134. "Проект BOSSMOOL развивает средства разработки драйверов ядра..."	+/–
	Сообщение от dq0s4y71 (ok), 06-Окт-14, 18:39
	> немногословных (по сравнению с сями) Щито?
	Ответить | Правка | К родителю #56 | Наверх | Cообщить модератору

71. "Проект BOSSMOOL развивает средства разработки драйверов ядра..."	–1 +/–
Сообщение от Аноним (-), 04-Окт-14, 18:06
Давайте внедрим в ядро boost library ?
Ответить | Правка | Наверх | Cообщить модератору

	80. "Проект BOSSMOOL развивает средства разработки драйверов ядра..."	+/–
	Сообщение от Аноним (-), 04-Окт-14, 20:56
	qtcore
	Ответить | Правка | Наверх | Cообщить модератору

	91. "Проект BOSSMOOL развивает средства разработки драйверов ядра..."	+/–
	Сообщение от Аноним (-), 05-Окт-14, 08:59
	> qtcore kdelibs :)
	Ответить | Правка | Наверх | Cообщить модератору

	94. "Проект BOSSMOOL развивает средства разработки драйверов ядра..."	–1 +/–
	Сообщение от Ан (??), 05-Окт-14, 12:25
	неактуально ныне
	Ответить | Правка | Наверх | Cообщить модератору

76. "Проект BOSSMOOL развивает средства разработки драйверов ядра..."	–3 +/–
Сообщение от Аноним (76), 04-Окт-14, 19:22
драйвера должны писаться исключительно на ассемблере. всё таки самый низкоуровневый доступ обеспечивают. а все эти промокашки высокого уровня, с тоннами мутных абстракций и зависимых модулей, только тормоза да утечки памяти плодят лишние.
Ответить | Правка | Наверх | Cообщить модератору

	81. "Проект BOSSMOOL развивает средства разработки драйверов ядра..."	+2 +/–
	Сообщение от тоже Аноним (ok), 04-Окт-14, 20:57
	Вы что-нибудь знаете про ассемблер, кроме того, что он, теоретически, самый-самый маленький и быстрый? А про причины тормозов и утечек памяти? А про поддержку драйверов и их использование для семейства устройств, а не для одного-единственного? Причем драйвера пишутся для первого, а для последующих, с заранее неизвестным функционалом, их придется вдумчиво переписывать... на ассемблере, ага.
	Ответить | Правка | Наверх | Cообщить модератору

	82. "Проект BOSSMOOL развивает средства разработки драйверов ядра..."	–2 +/–
	Сообщение от Аноним (-), 04-Окт-14, 21:01
	А что есть С? А высокоуровневый ассемблер и есть! :) Плюсф _тут_ не нужны. Ъ.
	Ответить | Правка | К родителю #76 | Наверх | Cообщить модератору

	83. "Проект BOSSMOOL развивает средства разработки драйверов ядра..."	+1 +/–
	Сообщение от metallica (ok), 04-Окт-14, 21:58
	> А что есть С? А высокоуровневый ассемблер и есть! Неправда. C-абстрактная машина, cостоящая, исключительно, из абстрактных сущностей и их отношений, описываемых соответствующим документом, называемым стандартом. Асм, по определению, независимо от разновидностей синтаксиса, определяется спекой на мнемоники набора инструкций конкретной arch.
	Ответить | Правка | Наверх | Cообщить модератору

	85. "Проект BOSSMOOL развивает средства разработки драйверов ядра..."	+/–
	Сообщение от pavlinux (ok), 04-Окт-14, 23:52
	> независимо от разновидностей синтаксиса, определяется спекой > на мнемоники набора инструкций конкретной arch. Фсё, приплыли, Java - ассемблер.
	Ответить | Правка | Наверх | Cообщить модератору

	86. "Проект BOSSMOOL развивает средства разработки драйверов ядра..."	–1 +/–
	Сообщение от angra (ok), 05-Окт-14, 06:13
	Только если каждая команда джавы порождает ровно одну инструкцию джава машины. То есть является мнемоникой для байткода. Я не знаю джаву, но весьма сомневаюсь, что дела в ней обстоят именно так.
	Ответить | Правка | Наверх | Cообщить модератору

	87. "Проект BOSSMOOL развивает средства разработки драйверов ядра..."	–2 +/–
	Сообщение от pavlinux (ok), 05-Окт-14, 07:00
	> Только если каждая команда джавы порождает ровно одну инструкцию джава машины. То есть, если написать, CMP AX, 0, а гадкий ассемблер  переделает это в  TEST AX, AX - значит это не ассемблер?  А SMP режиме, ваще ж..па. :)   Вы уж определитесь тут...
	Ответить | Правка | Наверх | Cообщить модератору

	106. "Проект BOSSMOOL развивает средства разработки драйверов ядра..."	–1 +/–
	Сообщение от angra (ok), 06-Окт-14, 00:17
	> То есть, если написать, CMP AX, 0, а гадкий ассемблер  переделает > это в  TEST AX, AX - значит это не ассемблер? Это уже оптимизации со стороны транслятора. Также как и макросы типа .IF к самому языку ни разу не относится.
	Ответить | Правка | Наверх | Cообщить модератору

	113. "Проект BOSSMOOL развивает средства разработки драйверов ядра..."	+/–
	Сообщение от Аноним (-), 06-Окт-14, 04:54
	> Асм, по определению, независимо от разновидностей синтаксиса, > определяется спекой на мнемоники набора инструкций конкретной arch. Попробуй код типа void _start(void) {         ((void (*)(void))0xffff0020)(); } выполнить на произвольной платформе :). Не забудь рассказать что получилось. Кстати да, питонисты, а покажите как это с вашим турбокостылем выглядит? :) С технической точки зрения это переход на адрес 0xffff0020 и выполнение того что там находится. Без знания этим кодом что там вообще за фигня :). Такой вот "платформонейтральный, типа" способ записать нечто типа JMP 0xffff0020. Насколько такая штука платформенно нейтральна - ну вы поняли, еще меньше чем ассемблер проца под который этот трюк делается, ибо подразумевает вообще конкретный SoC :)
	Ответить | Правка | К родителю #83 | Наверх | Cообщить модератору

	115. "Проект BOSSMOOL развивает средства разработки драйверов ядра..."	–3 +/–
	Сообщение от Аноним (-), 06-Окт-14, 05:42
	> Кстати да, питонисты, а покажите как это с вашим турбокостылем выглядит? :) Парень у тебя большие проблемы с головой. Ты таки закручиваешь гвозди и забиваешь шурупы.
	Ответить | Правка | Наверх | Cообщить модератору

	117. "Проект BOSSMOOL развивает средства разработки драйверов ядра..."	+1 +/–
	Сообщение от тоже Аноним (ok), 06-Окт-14, 08:47
	> Ты таки закручиваешь гвозди и забиваешь шурупы. Вам не приходила в голову жуткая мысль, что код молотка и отвертки выглядит примерно так?
	Ответить | Правка | Наверх | Cообщить модератору

	139. "Проект BOSSMOOL развивает средства разработки драйверов ядра..."	+/–
	Сообщение от Аноним (-), 06-Окт-14, 19:36
	> Парень у тебя большие проблемы с головой. Ты таки закручиваешь гвозди и > забиваешь шурупы. Во первых, это не я, а чуваки которые тулсы для allwinner'ов клепают. Во вторых, мне интересно посмотреть как сие выглядит, раз питонисты вещают что с доступом к памяти у них все шоколадно. Вот и покажите как вот такой сорт шоколада изобразить :). В сях доступ к памяти универсален и на предмет данных и на предмет выполнения.
	Ответить | Правка | К родителю #115 | Наверх | Cообщить модератору

	190. "Проект BOSSMOOL развивает средства разработки драйверов ядра..."	+/–
	Сообщение от pavlinux (ok), 12-Окт-14, 01:32
	>> Кстати да, питонисты, а покажите как это с вашим турбокостылем выглядит? :) > Парень у тебя большие проблемы с головой. Ты таки закручиваешь гвозди и > забиваешь шурупы. Если шуруп забить и провернуть на один оборот, будет тоже самое, только быстрее (см. PHP) Иль вы сайты на С++ пишете?
	Ответить | Правка | К родителю #115 | Наверх | Cообщить модератору

	95. "Проект BOSSMOOL развивает средства разработки драйверов ядра..."	+1 +/–
	Сообщение от Аноним (-), 05-Окт-14, 14:04
	>драйвера должны писаться исключительно на ассемблере Открываем linux-3.XX.YY/arch/ и считаем количество аппаратных архитектур (я 29 насчитал). И это не считая того, что внутри каждой архитектуры могут быть процессоры разных поколений, которые поддерживают или неподдерживают какие-то конкретные машинные инструкции. И что, для всех вариантов на ассемблере написать драйвер одного и того же устройства, например, для сетевухи?
	Ответить | Правка | К родителю #76 | Наверх | Cообщить модератору

99. "Проект BOSSMOOL развивает средства разработки драйверов ядра..."	+/–
Сообщение от Seyko (?), 05-Окт-14, 18:41
По теме: что там MOOL развивает? Скачать можно пример модуля hello_word и исходники ядра 2.6.23 с C++ include и runtime. Исходники правленные, patch нет. Никакая система на c++ не портирована. Хотя где-то упоминается, что есть портированный сетевой драйвер. Зачем в ядре RTTI и exceptions -- не ясно. Короче: или отсутствует дополнительная информация, или сообщение -- чистый вброс
Ответить | Правка | Наверх | Cообщить модератору

	125. "Проект BOSSMOOL развивает средства разработки драйверов ядра..."	+/–
	Сообщение от metallica (ok), 06-Окт-14, 12:41
	> Зачем в ядре RTTI и exceptions -- Понятно, что сначала нужно будет вcю libsupc++ писать специально для ядра. Представляю что будет, если индусы решат в новом ядерном _Unwind_RaiseExceptions дёргать INT X.
	Ответить | Правка | Наверх | Cообщить модератору

	129. "Проект BOSSMOOL развивает средства разработки драйверов ядра..."	+/–
	Сообщение от yet another anonymous (?), 06-Окт-14, 14:49
	> Представляю что будет, если индусы решат в новом ядерном _Unwind_RaiseExceptions дёргать INT X. Вы это сказали так, как будто сейчас в C-шной реализации нет ограничений на код в соответствующих обработчиках.
	Ответить | Правка | Наверх | Cообщить модератору

	147. "Проект BOSSMOOL развивает средства разработки драйверов ядра..."	–1 +/–
	Сообщение от anonymous (??), 07-Окт-14, 07:44
	> Зачем в ядре RTTI и exceptions -- не ясно. Да не будет их там. Логично задействовать метапрограммирование, классы и типизацию. А виртуальные функции использовать, наверное, не надо.
	Ответить | Правка | К родителю #99 | Наверх | Cообщить модератору

	150. "Проект BOSSMOOL развивает средства разработки драйверов..."	+2 +/–
	Сообщение от arisu (ok), 07-Окт-14, 09:10
	> Логично задействовать метапрограммирование, классы и типизацию. и жаль, что в с++ вместо всего этого неудобные костыли.
	Ответить | Правка | Наверх | Cообщить модератору

	155. "Проект BOSSMOOL развивает средства разработки драйверов..."	–1 +/–
	Сообщение от bOOster (?), 07-Окт-14, 11:19
	>> Логично задействовать метапрограммирование, классы и типизацию. > и жаль, что в с++ вместо всего этого неудобные костыли. Ты вообще знаешь что такое с++? Если у тебя не хватило серого вещества понять язык, то это не значит что там все плохо.
	Ответить | Правка | Наверх | Cообщить модератору

	157. "Проект BOSSMOOL развивает средства разработки драйверов..."	+/–
	Сообщение от arisu (ok), 07-Окт-14, 11:35
	> Ты вообще знаешь что такое с++? конечно: мерзкий набор неудобоваримых костылей и legacy. употребим только в малых дозах, с водкой или с таблетками от головной боли. > Если у тебя не хватило серого > вещества понять язык, то это не значит что там все плохо. видишь ли, дело в том, что ты-то тоже c++ не знаешь. его вообще не так много людей знают, потому что это куча гуано, рядом с которой дизайн даже не сидел. c++ — это отличный инструмент для того, чтобы сделать простые вещи сложными, а сложные — почти невозможными. и зачастую всё это с синтаксисом, глядя на который perl понимает, что ему ещё есть куда стремиться. конечно, в c++ не всё плохо: то, что страус взял у си — более-менее терпимо. остальное ужасно. особенно ужасны шаблоны, которые делались существами из параллельного мира, и делались для марсианских слизней. впрочем, фанбои уверены, что язык надо Превозмогать, что инструмент, который легко изучить и понять — не Ъ. но это личные проблемы фанбоев, я использую D и мне хорошо. товарищ Александреску тоже считает, что D лучше c++, можешь ему рассказать, что у него просто мозгов не хватило понять c++.
	Ответить | Правка | Наверх | Cообщить модератору

	158. "Проект BOSSMOOL развивает средства разработки драйверов..."	+/–
	Сообщение от тоже Аноним (ok), 07-Окт-14, 12:20
	Единственное противоречие в этой системе - то, что дорожки, ведущие от С++ к Жабе и Шарпу плотно протоптаны, а к D ведет какая-то заросшая тропа. Если он и лучше, и проще - почему? Признаться, у меня вообще "Александреску" и "проще" решительно не стыкуются...
	Ответить | Правка | Наверх | Cообщить модератору

	159. "Проект BOSSMOOL развивает средства разработки драйверов..."	+1 +/–
	Сообщение от arisu (ok), 07-Окт-14, 12:26
	> Единственное противоречие в этой системе - то, что дорожки, ведущие от С++ > к Жабе и Шарпу плотно протоптаны, а к D ведет какая-то > заросшая тропа. да, не любим дураков, есть такое. пусть дураки лучше в жабо-шарпо-плюсах кучкуются. > Если он и лучше, и проще - почему? Признаться, у меня вообще > "Александреску" и "проще" решительно не стыкуются... винда — лучшая ОС. улавливаешь связь?
	Ответить | Правка | Наверх | Cообщить модератору

	165. "Проект BOSSMOOL развивает средства разработки драйверов..."	–1 +/–
	Сообщение от тоже Аноним (ok), 07-Окт-14, 12:48
	D is for D'Artagnan?
	Ответить | Правка | Наверх | Cообщить модератору

	167. "Проект BOSSMOOL развивает средства разработки драйверов..."	+/–
	Сообщение от arisu (ok), 07-Окт-14, 12:53
	> D is for D'Artagnan? D is for «Mars», which was the planned name. alas, Mars is gone, only Phobos left.
	Ответить | Правка | Наверх | Cообщить модератору

	169. "Проект BOSSMOOL развивает средства разработки драйверов..."	–1 +/–
	Сообщение от yet another anonymous (?), 07-Окт-14, 14:05
	> D is for «Mars», which was the planned name. Mars Compilers --- не смогли сделать шаблоны в своем как-бы-плюсовом компиляторе (ну, и многое другое). Дабы скрыть свой epic fail, сыграли в альтернативного царя горы --- гораздо лучший и продвинутый язык D для настоящих ... Теперь аннонс: AAAAAAAAArisu! Нервных и впечатлительных просьба покинуть зал!
	Ответить | Правка | Наверх | Cообщить модератору

	172. "Проект BOSSMOOL развивает средства разработки драйверов..."	+1 +/–
	Сообщение от arisu (ok), 07-Окт-14, 17:53
	ты прекращай упарываться с начала недели. оно, конечно, никто всё равно не заметит, упоротый ты или с чистого ума чушь несёшь, но всё равно…
	Ответить | Правка | Наверх | Cообщить модератору

	182. "Проект BOSSMOOL развивает средства разработки драйверов..."	+/–
	Сообщение от Аноним (-), 08-Окт-14, 07:03
	> употребим только в малых дозах, Да ладно тебе, Кэп, на сях обычно как раз большие проекты наворачивают. Для мелких и просто сей хватает. А если кто плюсы юзанул - это обычно уйма кода и бинарь на пять мегов.
	Ответить | Правка | К родителю #157 | Наверх | Cообщить модератору

	184. "Проект BOSSMOOL развивает средства разработки драйверов..."	+/–
	Сообщение от arisu (ok), 08-Окт-14, 09:40
	> Да ладно тебе, Кэп, на сях обычно как раз большие проекты наворачивают. ну так при наличии достаточной мотивации и траншею детской лопаткой можно выкопать. я же не говорю, что не используют, я говорю, что это печальное зрелище. особенно когда какие-нибудь любители бустов вместе собираются — вообще гаси свет.
	Ответить | Правка | Наверх | Cообщить модератору

	185. "Проект BOSSMOOL развивает средства разработки драйверов..."	+/–
	Сообщение от arisu (ok), 08-Окт-14, 09:44
	> А если кто плюсы юзанул > - это обычно уйма кода и бинарь на пять мегов. совершенно необязательно, кстати сказать. бинари раздуваются от шаблонов — и с этим, увы, ничего не поделаешь. в D тоже бинари раздуваются, например. плата за универсальность кода. точнее, плата за быстрый и универсальный код. но никто не запрещает ни в c++, ни в D не использовать шаблоны, ограничиться структурами и классами. и будет код вполне маленький. собственно, D на bare metal как-то так и используют. ещё и runtime перетачивают, убирая оттуда всё ненужное. получается такой себе Better C.
	Ответить | Правка | К родителю #182 | Наверх | Cообщить модератору

	171. "Проект BOSSMOOL развивает средства разработки драйверов ядра..."	+/–
	Сообщение от dq0s4y71 (ok), 07-Окт-14, 15:13
	> Логично задействовать метапрограммирование, классы и типизацию. Классы там уже есть, где надо. Только за управление ими отвечает сам программист, а не компилятор, что для низкоуровневого системного программирования закономерно. Зачем там нужно метапрограммирование - не понимаю. Они операционку пишут, а не программу бухучёта, поэтому их код должен быть максимально управляем и предсказуем. Строгая типизация тоже не нужна. Они же с "железом" работают, которое о типах ничего не знает, поэтому преобразования типов там сплошь и рядом. Можно конечно усложнить жизнь программистам и заставить писать их вместо естественного (type)data заклинания типа reinterpret_cast<...>... > А виртуальные функции использовать, наверное, не надо. Ну, вот и получается, что если не использовать всё ненужное от С++, то писать надо на Си...
	Ответить | Правка | К родителю #147 | Наверх | Cообщить модератору

	173. "Проект BOSSMOOL развивает средства разработки драйверов ядра..."	–1 +/–
	Сообщение от yet another anonymous (?), 07-Окт-14, 19:40
	> Зачем там нужно метапрограммирование - не понимаю. Alexander Stepanov and Paul McJones / Elements of Programming [Addison-Wesley, 2009; ISBN-13 978-0-321-63537-2; ISBN-10 0-321-63537-X]
	Ответить | Правка | Наверх | Cообщить модератору

	176. "Проект BOSSMOOL развивает средства разработки драйверов..."	+1 +/–
	Сообщение от arisu (ok), 07-Окт-14, 19:58
	> Зачем там нужно метапрограммирование - не понимаю. большинство не понимает. потому что никакого метапрограммирования в «мэйнстримных» языках нет, культуры и практики его применения тоже. а жаль.
	Ответить | Правка | К родителю #171 | Наверх | Cообщить модератору

	178. "Проект BOSSMOOL развивает средства разработки драйверов ядра..."	–1 +/–
	Сообщение от Michael Shigorin (ok), 08-Окт-14, 04:22
	> Зачем там нужно метапрограммирование - не понимаю. Они операционку пишут, а не > программу бухучёта, поэтому их код должен быть максимально управляем и предсказуем. Любой код, начинающий местами напоминать самого себя, может быть улучшен при помощи метапрограммирования.  В том числе и по критерию сопровождаемости.
	Ответить | Правка | К родителю #171 | Наверх | Cообщить модератору

	186. "Проект BOSSMOOL развивает средства разработки драйверов ядра..."	–1 +/–
	Сообщение от dq0s4y71 (ok), 08-Окт-14, 12:34
	Да, а ещё Си не умеет динамических строк, эксепшенов и сборщика мусора. Очень бы пригодились в ядре :)
	Ответить | Правка | Наверх | Cообщить модератору

	187. "Проект BOSSMOOL развивает средства разработки драйверов..."	+1 +/–
	Сообщение от arisu (ok), 08-Окт-14, 13:04
	> Да, а ещё Си не умеет динамических строк, эксепшенов и сборщика мусора. > Очень бы пригодились в ядре :) конечно, пригодились бы. сборщик мусора вообще очень полезная штука, вместе с динамическими массивами и контролем диапазонов. Oberon всё это умел, и отлично работал на практике.
	Ответить | Правка | Наверх | Cообщить модератору

141. "Проект BOSSMOOL развивает средства разработки драйверов..."	+1 +/–
Сообщение от arisu (ok), 06-Окт-14, 23:18
хорошо, что это индийцы: их говнокод вскорости не сможет поддерживать никто, и в первую очередь они сами. после чего сабжевая мерзость тихо сыграет в ящик.
Ответить | Правка | Наверх | Cообщить модератору

174. "Проект BOSSMOOL развивает средства разработки драйверов ядра..."	+/–
Сообщение от Archer73 (ok), 07-Окт-14, 19:53
Как называется проблема ООП когда при малейшем изменении реализации класса-предка неожиданно ломается половина нормально работавших классов-потомков?
Ответить | Правка | Наверх | Cообщить модератору

	175. "Проект BOSSMOOL развивает средства разработки драйверов..."	+1 +/–
	Сообщение от arisu (ok), 07-Окт-14, 19:56
	> Как называется проблема ООП когда при малейшем изменении реализации класса-предка неожиданно > ломается половина нормально работавших классов-потомков? хреновая архитектура.
	Ответить | Правка | Наверх | Cообщить модератору

	199. "Проект BOSSMOOL развивает средства разработки драйверов ядра..."	+/–
	Сообщение от Аноним (195), 15-Янв-24, 13:04
	Для чего разработчику базовых классов дали protected и private? Учи матчасть.
	Ответить | Правка | К родителю #174 | Наверх | Cообщить модератору

177. "Проект BOSSMOOL развивает средства разработки драйверов ядра..."	+/–
Сообщение от Аноним (-), 07-Окт-14, 22:12
Давно пора. Понятно что весь ворох возможностей C++ по части исключений, rtti, множественного наследования, stl тащить не нужно, но на уровни C с классами его не использовать в XXI веке глупо, потому что код это генерит такой же как на C, но писать нужно в разы меньше, и в те же разы меньше вероятность ошибиться.
Ответить | Правка | Наверх | Cообщить модератору

188. "Проект BOSSMOOL развивает средства разработки драйверов ядра..."	–1 +/–
Сообщение от Дмитрий Т (?), 08-Окт-14, 13:35
Если уж браться программировать на С++, то только закончив медитировать над: Герб Саттер, Андрей Александреску, «Стандарты программирования на C++». Но насколько видел многие люди на С++ сначала пишут, а потом собирают шишки, но до чтения так и не доходят... Так как этот язык имеет обманчивую кажущуюся простоту, а внутри мало кем освоенную груду нюансов.
Ответить | Правка | Наверх | Cообщить модератору

189. "Проект BOSSMOOL развивает средства разработки драйверов ядра..."	+/–
Сообщение от Аноним (-), 10-Окт-14, 11:10
вообще с++ это не только ексепшены и если их отключать для ядра, получается хороший компактный код виндовый гуи win32.sys полностью на С++ как и многие ядреные модули
Ответить | Правка | Наверх | Cообщить модератору

	191. "Проект BOSSMOOL развивает средства разработки драйверов ядра..."	+/–
	Сообщение от iosys (?), 28-Ноя-14, 08:58
	Но всё же, почему бы и не написать ядро с парадигмой ООП? Определить класс ядра и методы к нему: class kernel { // private variables and functions public:     ctrl_memory();      // управление памятью     ctrl_processes();   // управление процессами     manager_drivers();  // интерфейс для драйверов     manager_hardware(); // интерфейс для работы с железом     // etc... }; что-то в таком роде)) Конечно же, это всё условно.
	Ответить | Правка | Наверх | Cообщить модератору

	192. "Проект BOSSMOOL развивает средства разработки драйверов..."	+/–
	Сообщение от arisu (ok), 28-Ноя-14, 09:00
	иди в гайку, там хорошо и классы.
	Ответить | Правка | Наверх | Cообщить модератору

	193. "Проект BOSSMOOL развивает средства разработки драйверов..."	+/–
	Сообщение от iosys (?), 28-Ноя-14, 09:05
	> иди в гайку, там хорошо и классы. что за гайка?
	Ответить | Правка | Наверх | Cообщить модератору

	194. "Проект BOSSMOOL развивает средства разработки драйверов..."	+/–
	Сообщение от arisu (ok), 28-Ноя-14, 09:11
	>> иди в гайку, там хорошо и классы. > что за гайка? Haiku, открытый наследник BeOS.
	Ответить | Правка | Наверх | Cообщить модератору

	200. "Проект BOSSMOOL развивает средства разработки драйверов..."	+/–
	Сообщение от Аноним (195), 15-Янв-24, 13:06
	Лицензия у ней некошерная.
	Ответить | Правка | К родителю #192 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема