Delphi Corner Weblog

The integration of C++Builder and Delphi seems to have caused a few problems for those of us who write components or classes in Delphi, and then want to use these in C++Builder. There are a few things one should avoid when one writes classes (see below), and the symbol BCB doesn’t seem to be defined when the Delphi compiler is called from C++Builder.

Some of the things one should not do are mentioned on the JVCL sourceforge pages.

One other thing is something I discussed elsewhere with someone. In Delphi, it is not unusual to create multiple constructors with different names which tell the user what they do.

A simple example I concocted up is below:

unit GraphicVectors;

interface

uses
  SysUtils, Classes;

type
  TGraphicVector = class(TObject)
  public
    constructor Create(X, Y: Double);
  end;

  TPolarVector = class(TGraphicVector)
  public
    constructor CreatePolar(Radial, Theta: Double);
  end;

implementation

This defines TGraphicVector, which takes two Cartesian coordinates, X and Y, both of type Double. And a descendant TPolarVector, which is internally almost the same, but can be defined using polar coordinates. So TPolarVector has two constructors, the one inherited from TGraphicVector, and CreatePolar, which accepts polar coordinates.

Constructors which differ only in name

Problem is, that both have two parameters of type Double. In Delphi, this is not a problem, because the constructors have different names. But C++ constructors do not have any names of their own. They get the name of the class for which they are defined.

So the .hpp file for the unit above contains this, for TPolarVector:

class DELPHICLASS TPolarVector;
class PASCALIMPLEMENTATION TPolarVector : public TGraphicVector
{
    typedef TGraphicVector inherited;

public:
    __fastcall TPolarVector(double Radial, double Theta);
public:
    #pragma option push -w-inl
    /* TGraphicVector.Create */ inline __fastcall
        TPolarVector(double X, double Y) : TGraphicVector(X, Y) { }
    #pragma option pop

public:
    #pragma option push -w-inl
    /* TObject.Destroy */ inline __fastcall virtual ~TPolarVector(void) { }
    #pragma option pop

};

You can see the problem above: there are two constructors TPolarvector(double, double). The first is TPolarvector.CreatePolar, the second is TGraphicVector.Create, which must be redeclared as TPolarVector to make it a constructor for TPolarVector as well. C++ does not allow two constructors with the same signature, so you will get two errors for the second declaration:

[C++ Error] GraphicVectors.hpp(49): E2238 Multiple declaration for ‘_fastcall TPolarVector::TPolarVector(double,double)’
[C++ Error] GraphicVectors.hpp(46): E2344 Earlier declaration of ‘_fastcall TPolarVector::TPolarVector(double,double)’

Conclusion

So, apart from what the JVCL pages describe, you should also avoid using constructors with the same signature but differing in name. It is best if you simply do not use any other constructor name than Create. If you need more than one, be sure to use the overload directive.

Share This | Email this page to a friend

Following up

I received a few interesting replies to my previous post about features Borland implemented in the Win32 compiler for Delphi, but "forgot" to document. I’m sure you can find them in the comments section, but I’d like to repeat them here.

Gerriz Beuze and Rossen Assenov mentioned some other features and I checked them. These seem to be valid in the Win32 personality of Delphi 2005 too:

• Default array properties can be overloaded, i.e. have the same name, as long as the signature, i.e. the array parameter list, is different.

  type
    TTestClass = class
    private
      function GetInts(index: Integer): Integer;
      procedure SetInts(index: Integer; const Value: Integer);
      function GetIntsS(Find: string): Integer;
      procedure SetIntsS(Find: string; const Value: Integer);
    public
      property Ints[index: Integer]: Integer read GetInts write SetInts;
        default;
      property Ints[Find: string]: Integer read GetIntsS write SetIntsS;
        default;
    end;
  

• Identifier escape char "&" is supported. You can do something like:

  var
    &object: TObject;
  

• Method directive "final" supported.
• Method directive "inline" is supported. But, unlike Gerrit claimed, it also works in .NET.
• Static class methods are supported.
• Class properties are supported:

    private
      class function GetClassProp: Integer; static;
      class procedure SetClassProp(const Value: Integer); static;
    public
      class property P: Integer read GetClassProp write SetClassProp;

• Compiler hint directive "experimental" is supported.

  unit SomeName experimental;

• Classes support the "abstract" and "sealed" directives.
• Classes can contain "const", "type" and "var" declarations:

  type
    TAbstract = class abstract
    public
      type
        TTestArray = array of Integer;
        TSealed = class sealed
          procedure DoIt(Param: Integer);
        end;
      const
        Cons = 13;
        ConsB: Integer = 12;
      var
        Y: Integer;
    end;
  

Some more

I found some more features, officially introduced in Delphi 8 and Delphi 2005 for the .NET compiler, which also work in the Win32 personality:

• Code folding regions:

  {$REGION 'private members'}
    // ...
  {$ENDREGION}

  This is not really a surprise, since they seem to be more an IDE feature than a language feature, but the language must still know them, and not throw an error.

• Dynamic initialization of dynamic arrays, using the Create syntax:

    type
      TDoubleArray = array of Double;
  
    var
      A: TDoubleArray;
      D: Double;
  
    begin
      A := TDoubleArray.Create(1.7, 3.9, 17.1, 39.7, 42.0);
      for D in A do
        Writeln(D:1:1);
      // etc...
  

  I’m not sure if that is actually documented anywhere, not even for the .NET compiler (where this already worked in Delphi 8, see the KnobControl demo control in the demos that come with Delphi).

But why undocumented?

It seems that some of them are not completely undocumented. The Borland Delphi 2005 Reviewer’s Guide discusses the Win32 compiler (page 59ff.). It mentions function inlining, nested types, strict private, nested consts, support for Pentium 4 SSE3 and SSE2 instruction opcodes and data types, and XML document generation (some of which I hadn’t even noticed). A BDN article by Bob Swart mentions a few new features as well, but for .NET. I tried them in Win32, and they don’t compile.

I’m not sure why the rest is undocumented though, and why Borland is not advertising these new features. Perhaps they were not finalized yet, and Borland doesn’t want to support them, right now. Perhaps they were simply forgotten in the documentation. But the fact that they are undocumented means that you should take extreme care when you use these features. One problem I noticed is with class helpers.

Class helpers

In the previous post, I mentioned class helpers. They do work, but if you try to derive from a "helped" class, you might get an internal compiler error, which means that the implementation is not fully OK yet. Like I said, always use undocumented features with care.

Share This | Email this page to a friend