Возможно, Вам стоит присоединится к развитию RAPID APPLICATION DEVELOPMENT HiAsm

Топик: Как было бы здорово, если бы существовала среда HiAsm-AVR
http://hiasm.com/xf/topic.php?t=31314&start=50

P.S. НiAsm написан на Delphi

Нет, это в другую сторону. И слишком сложно. А надо быстро и дешево, скриптоподобно.
Паскаль - подходит на 100%
В общем, я потестил ptoc - пока ничего невнятного не обнаружил. Был бы он чуть ближе к FPC...

Cсылка была на pascal to c на эту страницу http://www.garret.ru/lang.html

Ни в коем случае. Изначально вся модемная связь делалась по французским стандартам. Сейчас уже не помню названий. Американцы потом подключились и перехватили.

И наоборот плохо... А если не сравнивать живых людей как продукты из потребительской корзины - лучше, хуже - вот тогда хорошо

Осознанно и добровольно
Обусловлено это переползание было переползанием в сферу embedded. Нужно было срочно разработать устройство с достаточно сложной программой, на максимально дешевом железе (от цены железа напрямую зависела лично моя прибыль) ну и тут из вариантов было:
A. Отказаться от проекта.
B. Здорово удорожить проект (взять 186-й или любой другой x86 и делать программу на чем угодно).
C. Освоить подходящие инструменты для работы с дешевыми МК, после обзора выснилось что инструментов таких всего 2 - ASM и C. (ну а насчет, что лучше ASM или ЯВУ уже была тьма тьмущая тем).

Нетрудно догадаться что вариант С мне показался наиболее правильным вариантом.


Такое мнение может быть либо до начала, либо в самом начале освоения языка (в первый день)
т.к. возникает противоречие между вопросами:
1. Почему язык не похож ни на что с чем привычно работал раньше?
2. Почему столько народу на нем работают?

Читаем книжку по языку практикуемся, и оказывается что язык то совсем не плох.

Очень наглядно переползать на "C" с ASM'а т.к. сразу на лицо выигрыш во времени разработки. При этом свободы действий язык не ограничивает т.е. пропасти между ASM и C, такой как между ASM<->BASIC (ASM<->PASCAL) нет.

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

Ну а когда осознаете, что качественный компилятор и IDE для c#/паскаль/ассемблер/java есть практически под любой проц, и осовоив _любой_ из этих языков можно стать независимым от платформы, то альтернативы _не_использовать_"C"_ просто не остается.

Ок ощасливьте нас пожалуйста ссылками на компиятор и IDE (C#/паскаль/java) для процов перечисленных здесь:
http://www.iar.com/website1/1.0.1.0/675/1/index.php
Пока нет ссылок, ваша фраза - это пустой звук. "хотение" как у Емели, так сказать.

PS: ассемблер выбросте из списка языков, т.к. он для каждого проца свой. Тобиш сколько процов столько и ассеблеров, учить каждый будем?

А что уже есть "качественный компилятор и IDE для c#" под AVR- или MSP- платформы?
А слабо в качестве доказательства Жабу можно поднять на tiny2313? Мне -- слабо.
(И кроме того, мне кажется, Вы напрасно причисляете Жабу и Шарп к компилируемым языкам... Ну Шарп, еще куда ни шло. Но Жаба... )

Коллега, не надо голословно утверждать, что "осовоив _любой_ из этих языков можно стать независимым от платформы". Доказывайте, что Вы можете написать софт на "_любом_ из этих языков" для "любой платформы". Давайте для начала возьмем платформу согласно этой ветки форума -- AVR.

Итак, платформа AVR! Уважаемый Огурцов доказывает, что для AVR существует "качественные компиляторы" для всех названных им языков -- "c#/паскаль/ассемблер/java".
Внимание! Тишина в зале!

На микрософте поройтесь. Для моего камня пока нет(и не надеюсь), но наиболее популярные уже поддерживаются.


Косность мышления ? Как тут и во флуде уже неоднакратно было сказано - паскалист допускает существование других языков программирования, сишник - нет. Си - этакая потенциальная яма, скатившись в которую, прогер уже не может выбраться. А если сразу начинал с си и не имеет от этого прививки в виде паскаля - вообще без шансов



Да уж просили бы сразу под pic )))
Я сейчас пишу про паскаль, ну чтобы сишники не расслаблялись.
Про avr - смотрите мой пост выше - gcc и не зачем парить мосг.

