[VCucumber 0]

В общем, я потестил ptoc - пока ничего невнятного не обнаружил.

Вариант: создаем проект в Delphi-8, компилим. Затем декомпилим в cpp-clr. Затем снова компилим, gcc++ или как он там называется. В общем, все упрется в либы, т.е. framework. Но framework для линуха есть, gtk#, как минимум, а с ним исходники, которые можно попробовать скомпилить куда надо. Порт M$ Framework под линух вроде бы тоже есть, но я как-то его еще не нашел. Иначе таки просить у M$ исходники micro-framework - он дают своим партнерам типа под nda. Готов кто договорится ?

[_Pasha 0]

И мне почему-то кажется, что и задач, которые требуют тяжелых камней, намного меньше, чем задач, которые решаются на той-же ("народной") мега8.

Вот такида! +1

 

Вариант: создаем проект в Delphi-8, компилим. Затем декомпилим в cpp-clr. Затем снова компилим, gcc++ или как он там называется. В общем, все упрется в либы, т.е. framework.

Ну, на кой мне для РС такие сложности? А на МК - Тут же все делается на своих либах. Или вот - FPC для ARM. Такшта...

[zhevak 0]

Вариант: создаем проект в Delphi-8, компилим. Затем декомпилим в cpp-clr. Затем снова компилим, gcc++ или как он там называется...

Сурово. Месье знает толк ...

[VCucumber 0]

Ну, на кой мне для РС такие сложности? А на МК - Тут же все делается на своих либах.

Прога, которую ищите, по сути, тоже компилер/декомпилер. Вообще, такую вещь можно самостоятельно и цивильно сделать. Но только на C#(или его братьях-сестрах).

На своих либах - проще. Только нуево, писать свои либы, если есть возможность использовать чужие и отлаженные. Я за это даже бга паять научусь ) Надеюсь.

[Kopa 0]

А слабо в качестве доказательства Жабу можно поднять на tiny2313? Мне -- слабо.

(И кроме того, мне кажется, Вы напрасно причисляете Жабу и Шарп к компилируемым языкам... Ну Шарп, еще куда ни шло. Но Жаба... :( )

Внимание! Тишина в зале!

 

В продолжение дискуссии:)

 

Отличий в стековом байт-кодовом подходе VM ( виртуальных машин ) Java и С# меньше,

чем можно себе представить. Для Java ( байт-кода ) и С# ( MSIL - байт-кода ) есть даже

front-end для Си компиляторов.

 

При достаточной мотивации использовать ( не совсем понимаю, что значит поднять ) можно

уже были ссылки на 2-а старт проекта Java для AVR ( поищите nanoVM и JODE )

 

На Iar интересуясь для AVR ( поднимал 2-у лет назад ) Java интерпретатор:). ( ~14Кб)

Для каких-то применений возможно, и в таком виде, использовать. Для серьёзного, использования

из Java, пожалуй, стоит для МК убрать понятие GC ( сборки мусора) и создать оптимизатор ( на базе JIT ) из байт-кода в нативный код требуемого контроллера. И будет вам счастье:)

 

P.S. Универсальный ассемблер - не сильно большая утопия.

Как вариант наиболее близкий к этому подходу можно использовать Forth ( Форт).

[SapegoAL 0]

Так вот куда все подевались, а я всё пропустил. :)

Хочу вставить свои 5 копеек.

 

Итак на мой взгляд.

1) Автор топика прав. Дают не знания, а учат получать и усваивать знания, которые необходимы. Для этого необходим кругозор, систематизация и т.п. К примеру, на 5 курсе мне надо было в среднем от 2 до 7 дней чтобы выучить и сдать любой экзамен. Средний бал у меня был 4.7

2) Количество языков, исходя из п.1., желательно всётаки больше. Это приводит к общему пониманию как работает процессор или система программирования. Как работает компилятор. Приведу пример, по поводу обсуждаемого for. Если на это посмотреть так как я смотрю на это, то оператора for в С просто нет! Есть три оператора, которые компилятор размещает возле скобок{}.

Хорошо это или плохо? Это даёт понимание, но только после знакомства с Pascal.

3) А вот ++ мне кажется построены значительно хуже чем object Pascal (Delfi). И это, на мой взгляд, следствие простоты синтаксиса С. Расширение синтаксиса, привело к труднозапоминаемым конструкциям. А в Паскале стройность построения и относительная сложность привела к органичному "вписанию" объектов. Иными словами, как всегда, две стороны одной медали. Достоинства и есть недостатки. Именно поэтому студенты должны сравнивать. Сами сравнивать.

 

Понятно, что история не даст заднего хода, и на ближайшее будущее С и С++ будут основными языками, но это не значит что ничего больше и не надо изучать. Это просто бред. Если апельсины вкустные, то больше ничего есть и не будем. :)

[dxp 53]

