What new features would you like to see in Delphi 13?

[Kas Ob. 121]

@Stefan Glienke you put your finger on the biggest pain source in Delphi and CBuilder.

 

I honestly believe that the cause of this negligence and procrastination on enhancing the compiler is sourced from few things but mainly the stupid and outdated DebugInfo, see, enhancing the compiler to spit better, shorter and efficient code means the simple and stupid assembly instructions, right now it is a must to have at least one instruction per line at least, but with optimization some lines will not have any instructions, also means there will be multiple lines executed in one or more ASM instructions, also means some lines will be reordered or even omitted and this is important for the debugger, now comes the Borland DebugInfo and its really need to be re-hulled or even dropped and switched to something else, changing the simple and current retarded assembly flow will require the DebugInfo to have such changes convoyed to the debugger, and this is the black pit, enhancing compiler will require enhancing the debugger, and i mean almost rebuilding form the ground along with new.

 

That is technical debt for Embarcadero, and they are castrating LLVM for the sake of the debugger and debug info.

[Vincent Parrett 750]

7 hours ago, Stefan Glienke said:

and then there is this statement:

that sent me down a rabbit hole for the last few hours 😉

 

The most interesting thing though was the link to talk on the Carbon compiler

 

 

Super interesting talk (although annoying that he takes sooo many questions during the talk when we can't actually hear the questions and he doesn't repeat them - wish people would save the questions till the end). 

 

I've written bunch of lexers/parsers/ast's over the years - this talk makes me want to go and rewrite them all (of course I won't because I just don't have the time). 

 

[mitch.terpak 5]

18 hours ago, Dalija Prasnikar said:

Imagine how slow would compilation be with those optimizations turned on. 

 

I hope than newer LLVM could be faster, but I wouldn't keep my hopes up https://discourse.llvm.org/t/if-llvm-is-so-slow-is-anything-being-done-about-it/75389

Delphi compiled to Linux is borderline unusable, whatever the reason is, I'm seeing x20 slowdown on some code (see screenshot). For example in a procedure that does Sparse Matrix Factorization. I had to port parts of our code to C++ (DLL) and will probably have to port more as work around for this. Sure it can compile longer, even if it'd compile for 30min I don't mind.

 

[PeterPanettone 157]

As a developer who deals a lot with design, I find Delphi's lack of layout options a thorn in my mind. The layout features in Delphi are one-dimensional (e.g., property Align).

 

Delphi lacks a layout component like TdxLayoutControl from DevExpress for a professional design: 

 

 

In practice, the lack of professional layout capabilities results in many bumbling-looking applications, with controls that sometimes overlap when run on a device with display settings different from those of the original application developer. This shortcoming has given Delphi the unjustified reputation of being an unprofessional amateur developer tool.

 

That's why my greatest wish for the Delphi community would be a native layout control from Embarcadero. Or even better, Embarcadero should buy the TdxLayoutControl component from DevExpress and integrate it into the Professional version. This would give Delphi the professionalism it deserves due to its other capabilities.

Edited March 3 by PeterPanettone

[JonRobertson 72]

52 minutes ago, PeterPanettone said:

This shortcoming has given Delphi the unjustified reputation of being an unprofessional amateur developer tool.

I have heard or read many "justifications" for dismissing Delphi, but never that one.

 

That said, DevExpress does have excellent components. I currently do not have the privilege of a license for any. Thank you for pointing out TdxLayoutControl , along with the video. I need to spend a little time to put together a proposal, I suppose, for my managers. 

[Anders Melander 1783]

8 hours ago, PeterPanettone said:

In practice, the lack of professional layout capabilities results in many bumbling-looking applications, with controls that sometimes overlap when run on a device with display settings different from those of the original application developer. This shortcoming has given Delphi the unjustified reputation of being an unprofessional amateur developer tool.

Nonsense. Windows developers have been able to create professionally looking applications that for decades without the aid of layout controls. The main reason for amateurish looking applications is amateurish developers.

 

9 hours ago, PeterPanettone said:

Or even better, Embarcadero should buy the TdxLayoutControl component from DevExpress and integrate it into the Professional version. This would give Delphi the professionalism it deserves due to its other capabilities.

The DevExpress layout control is tightly coupled to the rest of their library but even if it had been possible to separate it from the rest then it would be a terrible idea. Embarcadero does not have the resources or expertise to maintain and evolve something as complex as TdxLayoutControl. Just look at the state of the 3rd party libraries they already have incorporated into Delphi.

I wouldn't mind a rudimentary layout control as a part of the VCL but if they can't even get something as simple as TGridPanel to work properly then I think it's better they not even try.

[Attila Kovacs 629]

it will also be enough if QP is operational by the time D13 arrives

[FredS 138]

5 hours ago, Attila Kovacs said:

it will also be enough if QP is operational by the time D13 arrives

Yeah, was wondering about that.

As stated back in January it should be up in a week, especially after 'months of planning'..

[Sonjli 6]

It would be nice to add inline methods writing in classes.

I mean declaration and implementation all in the class.