Но вообще, мысль вы подкинули интересную. Кто-то бы запросил у M$ исходники микрофреймворка - можно было бы поломать голову и над avr - в xmega поди ж и вошлось бы.


Жабы они разные, есть и такие как java#


Позволю себе утверждать. Сейчас и еще более в дальнейшем. Но под громким словом "платформа" в данном случае, конечно, имею ввиду нормальные камни. Хорошо, если так не нравится, то те камни, которые M$ считает нормальными )))

Извините за плагиат.

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

Человеческие ресурсы ограничены. Лучше знать один язык, но очень хорошо. Только не передергивайте, прошу Вас! Я сказал, что зная Си у меня абсолютно нет никакой надобности знать еще какой нибудь похожий на него язык, например Паскаль. Другие языки, типа ассемблер, Жаба, Шарп, -- эти языки намного дальше отстоят от Си, чем Паскаль. Поэтому в каких-то случаях имет смысл их знать, как второй язык. А Паскаль... ... ну это такая хрень, которая практически ничем не отличается от Си. Ну разве что отсутствием препроцессора, повышенной заботой к программистам_с_кривмими_руками (которые путают постоянно типы. Это бедствие, знаете-ли!) и отсутствием широкого распространения "качественных компиляторов под любую платформу". Осюда получается, что паскалисты думают, что если у Си-шников костное мышление. Кто бы говорил!



Ну не мне Вам объяснять, что Жаба изначально задумывалась как независимый от камня язык. А то, что Жабу натягивают на компиляторы, -- ну так ... это извращения "они разные, есть и такие как java#"! Да Вы и сами видите, что ничего хорошего из этого не выходит.

Я не посоветую паскаль только по той причине, что я его знаю и он мне нравится. Точно так же не буду пихать во все щели си. Есть конкретные задачи и для каждой подходит _свой_ язык. Для tiny2313 подходит gcc. Для avr вообще на макроассемблере нужно писать. Жаль такой для avr мне неизвестен.


Ну вот, это то, о чем я и говорил выше.


Поймите же наконец, есть паскаль, есть борланд-паскаль, есть Delphi 1,2,3,4,5,6,7 - все разные, есть наконец Delphi 8, которая стоит абсолютно на одном уровне с C#/Java#/CPP CLR/VB#. Наврено уже новое что-то вышло. А вы все про "какой-то" паскаль, который вы себе придумали. Я уж не знаю, какие у вас фичи в него входят.


Ушол.

(С) "Кто все эти люди?"

Кто такая M$??? Почему Вы думаете, что только она вправе решать какие камни нормальные, какие не нормальные?

Причем тут костность мышления. Нет такого языка Assembler. Есть Assembler конкретного проца. Assembler x86, Assembler AVR, Assembler ARM и т.д. и т.п.. Какой из этих ассемблеров Вы предлагаете освоить чтобы быть независимым от платформы?


"На помойке поройтесь, авось че будит" (С).
Нет для Вашего камня, нет и для тех что использую я, так значит нет? Так значит недостаточно знать java/pascal/c# чтобы независеть от камня?

В слух не надо почитать ? )

http://www.microsoft.com/netmf/default.mspx
http://www.microsoft.com/netmf/hardware/default.mspx
http://www.microsoft.com/communities/newsg....microframework

Ушол2
зы: не кантовать

Прадовало:



(1) ключевое слово can. В английском языке can выражает не полную уверенность. Т.е. не совсем как в русском -- можете получить, а может и не получить, но около того.
(2) ага, все другие протоколы не гарантируют безопасных соединений.
(3) знаем-знаем! Разработка пройдет в два раза быстрее, объем кода будет в 10 раз больше, быстродействие раза два ниже. А глюки потом патчами исправим.

