The Boost library is now available for C++Builder and RAD Studio 10.3.1.
Boost is a very important third party C++ library, and one many of our customers request support for. It's taken us longer than we had hoped, but I'm very glad to announce it's available in the GetIt package manager today. You can find it by opening GetIt (Tools menu, GetIt Package Manager) and either clicking the Libraries category or searching for "Boost" in the search box.
Boost is available in three flavours:
These are just some some of the really useful libraries now available to you with C++Builder. Also supported are libraries like Boost.asio, a famous library for asynchronous network and other I/O; Boost.InterProcess for interprocess communication; Boost.lockfree for non-locking data structures; and more.
It's taken us some time to release Boost for C++Builder 10.3.x, which we regret. We are very glad to have released it now, and would like to discuss our plans for the future.
Most importantly: It is our aim to support Boost day-of or close to the release date for any version. Unlike 10.3, this will happen for 10.3.2: you can expect Boost when 10.3.2 is released, and the same for 10.4 and other future versions.
You'll notice we now support a much newer version of Boost (1.68 today) with our newer C++17 compiler for Win32. This is a great benefit to you because of the newer libraries you can use. We plan to release an upgraded Win64 compiler soon, and when we do, that too will support a newer version. At the moment, we're unsure if this will be 1.68 or even newer, such as 1.70. (1.70 was released just thirty days ago, and we did not want to delay releasing any further in order to merge changes forward. However, it or 1.71 are a candidate version for the future.)
We'll also be staying up to date with Boost in future. We will be merging support forward as Boost releases new versions. Ideally, we will also be aiming to merge compatibility changes back into Boost itself. This isn't a matter of simply providing a patch to the Boost project: it's actually up to the maintainers of each individual library, all 127 of them, so this may take some time. During that, we'll be merging changes forward regularly ourselves.
We hope you find Boost and its presence through GetIt a great benefit to you. Thankyou for sticking with us while it took us time to release it, and we look forward to timely and swift releases of up to date Boost versions in the future.
Reduce development time and get to market faster with RAD Studio, Delphi, or C++Builder. Design. Code. Compile. Deploy.
Start Free Trial
Free Delphi Community Edition
Free C++Builder Community Edition
Good news. What about progress in clang compiler ? Last time I tested it was unusable for real-world projects. There were more reasons but main reason was compilation and linking speed which was about 10-11 x slower than old compiler. New functions are not worth enough to justify such slowdown in everyday work. Also new IDEs beginning from Seattle were significantly slower and frequently crashed. We are using currently C++ Builder XE8 and dont plan to go to new version if these problems are not resolved.
Slowdowns like that are due to very specific code constructs, not in general to Clang. We ask that you attach the code that shows that slowdown to a QP entry, or work through Support if it's confidential. Once it's narrowed down to what code or headers or similar cause it, we can address that in the compiler.We've done that regularly, and in 10.3.1, for example, had another speed increase due to changes in exception handling.IDE crashes - are those filed in QP? We have solved quite a few.
"Slowdowns like that are due to very specific code constructs, not in general to Clang"I disagree with this comment, it's not just one or two files that compile a little slower, but whole projects build 5 times slower or worse than with the classic compiler. You can even see this with a new completely empty project. Build times on my PC are (average of several builds):New empty project:classic 1.5sClang 4.5sReal world project 1:classic 8sClang 45s Real world project 2:classic 18sClang 2 mins 15sThis is an absolute showstopper for us, there is no way we can accept a 5 times hit in build speed on all our projects. We would for sure like to use the new C++ 11/14/17 features but until this gets close to parity we are stuck on the classic compiler. I have seen a number of similar comments in the forums so we are not the only team in this position.
Is it possible that the real-world projects you're looking at all refer to some common headers or similar, where the 'specific code constructs' I mentioned are contained?
It would be really useful if you could send a copy of your project to Support. We can have our engineers analyse it and solve whatever it is that's causing the slowdown. Please feel free to email me about this too (david dot millington @embarcadero.com).
Hi David,Thank you very much for responding to this, it makes a big difference to know that somebody is paying attention. I would be very happy to help your engineers look into this.Do you have any specific list or examples of code constructs that are known to be slow with the Clang compiler, or do you just look into it on a case by case basis?I'll email you regarding sending you a copy of one of our projects.Regards,Robin
Thanks Robin! There have been a few things (I'd need to ask the engineers) but in general we take it on a case-by-case basis.I saw your email and will reply soon.