J>>Это где же Александреску говорил, что его решения — для прикладного программирования??? J>>А если какие-то идиоты принимаются писать прикладной код в стиле библиотечного кода, а гуй — на асме, а драйвер — на вижуал-бейсике — так это их персональные половые проблемы.
E>Да и в "Моей Борьбе" ничего такого в целом ненаписано. Но идиоты нашлись и находятся до сих пор... Может таки не толкьо в идиотах дело?
Только в них. Сам по себе майн кампф не стал бы причиной концлагерей. Книга сама по себе не в состоянии изменить этот мир, она только одно из средств пропаганды и агитации.
AJD>>А зачем его туда тянуть если ядру уже 100 лет в обед и оно и так работает. Когда ядро начали разрабатывать разве были нормальные компиляторы с++? MSS>Ходят сплетни, что 2мерную графику в НТ строили cfrontом ftdisk и portcls — это намного позже уже, второй особенно.
А насколько этим сплетням можно доверять? И что понимается под "2мерную графику в НТ" — GDI?
Добавлю от себя — ссылка закрывает арифметику указателей. Что возлагает на компилятор контроль за тем что я могу случайно (при синтаксисе С/C++ это как два байта переслать) сделать инкремент указателя (а хотел — обьекта). Оччень приятная мелочь.
Здравствуйте, Left2, Вы писали:
L>Добавлю от себя — ссылка закрывает арифметику указателей. Что возлагает на компилятор контроль за тем что я могу случайно (при синтаксисе С/C++ это как два байта переслать) сделать инкремент указателя (а хотел — обьекта). Оччень приятная мелочь.
+1
И аналогично c присваиванием:
void f(int* p)
{
++p; // а хотели ++(*p)
p = 0; // а хотели (*p) = 0
}
void f(void** p)
{
void* l = p; // а хотели void* l = (*p)
}
Фактически получается, что передача объекта через указатель вводит второй, дополнительный объект — помимо самого значения, появляется ещё указатель на значение. В большинстве случаев этот дополнительный объект совершенно не нужен — т.е. мы не хотим производить с ним никаких действий, только использовать для обращения к самому значению. И при этом обращения к этим двум объектам записываются достаточно похоже. В случае с именем 'p' это ещё не так очевидно, а в случае с, например, contract_address и *contract_address ситуация становится значительно хуже, т.к. при чтении кода мозг фокусируется на семантике, т.е. елси я вижу contract_address, то я думаю о адресе контракта, не смотря на то, что это на самом деле накая деталь имплементации под названием указатель на адрес контракта.
Здравствуйте, Roman Odaisky, Вы писали:
КБ>>Сделано. Штука называется "wear leveling". Так что можете за флэшку не бояться.
RO>Хм, похоже, ты более прав, чем я. Хотя я до конца так и не понял. http://en.wikipedia.org/wiki/Flash_memory#Flash_file_systems.
Есть 2 разных подхода. Флешка может быть просто припаяна к системной шине. Тогда она выглядит как флешка — большие сектора, ограниченное количество циклов перезаписи и т.п. А может изображать из себя IDE disk. Тогда она и выглядит как IDE disk — сектора по 512 байт и т.п. Первый случай — обычная практика во всяких там embedded системах. Второй — это все эти флеш-брелки, а так же новая мода, ставить флешку вместо диска в нотебуки. В первом случае уместна jffs2, во втором можно использовать традиционную файловую систему.
Я не уверен, кстати, что jffs2 хорошо себя ведет на флешках размером в несколько гигабайт. Ее, все же, не для того проектировали.
Здравствуйте, Pzz, Вы писали:
TL>>Судя по ничтожной скорости создания-записи мелких файлов — таки да.
Pzz>Может это только в дешевых китайских флешках так? А в более приличных — по-человечески?
Трудно сказать — я в своей цифрофотографии пользуюсь "почти топовыми" SanDisk Extreme III — ситуациая аналогична. Но могу согласиться что эффект обусловнен контролером и интерфейсом USB и что если подключить флешку напрямую к IDE то скорость выровняется. Однако, насколько я знаю, это таки из-за того что флешка пишется своими строками, а не секторами файловой системы.
Здравствуйте, Left2, Вы писали:
L>Добавлю от себя — ссылка закрывает арифметику указателей. Что возлагает на компилятор контроль за тем что я могу случайно (при синтаксисе С/C++ это как два байта переслать) сделать инкремент указателя (а хотел — обьекта). Оччень приятная мелочь.
Инкремент объекта? =) У вас часто встречаются объекты поддерживающие инкремент?
Здравствуйте, Константин Б., Вы писали:
КБ>Инкремент объекта? =) У вас часто встречаются объекты поддерживающие инкремент?
Присваивание -- часто...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
> S>А никто и не предлагает интерфейсы плюсовые наружу выставлять... > > Т.е. вернулись к началу ветки — к плоским COM-подобным интерфейсам (по сути — таблица с указателями на функции).
Да меня собственно и сишный интерфейс вполне устраивает. Речь шла о том, что для реализации "потрохов" системы необязательно ограничиваться только С.
> Кроме того такое плоское апи уменьшает сцепление — оно не зависит даже от языка реализации интерфейса (это азы кома, вроде бы).
Это дает любое ABI, не обязательно COM. Вопрос только в реализуемости и сложности реализации данного ABI на других языках и разных трансляторах одного языка.
> С классическими монолитными ядрами вроде уже никто не работает — динамически подружаемые модули составляют существенную часть работающего ядра. Апи подсистем ядра для этих модулей должно быть плоское. Подсистемы ядра общаються между собой и тоже, в идеале, должны обладать плоским апи (вдруг мы захотим сменить ну, например, шедулятор ). Но темлейты не дают нам такой гибкости, точнее, темплейты завернутые в плоский апи теряют всю свою темплейтность.
Ну теряют, а в чем проблема то? Мы не можем из одного модуля выставить шаблон непонятно чего в другой модуль? А оно вообще надо? Зато для использования внутри своего модуля можно не кодировать каждый раз какой-нибудь хэшмэп и не пользоваться голимым void*.
> Попробуйте придумать/написать плоскую обертку для stl — получиться что-то вроде at&tшной сdt (с кучей указателей на функции и void * в качестве контейнерного элемента).
Ну и? Смысл этого действия в чем?
> Плоский апи — это границы применения темплейтов, также граница использования исключений, множественного наследование, rtti и прочих особенностей с++. Вроде бы сразу появляеться антипример — сильно-теплейтная АТЛ для плоского COM вполне существует и является вобщем state-of-art библиотекой. Но вот тут и возникает отличие — реализуя в коме свой IStream, вы одновременно реализуете свой ISequentialStream и свой IUnknown. Однако в ядре вы, реализуя свой IStream, должны использовать предоставленный системой ISequentialStream которой в свою очередь будет использовать предоставляемый системой IUnknown (это аналогия, не буквально).
Ну, а проблема-то в чем?
> Допустим я пишу свой драйвер для сетевого юсб-девайса. Я должен предоставить интерфейс outputPacket(const void * raw, size_t size), зарегить его в системе и получить от системы интерфейс для юсб. В методе я заполняю USBPacket и вызваю у юсб-интерфейса метод usbSendCommand(USBPacket somePacket). Все. Тут (в заполнении структуры USBCommand) негде разгуляться всем фичам с++.
Ну раз негде — не используй их, в чем проблема-то? А вот если этот USB-device представляет из себя убогий юсб винмодем, то там наверное еще кучу всякой фигни посчитать придется...
> Кратко: > 1) современное ядро ос не монолитно и представляет собой большое количество модулей, причем часть модулей подгружаеться/выгружаеться в рантайме.
да. Разумеется, писать на С++ монолитный софт гораздо приятнее. Однако и в случае жесткой разбивки на тонкие уровни С++ все равно удобнее С.
> 2) модули выполняют какую-то одну относительно несложную задачу.
одну — да, несложную — нет. Поскольку вряд ли можно считать несложной задачей рендеринг или ЦОС.
> 3) для выполнения каких-то запросов эти модули выстраиваются в стек и разные уровни стека между собой общаются на плоском апи.
да.
> В результате размеры и сложность этих модулей становятся небольшими, их внешние интерфесы — плоскими.
размеры и сложность — нет (все таки 5 миллионов строк кода, пусть и побитые на большое количество модулей), внешние интерфесы — да.
> А это ведет к тому что в ядре > 1) не подходит тот шаблонный подход к проектированию, который используеться для билиотек типа стл, атл, буста.
Фишка в том, что библиотеки и софт, который их использует, вообще проектируются (должны, по крайней мере) по-разному. Поэтому лично я считаю, что тут более уместно разделение библиотека/код, который ее использует, а ядро это или там гуи — дело десятое.
> 2) полноценный с++ оказываеться просто не нужен, и полное его использование приводит к овердизайну.
Полное использование — это "чтоб було"? Разумеется, так не надо делать.
> Хотя принципиально никто не мешает использовать туже стл в ядре. Но вобщем никто и не мешает написать само ядро на пэ-ха-пэ или луа, у них есть даже одно преимущество перед с++ — сборка мусора
Вот насчет gc в ядре у меня есть большие сомнения... Ну да посмотрим, что у MS с их сингулярити получится.
> S>В бусте то ли уже появились, то ли вот-вот будут. А пока широко распространенных нету — и самому недолго написать. > Я понял — известных реализаций типа queue.h нет. Ну на нет и суда нет, хотя отелось бы посмотреть как это будет выглядеть в темплейтах с++.
Известные реализации есть. Нет широко распространенных. Посмотреть, как оно выглядит на С++, можно здесь: http://svn.boost.org/trac/boost/browser/trunk/boost/intrusive
> S>Ситуация тут ровно та же, что и с макросами. И даже если все "руками написать", то — сюрприз — все равно две копии кода будут Так что в качестве аргумента против шаблонов — не катит. > тут не макросы vs шаблоны, а "шаблонный" подход к проектированию vs плоский комоподобный апи.
Что такое собственно "шаблонный подход к проектированию"? Такого термина я не встречал.
> А макросы против шаблонов почти всегда не катят — это очевидно.
Не всем
> S>С чего бы это система контроля версий вдруг стала system-level? > Требование к софту программеров и не_программеров разные (правда общий момент есть — чтобы работало и не глючило ). Поэтому ядро, службы/демоны, средства разработки — все то, что не решает проблемы пользователя-не_программиста я отношу к system-level. Возможно у меня сильно шырокое определение system-level , спорить не буду.
Да уж широковато, на мой взгляд.
> S>Лень мне по их исходникам лазить... А без изучения — какое может быть сравнение? Да и квалификацию писателей все равно не учтешь. > Да одинаковые у них квалификации,
Вообще-то квалификации ядрописателей линукса очень высокая. А вот кто писал monotone — не очень понятно. Может студенты, может "средние" программисты.
> все системы одинаково часто сравниваються во всяких обзорах и обладают примерно одинаковой функциональностью (и багами).
Допустим.
> Неужели вы верите в с++гениев недооцененных серой толпой голо-cишных-питон-программеров .
Ни в коем случае. Просто весьма вероятно, что примерно одинаковые системы написали сишные суперзвезды и серая толпа плюсовых кодеров.
Posted via RSDN NNTP Server 2.1 beta
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Здравствуйте, Erop, Вы писали:
E>Здравствуйте, jazzer, Вы писали:
J>>Это где же Александреску говорил, что его решения — для прикладного программирования??? J>>А если какие-то идиоты принимаются писать прикладной код в стиле библиотечного кода, а гуй — на асме, а драйвер — на вижуал-бейсике — так это их персональные половые проблемы.
E>Да и в "Моей Борьбе" ничего такого в целом ненаписано. Но идиоты нашлись и находятся до сих пор... Может таки не толкьо в идиотах дело?
Это, батенька, закон Мерфи: "Какой бы исчерпывающей ни была инструкция, всегда найдется идиот, который сделает все наоборот и при этом будет утверждать, что в инструкции все именно так и написано".
Здравствуйте, Erop, Вы писали:
E>Здравствуйте, The Lex, Вы писали:
TL>>Лично я пока что не вижу чем Сам Линус может мне помочь в моей лично скромной жизни. Копаться в ядре линукса я не буду — что лично мне Линус еще может предложить? А полезного лично для меня?
E>Ну он начал и до какой-то степени довёл довольно сложный проект и как архитектор и как программист и как администратор и как тимлидер. Это очень большой и однозначно успешный практически опыт.
E>Вот поэтому к его рассуждениям и имеет смысл прислушиваться. Ну чисто чтобы на чужом опыте учиться...
Ты не озвучишь его опыт ведения проектов на С++?
Он ведь именно о С++ изволит говорить, а я вот не помню, чтоб он вообще на С++ серьезно писал, не говоря уже о руководстве С++-проектами.
Здравствуйте, Ka3a4oK, Вы писали:
AA>>Нет силы разрушительной страшнее, AA>>Чем кода стиль "Я-Прочитал-Александреску"...
KK>Буст не в таком ли стиле написан ?
нет
Здравствуйте, jazzer, Вы писали:
J>Ты не озвучишь его опыт ведения проектов на С++? J>Он ведь именно о С++ изволит говорить, а я вот не помню, чтоб он вообще на С++ серьезно писал, не говоря уже о руководстве С++-проектами.
Он говорит о том, чем ему не нравится С++ применительно к большому и сложному софтверному проекту. Возможно, конечно, он С++ не знает, но ты-то может быть и знаешь. Так что можешь оценить его аргументацию. Только не в стиле "он дурак, и С++ не знает", а в стиле "вот чувак имеет такие-то опасения. Что я сделаю в своём С++ проекте, чтобы его опасения не стали правдой?"
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, jazzer, Вы писали:
J>Ну т.е. Торвальдс — это менеджер. Чего он полез с менеджерской
колокольни судить о языке, которого он не знает — не очень понятно.
Нет, Торвальдс — очень хороший программист. Но! Он системный
программист, часто работающий на уровне ассемблера (он писал, что GDB в
качестве дизассемблера чаще всего использует).
Cyberax пишет:
C> В результате — у него стандартная болезнь системщиков. Т.е. неприятие
чего-либо кроме С.
C> Sapienti sat!
Чего только не приплетут, и Линус больной системщик, и менеджер, и
колокольня у него уже не та. Что угодно, лишь бы не слышать
нежелательную информацию.
Здравствуйте, OCTAGRAM, Вы писали:
OCT>Чего только не приплетут, и Линус больной системщик, и менеджер, и OCT>колокольня у него уже не та. Что угодно, лишь бы не слышать OCT>нежелательную информацию.
А поконкретнее? Можно рациональные нежелательные аргументы?
Cyberax пишет:
> OCT>Чего только не приплетут, и Линус больной системщик, и менеджер, и > OCT>колокольня у него уже не та. Что угодно, лишь бы не слышать > OCT>нежелательную информацию. > А поконкретнее? Можно рациональные нежелательные аргументы?
Тема перетёрта на сто раз. Было бы желание искать, всё в нете есть.
Нужны аргументы — пожалуйста. FQA Lite, например. http://yosefk.com/c++fqa/
Нужны люди с C++ прошлым — пожалуйста. Martin Krischik, например. Далеко
не единственный.
Нужны ответы на вопросы — наверняка, вы не первый, кто их задал, и они
уже отвечены. Да и сами вопросы достаточно предсказуемы. На http://groups.google.com/group/comp.lang.ada были неплохие дискуссии
года два-три назад.
Много хорошие цитат было собрано в http://www.cs.kuleuven.ac.be/~dirk/quotes.html#PL
Здравствуйте, OCTAGRAM, Вы писали:
OCT>Тема перетёрта на сто раз. Было бы желание искать, всё в нете есть. OCT>Нужны аргументы — пожалуйста. FQA Lite, например. OCT>http://yosefk.com/c++fqa/
Это FUD Lite. Сразу наткнулся:
[11.2] What's the order that local objects are destructed?
FAQ: In reverse order of construction — the stuff declared last is destroyed first.
FQA: Which makes sense, but are you sure you want to write code that depends on this?
[11.3] What's the order that objects in an array are destructed?
FAQ: In reverse order of construction — the last element is destroyed first.
FQA: Which sort of makes sense, but you surely don't want to write code that depends on that one, do you?
Мда. И такого там еще полная куча.
Правильная критика, конечно, есть — но почему-то не приводится как это лучше делать в чистом С.
OCT>Нужны люди с C++ прошлым — пожалуйста. Martin Krischik, например. Далеко OCT>не единственный.
И?
OCT>Нужны ответы на вопросы — наверняка, вы не первый, кто их задал, и они OCT>уже отвечены. Да и сами вопросы достаточно предсказуемы.
Именно, не вопросы, а FUD со стороны С++ haters.
OCT>http://groups.google.com/group/comp.lang.ada были неплохие дискуссии OCT>года два-три назад.
Мда. Еще и ADA не хватало.
OCT>Много хорошие цитат было собрано в OCT>http://www.cs.kuleuven.ac.be/~dirk/quotes.html#PL OCT>На эту тему уже трудно сказать что-то новое.
Правильно. Нефиг FUD распространять.
dupamid пишет: > Это просто раздувание еще одной священной войны. Что касается критики > С++ то язык не без грехов, *но* во-первых часть этих грехов была > унаследована от горячо любимого Линусом С, а во-вторых реально лучших > альтернатив нет.
Ада? > и если она действительно будет так хороша люди на нее перейдут.
Наиииивный. В IT мире другие законы. Большинство равняется на
большинство, создавая положительную обратную связь. Управляется это
большинство в большей степени деньгами и маркетингом, нежели здравым
смыслом. Любая нелепость может стать обыденностью. Об алгоритмах и
программах <http://is.ifmo.ru/reflections/algorithms/> :
> Если говорить о промышленной разработке корпоративных систем, то > индустрия уже давно топчется на месте. Ситуация с постоянным выпуском > новых версий, появлением платформ и сред больше напоминает шоу-бизнес, > чем серьезную вдумчивую работу. В результате мы имеем кучу красивых > разноцветных кирпичей, из которых можно построить все что угодно, > кроме дома, для построения которого мы их собственно и покупали.
> Еще могу добавить, что подавляющее большинство критиков С++ его > банально плохо знают и не понимают почему он устроен так сложно, т.е. > критика С++ сводиться к тому, что язык слишком сложен, я его не > понимаю и не понимаю код, который пишут другие — поэтому С++ плох. > Плохой код можно писать на любом языке, так же как и хороший.
Да, но это не оправдание для тех остальных, кто C++ знает хорошо.