Да и потом, много-ли найдется мастеров, кто занимается с камнями средней тяжести: AT91SAM7X, AT91SAM9260, LPC3180, и кто согласится угробить свой камень дотНЭТ-ом? Во всем мире из нашлось всего 650 чел. А то, что M$ умеет показывать фокусы с цифрами ("1.5 million devices are currently running on the .NET Micro Framework." ) -- все знают. Недавний пример с Вистой: M$ ликовала, что количество продаж Висты за первый менсяц превысило количество продаж ХР за тот же период. Надувательсто состояло в том, что MS приплюсовала продажи дистрибутива оптовикам и поставщикам оборудования, а не конечным пользователям. Потом эти дистрибутивы у них не хило-так зависли. Вспомните скандал с нотиками.

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

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

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


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

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

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

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

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

При достаточной мотивации использовать ( не совсем понимаю, что значит поднять ) можно
уже были ссылки на 2-а старт проекта Java для AVR ( поищите nanoVM и JODE )

На Iar интересуясь для AVR ( поднимал 2-у лет назад ) Java интерпретатор. ( ~14Кб)
Для каких-то применений возможно, и в таком виде, использовать. Для серьёзного, использования
из Java, пожалуй, стоит для МК убрать понятие GC ( сборки мусора) и создать оптимизатор ( на базе JIT ) из байт-кода в нативный код требуемого контроллера. И будет вам счастье

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

Так вот куда все подевались, а я всё пропустил.
Хочу вставить свои 5 копеек.

Итак на мой взгляд.
1) Автор топика прав. Дают не знания, а учат получать и усваивать знания, которые необходимы. Для этого необходим кругозор, систематизация и т.п. К примеру, на 5 курсе мне надо было в среднем от 2 до 7 дней чтобы выучить и сдать любой экзамен. Средний бал у меня был 4.7
2) Количество языков, исходя из п.1., желательно всётаки больше. Это приводит к общему пониманию как работает процессор или система программирования. Как работает компилятор. Приведу пример, по поводу обсуждаемого for. Если на это посмотреть так как я смотрю на это, то оператора for в С просто нет! Есть три оператора, которые компилятор размещает возле скобок{}.
Хорошо это или плохо? Это даёт понимание, но только после знакомства с Pascal.
3) А вот ++ мне кажется построены значительно хуже чем object Pascal (Delfi). И это, на мой взгляд, следствие простоты синтаксиса С. Расширение синтаксиса, привело к труднозапоминаемым конструкциям. А в Паскале стройность построения и относительная сложность привела к органичному "вписанию" объектов. Иными словами, как всегда, две стороны одной медали. Достоинства и есть недостатки. Именно поэтому студенты должны сравнивать. Сами сравнивать.

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

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


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

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

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

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

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

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

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


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

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


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

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


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


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

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



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


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




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

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

А если не видно разницы...(с) то нафиг этот билдер.
И вообще, нафиг этот билдер - глюкало еще то.
Гораздо лучше по-честному - либо Delphi, либо VS.


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


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

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

+1

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

Да нет, угодило. Всем угодило. Более того, для МК считаю значительно более удобным. Основное преимущество, что могу выбрать степень детализации задания компилятору. То есть более точно донести компилятору, что я хочу получить от этого кода.
Ну и плюс, что меня не контролирует компилятор понапрасну. Ну типа "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с и прочее. Вместе с эмуляцией. Почему убрали - не знаю.

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

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


Ага, особенно, если учесть, что в основе обоих одна и та же оболочка и VCL. Одинаковое глюкало.


Не надоело еще сравнивать несравнимые вещи? Когда VS научится лепить графические апликухи тем же способом, что и билдер, тогда и сравним. Уж Qt в противовес билдеру приводили бы, что-ли. Это была бы тема.


Вот это похоже на правду.


