Como integrante del programa MVP de Embarcadero fui invitado para confeccionar a un call for papers acerca de C++ Builder.
El tiempo apremiaba, así que opté por desarrollar con mayor formalisto, que no rigurosidad, lo que os explicaba en ¿Por qué C++ Builder. De esa manera es como surgió mi autoría en el memorando (whitepaper) C++ Builder in the requirements, y que fue sometida el pasado 13 de abril de 2018.
C++ Builder in the requirements
April 13th 2018. Javier Gutiérrez Chamorro
Abstract
One of the key factors for successful development projects starts in its roots. The development technology you use.
For a variety of reasons, Embarcadero C++ Builder is not a well-known player in the development industry. This should not be a showstopper for choosing it. Knowing C++ Builder strong and weak points, will give you the criteria to choose it as your platform when better covering your needs.
Technical requirements
Once your functional requirements gathering is completed, and you have already delivered the functional analysis of the project, you will have a pristine idea of what your development should do.
Knowing the project functionalities, and even the way it should behave, is only the beginning of the race. Your users and customers will have hidden expectations that are not formalized in the functional analysis, and you should move forward to foresee them.
I am sure you do not want to deliver a project that even if meeting all the written requirements in the list; it makes your users unhappy, or at least not completely satisfied. All of us want to supply the better possible software.
You can think on questions like:
Meeting expectations, as opposite to only meeting requirements is one of the most important factors that differentiate between good software, and the excellent one.
C++ Builder strong points
Proven code base
C++ Builder from Embarcadero has evolved from the experience and improvements applied since it was born as Turbo C back in 1986.
These are more than 30 years supporting virtually millions of C/C++ developers over the time.
Later on (1990), the successor appeared Boland C++. Leveraging C++ standards while still supporting plain C, while in 1997 the first version of C++ Builder launched.
C++ based
C++ Builder is C++ language based. A huge amount of developers are familiar with this programming language, which means it will be easier for you to setup a team in C++, than in less popular development languages.
Performance
C++ compilers such as Clang, the backend behind the scenes of C++ Builder is very efficient in terms of code quality. It is not surprising that in most scenarios same program written in C++ in comparison with other languages such as VB.NET will run 2x or 3x faster, and need lees memory.
Low level
Programming languages, even the newer ones such as Java or C#, borrowed some elements of C++, but they were never designed having low-level system interaction in mind.
C++ and C, were created on the decade if the 70s of the XX century to achieve the development of UNIX operating system. It is conceived to interact with the lowest hardware and operating system layers, which means that accessing Windows APIs for instance, is more natural and easy that lets say with Delphi.
Productive IDE
You can forget about command-line with C++ Builder. No need to manually edit makefiles or use complex commands like in GCC/G++. Of course, you can use all of that if you want, but the entire job can done visually.
C++ Builder includes a powerful project manager, editor with syntax highlight and refactoring aids, a debugger, as well as some other utilities such a profiler. Much a like other state-of-the art IDEs like Visual Studio or Delphi.
RAD (Rapid Application Development)
Success of C++ Builder, as it was in Visual Basic has been its RAD approach. You can directly drag and drop your controls over a form to create the application user interface, saving lots of time in that way. There is no need to write code for it as you have seen in Visual C++ with MFC (Microsoft Foundation Classes) or WinAPI.
C++ Builder (and Delphi) thanks to its VCL (Visual Component Library) and FMX (FireMonkey Application Framework) allow you to focus in coding, and not in user interface implementation.
Native code
Native code generation has been always inside C++ Builder and Delphi. They do not require any byte-code just-in-time compiler (JIT) as Java or .NET does. So applications start much faster, and do not require the user to install any additional supporting tools like the JRE (Java Runtime Environment) or .NET Framework.
Native code directly runs on the iron, and does not require any intermediate translation, so it gets the most on the available resources.
No external dependencies
Programs built with C++ Builder are statically linked. The entire infrastructure needed to run is available inside the generated standalone executable. You do not need to distribute third party DLLs with your program, and the user does not need to install them on his side.
This means that your programs will be smaller, only required code is included into it, as opposite of having the full DLL no matter if you never use it. In addition, of course it is self-contained, so you have total control about its requirements.
Have you experienced a program that should run in Windows XP but a third-party DLL requiring Windows 7 or later limiting your entire program to run at least in the later? Therefore, I have good news, because that is not happening with C++ Builder.
ah, que vagancia leer todo eso en inglés…! Así por alto veo que dices básicamente que C++ es muy bueno, alto y guapo (de lo cual estoy de acuerdo), pero has retirado aquello de que su VCL heredaba de Delphi y que no la habían hecho propia.. 😀 ¿No te atreviste a meterlo? Bueno, di tú que para qué, hiciste bien, para el caso que iban a hacer… Pensarían: «aaah, que vagancia, ponerse a hacer eso ahora otra vez!». Y plof!, a quitarte la placa de MVP 😀 Tampoco dices que FMX es una basura… Da gracias que, comparado con .NET, cualquier cosa es mejor.
Así por alto…, y acabé leyéndolo entero 😀 Al final se lee fácil.
¡Para estar en inglés bianamaran has capturado la esencia de muchas cosas!
Lo de la VCL en Delphi es algo que ellos ya saben, tiene lógica porque Delphi apareció antes, igual que el .NET Framework es en su mayoría C#. Sin embargo, si lo reescribieran en C++, la ganancia de rendimiento sería aprovechable, tanto en C++ Builder como en Delphi.
FMX me gusta, aunque es para lo que es, aplicaciones multiplataforma, en las que en cierta forma, vas a tener que sacrificar rendimiento y tamaño en favor de la portabilidad.