Мне вот интересно, хоть кто-то портировал старый проект на Delphi .NET? Какой в этом профит? Паникеры же, при выходе Delphi 8, скорее всего, сразу капитулировали перед MS. Призма, точнее компилятор изначально продукт сторонний, но как компилятор Паскаля для .NET он никому не мешает, пусть и разницы там между языками 0, только шарп равнее других.   
Смысла в переделывании VCL под .NET, где и так есть аналогичная библиотека я никакого не вижу. На .NET по-моему вообще ловить остальным нечего, полностью подконтрольная MS территория.

Ну дык кто мешает исполнять? И не надо путать теорию с практикой. Удобнее и комфортнее когда я сам могу решить где объявлять. Ну да - это источник опечаток.

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

Вообще если послушать сишников, то они write only-программисты, порождающие код со скоростью печати.

Не понимаю чем это может помочь. Чем ближе к месту использования объявлена тем лучше. Зачем делать областью видимости переменной весь метод, когда реально она используется только в одном блоке?

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

Alexeis, от привычки зависит. Опыт портирования говорит мне, что в паскале менее удобнее

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



Шанс удалить нужную переменную которая объявлена "по месту", намного ниже чем переменную объявленную где-то в другом месте. Ну и плюс это никак не решает проблему

А доводы типа:

это какое-то абстрактное философствование.

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

  Счетчик цикла не должен быть доступен везде.  Паскаль не позволяет его объявлять локально, зато громко материться при попытке задейстовать его вне цикла. Более того, он даже скажет, что счетчик при возможности оптимизируется регистром и его значение после цикла может быть неопределенным. Согласен, что вынос его не особо помогает, зато определение переменных вначале быстро отучивает писать функции на сто листов, заставляет программиста разбивать задачи на небольшие функции, которые решают одну свою задачу. В общем язык сам способствует улучшению качества кода. 
  С++ же не ограничивает программиста в возможностях по написанию ###кода. Для начинающего программиста С++ просто находка. Столько ошибок можно накосячить! Конечно, тонкие намеки паскаля, порой слишком тонкие   , так что безусловно чудят. Учитывая что порог вхождения в паскаль на порядок ниже чем в С++, то и процент "чудо-кода" выше, но те кто продолжают работать на паскале и дальше, потом не променяют его на С++ .

Структура процедурки на Паскале:

procedure ProcName
var <Список локальных параметров>
<Локальные процедурки> // сишникам завидовать
begin
<Тело процедуры>
end;

Объясните мне, как даже самых зверских правок между begin и end могут пострадать локальные переменные? У меня с точностью до наоборот, функция искромсана, но переменные живут, периодически можно посмотреть хинты при компиляции, что never used и почистить, но лишнего точно не сотрешь.



Кстати, с этим в Delphi жестко, счетчик обязан быть локален и всегда ReadOnly.

for i:=0 to 10 do Inc(i) просто не скомпилируется. И я на это пару раз попадал.

Что же касается Си, то в Си цикла for нет вообще, есть while в котором изменение контрольных переменных перенесено. 
И вот такое вот ****



У меня сейчас Билдер сожрал и даже варнинга не выдал.

Это точно так же и на паскаль распространяется, выделили неиспользуемую переменную, зацепил, снес и далее по тексту.




Это касается только цикла for, а вот если мне надо реализовать не "цикл от 1 до N", а что-то более сложное, то тут уже компилятор не поможет.



Далеко не всегда это можно сделать, вернее не всегда это имеет смысл.

Интересно, а итераторы в делфях уже есть?

Вообще-то я тему поднял именно вопросом, что есть в плюсах, чего нет в Delphi. Навскидку могу только вспомнить функции с переменным числом аргументов, которые вот сколько пишу ни разу не понадобились за исключением встроенных вроде WriteLn. Итератор, слово-то. for each давно есть, хотя я не юзаю, да и раньше проблем с перебором никаких не было. Х)

пример можно?

Если коротко из справки, то:



Дальше там еще много интересного, хотя пока есть TList<T> и TCollection<T>, которые можно спокойно через for i:=0 to Count-1 перебрать, вряд ликто-то будет сидеть и писать свои энумераторы.