То ли лыжи не едут...

← →
Dimka Maslov © (2013-01-11 21:57) [0]

Пишу прогу. В проге есть модуль. В модуле куча различных классов. Ввожу ещё один класс. В классе метод. Нажимаю Shift+Ctrl+C. Класс разворачивается в implementation. Всё нормально. Компилирую. Получаю такую ошибку: http://www.daemys.com/f/bug.jpg

Дичь какая-то. Но происходит на двух разных машинах. Причём только если в рамках данного проекта в данном модуле объявлен класс с таким именем. Независимо от предка. Независимо от настроек проекта (он пересоздавался заново). Независимо от расположения относительно других классов и методов. Если класс обозвать по другому - всё работает. Что же это такое делается?

← →
alexdn © (2013-01-11 22:01) [1]

Это потому что XP и Delphi 2006 помоему..

← →
Игорь Шевченко © (2013-01-11 22:02) [2]

По uses ни с кем не пересекаешься с идентификатором, объявленным с таким же именем ?

← →
Dimka Maslov © (2013-01-11 22:03) [3]

2009. И чем этой парочке не нравится TBucklingPlateItem в модуле shprenClasses проекта shpren.plugin?

← →
Dimka Maslov © (2013-01-11 22:04) [4]

> Игорь Шевченко © (11.01.13 22:02) [2]

Нет. Такого имени нигде больше нет.

← →
alexdn © (2013-01-11 22:08) [5]

Не едут. Ошибку строчкой выше видел?

← →
Аббат Пиккола (2013-01-11 22:08) [6]

Я бы проверил, что я имею в виду, говоря "Если класс обозвать по другому - всё работает":

1. сначала стер бы букву m
TBucklingPlateIte.Proc
2. затем букву e
TBucklingPlateIt.Proc

и так далее.
Можно, конечно, и короче - делением пополам.
Может сдуру в имени класса одна буква русская, к примеру.

← →
Dimka Maslov © (2013-01-11 22:11) [7]

> Не едут. Ошибку строчкой выше видел?

Она вроде как пустая. А выше комментарий. И если переименовать класс то всё работает.

> Аббат Пиккола (11.01.13 22:08) [6]

Пробовал. Реагирует только на такое имя.

← →
Dimka Maslov © (2013-01-11 22:12) [8]

> Может сдуру в имени класса одна буква русская, к примеру.

Хоть греческая. Всё должно работать.

← →
Игорь Шевченко © (2013-01-11 22:13) [9]

По uses ни с кем не пересекаешься с идентификатором, объявленным с таким же именем ?

← →
Аббат Пиккола (2013-01-11 22:16) [10]

Безумная идея: может dcu-файлы датированы как-то не так, а дата слетела из-за того что XP время опять отыграло на час из-за перевода времени? Может удалить dcu принудительно?

← →
Dimka Maslov © (2013-01-11 22:16) [11]

> По uses ни с кем не пересекаешься с идентификатором, объявленным
> с таким же именем ?

Ни по uses, ни вообще никак. Такого имени нигде больше нет. Специально даже полный поиск по всем pas файлам на диске делал. И даже бы если пересекался, то такого быть не должно.

← →
Аббат Пиккола (2013-01-11 22:17) [12]

Если я верно помню, Delphi смотрит на дату и время редактирования файлов при перекомпиляциях

← →
alexdn © (2013-01-11 22:17) [13]

> Dimka Maslov © (11.01.13 22:16) [11]
А переименовываешь на что? просто интересно, ну когда работает.

← →
Dimka Maslov © (2013-01-11 22:17) [14]

> Безумная идея: может dcu-файлы датированы как-то не так,
> а дата слетела из-за того что XP время опять отыграло на
> час из-за перевода времени? Может удалить dcu принудительно?
>

Удалялось всё, все настройки проекта (пересоздавался заново), все dcu, все временные файлы. Не помогает. Только переименовать класс. Но хочется разобраться, что за хрень вообще такая.

← →
Dimka Maslov © (2013-01-11 22:19) [15]