Зачем ему наследник? Он сам живее всех живых?.. Кто у делфы наследник? Аналогия понятна?


Ой, не надо этих песен/басен! Разберитесь сначала в вопросе как следует, потом подискутируем. Хинт: разработавшие и применяющие жабу с шарпом поди не глупее нас с вами, если бы все было бы так, как вы пишете, уже давно на AVR бы на шарпе код лепили. Только хде ж он?



Не прошло и тридцати лет. Еще осталось дождаться, пока в них глюки вычистят, научатся широко применять и появятся приемы типа описанных в "Modern C++ Design", а также делфовая STL.

Нет. Был опыт, причем не только мой, но целой команды. После замены билдера на дельфи число необъяснимых глюков снизилось на порядки.


Вы, вообще, VS когда-нибудь запускали ?


Нет. Если он такой живой, зачем нужно было шарп создавать ? Ну писали бы все на си. Так ведь нет, народу почему-то паскаль подавай, дельфи, шарп и иже с ним. А был бы си такой хороший и кто бы дергался на что-то иное ?


Ок, не буду спорить. Возможно и жаба компилиться в таргет, а не интерпретируется как Х-код. Просто я вижу жутко тормозные жабовые приложения и шарп, который летает в полный рост. А по поводу оптимизации, это на аргумент предыдущего оратора, так оно зависит не от языка вообще, а от конкретной реализации компилятора. Абсолютно одинаково с це.


Скоро уже, подождите чуток ) А для ARM, MIPS уже можно ; Но что-то я уже повторяюсь.

"поворотливость" программы зависитъ только от компилятора. язык тут ни при чем. но так сложилось что подавляющее большинство компиляторов для контроллеров - С/С++.
у любой конструкции С есть эквивалент в паскале, любую программу можно с минимальными изменениями перенести туда и обратно. так что не надо гнать на язык.

Пишу на Builder'е начиная с 1й версии, необъяснимых глюков не встречал (объяснимые - встречал), может что то в 'команде' не так?



Во избежании обвинения в пристрастии к BCB, сразу говорю, что писал (и пишу) еще на VC, gcc, icc (x86 & Itanium), HiTech C.

Тем, что как любой фиксированный синтаксически/семантически шаблон используется
в определённых ему рамках и пишется не задумываясь о его необходимости и
возможной негибкости при использовании. ( т.е. "зашоренное" мышление )

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

P.S. Но это не только в Си проявляется.

Неповоротливость, как и гибкость, зависят только от языка, но никак не от компилятора. Почему, например, для перевда буквы в нижний регистр нельзя просто установить бить 0x40, как в Си (c |= 0x40), а надо сначала получить код символа, выполнить с ним арифметическую операцию, а потом преобразовать опять в символ?

Вот например, недавно узнал, что оказывается внутри скобок begin-end нельзя объявлять локальные переменные. То есть, любая временная переменная, которая нужна на протяжении 3-4 строк, должна объявляться в начале функции и жить на всем ее протяжении. Да у меня в каждом цикле объявляются переменные а в конце цикла уничтожаются! А в паскале я должен позаботиться о них в начале функции, придумать им разные имена и т.д.?

А вообще, такие заявления (об эквивалентности Си и паскаля) могут делать только те, кто начинал с паскаля. Я начинал и Си, и когда пытался познакомиться с паскалем, меня просто бесило, что вещи, элементарные и очевидные в Си, обрастают в паскале кучей ограничений. Если вы начинали с паскаля, то эти ограничения вам объяснили сразу, поэтому переходя на Си вы даже не думаете о том, что что-то можно сделать проще и легче, потому что программируя на Си, вы продолжаете думать по-паскалевски, вы просто не знаете о том, что мир шире, что можно выйти из его дурацких ограничений, так же, как дальтоники не догадываются о том, что мир на самом деле ярче, чем они его видят.

Тут Вы неправы, хотябы потому, что С89 тоже требует объявлять переменные в начале функции и это мало кого смущало.