3) А вот ++ мне кажется построены значительно хуже чем object Pascal (Delfi). И это, на мой взгляд, следствие простоты синтаксиса С.

Есть в ObjectPascal (Pascal упоминать не надо - это совсем не то, что подразумевают по этоим словом) шаблоны и множественное наследование?

 

Расширение синтаксиса, привело к труднозапоминаемым конструкциям.

Какие конструкции в С++ вы относите к труднозапоминаемым?

[SapegoAL 0]

Какие конструкции в С++ вы относите к труднозапоминаемым?

Я не говорю о конкретных возможностях языка, не об эффективности компилятора, не о стройности построения. Я говорю о синтаксисе языка, притянутом за уши.

 

Вы сейчас можете утверждать что угодно, но давайте посадите простого паренька за компьютер, не вдаваясь в подробности с преподом рядом. На Delfi он создаст самостоятельное приложение через 2 дня. Можно с объектами. На билдере (Той же фирмы) он будет с той же задачей мудохатся неделю.

 

Что означает конструкция "::"? С чем она у вас ассоциируется? Как скоро появится C+++? Там надо будет ввести конструкцию ":::", а также ":;:" и "::::". Это, на мой взгляд, банальное продолжение синтаксиса С "for(;;){}". Но при 10 операторах и 6 ключевых словах это супер, а вот в плюсах это конкретный недостаток.

 

Конечно, когда знаний вагон и опыта море - это не мешает а помогает (писать быстрее), но в освоении очень тяжело. Это я вам по собственному опыту говорю. А я с разными языками знакомился.

 

Это объективный факт. Посмотрите какие сложности с программерами на плюсах.

[VCucumber 0]

Есть в ObjectPascal (Pascal упоминать не надо - это совсем не то, что подразумевают по этоим словом) шаблоны и множественное наследование?

Да, а почему нет множественного наследования в c#, наследнике ++ ?

Нате вам

Как известно, язык Java не поддерживает множественное наследование реализаций (классов). Это объясняется тем, что такое наследование порождает некоторые проблемы. Чаще всего указываются неоднозначности, возникающие при так называемом «ромбовидном» наследовании, когда один класс ”A” является наследником двух других классов ”B” и ”C”, причем и тот и другой наследуют класс ”D”.

 

Вместо множественного наследования классов в Java введено множественное наследование интерфейсов, при котором, как утверждается, никаких проблем не возникает.

 

Кроме того автор языка Java Джеймс Гослинг считает, что одиночное наследование реализаций способствует правильному проектированию

 

http://www.javable.com/docs/articles/minherit/

 

Для паскаля тоже верно.

 

Какие конструкции в С++ вы относите к труднозапоминаемым?

Кстати, про краткость: сравните . и ^ с :: и ->

Изменено 27 ноября, 2008 пользователем Огурцов

[dxp 53]

Вы сейчас можете утверждать что угодно, но давайте посадите простого паренька за компьютер, не вдаваясь в подробности с преподом рядом. На Delfi он создаст самостоятельное приложение через 2 дня. Можно с объектами. На билдере (Той же фирмы) он будет с той же задачей мудохатся неделю.

Приложение одного уровня в Delfi и Builder'е будет создано за сопоставимое время.

 

Что означает конструкция "::"? С чем она у вас ассоциируется?

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

 

Как скоро появится C+++? Там надо будет ввести конструкцию ":::", а также ":;:" и "::::".

Это просто ваши фантазии. Нет никакой связи между количеством плюсов в названии и количеством двоеточий - это ваши фантазии, не понятно на чем основанные.

 

И к вопросу, который я задал, это не относится. Напомню, что вы упомянули какие-то труднозапоминаемые конструкции в С++, я такие что-то не помню/не знаю, поэтому меня это заинтересовало, и я решил уточнить, какие именно конструкции для вас труднозапоминаемые. Оказалось, что оператор области видимости ::. :)

 

Это, на мой взгляд, банальное продолжение синтаксиса С "for(;;){}". Но при 10 операторах и 6 ключевых словах это супер, а вот в плюсах это конкретный недостаток.

 

Во как! А for(;;){} чем не угодило?

 

Конечно, когда знаний вагон и опыта море - это не мешает а помогает (писать быстрее), но в освоении очень тяжело. Это я вам по собственному опыту говорю. А я с разными языками знакомился.

 

Это объективный факт. Посмотрите какие сложности с программерами на плюсах.

Вы не обращали внимание, сколько времени собирается программа в делфи и сколько аналогичная программа в билдере? Разница в разы. О чем это говорит? Да о том, что С++ просто язык куда более сложный, в нем множество нюансов - именно нюансами он и сложен (а отнюдь не "труднозапоминаемыми" конструкциями). А если сравнивать его с другими языками, то тут надо не забыть оценить, дают ли эти языки такой же результат, как С++. Мне вот язык Python очень нравится, я на РС утилитки для себя только на нем и пишу. Но довольно глупо его сравнивать с С++.

 

 

 