> А переименовываешь на что? просто интересно, ну когда работает.

Во что угодно, хоть TBucklingPlateItem_, хоть TBucklingPlate, хоть вообще что.

← →
Аббат Пиккола (2013-01-11 22:19) [16]

Пробовал удалить dcu этого модуля?

← →
Dimka Maslov © (2013-01-11 22:20) [17]

> Пробовал удалить dcu этого модуля?

Все dcu проекта

← →
Аббат Пиккола (2013-01-11 22:22) [18]

А при помещении этого же класса в другой модуль все работает?

← →
Dimka Maslov © (2013-01-11 22:24) [19]

> А при помещении этого же класса в другой модуль все работает?

Да, работает.

← →
Аббат Пиккола (2013-01-11 22:26) [20]

7100 строк... Дубликат объявления точно исключен? Проверял поиском ?

← →
Аббат Пиккола (2013-01-11 22:26) [21]

Хотя - нет, на дубюликат было бы другое сообщение...

← →
Dimka Maslov © (2013-01-11 22:26) [22]

> Проверял поиском ?

Дважды по всему компу.

← →
Аббат Пиккола (2013-01-11 22:30) [23]

Попробуй создать новый проект, засунуть туда только этот модуль и отклмпилировать

← →
Dimka Maslov © (2013-01-11 22:36) [24]

> Попробуй создать новый проект, засунуть туда только этот
> модуль и отклмпилировать

Только этот модуль вне проекта не живёт. Он от второго модуля сильно зависит. А создавать новый проект с нуля я пробовал на двух компах - симптоматика одинаковая

← →
Dimka Maslov © (2013-01-11 22:37) [25]

При этом прыгалка между interface и implementation работает. Проблема только при компиляции возникает.

← →
Игорь Шевченко © (2013-01-11 22:41) [26]

> Дважды по всему компу.

Я бы проверил не только pas файлы но и *.*

← →
Dimka Maslov © (2013-01-11 22:49) [27]

> Я бы проверил не только pas файлы но и *.*

Нет такого файла. Даже если и был, что чисто теоретически, как это может спровоцировать подобное поведение?

← →
Игорь Шевченко © (2013-01-11 22:53) [28]

Dimka Maslov © (11.01.13 22:49) [27]

Чисто теоретически с таким именем может быть объявлен не класс в каком-то dcp или dcu

← →
Dimka Maslov © (2013-01-11 22:58) [29]

> Dimka Maslov © (11.01.13 22:49) [27]

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

← →
брат Птибурдукова (2013-01-11 23:00) [30]

было подобное в проекте com-сервера в *_tlb.pas, но тут же явно не та ситуация. Я б предположил, что в Users\...\Rad studio\... лежит вражеская дцуха и планомерное поедает мозг — но автор утверждает, что такого нет.

← →
Аббат Пиккола (2013-01-11 23:03) [31]

А если пойти на поводу у этих сообщений и поставить (хоть это и глупо) ";" после имени класса? Как будут выглядеть сообщения?

TBucklingPlateItem;.Proc

← →
Dimka Maslov © (2013-01-11 23:10) [32]

> Аббат Пиккола (11.01.13 23:03) [31]

Лучше не становится. Declatation expected but "." found (что естественно). Если убрать .Proc Unsatisfied forward or external declaration: "TBucklingPlateItem.Proc". Что тоже естественно.

← →
Аббат Пиккола (2013-01-11 23:10) [33]

А если вообще удалить реализацию метода, оставив только объявление в интерфейсе? Как будут выглядеть сообщения?
Вообще я сталкивался с подобным поведением, только когда имеется несколько мест с одинаковым объявлением, компилятор пытается использовать один файл, а IDE останавливается на строке в совсем ином файле. Они почему-то работают достаточно "независимо" друг от друга.

← →
Dimka Maslov © (2013-01-11 23:10) [34]

← →
Dimka Maslov © (2013-01-11 23:11) [35]

> А если вообще удалить реализацию метода, оставив только
> объявление в интерфейсе? Как будут выглядеть сообщения?

Unsatisfied естественно будет. И объявляется один раз.

