Опять?

maytonRWolf, полностью согласен. Но вы навязываете мне "повестку дня". Тема embedded development
весьма интересна и обширна и заслуживает отдельного топика. Но здесь мы обсуждали другое.

Мы еще обсуждали real time в приборостроениии. Мои аппонеты высказывались:

- Real time OS не нужные понты.
- Так же, на марсоходах real time не нужна.
- VxWorks не нужна.
- NASA ошибается. =)

mayton3) не имеет значения при формальном описании АЛГОРИТМОВ в общем понимании этого слова. Ни в одном
из известных описаний ИЗВЕСТНЫХ алгоритмов вы не найдете требований касающихся MemoryModel/GC,
JIT-компилляторов, трансляторов и уж тем более ремарок в сторону невозможности реализовать это Java.
Собственно мы тогда весь вечер спорили ни о чем. Я с вашими словами абсолютно согласен. И сам постоянно повторял про возможность описания алгоритмов хоть на ассемблере МК-52, хоть на машине Тьюринга.

Я напирал на то, что некоторые алгоритмы абсурдно описывать на Java. Как вы себе представляете описание алгоритма диспетчера потоков ОС Windows на Яве? Для этого вам внутри JVM придется реализовать некую другую ВМ - запрограммировать тот же ассемблер МК-52 и расширить возможности того процессора до обработки исключений и поддержки виртуальной памяти как минимум?

Но умно ли это?

Как описать RAII на C#? Ну можно воспользоваться оператором using (?) и методом Object.Dispose(). А если их нет в языке?

egorychpetravКак описать RAII на C#?да нельзя описать алгоритм ни на одном ЯП, хоть C#, хоть на ассемблере МК-52. На них можно ( или нельзя ) алгоритм реализовать. По описанию, сделанному с помощью других средств.
Отличать пора бы уже описание от реализации.
Ну вот. Так и нужно.

Но в терминах С++ я не просто опишу (в упрощенном варианте) любой алгоритм, я еще и на С++ запрограммирую любой алгоритм. Даже сборку мусора в C#.

maytonpetravЯ напирал на то, что некоторые алгоритмы абсурдно описывать на Java. Как вы себе представляете описание алгоритма диспетчера потоков ОС Windows на Яве? Для этого вам внутри JVM придется реализовать некую другую ВМ - запрограммировать тот же ассемблер МК-52 и расширить возможности того процессора до обработки исключений и поддержки виртуальной памяти как минимум?
Я подозреваю что и я и многие здесь присутствующие нечитали исходников диспетчера потоков ОС Windows.
И поэтому о глубине и степени сложности мы можем иметь лишь приблизительное представление. Но если
вы опишите словами какие там трудности и с какими проблемами мы сталкиваемся то думаю какое-то решение
можно придумать.
Я, конечно, тоже не читал тех исходников.

- 100% для оптимизации ядра там используется union.
- Так же любой вариант прямого доступа к памяти.
- В С/С++ достаточно просто встраивается асм-функция сохраняющая/восстанавливающая значения регистров процессора при переключении потоков.
- Управление драйверами в реальном времени.
- Переключение потоков через заданный квант времени.

Как на Яве это описать?

Можно конечно написать на псевдокоде (я не работал на Яве):


И написать функцию сохранения контекста потока. Но вы где-то такое видели?

mayton,

Да, в дополнению к union еще структуры с полями в виде битовых полей!

Модератор: Тема перенесена из форума "C++".

maytonpetrav, я тебе даже более скажу. В Java я не могу сделать swap(..) для двух строковых аргументов.
Но это не мешает мне успешно решать все возникающие бизнес-задачи. Честно говоря я очень разочарован
списком который ты привёл. Там нет алгоритмически нерешаемых вопросов. Есть технические limitations
которые ты искусственно ввёл. Ты требуешь от меня решать на Java некоторые технические задачи
но при этом заведомо ставишь ограничение на то как мне их решать. В этом есть некая натяжка.
Ты как-будто-бы во время игры меняешь правила игры.
Так не я ввёл эти ограничения. А жизнь.

Я просто говорю, что некоторые алгоритмы бессмысленно (но можно) описывать на языке некоторой ВМ, по определению ограниченной. По сравнению с С++, который ограничений не имеет.

maytonБолее развёрнуто я отвечу тебе на эти пункты чуть позже. Щас некогда.
Не очень жду, извини. Устал от спора.

Dima TА вот дальше из этого ты делаешь абсолютно нелогичный вывод: "Все задачи НАДО решать на С/С++". С чего вдруг производителность конечного продукта стала единственной характеристикой оценки качества продукта?
Вы что-то пропустили в том почищенном топике.

Например, серьезные задачи управления данными я рекомендовал решать на SQL (NoSQL тут не трогаем). Потому что получится и производительнее и быстрее в разработке.

Кроме того, я не призывал отказываться от Явы или Шарпа.

