Опять?

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.

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