Embarcadero continue to add innovative features to their RAD Studio (C++ Builder and Delphi) product. They have just released an updated product road map which shows their plans for the rest of 2018 and the start of 2019.
The introduction of C++ 17 support and the improved support for high DPI screens are two of the many features mentioned.
For full details of the road map go to
Road map (Aug 2018)
For convenience we reproduce a copy of the road map here:
Embarcadero have anounced new editions of their C++ IDE and Delphi IDE. Known as “Community Edition” these are free licensed versions of the “Professional edition” for students, home users, open source developers and anyone who programs but does not generate an income. There are accurate details of the restrictions on use at the links below.
This is a very positive move by Embarcadero. It makes it easy for anyone to experience first hand the quality of their products. It can’t help but increase the popularity of the Embarcadero C++ and Delphi programming environments.
Here are the links, if you are new to Embarcadero products go get it now!
C++ Community Edition
Delphi (object pascal) Community Edition
Many functions in third party libraries, APIs or in your own code often return some kind of error indication as to the success or otherwise of the function call.
Always check errors when a library (or other) function returns an error (even if you are going to ignore it !).
Why do we make this statement? For all the following reasons.
a) It documents in your source code the fact that the function returns an error (you may decide to check this later).
b) It makes it easier to check the error status when you are debugging your code as/when it doesn’t work.
c) It makes it easier to add error checking at a later date.
d) It encourages you to think “should I be really ignoring the error code returned by a function” at the time that you write your code. In most cases the answer to this question is probably “no”. Checking errors almost always adds little to code complexity and often saves time in the long run.
When developing C++ code it is very common to declare a pointer to a variable of a specific type (either as a local variable, a class member or (hopefully more rarely) a global variable.
Consider the following two exactly equivalent lines
TMyType *Variable; // no space between the * and the variable – *** preferred ***
TMyType * Variable; // space between the * and the variable
Similarly when using the value pointed to (dereferencing) consider the following two exactly equivalent lines
TMyType X = *Variable; // no space between the * and the variable – *** preferred ***
TMyType X = * Variable; // space between the * and the variable
In each case we prefer the first of the two lines. Why? because the second form looks too much like the multiply operator (z = x * y).
It is very important to be consistent throughout all your code. Knowing that we always use the first form allows us to use a search on “*Variable” and find ALL the instances where the pointer is dereferenced.
If I have a person sawing a log for me and it takes them three quarters of an hour to saw through three quarters of a log I can reasonably assume that it will take an hour to finish the job. Given this information I can also assume that if there are ten logs that require sawing and one is done each day (so the person sawing is fresh each time) then each day I need to allocate one hour to the sawing task.
How can we software engineers explain to our managers that software development is not like sawing a log?
Firstly it’s exceedingly hard to know how far through the software you are at a given time.
Secondly you can’t usually predict when the next time consuming challenge is going to hit you. Some parts of a design may go smoothly but then the development may uncover something that had not previously been considered and the sensible engineering solution may well be to re-write (or at least refactor) some of the earlier design that may have been considered “finished”.
With larger projects this unpredictably does tend to even out so that you can (with experience) make estimates of the time needed to get a software system to a point where it is useable.
But I’ve just been asked how long will it take me to fix an issue with a particular type of output on a particular type of device. Once I find how to make the change it will be a ten minute fix. But how can I estimate how long it will take to find (or even if it is actually possible?). How much of the device manual will I have to read and understand in order to find the correct method to achieve the result ? And how much of the code will need to be redesigned to accommodate the required change(s)? And if the documentation is poor (as it usually is) how much experimenting / testing will be required to get it working?
So what do I do ? Quote a short delivery time and then look a fool (and perhaps upset the customer’s planned schedule) if it takes three times as long as I said ? or quote a long delivery time and get the reaction “how long? just to do that simple job! ”. Best is to try to get managers to read and consider this blog !
When developing code it is a frequent occurance that you write something as a quick “get it to compile” fix whilst your mind is focused on the key part on which you are working.
Let me offer an example. Whilst developing a TCP/IP interface to a set of remote digital and analogue i/o you come across a need for a function to extract a set of characters that are specific within a string. You might quickly write a function with a prototype:
String ExtractSpecificCharactersFromString(String IncomingString);
In order to keep going on the main code you are writing on you may quickly write a dummy function body:
String ExtractSpecificCharactersFromString(String IncomingString)
This allows your code to compile and it retuns a sample data String that allows you to start testing your code, all of which is good!
But there is a real danger that “dummy” code like this can get left in genuine code for too long. You end up creating your own bug: “I am sure that digital output byte is set to 0xf500, so why does it keep reading as “0xf5c9?”
Having wasted time as a younger programmer chasing these self inflicted bugs I have adopted a procedure where I reserve a comment statement with three consecutive ’!’ characters specifically for tagging code that is still to be written. For the above example create the function body as:
String ExtractSpecificCharactersFromString(String IncomingString)
return String(“D0=0xf5c9”); // !!! still to be written
Then at regular “low concentration” moments you can go back to the code and search for the character string ”!!!! in “all project files” (using the Embarcadero C++ search terminology here) and quickly find all examples of dummy code where you know further work is required.
I chose ”!!!” for this task as it is a string which is exceedingly unlikely to appear in genuine C++ code. Choose something else if you like but whatever you choose stick with it!
Embarcadero have announced release 3 of 10.2 Tokyo (i.e. 10.2.3).
A summary of the new features is given at
Announcement of 10.2.3
The C++ Rename Refactoring has been in the pipeline for a while now. It’s great that it is finally here!
There’s also more in depth information at
Embarcadero Tokyo Release 3 DocWiki
Embarcadero have announced some information about Release 3 of 10.2 Tokyo (i.e. 10.2.3). This release is targeted for the first quarter of 2018.
For this release they have three key themes. First, to provide enhancements to the core visual frameworks, including better HighDPI support for VCL and quality improvements for FireMonkey (FMX). Second, they are continuing to improve the C++ capabilities, by including CMake command line support and C++ Rename Refactoring. Third, they are expanding RAD Server support for Ext JS.
We will keep you posted about when this release becomes available.
I use Embarcadero C++ for a lot of work. Sometimes Firemonkey is the right framework to use and sometimes VCL is. I have a lot of C++ files that contain classes that are equally useful for both frameworks.
Instead of having
at the tops of the files, for all *.cpp files that can be applied equally in either framework, I use the following line:
The file EmbarcaderoComponentLibrary.h resides in every project I create and is edited once at the start of the project design. It contains the following lines (along with a load of comment statement which I don’t reproduce):
//Set these for each project requirements
#define ROGER_USE_VCL 1
#define ROGER_USE_FMX 0
There are many rules that could claim to be the “first rule”…..
“Never have the same data maintained in two different places.”
If you don’t follow this rule you immediately have a new task of ensuring that the two different places contain the same data and also the headache of what happens when they do contain different data.
It sounds obvious, but you’d be amazed how many times this rule is violated.