← →
Аббат Пиккола (2013-01-11 23:12) [36]

То есть сообщения об ошибках явно изменились...

← →
Dimka Maslov © (2013-01-11 23:15) [37]

> То есть сообщения об ошибках явно изменились...

Причём изменились на абсолютно правильные. Забавно другое. Если методу добавить аргументов, он начинает ругаться ещё и на закрывающую скобку, требуя на её месте точку с запятой. Дичь какая-то.

← →
Аббат Пиккола (2013-01-11 23:16) [38]

Ладно, а можно закомментировать все остальные (ну или максимум, сколько возможно) классы в этом модуле?

Разборщик явно путается в begin end, точках и точках с запятой. Есть возможность выбросить остальной код, чтобы он никак не мешал? Да. кстати, а там нет каких-нибудь директив компилятору с ветвлениями? Вроде IFDEF

← →
Аббат Пиккола (2013-01-11 23:20) [39]

{$IFDEF}

← →
Dimka Maslov © (2013-01-11 23:21) [40]

> Аббат Пиккола (11.01.13 23:16) [38]

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

← →
Аббат Пиккола (2013-01-11 23:21) [41]

Хотя вряд ли это зависело бы от имени класса. Скорее важно было бы расположение объявлений в тексте, если бы дело было в этом. Главное непрятно то, что не ясно, как это локализовывать. Не гадать же в самом деле...

← →
Аббат Пиккола (2013-01-11 23:23) [42]

А если метод Proc переименовать? Не нравится мне это имя чем-то... То же самое?

← →
Dimka Maslov © (2013-01-11 23:26) [43]

> А если метод Proc переименовать? Не нравится мне это имя
> чем-то... То же самое?

Ои имени метода это тоже не зависит. Изначально там было несколько методов с нормальными именами (пустые методы из класса выше на картинке) и на всех их оно ругалось.

← →
Аббат Пиккола (2013-01-11 23:26) [44]

А если и объявление класса сделать в Implementation?

← →
Аббат Пиккола (2013-01-11 23:28) [45]

Переместить объявление класса из interface в implementation.

← →
Dimka Maslov © (2013-01-11 23:29) [46]

> А если и объявление класса сделать в Implementation?

Тогда компилирует. Бред какой-то получается.

← →
Аббат Пиккола (2013-01-11 23:31) [47]

Ну хоть как-то набрели на след...

← →
Аббат Пиккола (2013-01-11 23:33) [48]

А если оставить все это в implementation, а в interface добавить только предварительное объявление класса:

TBucklingPlateItem = class;

← →
Dimka Maslov © (2013-01-11 23:34) [49]

> Ну хоть как-то набрели на след...

След чего? В тексте больше нет нигде и ничего с таким именем.

← →
Аббат Пиккола (2013-01-11 23:36) [50]

След в том смысле, что класс с данным именем может компилироваться, если объявлен в другом месте модуля. Попробовал добавит ЕЩЕ И предварительное объявление (абстрактное) в интерфейсе?

TBucklingPlateItem = class;

← →
Dimka Maslov © (2013-01-11 23:36) [51]

> А если оставить все это в implementation, а в interface
> добавить только предварительное объявление класса:

А разве так вообще можно? Предварительное описание класса не работает даже если находится в разных type

type
TC1 = class;
type
TC1 = class (TObject);

Уже несработает.

← →
Аббат Пиккола (2013-01-11 23:40) [52]

Если ошибка вернется, значит модуль НЕ ЛЮБИТ именно это имя в секции intrerface. Это наталкивает на мысль, что причину проблемы нужно искать за пределами этого файла (в других файлах). Так как переменные в части implementation обычно скрыты от остального проекта (если только их не хакнуть специальными приемами с наследованием). И тогда пофиг, как класс там назван.

← →
Dimka Maslov © (2013-01-11 23:41) [53]

> След в том смысле, что класс с данным именем может компилироваться,
> если объявлен в другом месте модуля. Попробовал добавит
> ЕЩЕ И предварительное объявление (абстрактное) в интерфейсе?
>
>

