We all know the problem that the Delphi string types (UnicodeString or short String, AnsiString) do not necessarily fit to C++, and we have to use the method c_str() again and again. This is not only annoying, it can also lead to errors. In addition, we often want to have the content of a string in a different data type, or vice versa convert it into a Delphi string, for example to display it in an edit field of a form.

In addition, thanks to Embarcadero's decision to continue using a 16 bit character type under iOS and Android, instead of the system-specific wchar_t type, which is a 32 bit data type in the unixoid operating systems, this is not necessarily understandable. So it can happen that in a C++ program under Android we suddenly have it with 3 not necessarily compatible datatypes. In the business part of your application you should only have the choice between the national character set (8 bit, char, string) or the international character set (wchar_t, wstring). Furthermore, the indices for the Delphi string types are based on the desktop operating systems 1, but on the mobile operating systems they are based on C and C++ oriented 0. This can also lead to problems and necessary adjustments. All this would be simply impossible under C++, since an industry standard protects the developer's investment.

I would like to create a header file for further use in this blog, and this problem with the help of C++- templates and the specialization of these for special data types.

Maybe this one in front. I was once, so not only fairy tales begin. Often we as business consultants also start with such sentences. I was once at a customer's for an in-house training. Here several developers have been working on a program from the energy sector for several years. During the training, they also discussed the fact that for the Embarcadero string types, the constructors for the standard C++ data types are missing, or the conversion operators for the reverse direction are not implemented. Unfortunately, the operators in particular cannot be added via argument dependent name lookup (ADL). In this case, the powerful C++ compiler could solve this problem for us, and that without an error. Now this is certainly not interesting for a Delphi programmer, he might not even understand why I criticize this at all. And this might also explain why it is missing. Now one of the developers ran a grep- search over the current source code, and over the years 2.5 million calls of the method c_str() had accumulated in the source code. Should changes become necessary now, for example when migrating to a unixoid operating system, everyone can imagine the extent of the necessary work.

I would like to solve this problem for the future examples in this blog with the templates __ToVCL and __FromVCL. Again I use the predefined conditions for VCL or FMX, because only when using one of these frameworks the use of Delphi types seems to make sense. After that follow the two header files for Delphi string types <system.hpp> and C++ string types <string>.

For most data types you don't need international characters, so I use only a national variant for the implementation of the template and use the automatic conversion from UnicodeString to AnsiString in the Delphi class library. For the necessary type conversion I will use the template boost::lexical_cast, which can convert a string into any C++ type. This also works for data types defined by yourself, if you have implemented the stream operators.

Since I always deal with Unicode strings on the surface of the Delphi frameworks, I have implemented this only for this type. But an extension to the Delphi type Ansistring should be very easy for everyone. I am not interested in a complete and working library, but in explaining techniques, problems and solutions. 

Now the effort to carry the boost library on a mobile system like Android can be higher than the benefit. Or a compiler does not offer me the support of boost. Maybe there is an easy way, even boost must have found an approach. Therefore I change the above example as follows, and use the conditional translation again, if the target environment is Android.

Now this conversion is not effective, can also lead to errors if string types are used themselves. For these types I want to implement specializations. Normally the compiler creates a copy of the templates for each combination of type parameters and replaces the type parameters with the concrete types. This results in very robust and directly linked code that is faster than runtime decisions. Templates can also be specialized (define a different implementation for selected type parameters), which I want to take advantage of here.

There is also an inconsistency in the Delphi string types, because the indices here follow the standard behaviour on mobile operating systems and start with 0. Furthermore, the conversion from the 16 bit character set to the system type wchar_t, which uses 32 bit for all unixoidal ones, must be done here.

Now there may be problems with zero-terminated strings, since they are stored as const char*, unlike the international character fields with wchar_t. So I will implement a method with the same name __ToVCL, but it is not a template. For later use this is not important. And this approach frees me to keep the variants apart so that I can concentrate on content problems.

With this I implemented the differences between the mobile operating systems and possible conversions from national to international character sets at a central location. Should there be adjustments, there will be no impact on the parts of my business application. I have the decisions in my hands again. This gives me the opportunity to create a test application that is the same for FMX and the VCL and also works with the mobile operating system Android as target platform.

Now I already hear the criticism that I have a lot of function calls here, moreover this source code creates unnecessary copies and therefore cannot be effective. But this is not true for modern C++ compilers anymore. I will explain this in a later blog post and also show you a concrete example. And the function calls just give me as a responsible programmer the possibility to make decisions, resolve inconsistencies and react to future changes. And this not distributed over the complete source code of my application, but at a central location. Should I have to rework them, it is much easier to search for __FromVCL or ::ToVCL in the source code.