89??? 1989 год. Сколько лет прошло, по этой причине не помню, но то, что еще в 80-х годах на единственном более-менее доступном тогда борлондячем компиляторе можно было ограничивать область видимости и соответственно объявлять переменные внутри функции, это точно.

Меня смущало-бы и даже очень.

эти переменные не создаются/уничтожаются, а просто повторно используются одни и те же регистры. в паскале можно объявить одну переменную и повторно использовать в разных местах.а кто запрещает компилятору скомпилировать выражение c = c or $40 как установку бита ? вроде не проблема ?
вон в avr-gcc сначала устанавливать/обнулять биты приходилось через костыли cbi/sbi, потом научились делать через |=, &=~ . так что реализация таких мелочей зависит только от компиляторописателей, проблема паскаля в том, что он распространен значительно меньше чем С, соответственно намного меньше качественных компиляторов.

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

Изумительно При этом она будет жить и сохраняться и МЕЖДУ использованиями а использование переменной с одним и тем-же именем для РАЗНЫХ целей отнюдь не добавляет удобства и безошибочности.

Полагаю это справедливо для любого языка прогрпммирования.

В стандарте Ц89 переменную можно объявлять в любом месте в начале блока, а не только в начале функции, в том числе анонимного блока, не связанного ни с каким оператором ветвления. Напр.:
void func (int c, char
{
int a;
a = b + c;
{
float f;
f = a + c;
}
}

По стандарту Ц99 переменную можно объявлять в любом месте, где допустима инструкция (как в Ц++).

Вопрос в том, что есть реальные побудительные мотивы так "мудро" поступать или нет. А на мотивы уже язык свой отпечаток накладывает. Повторяю, именно реальные причины, а НЕ ВОЗМОЖНОСТЬ писать чего-либо через заднепроходное отверстие. В том-же "C" больше возможностей написать чего-либо через #@^#^%$ но МЕНЬШЕ ПРИЧИН это делать.

Сишники обычно пишут так:

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

Справедливости ради надо сказать что вы переносите свои действия на действия компилятора. А это не так. От того, где вы объявляете или уничтожаете локальную переменную - мало что зависит. Я бы сказал - ничего. Нормальный компилятор Си (ну IAR для AVR смотрел) будет генерить код вне зависимости от этого. А вот от количества локальных переменных будет результирующий код зависеть.

То есть синтаксис - имеет второстепенное значение. Эфективность кода зависит от качества компилятора.

А приведенный вами пример по Паскалю - принципиален. Это стратегия самого языка.
1) Объявление до использования
2) Запрет неявного преобразования
3) Контроль границ массива.

и многое другое... Это не случайные "недоработки". Это стратегия...

Для программиста Си сделаны серьёзные послабления в контроле за ним. Я могу сложить символ и целое значение. Или целое значение прибавить к указателю. В Паскале это невозможно. Надо сделать преобразование. Это не ограничение языка. Это делается для того, чтобы программист выполнял такие операции ОСОЗНАНО.
Иными словами Паскаль расчитан на программиста более слабого. Или для программиста, который свободен от ограничений по скорости/размеру.

Естественно что контроль за границами массива и границами перечислимых типов (с введением в компилируемую прогу соответствующих обработчиков) приводит к увеличению объёма результирующего кода. Но это не значит что язык не имеет права на жизнь. В таком контексте чисто объектные языки - вообще мёртворожденные. Они ещё медленнее, ещё более раздутые.

Вы глубоко заблуждаетесь. Как минимум, от этого зависит количество требуемой памяти - если переменная после выхода из блока уничтожается, то это не условность компилятора, а это происходит на самом деле - занимаемые ей регистры могут использоваться для других целей, если она была в стеке, то он сокращается, даже Keil для 8051, который хранит локальные переменные в обычной памяти, использует ее очень эффективно - если в функции имеется несколько блоков и в каждом объявляюся локальные переменные, то для них будут использоваться одни и те же ячейки памяти, более того - он строит дерево вызовов функций, благодаря чему переменные из "параллельных" функций также будут располагаться в одной области памяти, а для 8051 с ее объемом памяти это очень важно. Да и просто для понимания программы гораздо легче, когда действие переменной локализовано, в отличие от паскаля, где все переменные свалены в одну кучу независимо от их назначения, важности и области действия. Не говоря уже о том, что инициализация переменной сразу при объявлении гарантирует, что вы не станете использовать неинициализированную переменную.

