0

I'm writing a Delphi package with RAD Studio XE7. I recently faced a strange access violation, and I cannot figure out why it happened. The context was that I was trying to maintain a list of font names. So I declared the following type:

ICustomFontList = TList<UnicodeString>;

Inside one of my classes, I declared a variable as follow:

m_pCustomFontList: ICustomFontList;

Then, in the constructor, I tried to instantiate this variable like that:

m_pCustomFontList := ICustomFontList.Create;

I compiled the package, and created a C++ project that used the code. However I gained a strange access violation every time the m_pCustomFontList was instantiated in the constructor, on the Begin line of the following code (located inside System.Generics.Collections.pas) :

constructor TList<T>.Create;
begin
    Create(TComparer<T>.Default);
end;

Later I found that a TStringList was a better choice for my values, and I changed to that type. From this moment, the above mentioned access violation never reappeared. However I cannot understand what the problem was. I create several TList (or derived like TObjectList) in my packages and I never faced a such problem with any other kind of TList I declared (i.e. other than TList of UnicodeString). So can anybody explain to me why this particular TList generated an access violation on construction? Theoretically, nothing prevent to create a TList of UnicodeString if it's my desire, or I'm wrong?

Regards

--- EDIT on the 15.02.2017

Here is a small example that reproduce the issue on my computer. For that a package project in Delphi should be created, and a C++ VCL forms application project that will use this package. In the package, create a new unit and copy the following code:

unit Unit1;

interface

uses System.Generics.Collections;

type
    ICustomFontList = TList<UnicodeString>;

    TaClass = class
        private
            m_pCustomFontList: ICustomFontList;

        public
            constructor Create; virtual;
    end;

implementation
constructor TaClass.Create;
begin
    inherited Create;

    m_pCustomFontList := ICustomFontList.Create;
end;

end.

In the c++ project, simply add this line in the constructor of TForm1:

std::auto_ptr<TaClass> paClass(new TaClass());

then build the package and run the project

Regards

Martijn Pieters
  • 1,048,767
  • 296
  • 4,058
  • 3,343
Jean-Milost Reymond
  • 1,833
  • 1
  • 15
  • 36
  • Are you using C++ Builder? again please provide a [MCVE](http://stackoverflow.com/help/mcve), we are missing some important details here... – whosrdaddy Feb 14 '17 at 16:31
  • `TStringList` isn't necessarily better. It carries a lot more baggage. Do things change if you use `TList` or `TList` rather than your alias? – David Heffernan Feb 14 '17 at 16:55
  • Agreed, there is not enough information here to say what's going wrong. Please consider providing a [mcve]. – J... Feb 14 '17 at 18:36
  • @David: yes, the result is the same with a TList of string instead of UnicodeString. For the others, a complete (but small) project with the issue can be downloaded here: https://drive.google.com/open?id=0B7C-RwCTA9qaYk5RMklFN1puZzg – Jean-Milost Reymond Feb 14 '17 at 19:40
  • `ICustomFontList` in package and `ICustomFontList` in exe are different classes. You can verify this by compare `m_pCustomFontList.ClassType` and `ICustomFontList` inside and outside of the package. May be it is the root of the problem. This behavior can be fixed by declaring different class, for example `ICustomFontList = class(TList)`. – Michael Izvekov Feb 15 '17 at 04:19
  • Unfortunately this not works, making a class before TList does not resolve the issue. Furthermore the m_pCustomFontList is created inside the package, not outside, and the creation itself raises an exception, so I cannot test the m_pCustomFontList.ClassType. – Jean-Milost Reymond Feb 15 '17 at 12:24
  • This was a compiler bug that was fixed in Rad Studio 10.2 Tokyo (https://quality.embarcadero.com/browse/RSP-14274) – LachlanG Sep 29 '22 at 07:20

0 Answers0