* * *

Author Topic: Nested generics (in Delphi mode) => Fatal exception, compiler 3.0.2 crashes  (Read 320 times)

SirTwist

  • Newbie
  • Posts: 3
Hi Guys,

I have a problem with using generics and perhaps someone has a few good hints (beside the "do not use generics"). I worked with an own unit "msBaseObjs" with an TmsObj and TmsList<T: TmsObj>=class(TObjectList<T>)... since the times Delphi started supporting generics without crashes ;-)

Now I am working on a rather big project for some months, heavily using this "BaseObjs" for nearly every data structure I have. Yesterday, from one compiler run to the next, the compiler crashes when processing the "interface" section of one of the nested data units. I started a new, empty project and just copied the data units to this new project, but the compiler still crashes. I stripped down the data units to the three units which are nested, and it still crashes. But this construct was working before for several weeks.

In unit UmsOptions:
Code: Pascal  [Select]
  1.   uses BaseObjs;
  2. ...
  3.   TmsOptionEntry = class(TmsObj)
  4.     ...
  5.   end;
  6.   TmsOptionEntries<T: TmsOptionEntry> = class(TmsList<T>)
  7.      ...
  8.   end;
  9.  

In unit UmsImports:
Code: Pascal  [Select]
  1. uses UmOptions;
  2. ...
  3.   TmsImporter = class(TmsOptionEntry)
  4.     ...
  5.   end;
  6.   TmsImporters = class(TmsOptionEntries<TmsImport>)
  7.   public
  8.     ...
  9.   end;
  10.  

I inserted {$HINT "..."} before the TmsImporters = ... and between this line and the following "public" and the compiler does not reach the second {$HINT "..."}.

Any hints on that?

Sorry, forgot to say: FPC 3.0.2 on Win7/64, with Lazarus 1.6.4

Kind regards, and thanks in advance,
Sir Twist
« Last Edit: May 16, 2017, 07:15:07 pm by SirTwist »

Mr.Madguy

  • Jr. Member
  • **
  • Posts: 99
Yeah, I use generics very heavily too. That's, why I have to put their implementations into separate Dll, that weights almost 3Mb for 32bit version and almost 5Mb for 64bit one.  :o Delphi puts enormous amount of meta-data into it's modules.  %)

And they're very tricky - they often cause "Internal compiler errors" even in Delphi. For example in Delphi construction like TAbstactPairList<Integer, TAbstractPairList<String, TAbstractPairList<Boolean, TAbstractPairList<Double, TSomeObject>>>> works fine, but TAbstactPairList<Integer, TAbstractPairList<String, TAbstractPairList<Integer, TAbstractPairList<Double, TSomeObject>>>> all of a sudden causes internal compiler error. Code of actual TPairList implementation is very large, so it's very hard to localize source of this error. Usually I have to perform some nasty tricks to avoid such problems. Yeah, I know, that I love to push compilers to their limits, but that's my style.
« Last Edit: May 16, 2017, 09:24:30 pm by Mr.Madguy »

ASerge

  • Sr. Member
  • ****
  • Posts: 281
  TmsImporter = class(TmsOptionEntry)
    ...
  end;
  TmsImporters = class(TmsOptionEntries<TmsImport>)
  public
  end;
Type names are different.

 

Recent

Get Lazarus at SourceForge.net. Fast, secure and Free Open Source software downloads Open Hub project report for Lazarus