Класс именно с таким именем мне не нужен я его и переименовать могу. Просто хочется понять, что же сделано не так... А предварительное описание попробовал. Не помогло. Пойду спать. Утро вечера мудренее.

← →
Аббат Пиккола (2013-01-11 23:44) [54]

2 Dimka Maslov © (11.01.13 23:36) [51]

Ты прав. Это работает только в пределах одного объявления type

← →
Аббат Пиккола (2013-01-11 23:45) [55]

Да я понял. Мне и самому интересно. OK

← →
Eraser © (2013-01-12 13:09) [56]

А если по-новее делфи поставить или же накатить все имеющиеся апдейты на этот? Просто иной раз как посмотришь на список исправлений в каком-нибудь апдейте.

← →
TUser © (2013-01-12 13:31) [57]

Я бы попробовал dcc32 или как он там называется. Иногда консольный компилятор может больше сказать, чем IDE.

← →
Dimka Maslov © (2013-01-12 19:19) [58]

> А если по-новее делфи поставить

Не дают, уже давно прошу

> Иногда консольный компилятор может больше сказать, чем IDE.

А IDE не надстройка ли над консольным, которая транслирует его сообщения?

← →
Eraser © (2013-01-12 19:36) [59]

> Dimka Maslov © (12.01.13 19:19) [58]

ну, допустим, новую версию не дают, а ападейты то текущей версии все установлены?

> а ападейты то текущей версии все установлены?

Там автообновлятор работает

Корень зла найден. Всё заработало после того, как реализация класса была «поднята» выше метода другого класса, внутри которого объявлялся тип.

procedure TSectionProperties.AfterConstruction; type TSectionShapeClass = class of TSectionShape; const Classes: array[Low(FShapes)..High(FShapes)] of TSectionShapeClass = (TISection, TIOrthoSection, TUpperOpenBoxSection, TLowerOpenBoxSection, TBoxSection); var i: Integer; begin inherited; for i := Low(FShapes) to High(FShapes) do FShapes[i] := Classes[i].Create(Self); List.TestNameFunc := nil; end;

После выноса объявления типа за границы метода всё нормально заработало. Остаётся неясно, почему стало глючить только при таком имени нового класса, ибо ниже нормально уживалась реализация нескольких десятков классов.

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

← →
брат Птибурдукова (2013-01-14 12:49) [62]

> Classes: array[Low(FShapes)..High(FShapes)] of TSectionShapeClass
Вот за такое нас в институте 100% на пересдачу отправляли… %-)

> брат Птибурдукова (14.01.13 12:49) [62]

а что не так и как надо было сделать на пересдаче?

← →
брат Птибурдукова (2013-01-14 13:08) [64]

надо было
type
TSectionShapeClass = class of TSectionShape;
TSectionShapeClassIndex = Low(FShapes)..High(FShapes);
TSectionShapeClassArray = array [TSectionShapeClassIndex] of TSectionShapeClass;
const
Classes: TSectionShapeClassArray =
(TISection, TIOrthoSection, TUpperOpenBoxSection, TLowerOpenBoxSection, TBoxSection);

Впрочем, мы изучали классический виртовский паскаль, кое-как эмулируемый турбо паскалем ;-)

а если ещё проще?
Classes: array[FShapes] of TSectionShapeClass;

> брат Птибурдукова (14.01.13 13:08) [64]

К чему плодить лишние сущности, используемые к тому же исключительно локально.

> RWolf © (14.01.13 13:11) [65]

Проблема не из-за const была, а из-за type. А FShapes - это вообще массив. Но дело не в этом.

← →
брат Птибурдукова (2013-01-14 13:19) [67]

> К чему плодить лишние сущности
Для виртовского паскаля они не лишние, если верить преподу. Суть в том, что формально type a=1..10; b=1..10; — разные типы, несовместимые...

> Проблема не из-за const была, а из-за type
А вот не факт...

> Для виртовского паскаля они не лишние,

Т.н. «стиль» сам по себе излишество.

> А вот не факт...