Владимир2012maytonНет также научно подтвердённых работ которые доказывают невозможность реализовать на любом ЯП
то что реализовано на С++.
В начале 90-х на Foxpro сделал disassembler obj файлов.
Не помню правда мотивы почему решил написать на Foxpro ...
/тогда был QuickC http://vetusware.com/download/QuickC 2.51/?id=3503 и его часто использовал/
Вот видите. ФоксПро умер, а вы и мотивов своих не помните. =)

В начале 90-х я был школьником и у меня бы Спектрум, который загружался в интерпретатор Бейсика. Так я на Бейсике начал реализовывать свой язык программирования (после того как научился писать синтаксические анализаторы). А вот я помню почему прекратил: не было своих идей (я копировал бейсик на бейсике), работало медленно.

По ассемблеру тогда с литературой были проблемы. Зато на Спектруме еще до института выучил (кроме бейсика), Паскаль и Форт.

maytonpetrav- 100% для оптимизации ядра там используется union.
Очень странный тезис. Я знаком с Union и могу подтвердить что это замечательная штука.
В особенности в части доступа к bitfield. В некоторых ЯП нет концепции union.

union не имеет в С++ никакого отношения к битовым полям. Это способ в одной области памяти разместить несколько POD объектов.




maytonНо я могу эмулировать работу с union используя целочисленные операции над int, long.
Платформа позволяет. Поэтому вобщем-то не вижу принципиальных ограничений.

Хорошо. Изначальный ваш посыл неверен, но опишите на Яве работу с со структурой с битовыми полями.

petalvikpetravЯ просто говорю, что некоторые алгоритмы бессмысленно (но можно) описывать на языке некоторой ВМ, по определению ограниченной. По сравнению с С++, который ограничений не имеет.

Как на на C++ будет выглядеть алгоритм(?)/макрос(?) в режиме компиляции берущий из СУБД структуру БД и проверяющий в компайл-тайме правильность SQL-запросов, записанных в коде в виде строк (не ORM)?
Я это к тому, что шаблоны C++ при всей их полноте по Тьюрингу не имеют средств ввода-вывода.
Будет выглядеть как архив, в котором будет следующее:

- Исходники MySQL на С (или уже С++ ?).
- Мой скрипт на SQL.

А теперь попробуйте эти языки поменять местами. =)))

Dima TВот чезанах? А потом пишешь
Троллим? Парни пошлите его нах, не отвечайте, не кормите тролля.
О Чёрт, какая у Вас агрессия! Просто успокойтесь, если не понимаете о чем речь. И, точно, лучше конкретно Вам уйти из ветки. =)))

Владимир2012Все таки неужели "словесно блок схемный" стиль описания алгоритмов - лучшее из всех возможностей.
Неужели академический мир не создал каких то спецификаций ...
Создавал, что вы! Целый огромный язык создали — Unified Modeling Language .

В общем и целом проект провалился. Не набрал популярности.

Хотя на стартовом ажиотаже считался чуть ли не серебренной пулей. Должен был решить все проблемы в программировании. Упростить взаимодействие программистов с заказчиками. Некоторые даже мечтали об Executive UML — возможность программировать только лишь рисуя диаграммы (и, в мечтах, ничего не зная о программировании).

ЗимарглА в чем вопрос то?
Утверждение моих оппонентов изначально выглядело так: любой алгоритм можно описать на чём угодно, хоть на блок-схемах, хоть на Яве (с сборщиком мусора).

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

Постепенно в споре моё утверждение расширилось: любой алгоритм можно описать и запрограммировать на С++, а Ява и C# ограничены виртуальной машиной.

Мои оппоненты утверждают: Ява ограничений не имеет в области формального описания алгоритмов.

С тех спор и спорим.

Владимир2012petravС тех спор и спорим.
Диалог много лучше ...

https://ru.wikipedia.org/wiki/UML
https://ru.wikipedia.org/wiki/CASE

Использовал кто?
Насколько эффективно их использование ... ... ...
Возможно ли применить эти технологии при разработке на C и C++?
Я использовал на работе UML. Хороший инструмент. Но никакого конкурентрого преимущества при проектировании не даёт. Можно заменить блоксхемами, школьной доской, MS Word. В плане же документирования совсем не исключает написания текстовой документации.

Термин UML пропал из эфира лет 10-15-ть назад. Вместе с CASE.

Да, с С++ использовать можно. UML — это язык моделирования ООП.

maytonpetrav- Так же любой вариант прямого доступа к памяти.

Мы живём в эпоху виртуализации. Виртуальной стала память. Адресация.
Если вы покупаете хостинг. То в 99% случаев вы покупаете виртуальную
машину в контейнере Xen/VBox/HPUx Containers/Defence Zones. И как, через
какой механизм или через какой стек технологий она видит память одному
админу известно. Если вы - кодер технологий MS.Net, Java, Python, Perl, PHP,
то у вас нет задач адресуемого доступа ко всей памяти. Для буферов I/O
и различных алгоритмических идей есть возможность аллоцировать байтовый
массив и решать задачу в рамках имеющейся относительной адресации.

