From the documentation: "An abstract class is a class that cannot be instantiated directly. Instead, a descendent class must always be instantiated. However, for Delphi compatibility, the compiler ignores this directive."

Why does this get ignored and what does this have to do with Delphi? I personally would like for this to actually work and give a compiler error if you instantiate the abstract class.

Regards,
Ryan Joseph

Ryan Joseph wrote

From the documentation: "An abstract class is a class that cannot be instantiated directly. Instead, a descendent class must always be instantiated. However, for Delphi compatibility, the compiler ignores this directive." Why does this get ignored and what does this have to do with Delphi? I personally would like for this to actually work and give a compiler error if you instantiate the abstract class.

The compiler will generate a warning in case you instantiate a class that is abstract or has abstract methods. You can escalate these warnings to errors if you need:

=== code begin ===

program tabstract;
{$MODE OBJFPC}
{$WARN CONSTRUCTING_ABSTRACT ERROR}
type
   TAbstract1 = class abstract
   end;
   TAbstract2 = class
     procedure Test; virtual; abstract;
   end;
var
   a1: TAbstract1;
   a2: TAbstract2;
begin
   a1 := TAbstract1.Create;
   a2 := TAbstract2.Create;
end.

=== code end ===

This will generate two (different) errors.

With this we're allowing more than Delphi does (which warns in the second case, but the warning can not be escalated to error and does not warn for the first case at all), but Delphi compatbility is more important here, thus the default is a warning and not an error. This will not be changed.

Regards,
Sven

On Apr 17, 2021, at 3:09 PM, Sven Barth wrote: The compiler will generate a warning in case you instantiate a class that is abstract or has abstract methods. You can escalate these warnings to errors if you need:

It's probably not practical to put that warning into all potential files but a warning is still probably good enough as a reminder. It's curious though why it's not an error by default, because if the class is abstract and you instantiate it and try to use it things are going to fail anyways so why does the compiler allow it in the first place?

Regards,
Ryan Joseph

My own code will have cases where I have only implemented some of the abstract methods for some classes, in principle because the code is incomplete, but there are also case where it never makes sense to implement them and calling them indicates a logical error elsewhere in the code.

Colin

As I have said: Delphi compatibility.

Regards,
Sven

C Western wrote

but there are also case where it never makes sense to implement them and calling them indicates a logical error elsewhere in the code.

So do the logical thing... Throw an exception! Don't promote a faulty compiler. Fix your code instead.

Regards,
Graeme

Sven Barth wrote

but Delphi compatbility is more important here, thus the default is a warning and not an error.

How is this beneficial? The compiler should help the developer, but here it was decided that it's beneficial for the program to crash at runtime, because follow the broken Delphi compiler is more important! *shrug*

Such decisions really make me worry about the future of FPC. It ends up being NO better than Delphi, so why bother using FPC then. Stick to Delphi instead.

Regards,
Graeme

People who want to compile code in both FPC and Delphi are developers too. People who want to use their knowledge of Delphi to program in FPC are developers too.

You can never make everyone happy, and sometimes we go for incompatibility by default, and sometimes we don't. In this case, you can easily make it an error yourself with {$warn 4046 error}.

Such decisions really make me worry about the future of FPC. It ends up being NO better than Delphi, so why bother using FPC then. Stick to Delphi instead.

It's not like this is a new policy that you just discovered, so please stop already with the flamebait drama about how this makes you worry about the future of FPC.

Jonas

If you're willing to pay for me to obtain a delphi license, then I'd happily switch.  Seeing as how they charge over a thousand dollars even during their supposed sales, I have no interest in spending that kind of money for an environment that FPC offers for free. That means I don't have to spend my limited income on a license for a program I use a few times a year.

Admittedly, part of the reason I use it so rarely is because I really need to dig into it's gui and tcp capabilities (I program from the ocmmand prompt, but being able to generate gui screens on the fly would be nice).  I know Delphi can do this, but the last time I asked them about pricing, they told me it'd cost $1000 for just delphi 7, and that only costed $995 when it first came out, nearly 20 years ago.  I refuse to support that kind of price gouging, even if I could afford it.

But, as I said, if you're willing to foot the bill, I'd happily use it, as it does indeed have (some) advantages.

On Apr 18, 2021, at 5:00 AM, Sven Barth wrote: As I have said: Delphi compatibility.

This would have been a good candidate to put behind the delphi mode switch but I'm sure there is a reason for this also.

Regards,
Ryan Joseph

PM Travis Siegel wrote

... but the last time I asked them about pricing, they told me it'd cost $1000 for just delphi 7, and that only costed $995 when it first came out, nearly 20 years ago.

Wow!
Long time ago, I bought Delphi2 (it was bundled with Delphi 1, and that was the one I needed, since I was on Win 3.10) for about ƒ200. (€1.00 = ƒ2.20).
It came with a full manual (on paper that is).

Those were the days....

Jonas Maebe wrote

In this case, you can easily make it an error yourself with {$warn 4046 error}.

Correction: that's make it an error to construct a classes that contain abstract methods. For abstract classes, it's {$warn 4122 error}

Jonas

Jonas Maebe via fpc-pascal schrieb am
So., 18. Apr. 2021, 21:19:

Or as I had written already: {$WARN CONSTRUCTING_ABSTRACT ERROR}. This will switch both warnings to error.

Regards,
Sven

Graeme Geldenhuys via fpc-pascal schrieb
am So., 18. Apr. 2021, 17:54:

Calling an abstract method will already result in an EAbstractError to be thrown.

Regards,
Sven

Nowadays: backwards compatibility.

Regards,
Sven

On Apr 18, 2021, at 11:28 PM, Sven Barth wrote: Nowadays: backwards compatibility.

backwards compatibility strikes again. :)

Regards,
Ryan Joseph