Факт. После убирания type из метода глючить перестало.

← →
брат Птибурдукова (2013-01-14 13:25) [69]

ок, пусть будет факт. мне за споры денюжку не платят.

Главное щас не спорить, а донести информацию до других, что может быть причиной проблем с дельфёю.

Dimka Maslov © (14.01.13 12:46) [61]

Я объявляю локально type в методах, с подобной проблемой не сталкивался ни разу.
Возможно, стоит в QC написать

брат Птибурдукова (14.01.13 13:08) [64]

> надо было
> type
> TSectionShapeClass = class of TSectionShape;
> TSectionShapeClassIndex = Low(FShapes)..High(FShapes);
> TSectionShapeClassArray = array [TSectionShapeClassIndex]
> of TSectionShapeClass;
> const
> Classes: TSectionShapeClassArray =
> (TISection, TIOrthoSection, TUpperOpenBoxSection, TLowerOpenBoxSection,
> TBoxSection);

Жестоко

если мне надо объявить массив array[Boolean] of TFoo
я должен писать
type
BooleanIndex = Low(Boolean)..High(Boolean)
и
array[BooleanIndex] of TFoo

?

в VCL пишут просто

BoolStrs: array [Boolean] of ShortString = ("FALSE", "TRUE");

> Я объявляю локально type в методах, с подобной проблемой
> не сталкивался ни разу.
> Возможно, стоит в QC написать

Я тоже объявляю и до этого с проблемами не сталкивался. Тем более с таким их проявлением. А писать в QC всё равно, что в блог Медведева - толку мало будет. Главное знать об ошибке и уметь её обходить.

> толку мало будет

толку будет больше, потому что ты поможешь другим людям. Про delphimaster знает куда как меньшее количество программистов, чем про QC

← →
брат Птибурдукова (2013-01-14 14:23) [74]

> если мне надо объявить массив array[Boolean] of TFooя должен
> писать
Зачем? Есть уже готовый перечислимый тип — Boolean.

← →
брат Птибурдукова (2013-01-14 14:23) [75]

э... не перечислимый, а ordinal. Как это по-русски — упорядоченный?

брат Птибурдукова (14.01.13 14:23) [75]

Так у TC вроде не менее упорядоченный тип есть :)

← →
Аббат Пиккола (2013-01-14 17:07) [77]

Я никогда не объявлял типы в методах. И не сталкивался в VCL стакой практикой (возможно проглядел...). А что, есть такая документированная возможность? Можно пример из VCL?

> Аббат Пиккола (14.01.13 17:07) [77]

В VCL может и нет такого примера, но правилами это нигде явно не запрещено (иначе ошибка возникла бы сразу и была бы что-то типа Nested types not allowed)

Смысл такого локального типа только один - чтобы не заполнять лишними сущностями Structure, особенно когда идентификаторов много.

> Смысл такого локального типа только один

Смыслов больше, если тип относится к области действия только одной процедуры, то ему самое место внутри этой процедуры. Это называется инкапсуляция :)

← →
Аббат Пиккола (2013-01-14 17:22) [80]

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

Респект за упорство. :)

← →
брат Птибурдукова (2013-01-14 17:36) [81]

> Игорь Шевченко © (14.01.13 16:51) [76]
Неведомо. Я уверен, что у Low(FShapes) есть более приличный "псевдоним", но в приведенном коде такового нет — я исходил из кода примера :-)

> Аббат Пиккола (14.01.13 17:07) [77]
Ну в паскале вроде как структура подпрограмм полностью повторяет структуру программы (uses — более поздняя придумка, их в паскале оригинальном нет).

> Игорь Шевченко © (14.01.13 17:20) [79]

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

> Я уверен, что у Low(FShapes) есть более приличный "псевдоним"

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

брат Птибурдукова (14.01.13 17:36) [81]

Вообще-то если у типа есть Low, то он упорядочен, не ? :)

← →
брат Птибурдукова (2013-01-14 18:20) [84]

Я имел в виду, что тип мог не быть задан явно

То ли лыжи не едут... Найти похожие ветки