Add support for C++Builder 13 Florence
Borland's Object Windows Library for the modern age
Brought to you by:
jogybl,
sebas_ledesma
Note removal of "tmschema.h" in this toolset version [bugs:#632].
Related
Bugs:
#632Last edit: Vidar Hasfjord 2025-10-28
Support has now been added in "owllink.h" on branches/6.44 [r8542]. Typo was fixed in [r8543].
Related
Commit: [r8542]
Commit: [r8543]
Added support for command line tools: BCMAKE.BAT, BC.MAK
Enhanced owllink.h
Commit [r8544]
Related
Commit: [r8544]
@jogybl has merged the support into branches/6.36 [r8563], branches/7 [r8564] and trunk [r8565][r8566][r8567].
Support has also been added in OWLMaker [r8569].
Related
Commit: [r8563]
Commit: [r8564]
Commit: [r8565]
Commit: [r8566]
Commit: [r8567]
Commit: [r8569]
Last edit: Vidar Hasfjord 2025-11-25
@sebas_ledesma, @vattila When trying to build the trunk with C++ Builder 13, I get errors:
Any ideas how to fix this?
@jogybl wrote:
TCodePage lacks a less-than operator, so presumably cannot be used with std::lower_bound without an explicit predicate (or a less-than operator needs to be defined for the type).
Last edit: Vidar Hasfjord 2025-12-18
Interesting that the same code compiles with C++ Builder 12 and Visual C++
I can try to add the operator to see if that helps.
Actually, the operators are there, but defined in the .cpp and not in the header.
Moving the operators to from the .cpp to the .h solves this issue. ([r8583])
Related
Commit: [r8583]
With C++ Builder 13, CoolPrj fails to build with error
And C++ Builder 12 fails to compile CoolPrj with the error
I guess it cannot handle the 'spaceship' operator?
@jogybl wrote:
The standard apparently requires a template argument list after Encode, since it is prefixed by the template keyword (which is required for disambiguation, because Encode is a dependent name). We want argument list type deduction here, since specifying it is a little bit awkward (
Encode<decltype(sendMessage)>). Fortunately, according to Copilot, the standard allows an empty list to be specified, i.e.Encode<>, preserving the deduction . I've tested that this fix works with the Microsoft compilers. Hopefully, C++Builder 13 accepts it too.Note: The fix needs to be applied to QueryViews as well at line 399.
Thanks, that works.
The next error is
A possible solution: Replace the line
FontVariants = {};with
FontVariants.clear();@jogybl wrote:
This is deliberate. C++Builder 12 is not C++20 compliant and for this reason no longer supported on the trunk. In my latest work on CoolPrj, I started using C++20 features not supported by this compiler. The errors are hence expected.
@jogybl wrote:
Apparently, those compilers delay the relevant error‑checking until instantiation time, which makes them more permissive, if not strictly standard‑compliant.
The next set of errors:
Last edit: Ognyan Chernokozhev 2025-12-21
@jogybl wrote:
See "Unicode support in CoolPrj" [feature-requests:#54], especially my last comment. The Embarcadero toolset may not support the std::codecvt features I've used to implement support for reading and writing Unicode. The best solution may be to rewrite the code to no longer rely on these (deprecated) facilities. I surmise that rewriting these functions from scratch (with the help of AI) may not take much effort. Feel free to take ownership of the ticket.
Related
Feature Requests: #54
I am trying it with Copilot:
"To refactor the code to avoid using std::codecvt, you need to replace all text encoding conversions that currently rely on std::codecvt facets with alternative approaches. Since C++17, std::codecvt is deprecated and not recommended for new code. The most portable and future-proof way is to use platform APIs or third-party libraries (like ICU, iconv, or Windows API for Windows-only code).
Given your code is Windows-centric (uses
_TCHAR,MultiByteToWideChar, etc.), the most direct replacement is to use Windows API functions for conversions between UTF-8, UTF-16, and ANSI.Below is a refactored version of the relevant conversion functions, removing all use of std::codecvt and replacing them with Windows API calls. The templates and specializations for ConvertTo_ are replaced with explicit functions for each conversion."
Key changes and reasoning:
• All std::codecvt-based conversions are replaced with Windows API (MultiByteToWideChar, WideCharToMultiByte).
• The conversion templates are now explicit functions for each conversion direction.
• For UTF-32, the conversion is simplified and may not handle surrogate pairs perfectly; for full Unicode support, consider using a library like ICU.
• The rest of your code (line readers, file I/O, etc.) can remain unchanged, as long as you use these new conversion helpers.
Note:
If you need cross-platform support, consider using a library like ICU or utfcpp for encoding conversions. The above solution is Windows-specific.
Let me know if you want the full file with all changes applied, or if you need further adjustments for cross-platform support.
Attached is the latest iteration of the code changes implemented by Copilot Agent that finally compiles
Unfortunately, my trial of C++ Builder 13 expired long time ago so I cannot test the changes.
@jogybl wrote:
Alas, it doesn't work, though. I just did a quick test with Visual Studio 2026, and UTF-16LE fails to load correctly in CoolDemo. UTF-32 handling seems incomplete as well.
Perhaps AI assistance will work better if you ask it to create simple standard C++ functions from scratch, only based on Win32, without providing the existing code (which is confusing even for me who wrote it, due to the intricate stream interoperability).
Functions needed are:
Moral of the story: Do not rely on AI to effectively fix code that you do not understand.
@jogybl wrote:
The following attempt, using Microsoft Copilot in "think deeper" mode, looks more promising. I haven't tested it though.
(Edit: I've now done some tests, and the code seems to work well, handling all the UTF encoding variants. And it is lightening fast compared to the stream solution.)
File encoding helpers and readers (Win32 + ISO C++20)
Below are compact, self-contained C++20 functions that:
CreateFile/ReadFile) into bytes and then into:std::wstring(UTF‑16 native on Windows),std::basic_string<TCHAR>(runtime string depending on UNICODE macro),std::string(ANSI) if desired.std::wstringusing only Win32 APIs and small helper code (no external libraries).Copy the code below into a single
.cppfile and compile with a Windows-targeting toolchain (MSVC or clang-cl). It uses only Win32 APIs and standard C++20.Key design notes
std::basic_string<TCHAR>is produced by converting thestd::wstringto ANSI whenUNICODEis not defined, or returningstd::wstringcontent whenUNICODEis defined.Code
Quick usage guidance
ReadTextFileToWstring(path).TCHARstring: callReadTextFileToTString(path).std::string(UTF‑8): convertstd::wstringwithWideCharToMultiByte(CP_UTF8, ...).Limitations & notes
wchar_tis 2 bytes (Windows). It uses Win32 APIs (MultiByteToWideChar,WideCharToMultiByte) for conversions.std::nullopton I/O or conversion failures; you can extend with richer diagnostics if needed.Last edit: Vidar Hasfjord 2026-02-09