На качество компилятора синтаксис языкавлияет самым непосредственным образом.

Я знаю. Эта стратегия - крайне неудачная. А контроль границ массива - абсолютно бесполезная фича, которая, однако, имеет сильное эмоциональное воздействие на молодые умы. Но почему-то никому из них не приходит в голову простой вопос: а что будет делать программа, если произойдет выход за пределы массива? Какой код сгенерирует компилятор? А ничего умного она сделать не сможет - она сообщит пользователю об ошибке и аварийно завершится. (Что будет делать она в микроконтроллере - даже не представляю). И чем это принципиально отличается от ошибки по обращению к несуществующей памяти? Контроль границ массива должен осуществлять сам программист - если индекс масива берется из данных, вводимых пользователем или читаемых из файла. Тогда он может выполнить некие осмысленные действия, зависящие от программы. А если индекс ограничивается константой, например, при инициализации массива, типа for(i = 0; i < ARRAY_SIZE; ++i) - то здесь проверять индекс просто глупо, он и так никогда не выйдет за пределы. Однако паскалевский компилятор все равно будет лепить код проверки.

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

Если ты про С++ то опять же неправда. Так не запрещается сложение char и int или указателя с целым. А те ограничения, котрые там есть, гораздо более логичны и последовательны, чем паскалевские.

В более-менее продвинутых компиляторах происходит несколько иначе - компилятор выделяет память один раз на входе в функцию и освобождает на выходе, а создает/уничтожает переменные "в уме", ибо двигать туда-сюда указатель стека на каждую переменную расточительно. Поэтому даже если все переменные объявлены в начале функции, он вычисляет для себя области использования каждой переменной и размещает непересекающиеся в одном и тот же месте. Т.е. объявление локальных переменных в блоке - это больше для удобства программиста.

подолью масла в огонь

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

теперь, когда Си учат едва ли не в школе, ареол тайны пропал, но "элитность" поддерживается - дескать, если ты настолько туп, чтобы не понять, как работать с указателем на указатель на функцию, возвращающую указатель на символ, то юзай паскаль - он для таких, как ты

и так оно и есть на самом деле: юниксоиды старательно поддерживают имидж своей крутости тем, что по делу и без дела "колдуют" в консоли, что для виндятников выглядит просто магически Сишники пишут виртуозные по всем параметрам коды, которые вызывают благоговейный трепет у паскалистов...

в общем, все это похоже на меряние писек взрослыми дядями

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

Размер не имеет значения

P.S. Во времена популярности Turbo C и Turbo Pascal неоднократно раскручивал "Сишников" (я тогда был студентом-адептом паскаля) на тест: экзешник хелловорда на паскале всегда получался на 12-15 килобайт меньше, чем на паскале а заполнение экрана посимвольно всегда завершалось быстрее, чем при сишной реализации. и это повергало Сишников (стаж работы годы против моих студенческих дней) в уныние, которое они "обоснованно" (при помощи Тurbo Debugger-а) доказывали тем, что printf Cи использует "стандартную" функцию MS DOS для вывода на дисплей, а "нестандартный паскаль" напрямую через прерывание BIOS действует. не правда ли, все это вызывает смех сейчас, когда хелловорд на любом языке перевалил за сотню килобайт и на трехгигагерцовом пне запускается порой 1,5 секунды

в паскале с указателями можно делать то же самое (правда, всегда нужно явное приведение типов, но это лучше чем в С без приведения).

кстати, многословность, строгий синтаксис, повышенные требования к объявлениям переменных, параметров функций - характеристика языков, на которых пишутся большие, высоконадежные системы - Ada, Eiffel, Java.