It seems like a new version is looming :)

Delphi Developers: Official EMBT Updates 1 Minute

It seems like a new version is looming 🙂

From the blog post by Tim Del Chiaro 

Incredible Windows 10 Support

Delphi and C++Builder developers will be able to rapidly update their VCL and FMX applications to take full advantage of the Windows 10 wave.

Double the IDE Project Power

The product and build management system has been re-architected which effectively doubles the project size capacity resulting in higher stability and performance when dealing with large projects, particularly multi-platform projects.

Quality, Stability, and Documentation

Major changes and improvements have been made to the development, testing, and documentation.

RAD C++ for Windows 10

Introducing the world’s first CLANG based C++ compiler for Windows and mobile with RAD PME extensions for rapid Windows and Cross-Platform development, tight integration with VCL for Windows and FMX cross-platform frameworks, C++11 language support and backward compatibility.

and much more!

http://delphi-insider.blogspot.no/2015/08/see-whats-coming-in-rad-studio-delphi.html

Published by Lars Fosdal

Software Developer

Published

29 thoughts on “It seems like a new version is looming :)”


  4. Ralf Stocker I actually hope the opposite – I want super codegen, which I think LLVM will give.  I’d like to see Delphi competitive against C# or even C++ in terms of performance.


    What I hope will happen is that the “new” LLVM-based compiler (with reference counting etc) will be released for Windows, and the old legacy compiler will remain.  There’s no way they’ll get rid of it – too many people rely on it – but those starting new projects or wanting better performance etc can target the new compiler.  I hope.  (And I very much doubt this will be in this version – it’s a hope for the future.)  Tagging Marco Cantù just so you see this 😉


  7. David Millington Marco Cantù  I would appreciate having improved codegen, I would appreciate having ARC on Windows, and seeing new compiler features implemented.


    However, I am seriously worried about future of 8-bit strings in that case. Not having them would be showstopper in my case.


    And I am afraid that providing old, “legacy” compiler to cater for such cases is not good enough because I want both new and old features in single compiler. 


    Of course, I am aware that LLVM compiling speed is not exactly stellar but as far as I am concerned I could live with that drawback.


  11. David Heffernan I can fully understand your position. ARC could be a real performance killer for some applications.


    Which brings me to the point where I have to say, no matter how much I do like ARC as concept, that introducing it was huge mistake.


    You cannot have single code base (well, you can but such code base is nothing more than huge mess) when you have different memory management for different platforms. Not to mention other differences.


    I think EMBT has painted themselves into a corner. They will either have to maintain different compilers – messy business for both them and Delphi devs, or they have to leave some of their customers out in the cold. 


    We all lose big time either way.


  13. Marco Cantù LLVM main drawback is sluggishness, ideally LLVM could be offsetted by transparent background compilation.


    For instance Java compilers are quite terrible, but thanks to widespread background compilation in IDEs, that is only rarely an issue.


    Otherwise Delphi compile times could be demoted to C++-compiler class, without being able to match modern C++ in terms of runtime performance (you would also need templates for that rather than generics, as generics mean interfaces, and interfaces do not offer static optimization opportunities).


    Years ago, slow C++ compilation is one of the reasons I started using Delphi whenever possible.


  16. Horácio Filho all generics can do, template can also, but the reverse is not true.


    See https://msdn.microsoft.com/en-us/library/c6cyy67b.aspx and https://visualstudiomagazine.com/articles/2012/12/20/c-plus-plus-templates.aspx


    The  downside of templates in C++ is lack of constraints (source of errors), but Delphi has a syntax for constraints, and LLVM Delphi would still be statically compiled, so would not benefit from the runtime advantages .Net generics have.


  17. Eric Grange Delphi’s constraint syntax is designed for generics, and modelled on the .net syntax. All this was specced when the Delphi .net compiler was the big thing. That’s why it’s all so similar to .net generics.


    But Delphi’s constraints syntax is woefully lacking. Indeed in C++ land they’ve tried to improve with traits and that keeps getting pushed back because they can’t agree on a spec.


    The area that I feel is most lacking is the inability to constrain types to support operators. I dream of being able to use a library like Eigen in Delphi code.


  18. David Heffernan I suspect supporting operators would require a step well into the realm of templates, as they cannot be statically type-checked before specialization.


    An operator basically acts as a function returning any type, so you would need different constraints for a “+” operator returning a string, a float, a matrix, a whatever, and that for all operators. This would make declaring the generic a lot more complex, or the declaration a lot more fragile (and not very generic).


    For instance what would be the generic declaration constraint for an “Add” function that would basically wrap a “+” operator?


    It would have to be capable of handling: concatenating strings, adding an int and a float and returning a float, adding a float and an int and returning an float, adding two ints and returning an int, adding a string and an int and returning a string, etc.


    The type of the result of an operator expression is very dependent on the specialized types, and not at all generic.


    Templates can handle that easily, but generics? hmmm…

Leave a Reply