Example:

// Inline implementation
type
	TMyClass = class
	private
	procedure DoSomething;
		begin
			ShowMessage('Hello guys!');
		end;
	public
	end;

 

[Stefan Glienke 2002]

44 minutes ago, Sonjli said:

It would be nice to add inline methods writing in classes.

I mean declaration and implementation all in the class.

Niklaus Wirth just turned over in his grave about this proposal.

[JonRobertson 72]

2 hours ago, Sonjli said:

It would be nice to add inline methods writing in classes.

Not for me. I'd want a compiler option to turn it off. But that wouldn't prevent others from using it. 

[Sonjli 6]

I stepped on shit... ok, I clean my shoe and Wirth can go back to rest in peace...

[JonRobertson 72]

My thought is that it is already too easy for code to be scattered rather than organized. At times, I get flustered trying to find my own code, let alone working in a code base that I didn't write.

 

And the impact on the Delphi compiler and "breaking interface changes".

 

When a change is made in the interface section of a unit, other units that depend on the change must be recompiled. But when changes are made only in the implementation or other sections of a unit, dependent units don't have to be recompiled. The compiler tracks these dependencies automatically and recompiles units only when necessary.

[Stefan Glienke 2002]

Looks like nobody ever corrected that statement with the introduction of generics - because then even changes in the implementation section are an interface breaking change. They experienced that themself with the 10.2.2 update where some bug in TArray.Sort<T> was fixed which caused issues so the update was pulled and corrected iirc.

[shineworld 73]

Delphi can use external DLL made with C.
I Delphi13 will be useful to import DLL made with C++ to open road to use directly tools like OpenCV, VTK, numpy, etc.
I don't know how complex it is but would be amazing...
 

[David Heffernan 2345]

1 hour ago, shineworld said:

Delphi13 will be useful to import DLL made with C++ to open road to use directly tools like OpenCV, VTK, numpy, etc.

This can already be done, and has been possible since Delphi 1

[shineworld 73]

Good to hear but no real match.
There are two libraries in git for porting OpenCV to Delphi.
Both use a middle-man C DLL made in C++ Builder to access the DLLs...

[David Heffernan 2345]

3 hours ago, shineworld said:

Good to hear but no real match.
There are two libraries in git for porting OpenCV to Delphi.
Both use a middle-man C DLL made in C++ Builder to access the DLLs...

That's inevitable though isn't it. Because OpenCV is written in C++. For which there is no single binary interface.

[JonRobertson 72]

7 hours ago, shineworld said:

Delphi13 will be useful to import DLL made with C++

 

6 hours ago, David Heffernan said:

This can already be done, and has been possible since Delphi 1

5 minutes ago, David Heffernan said:

OpenCV is written in C++. For which there is no single binary interface.

How was it possible with Delphi 1?

[David Heffernan 2345]

Just now, JonRobertson said:

How was it possible with Delphi 1?

Because Delphi 1 could import functions from DLLs.

[shineworld 73]

So, to use a 3rd part DLL made with C++, eg: MSVC or C++Builder itself,  it is necessary to create a Proxy C DLL with C++ Builder.
https://blogs.embarcadero.com/how-to-use-a-c-dll-in-any-delphi-program/

 

[JonRobertson 72]

6 minutes ago, shineworld said:

So, to use a 3rd part DLL made with C++, eg: MSVC or C++Builder itself,  it is necessary to create a Proxy C DLL with C++ Builder.
https://blogs.embarcadero.com/how-to-use-a-c-dll-in-any-delphi-program/

Yes, unless you have the C++ source and wanted to create a C++ DLL that could be used from Delphi using a COM interface.

http://rvelthuis.de/articles/articles-cppobjs.html

Edited March 13 by JonRobertson

[David Heffernan 2345]

34 minutes ago, shineworld said:

So, to use a 3rd part DLL made with C++, eg: MSVC or C++Builder itself,  it is necessary to create a Proxy C DLL with C++ Builder.

I don't think that's the case. If you need to interface with a C++ codebase, then you need to create either a C wrapper, or a COM wrapper, but in each case you aren't limited to C++Builder. Whichever compiler you use to compile the C++, you compile the C wrapper, or the COM wrapper. The point is that the C or COM wrappers are compiler agnostic. But C++ code is, in general, not compiler agnostic. So you just need to compile your wrapper in the same toolchain as the C++ library.

 

There are actually tools to create such wrappers. I'm thinking of SWIG.

 

But there's no way that there's going to be a Delphi produced which can consume C++ libraries compiled by some arbitrary C++ compiler.

[JonRobertson 72]

1 minute ago, David Heffernan said:

But there's no way that there's going to be a Delphi produced which can consume C++ libraries compiled by some arbitrary C++ compiler.

And has not been possible since Delphi 1.

[PeterPanettone 157]

Another interesting possibility is to create DLLs using Python that Delphi applications can use. Python provides several ways to create DLLs, including using the ctypes module or the cffi module or compiling Python code to a shared library using tools like Cython or PyInstaller.