Я не знаю сегодня задач кроме собственно создания ОС и аллокатора памяти
которая требует в обязательном порядке т.н. прямого доступа. Собственно
прямой доступ к памяти по степени необходимости и целесообразности
граничит с доступом к физическим секторам HDD. Это вызывает удивление
и здравые вопросы о смыслах.
Вы меня простите, но мне кажется, что вы не понимаете разницы между даже уже разнородными понятиями:

- Гипервизор.
- Прямая адресация.
- Виртуальная память.
- Кольца защиты.
- Прямой доступ к памяти в С++.
- Доступ к памяти в .NET, например.

Я уж не говорю о том, что вы не знаете, что такое union и битовые поля в С++.

Ну о чем тут можно разговаривать?!

И да, я изначально напирал на алгоритмы ОС и драйверов (но не только!). Но вы даже не понимаете разницы в прямом доступе к памяти в обычных С++ приложениях и в доступе к памяти в ВМ (который вы там вообще управлять не можете).

maytonИ я думаю что 9 из 10 разработчиков способны прожить длинную и счастливую
жизнь но так и не озадачиться подобным вопросом.

Кроме того ЕМНИП вопрос звучал в контексте создания т.н. диспетчера потоков Windows.
Очевидно в этом есть какой-то смысл. Нужно у автора уточнить.

Я не знаю что вам сказать, если вы ставите знак равно между массивом байтов в .NET и массивом байтов в native C++.

maytonВозможно вы бравируете связью С++ и архитектуры.
Вот! Совершенно верно! Именно об этом я и говорю.

Кроме того на С++ реализованы все ВМ, все ОС и т.д.

На С++ можно решить все задачи и реализовать все алгоритмы. Но в рамках ВМ вы ограничены ВМ.

maytonpetravЯ уж не говорю о том, что вы не знаете, что такое union и битовые поля в С++.

Вы - напористый малый. Я действительно их спутал со struct.
Их и спутать то нельзя. Упрощая (очень упрощая):

- union это несколько структур в одной структуре (одной области памяти).
- bit set - это последовательность упакованная (на уровне битов) в памяти разных типов данных данных (встроенных) размер которых мы ограничиваем количеством битов.

maytonВ конце концов я могу
эмулировать процессор и с помощью счётчиков тактов, continuations,
и используя имеющийся механизм multithreading реализовать модель
процессора x86 и эмулировать кванты времени и весь прочий
нужный вам функционал.

И поскольку в данном вопросе вы не информированы то я делаю вам одолжение
и информирую вас. Что технически, задача эмуляции процессора и ОС на Java
сегодня уже решена.

Я даю вам ссылку на проект jDoxBox. Это ОС MS-DOC + стек x86 технологий
реализованных как обычное java приложение.
Так об этом я вам всегда и говорил! Даже есть на JS (в браузере) эмулятор Спектрума.

Что, что бы описывать системные алгоритмы в Яве вам внутри ВМ придется создать свою другую ВМ. И в рамках её описывать системные алгоритмы.

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

petalvikpetravКроме того на С++ реализованы все ВМ, все ОС и т.д.
Не все. Запросто можно написать на огромном количестве языков.
Тот же GC для дотнета был изначально написан на Лиспе.
На диалекте C# были написаны ОСи Singularity и Midori.
Про GC на Лиспе - ссылку на сайт Майкрософта, пожалуйста. А сам Лисп, конечно, был реализован на С/С++.
Тот проект Microsoft Reserch ничем не закончился.

petalvikpetravНа С++ можно решить все задачи и реализовать все алгоритмы. Но в рамках ВМ вы ограничены ВМ.
С 90-х годов прошлого века существуют процессоры, аппаратно выполняющие байт-код Java. Попробуй решить на них что-нибудь на C++. :D
Я еще слышал про Лисп-процессоры. Но где они? В 90-х?

maytonpetalvikпропущено...

Не все. Запросто можно написать на огромном количестве языков.
Тот же GC для дотнета был изначально написан на Лиспе.
На диалекте C# были написаны ОСи Singularity и Midori.

Конечно он ошибается. Операционки писались всегда на "C". Собственно ради этого
и был создан первый компиллятор. На плюсах был написан ЕМНИП BeOS та и тот
уже приказал долго жить.

Насчёт ВМ - не готов щас спорить. Но можно поднять исходники OpenJDK к примеру
и глянть что к чему.
Конечно, я в данном споре понимаю С как подмножество С++. Хотя знаю, что современный С обладает возможностями которых нет в С++. В прочем, как и "не современный" С. В общем, это языки одной сути, в кавычках.