c#, наследнике ++ ?

Кто вам сказал эту глупость? Что С# наследник С++.

 

Что касается жабы и шарпа, то применямые в них решения будем сравнивать с С++ тогда, когда они сравнятся по эффективности. Включая заявления о "правильности проектирования". Вот и все.

[VCucumber 0]

Вы не обращали внимание, сколько времени собирается программа в делфи и сколько аналогичная программа в билдере?

А если не видно разницы...(с) то нафиг этот билдер.

И вообще, нафиг этот билдер - глюкало еще то.

Гораздо лучше по-честному - либо Delphi, либо VS.

 

Кто вам сказал эту глупость? Что С# наследник С++.

Наврено сам придумал. Но копирайт поставить не могу - вдруг прочитал где.

Ок, а иначе кто наследник ?

 

Что касается жабы и шарпа, то применямые в них решения будем сравнивать с С++ тогда, когда они сравнятся по эффективности.

Ну не сравнивайте шарп и оригинальную (не java#) жабу по быстродействию. Шарповский X-код ложится прямо на команды таргета, а джава (не java#)- все-таки интерпретатор. Так что если вы по эффективности одного делаете предположение о другом, то ошибаетесь. Шарп по эффективности ничуть не хуже, чем це++, а по остальным критериям, включая легкость разработки, так и гораздо лучше.

[tyro 0]

Есть в ObjectPascal (Pascal упоминать не надо - это совсем не то, что подразумевают по этоим словом) шаблоны и множественное наследование?

В Delphi 2009 шаблоны есть. http://www.codegear.com/article/38622/imag...oUpgradeRUS.pdf

[vik0 0]

И вообще, нафиг этот билдер - глюкало еще то.

Гораздо лучше по-честному - либо Delphi, либо VS.

+1

Ну не сравнивайте шарп и оригинальную (не java#) жабу по быстродействию. Шарповский X-код ложится прямо на команды таргета, а джава (не java#)- все-таки интерпретатор. Так что если вы по эффективности одного делаете предположение о другом, то ошибаетесь. Шарп по эффективности ничуть не хуже, чем це++, а по остальным критериям, включая легкость разработки, так и гораздо лучше.

Да ладно вам. С каких это пор MSIL стал ложиться прямо на команды таргета? Да, JIT компиляция - вещь хорошая, но до нормального оптимизатора нормального компилятора C++ ей как "до Шанхая пешком".

PS. AFAIK, Java тоже использует JIT компиляцию..

[SapegoAL 0]

Во как! А for(;;){} чем не угодило?

 

 

Да нет, угодило. Всем угодило. Более того, для МК считаю значительно более удобным. Основное преимущество, что могу выбрать степень детализации задания компилятору. То есть более точно донести компилятору, что я хочу получить от этого кода.

Ну и плюс, что меня не контролирует компилятор понапрасну. Ну типа "a=a-'0';".

 

Но ничего не вижу ужасного и если я напишу begin-end вместо {}. Написание текста - малая часть от создания проги.

 

Я пытался указать, что лаконичность C (малое число ключевых слов) совершенно закономерно перешла на C++. Но там, намного больше надо передать. И в паскале ничто не мешает введению целой кучи новых ключевых слов. А в плюсах - построение. На мой взгляд выглядит натянуто и неубедительно. Начинаешь терятся в этой программе.

 

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

 

Будучи студентом, мы изучали Fortran IV, потом PL/I. Ну а сам я работал на Fortran 77, Basic несколько позже Pascal. Но, считаю, что очень многое я переосмыслил когда начал на ассемблере писать.

Причём именно после ЯВУ.

 

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

 

К тому же, с чего вы взяли что все будут по завершению этого вуза программистами по МК. Человек может устроится куда угодно и в любой момент лихо завернуть свою судьбу. Например, будет по симатику работать. А там LAD/FBD/STL/SCL. То есть из языков - один ассемблеро-подобный, второй паскале-подобный. А о Си, к сожалению речи не идёт. Я уже о плюсах и не говорю.

 

Ссылку http://www.mikroe.com/ru/ надеюсь давали???

 

 

ЗЫ: Правда - не пользовался. Библиотеки помощнее чем в CV AVR были. И ММС и ЖКИ, включая графический, клава матричная, 24с и прочее. Вместе с эмуляцией. Почему убрали - не знаю.

[_Pasha 0]

Ссылку http://www.mikroe.com/ru/ надеюсь давали???

ЗЫ: Правда - не пользовался. Библиотеки помощнее чем в CV AVR были.

Вообще-то, он кривой. Но интересовался я им года 2 назад, могло что-то и измениться.

А вот убрали всю ветку продуктов для АВР. На "оригинальном" сайте ведь все есть.