такая беда:



если определение TRectangleArray перенести во внутрь TRectangle, выводит: [DCC Error] Rectangle.pas(19): E2086 Type 'TRectangle' is not yet completely defined

как быть? без указателей возможно обойтись?

Разве что как-то так....

если функция Split будет назначаться извне
или

если будет описана внутри класса

Это сообщение отредактировал(а) MetalFan - 27.6.2007, 21:59

а почему при использовании практически методов ты используешь записи? переходи-таки на классы/объекты, как продемонстрировал товарищ MetalFan 
тем более, что для классов есть предварительное объявление(акцентирую внимание автора на втором фрагменте кода, приведенным MetaLFan'ом), а для записей такого нет...

да понятно что с классами таких проблем не будет  но нужны именно структуры, это порт внешней библиотеки которая в классах дельфи ни бум-бум. хочется изящества: ExternalFunction(rect), а не: ExternalFunction(rect.RealRect), и свойства враперы, и ненужный overhead по всем операциям: создания, взятия значений, присвоения, т.д. тем более, компилер (D2007) позволяет использовать хитрые структуры, со свойствами\методами\внутреннеми типами. придётся просто вынести метод из структуры в виде обычной процедуры. эх, дельфи-дельфи.. сыро-сыро, так хочется походить на C#, ан нет, всякие мелочи постоянно портят погоду.

никаких объективыных сложностей по реализации нормальной поддержки подобных конструкций компилером не вижу. понятное дело, когда массив у нас статический (TRecordArray = array[0..9] of TRecord), то не получится засунуть его в описание самого TRecord, т.к. размер TRecord не известен на момент определения TRecordArray, т.к., сам TRecord содержит TRecordArray. короче, цикличное описание. именно эту щекотливую ситуацию разработчики компилера решили радикально - полным запретом на использование подобных конструкций.

в тоже время статический TRecordArray в качестве пареметра одного из методов может быть использован без проблем, т.к. не меняет размер TRecord и передаётся по ссылке, если бы не полное табу наложенное разработчиками. динамический же массив - ссылка на реальные данные и не более того - четыри байта - размер всегда известен, т.е. поле этого типа может без проблем определяться внутри структуры и использоваться методами, но мы имеем всё тоже самое табу.

в общем, вот они прелести single-pass компиляторов. тут отчего-то захотелось продолжить монолог темой inline методов\процедур, ну да ладно..   


<offtop>
на дельфи кодю 10 лет, а вопросы для раздела новичков  
</offtop>

cully, 
Мдя... В борландах(CodeGear) могли бы и продумать такую ситуацию... :( Но можно извратиться 


Добавлено через 1 минуту и 45 секунд
Ход конем так сказать   

Rennigth, в этом случае, как и в случае использования классов, встаёт вопрос управления памятью, постоянное отслеживание, кто создал TRectangle? кто должен освободить?

ждём новую версию компилера, может там этот вопрос решат, хотя не верится что-то   

Нет. Зачем? Просто при использовании функции(или метода, незнаю как назвать даже) Split, передавай туда твой же TRectangle только с @. Работать с указателем надо будет только в самой Split.

Rennigth, кхм, в твоём коде, Split возвращает массив указателей, указатели должны на что-то указывать, если они будут указывать на локальные переменные Split, то после выхода из неё локальные переменные удалятся, указатели будут указывать на случайные данные. значит надо GetMem, FreeMem - ручное управление памятью.

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

просто вынес метод в процедуру.