Здравствуйте, vdimas, Вы писали:
V>Проблемы скорее оформительского плана: V>
V>using (MyRAII1 r1 = new MyRAII1())
V> using (MyRAII2 r2 = new MyRAII2())
V> using (MyRAII3 r3 = new MyRAII3())
V> using (MyRAII4 r4 = new MyRAII4()) {
V> ...
V> ...
V> }
V>
V>Даже в таком написании глаз не то чтобы радовал...
Ты бы хоть ради хомхмы прежде чем излагать свои теории на людях зашел бы в студию и попробовал написать этот код в ней. Она бы тебе сразу отформатировала код следующим образом:
using (MyRAII1 r1 = new MyRAII1())
using (MyRAII2 r2 = new MyRAII2())
using (MyRAII3 r3 = new MyRAII3())
using (MyRAII4 r4 = new MyRAII4())
{
...
...
}
On Tue, 15 Nov 2005 18:41:01 -0600, VladD2 <73@users.rsdn.ru> wrote:
> Здравствуйте, vdimas, Вы писали: > > V>Проблемы скорее оформительского плана: > V>
> V>using (MyRAII1 r1 = new MyRAII1())
> V> using (MyRAII2 r2 = new MyRAII2())
> V> using (MyRAII3 r3 = new MyRAII3())
> V> using (MyRAII4 r4 = new MyRAII4()) {
> V> ...
> V> ...
> V> }
> V>
> V>Даже в таком написании глаз не то чтобы радовал... > > Ты бы хоть ради хомхмы прежде чем излагать свои теории на людях зашел бы в студию и попробовал написать этот код в ней. Она бы тебе сразу отформатировала код следующим образом: >
> using (MyRAII1 r1 = new MyRAII1())
> using (MyRAII2 r2 = new MyRAII2())
> using (MyRAII3 r3 = new MyRAII3())
> using (MyRAII4 r4 = new MyRAII4())
> {
> ...
> ...
> }
>
> И никаких проблем. > > Собственно налог на плюсах будет примерно такой: >
Здравствуйте, sch, Вы писали:
sch>Соответственно, больше всего пугает самое новое и необычное: например, чаще всего у C++ программистов нарекания вызывает GC из .NET. Боже мой, он будет лазить по моим структурам когда ему захочется, и будет освобождать память! sch>Сам!
Это всё звучит очень складно и умно — простота, новые принципы кодирования и т.п.
На одной конференции мой коллега задал вопрос проповедникам из Microsoft:
"Как защитить код на шарпе от декомпиляции?"
На что получил ответ:
"Напишите в шестой студии DLL, которая будет хранить в себе весь код, нуждающийся в защите"
И это, повторяю, сказал представитель Microsoft.
С++ весьма вольный язык, понятное дело. Именно из-за этого при разработке некоего проекта необходимо установить стандарт на решение типовых низкоуровневых задач.
Например:
— смарт поинтеры используем только такие-то и такие-то (как правило один интрузивный, один неинтрузивный и один авто)
— запрещается помещение результата операции new в голый указатель, кроме случаев, где этот указатель является закрытым членом типа, но в любом случае рекомендуется делать эти указатели в виде смарт-поинтеров.
— при разработке проколов взаимодействия объектов четко специфицировать отношение владения/использования. Граф зависимостей, отображающий отношение владения может быть только однонаправленным.
— специфицируются либы и способы их использования, скажем, для обратных вызовов используется такая-то либа (сейчас буст популярен), для строк и прочих агрегатов — такая-то (обычно STL, но порой коряво сопрягается в MFC/ATL проектах, проще использовать их... Под эти строки/коллекции иногда пишут свои специализации как бинд на алгоритмы STL
Т.е. задача подобных низкоуровневых стандартов кодирования — это единообразное решение, которое не должен изобретать каждый программист в собственных кусках кода.
Ну и плюс надо знать особенности С++ и не пытаться, например, выкидывать исключения в деструкторе.
Скажу честно, что и я уже очень давно не помню проблем с утечками или падениями. Использование всяких auto_value, смарт-поинтеров, заведомо надежных библиотек и просто стандартной библиотеки, во первых, делает код ГОРАЗДО короче, во вторых, настолько же безопаснее. Свой код надо складывать из заведомо надежных и отработанных кирпичиков.
Разумеется, бывают места, где приходится поупражняться с битами. Но, во первых, этих мест в реальных проектах очень мало (маленький % по отношению к остальному коду), во вторых, эти места обычно тщательно изолируют от прямого использования.
Если С++ команда работает без четких выработанных внутренних стандартов, то естественно, проблемы могут возникать у кого угодно, и "сверестественный" проффесионализм здесь не при чем. Профессионализм должен проявляться в организации своего труда, в первую очередь, остальное — во многом лишь следствие.
vdimas,
LCR>>А что собственно "бррр"? И тем более чем не угодил первый вариант? И наконец, может есть третий вариант, который лучше их обоих?
V>В синтаксисе using не учтена возможность использования нескольких ресурсов на одном и том же уровне вложенности. И, если честно, то мне даже трудно представить себе последовательность раскрутки стека, даже в случае наличия такого синтаксиса, если при создании одного из ресурсов произошла исключительная ситуация. Эту ситуацию в C# описывают ручками и городят уровни вложенности там, где логически они не нужны.
Раскрутка такая же как при вложенных {try — catch — finally}'ах.
Один уровень вложенности вместо четырёх — not a big deal, гораздо важнее ограничение области видимости, а оно есть в обоих вариантах.
По сравнению со вложенными {try — catch — finally} using выглядит симпатичнее, вот я и удивился.
Здравствуйте, VladD2, Вы писали:
VD>А какая разница? Я не призивал использовать Сингулярити для создания копрпоротивных веб-порталов. Я просто заметил, что есть таки вполне разумные люди — ученые, которые пишут драйверы на C#. Пускай это пока что игрушка ученых, но идея эта уже далеко не бредовая.
Не ученых, а инженеров. Да, кстати, чем, по твоему, драйвер отличается от обычной программы? (раз их разработку на C# могут делать только ученые )
Я могу ответить — чем. Непосредственным обращением к аппаратуре. Что есть непосредственное обращение к аппаратуре? Это запись/чтение в память, общение с портами ввода/вывода (что можно рассматривать как частный случай обращения к немного другой памяти), а так же реакция на прерывания.
Может программа на C# непосредственно обращаться к портам ввода/вывода? или по фиксированным адресам памяти? Или настраивать внутренние регистры процессора на новые карты отображения виртуальных устройств ввода/вывода? НЕТ. И никогда не сможет by design. Очевидно, надо на ASM/C/C++ написать требуемый функционал, и приподнести его "на блюдечке" управляемой среде в виде простых интерфейсов. Реально это? Вполне. Разработка "научная"? гх-гхх
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>А зачем мусор в правой части?
Это что, незаконный синтаксис для С++? Код в общем-то условный. Ты же не думашь, что объекты пасущие ресурсы будут получать информацию телепатически. В рельном коде там будет еще немало инициализирующего кода.
ПК> И зачем скобки после r4?
Иначе код будет не идеттичным. Обаласть видимости юсиноа именно такая. Без скобок она будет слишком широкой.
ПК>Плюс, если автор пишет короткими функциями, окружающие скобки скорее всего будут скобками функции, содержащей данный код.
И в юсинге их не будет.
Более того. Лично у меня вообще юсингов не так много в коде. Многие из них скрыты в библиотеках или других оператороах. Например, foreach тоже делает using если у итератора реализован IDisposable.
PS
В общем, это довольно несерьезное обсуждение. Надо очень долго и упорно заниматься аутотренингом, чтобы поверить в то, что ручное управление памятью не приводит к усложнению программ и увеличению ошибок. В то же время упраление внешними ресурсами таких проблем не дает.
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, kliff, Вы писали:
K>Тебя наверное сильно задел такой фанатик)
Если бы это был один человек, то я бы и усом не повел. Но это какое-то групповое безумие. С завидной периодичностью на форумах появляется новый орел который делает много смелых заявлений ничего не имеющих с дествительностью. Многие потом еще начинают кричать, что им что-то навязывают. Хотя спорить с ними начали исключительно по причине того, что они несли полную чушь.
K> Кстати ты чем-то похож на него, без обид только.
Я надеюсь, что это только поверхностная схожесть, так как свой выбор делаю на базе фактов, а не на базе мифов и аутотренинга.
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, vdimas, Вы писали:
VD>>А какая разница? Я не призивал использовать Сингулярити для создания копрпоротивных веб-порталов. Я просто заметил, что есть таки вполне разумные люди — ученые, которые пишут драйверы на C#. Пускай это пока что игрушка ученых, но идея эта уже далеко не бредовая.
V>Не ученых, а инженеров.
У тебя уже пунктик на инженерах выработался.
Именно ученых. Я бы даже сказал исследователях.
V> Да, кстати, чем, по твоему, драйвер отличается от обычной программы? (раз их разработку на C# могут делать только ученые )
Я вот никак понять не могу, что тебя все время тенят на искажение чужих слов и вообще на демагогию?
Где сказано, что "их разработку на C# могут делать только ученые"?
По-моему вопрос кто и что делает для этой ОС очевиден и обсуждения не требует.
V>Я могу ответить — чем. Непосредственным обращением к аппаратуре. Что есть непосредственное обращение к аппаратуре? Это запись/чтение в память, общение с портами ввода/вывода (что можно рассматривать как частный случай обращения к немного другой памяти), а так же реакция на прерывания.
Почитай про микроядерную архитектуру. Глядишь твое мнение о том, что должен делать драйвер и изменится.
Задача драйвера устройсва — взаимодействовать с устройством на низком уровне обеспечивая высокоуровневый протокол для ОС и прикладных программ. При этом нет реальной необходимости непосредственно обращаться к аппаратуре и делать все остальное перечисленное тобой. Все обращения к портам и т.п. можно скрыть за очень небольшим по объему HAL-ом который будет выглядеть для драйвера как некое универсальное АПИ.
Что же касается о невозможности обращаться к адресам памяти на C#, то это скорее говорит о товем знании C# нежели о его ограничениях.
V>Может программа на C# непосредственно обращаться к портам ввода/вывода? или по фиксированным адресам памяти? Или настраивать внутренние регистры процессора на новые карты отображения виртуальных устройств ввода/вывода? НЕТ. И никогда не сможет by design. Очевидно, надо на ASM/C/C++ написать требуемый функционал, и приподнести его "на блюдечке" управляемой среде в виде простых интерфейсов. Реально это? Вполне. Разработка "научная"? гх-гхх
По твоим словам получается разработчики Сингулярити нагло врут утверждая, что драйверы устройств написаны на C# без использования опасного кода. Но я почему-то скронен верить именно им, а не тебе.
Что касается научности, то опять таки мнение гордого инжинера тут вряд ли окажется весомым. Цели исследований описаны на сайте проекта. То что эти цели счтены научными сомнений не вызвает, так как занимаются этим люди из университетов.
Ты же, как всегда, с целью облить что-то неугодное тебе грязью выцепляшь из контекста какие-то одтельные веши и пыташся их "разоблочить". Зачем? Я не знаю. Но цедь явно не добрая.
ЗЫ
В общем, почитай про миноядерную архитектуру и идею HAL. Тогда возможно разговор на эту тему у нас и получится.
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Просто если принять как данность, что кодирование на голом с++ — вещь неправильная, то следующий логичный шаг — использовать язык/среду, в которой соответствующие проблемы были устранены изначально.
Раньше особого выбора просто не было. Теперь есть.
Я имел в виду, что помогать другим — не главная моя цель. Я, в общем-то, эгоист. Соответственно, даже наверняка зная, что кто-то не прав — переубеждать через силу я не буду.
Здравствуйте, VladD2, Вы писали:
V>>Не ученых, а инженеров.
VD>У тебя уже пунктик на инженерах выработался.
Да нет, это у кого-то просто уже крышу сносит на управляемых средах. В чем проявляется "ученость" исследований в данном случае?
VD>Именно ученых. Я бы даже сказал исследователях.
Да, и что исследуем? Вроде же можно пойти почитать про микроядерную архитектуру? Любой экперимент — априори исследование. Дык, я тогда тоже ученый. Где гипотезы, выкладки, расчеты и доказательства? Нету? то-то и оно... Доказывать нечего, надо "брать и делать". Инженерная разработка чистой воды.
VD>По-моему вопрос кто и что делает для этой ОС очевиден и обсуждения не требует.
VD>Почитай про микроядерную архитектуру. Глядишь твое мнение о том, что должен делать драйвер и изменится.
А если нет? Или существует только микроядерная архитектура?
VD>Задача драйвера устройсва — взаимодействовать с устройством на низком уровне обеспечивая высокоуровневый протокол для ОС и прикладных программ. При этом нет реальной необходимости непосредственно обращаться к аппаратуре и делать все остальное перечисленное тобой. Все обращения к портам и т.п. можно скрыть за очень небольшим по объему HAL-ом который будет выглядеть для драйвера как некое универсальное АПИ.
Это ты споришь или соглашаешься? вот из моего предыдущего поста: VD>Очевидно, надо на ASM/C/C++ написать требуемый функционал, и приподнести его "на блюдечке" управляемой среде в виде простых интерфейсов.
Понимаешь, HAL она такая штука, что ее границы можно выбирать произвольно. Если сделать высокий уровень абстракций, то львиная доля кода перекочует в тот самый unmanaged, и блоки HAL под конкретные модели конкретных железяк в все так же будут разрабатывать вне C#.
Поэтому понятие "драйвер на C#" требует нового осмысления .
VD>Что же касается о невозможности обращаться к адресам памяти на C#, то это скорее говорит о товем знании C# нежели о его ограничениях.
Если ты про unsafe, то они же ведь собрались его постепено выкинуть, именно начиная с этой ОС, т.к. необходимость пропадет. И к портам все-равно невозможно обращаться. А при наличии HAL — и к памяти можно не обращаться.
V>>Может программа на C# непосредственно обращаться к портам ввода/вывода? или по фиксированным адресам памяти? Или настраивать внутренние регистры процессора на новые карты отображения виртуальных устройств ввода/вывода? НЕТ. И никогда не сможет by design. Реально это? Вполне. Разработка "научная"? гх-гхх
VD>По твоим словам получается разработчики Сингулярити нагло врут утверждая, что драйверы устройств написаны на C# без использования опасного кода. Но я почему-то скронен верить именно им, а не тебе.
Блин, я же сам в том посте и предположил, как именно это сделано. Это все и так понятно, в общем мимо.
Речь о том, что когда начнут вставлять реальные железки в реальные компы, то часть имплементации HAL возможно придется писать производителям железок. И не на C#.
VD>Что касается научности, то опять таки мнение гордого инжинера тут вряд ли окажется весомым. Цели исследований описаны на сайте проекта. То что эти цели счтены научными сомнений не вызвает, так как занимаются этим люди из университетов.
У них университеты частенько инженерные.
Да, именно, целые университеты занимаются инженерными разработками. Не накладывай совковую модель институтов на них, они сильно отличаются.
И всем плевать на мнение или там несогласие мое или твое. Есть довольно ощутимые границы научной и инженерной деятельности.
Научная: определения и аксиомы;
теоремы;
доказательства;
интерпретация результатов.
Инженерная:
определение требований;
написание спецификаций;
разработку и реализацию;.
тестирование и анализ.
VD>Ты же, как всегда, с целью облить что-то неугодное тебе грязью выцепляшь из контекста какие-то одтельные веши и пыташся их "разоблочить". Зачем? Я не знаю. Но цедь явно не добрая.
я плакаль... И почему я не позволяю себе подобных высказываний в адрес оппонента? На любой твой выпад можно отвечать этими словами. Специально сохранил в "избранном" линк сюда.
И кстати, я не пытаюсь разоблачить, я не согласен кое с чем и привожу аргументы.
VD>В общем, почитай про миноядерную архитектуру и идею HAL. Тогда возможно разговор на эту тему у нас и получится.
Смешно. Нет, действительно, смешно, когда прикладной программист говорит подобное системщику и разработчику выч. аппаратуры.
(Согласись, твои отсылки "пойти почитать, только тогда снизойду" на грани оффтопа, как и мой ответ )
Разговор не поэтому не получается, а из-за слишком сильной приверженности кого-то определенным взглядам, из-за очень легкого закрывания глаз на "неугодные" моменты и выпячивания других. Мы, в отличие от, спустимся медленно, медленно... И посмотрим внимательно, внимательно.
Здравствуйте, mrozov, Вы писали:
M>Все так. Или почти так.
M>Просто если принять как данность, что кодирование на голом с++ — вещь неправильная, то следующий логичный шаг — использовать язык/среду, в которой соответствующие проблемы были устранены изначально.
M>Раньше особого выбора просто не было. Теперь есть.
Согласен. Дотнет отберет прилично задач не только у Явы, но и у С++. Ну и на здоровье. Самое правильное — использовать наиболее подходящий инструмент для каждой задачи. С++ приобретет легкий оттенок "системного" языка, а про С мы наверно забудем.
Здравствуйте, vdimas, Вы писали:
V>Да нет, это у кого-то просто уже крышу сносит на управляемых средах. В чем проявляется "ученость" исследований в данном случае?
Singularity is a research project focused on the construction of dependable systems through innovation in the areas of systems, languages, and tools. We are building a research operating system prototype (called Singularity), extending programming languages, and developing new techniques and tools for specifying and verifying program behavior.
V> Вроде же можно пойти почитать про микроядерную архитектуру?
Пойди и почитай. Правда микроядерная архитектура сама по себе была предметом ислледования много лет такму назад. Сейчас она просто используется для достижения следующих целей.
V> Любой экперимент — априори исследование.
+1
V> Дык, я тогда тоже ученый.
Ты нигилист. Так что толку от твоих исследований не много.
V> Где гипотезы, выкладки, расчеты и доказательства? Нету?
И все то ты знашь. Хрошо все таки, что и научные планы тебе тоже никто делать не даст.
VD>>По-моему вопрос кто и что делает для этой ОС очевиден и обсуждения не требует.
V>Грамотные инженеры реализуют очередную задумку, действительно, обсуждать нечего.
Ты сходи на страничку проекта и потыках мышкой на профайлы этий самый "инженеров". Погляди где они работают, какие степени имеют и чем занимаются.
VD>>Почитай про микроядерную архитектуру. Глядишь твое мнение о том, что должен делать драйвер и изменится.
V>А если нет?
Ну, в общем — да. Может и не измениться. Тут все от человека зависит, его желания понять и разобраться.
V>Или существует только микроядерная архитектура?
Нет конечно. Я даже не уверен, что микроядерная архитектура применена в этой ОС. Просто она сдесь наиболее логична. Да и очень похоже по описанию. Как и в классической микроядерной ОС драйверы являются отдельными процессами, а общение между процессами осуществляется с помощью сообщений. Вряд ли для такой ОС можно применить монолитный подход из Линукса.
VD>>Задача драйвера устройсва — взаимодействовать с устройством на низком уровне обеспечивая высокоуровневый протокол для ОС и прикладных программ. При этом нет реальной необходимости непосредственно обращаться к аппаратуре и делать все остальное перечисленное тобой. Все обращения к портам и т.п. можно скрыть за очень небольшим по объему HAL-ом который будет выглядеть для драйвера как некое универсальное АПИ.
V>Это ты споришь или соглашаешься?
Я тебя поправляю. Если не доходит, скажу более прямо. В задачи драйвера не обязаны входить
непосредственное обращение к аппаратуре, то есть запись/чтение в память, общение с портами ввода/вывода, а так же реакция на прерывания
.
И на надо делать вид, что ты говорил то же самое.
V> вот из моего предыдущего поста: V> VD>>Очевидно, надо на ASM/C/C++ написать требуемый функционал, и приподнести его "на блюдечке" управляемой среде в виде простых интерфейсов.
Начнем с того, что С/С++ точно так же как и C# не имеют средств общения с аппаратурой, так как являются аппоратно независимыми языками. Точно так же С/С++ не имеют ни какого приемущества с точки зрения манипуляций с памятью (если говорить о небезопасном режиме). Так что слова про С/С++ — это вообще мягко говоря не правда/заблуждение.
Что касается "преподнесения на блюдечке", то это тоже какая то фигня. Несомненно машинные коды/асм необходимы в микроядре, так как без них просто невозможно обращение к тем самым I/O-портам, работа с прерываниями и т.п. Однако даже в NT и ее потомках этот код микроскопически мал. И то что драйвер может лезть к аппаратуре напрямую еще не значит, что он должен это делать. А уж в исследовательской ОС основными фичами которой является надежность и предсказуемость — это само самой разумеется. По этому она принципиально построена на миниатюрном HAL предоставляющем универсальный доступ к железу.
Назвать наличие HAL-а предоставлением на блюдечке чего-то от барского стола С++ у меня даже язык не поворачивается.
Ты уж извини, но твои слова, особенно в купе с цитатй приведенной выше как раз говорят, что ты или слабо представляшь что такое микроядерная архитектура, или намеренно пыташся дескридитировать выбранное ими средство.
V>Понимаешь, HAL она такая штука, что ее границы можно выбирать произвольно. Если сделать высокий уровень абстракций, то львиная доля кода перекочует в тот самый unmanaged, и блоки HAL под конкретные модели конкретных железяк в все так же будут разрабатывать вне C#.
Авторы Сингулярити открытым текстом сказали, что ОС и драйверы устройств разрабоатываются на безопасном подмножестве C#. И пока я не услышу громкие громких разоблочений их лжи, я склонен верить им, а не экспетрам во всех областях вроде тебя.
V>Поэтому понятие "драйвер на C#" требует нового осмысления .
Такая глубокомысленная фраза, что и сказать то по ней нечего.
VD>>Что же касается о невозможности обращаться к адресам памяти на C#, то это скорее говорит о товем знании C# нежели о его ограничениях.
V>Если ты про unsafe, то они же ведь собрались его постепено выкинуть, именно начиная с этой ОС, т.к. необходимость пропадет. И к портам все-равно невозможно обращаться. А при наличии HAL — и к памяти можно не обращаться.
Ну, начем с маааленького такого замечания. Ты опять вывертывашся. Ты утверждал о невозможности обращаться к адресам памяти на C#. Ну, так будь добр или согласиться с тем, что ты в очередной раз ошибся, или доказать свои утверждение. А вот заниматься в очередной раз флудом не стоит. Право это уже надоело.
Теперь что касается "они же ведь собрались его постепено выкинуть".
Жаль они об этом не знают. В их задачи входит создание максимально надежной ОС. По этому они конечно стремятся минимизировать объем небезопасного кода. Однако из этого никак не проистекает, тот факт, что небезопасного кода в ОС нет вовсе или что весь он написан на С++. Собственно разработчики этой ОС прямым текстом говорят, что тот же ЖЦ написан с использованием небезопасного режима C#.
Короче, в очередной раз обсуждать нечего. Твои слова просто не соответсвуют действительности.
V>>>Может программа на C# непосредственно обращаться к портам ввода/вывода? или по фиксированным адресам памяти? Или настраивать внутренние регистры процессора на новые карты отображения виртуальных устройств ввода/вывода? НЕТ. И никогда не сможет by design. Реально это? Вполне. Разработка "научная"? гх-гхх
VD>>По твоим словам получается разработчики Сингулярити нагло врут утверждая, что драйверы устройств написаны на C# без использования опасного кода. Но я почему-то скронен верить именно им, а не тебе.
V>Блин, я же сам в том посте и предположил, как именно это сделано. Это все и так понятно, в общем мимо. V>Речь о том, что когда начнут вставлять реальные железки в реальные компы, то часть имплементации HAL возможно придется писать производителям железок. И не на C#.
Нда, похоже ты даже не осоздаешь всю бессмысленность своих слов. Очень советую тебе прочесть что-нибудь популярное по микрояденой архитектуре. А то разговаривать с тобй просто не возможно.
V>Да, именно, целые университеты занимаются инженерными разработками. Не накладывай совковую модель институтов на них, они сильно отличаются.
Нда, это действительно какой-то инженерный комплекс. Гордость звания инженера перекрывает все вокруг.
Понимаеш ли, инженер — это специалист с высшим техническим образованием. Так что любой ученый технической специализации автоматом является инженером. Более того инженерия — это творческая техническая деятельность, что очень близко к научной деятельности. Так что несомненно любую научную деятельность в технической сфере можно причислить к инженерной деятельности. Однако научная деятельность тем и отличается, что практически на 100% является исследовательской, в отличии от инженерной, которая в основном присутсвует в чисто практических областях.
Собственно создание ОС с целью исследования тех или иных идей является чисто научной деятельность хотя бы потому, что результат исследования не предполагается использовать напрямую. Да, о чем вообще речь? Определение слова "исследование" — подвергнуть научному изучению. А определение слова "наука" — система знаний о закономерностях развития природы, общества, техники и мышления, а также отдельная отрасль таких знаний.
В данном случае речь идет о компьютерой науке (computer science), так как данное исследование дает знания всему человечеству.
V>И всем плевать на мнение или там несогласие мое или твое. Есть довольно ощутимые границы научной и инженерной деятельности.
Я кончно понимаю, что ты очень любишь слвово "инженер", но все же еще неплохо было бы знать значения используемых терминов. К тому же еще неплох было бы понимать, что бывает наука прикладная, а бывает фундаментальная.
V>Научная: V> V>определения и аксиомы; V>теоремы; V>доказательства; V>интерпретация результатов. V>
V>Инженерная:
V> V>определение требований; V>написание спецификаций; V>разработку и реализацию;. V>тестирование и анализ. V>
Это очень примитивное и узкое понимание того чем занимается наука и инженерия. Более широкое трактование я уже привел выше.
VD>>Ты же, как всегда, с целью облить что-то неугодное тебе грязью выцепляшь из контекста какие-то одтельные веши и пыташся их "разоблочить". Зачем? Я не знаю. Но цедь явно не добрая.
V> я плакаль... И почему я не позволяю себе подобных высказываний в адрес оппонента?
Я говорю о том, что вижу. Ты уж меня извени, но привык я так. Если вижу, что кто-то ворует — я говорю ворует. А если вижу, что беспречинно грязью что-то обливает, то говорю что обливает. Ну, а о том, что ты повзоляешь сам себе я и говорить то не хочу.
V> На любой твой выпад можно отвечать этими словами. Специально сохранил в "избранном" линк сюда.
Коллеционируй.
Что до выпадов. То я нападаю на то, в чем вижу конкретные недостатки и стараюсь разбираться в том на что нападаю. Ты же просто от болды пытаешся принизить значимость того или иного дела или оговорить его. Вот в этом и разница.
V>И кстати, я не пытаюсь разоблачить, я не согласен кое с чем и привожу аргументы.
Где аргументы то? Ты даже определения слов не знашь.
VD>>В общем, почитай про миноядерную архитектуру и идею HAL. Тогда возможно разговор на эту тему у нас и получится.
V>Смешно. Нет, действительно, смешно, когда прикладной программист говорит подобное системщику и разработчику выч. аппаратуры.
Смешно другое. Смешно когда человек считает себе системщиком и при этом без малейшего смущения делает стольк же грумкие, как и сомнительные заявления.
V>(Согласись, твои отсылки "пойти почитать, только тогда снизойду" на грани оффтопа, как и мой ответ )
Понимаеш, ли что-бы вести речь о чем-то с другими, и тем более, чтобы спорить. Нужно иметь соотвествующую базу. Ну, нельзя в форуме объяснять все с нуля. На это и всей жизни не хватит. Сказанное тобой о микроядерной архитектуре, лично у меня не оставляет и тени сомнений, что знаешь ты о ней по наслышке. По сему нужно или прекратить это бесполезно обсуждение, или все же разобраться в базе, чтобы говорить на одном языке. Тогди и объяснять в общем-то ничего не прийдется.
V>Разговор не поэтому не получается, а из-за слишком сильной приверженности кого-то определенным взглядам, из-за очень легкого закрывания глаз на "неугодные" моменты и выпячивания других. Мы, в отличие от, спустимся медленно, медленно... И посмотрим внимательно, внимательно.
Ага. Вместо того чтобы в чем-то разобраться куда проще указать на черезмерную приверженность и нетерпимость оппонента.
В общем, я не против обсудить эту тему. Но объяснять все с нуля не буду. Как минимум я не имею должной компитенции, а вопрос разянен в тонне статей доступных в Интернете. Так что если хочешь конструктива, прочти любое введение. А иначе давай завяжем.
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
VladD2,
> K>Тебя наверное сильно задел такой фанатик) > > Если бы это был один человек, то я бы и усом не повел. Но это какое-то групповое безумие. <...>
"По радио передают, что какой-то сумасшедший по встречке едет."
"Да тут их тысячи, тысячи!"
Posted via RSDN NNTP Server 2.0 beta
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
V>Понимаешь, HAL она такая штука, что ее границы можно выбирать произвольно. Если сделать высокий уровень абстракций, то львиная доля кода перекочует в тот самый unmanaged, и блоки HAL под конкретные модели конкретных железяк в все так же будут разрабатывать вне C#.
А зачем, собственно, произвольно выбирать ее границы? Есть довольно-таки простой критерий их выбора: надо предоставить доступ ко всему при минимальном объеме кода.
V>Речь о том, что когда начнут вставлять реальные железки в реальные компы, то часть имплементации HAL возможно придется писать производителям железок. И не на C#.
Может, я чего-то не понимаю? Дело в том, что с точки зрения 86й архитектуры есть, в общем-то, ровно две абстракции: память и порты. Все. Точка. Невозможно сделать железку, которая будет работать как-то по другому. Просто потому, что процессор ни до чего другого не сможет добраться. Все железки программируются именно так. Это означает, что достаточно сделать интринсик-функции чтения/записи в порт — и всё. Остальная логика программируется через них.
Развей, пожалуйста, мои заблуждения.
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, vdimas, Вы писали:
V>Согласен. Дотнет отберет прилично задач не только у Явы, но и у С++. Ну и на здоровье. Самое правильное — использовать наиболее подходящий инструмент для каждой задачи. С++ приобретет легкий оттенок "системного" языка, а про С мы наверно забудем.
Я тут, собственно, именно об этом и говорю. А меня бьют лопатами.
V>>Понимаешь, HAL она такая штука, что ее границы можно выбирать произвольно. Если сделать высокий уровень абстракций, то львиная доля кода перекочует в тот самый unmanaged, и блоки HAL под конкретные модели конкретных железяк в все так же будут разрабатывать вне C#. S>А зачем, собственно, произвольно выбирать ее границы? Есть довольно-таки простой критерий их выбора: надо предоставить доступ ко всему при минимальном объеме кода.
V>>Речь о том, что когда начнут вставлять реальные железки в реальные компы, то часть имплементации HAL возможно придется писать производителям железок. И не на C#.
S>Может, я чего-то не понимаю? Дело в том, что с точки зрения 86й архитектуры есть, в общем-то, ровно две абстракции: память и порты. Все. Точка. Невозможно сделать железку, которая будет работать как-то по другому. Просто потому, что процессор ни до чего другого не сможет добраться. Все железки программируются именно так. Это означает, что достаточно сделать интринсик-функции чтения/записи в порт — и всё. Остальная логика программируется через них.
S>Развей, пожалуйста, мои заблуждения.
Точка зрения понятна, но тем не менее HAL-ы делают более высокоуровневыми, чем реализации inp() и outp() стандартной библиотеки С. Развеять тебе поможет спецификация HAL тех же виндов (DDK), линухов (исходники). Сам я писал под embedded устройства, где в HAL помимо прочего входили атомарные операции (InterlockedXXX) и вывод на экран (в той операционке не было GDI, да оно и не нужно было, т.к. не требовалось общих/одинаковых операций при работе с экраном/принтером/битмапами). Так вот, реализация этих HAL была не так уж чтобы совсем тривиальна, и, разумеется, сильно засисела от конкретной железки PDA, на котором исполнялось. Даже реализация объекта ядра — таймера, сидела поверх HAL, т.к. на разных железках было разное физическое управление таймерами. Т.е. я и вел речь о том, что, по сути, границу HAL выбирают довольно-таки произвольно, в зависимости о потребностей. Например, выделять работу с таймерами в отдельный драйвер (даже если ОС построена на монолитной архитектуре) нецелесообразно, проще запихнуть в HAL и забыть.
Конкретно по 86-й архитектуре. Понимаешь, этой архитектуре сильно повезло в том плане, что для нее практически стандартизирована внешняя обвеска, т.е. DMA работает так-то, контроллер прерываний — так-то, таймеры — так-то и т.д.
Открой вкладку "Устройства" на св-ве компьютера и посмотри драйвера на различные системные устройства. На приличную часть из них выдается сообщение: "для этого устройства не требуется драйвер" (особенно на перечисленные мной).
И даже при таком раскладе, просто посмотри список экспортируемых ф-ий в system32/hal.dll. Около 100 ф-ий.
Ориентируясь же на произвольную архитектуру необходимо операционке предоставить унифицированный доступ к этим фичам. Разумеется, не через inp() и outp(), а именно через более высокий абстрактный уровень.
quicksort =: (($:@(<#[),(=#[),$:@(>#[)) ({~ ?@#)) ^: (1<#)
1.1.4 stable rev. 510
