I use it for a living, and I cannot recommend that piece of shit.
The IDE is alright, except the IntelliSense, if you can even call it that, becomes unusably slow in sufficiently large (really, just non-trivial) projects. The 32-bit compiler mostly supports C++98, with a couple C++11 features and a few missing C++98 ones. Don't expect to be able to use many open-source C++ libraries. The 64-bit compiler is a fork of an older version of clang, so you get more C++11 support but some of the Embarcadero extensions are missing (yeah, code isn't even syntactically portable between 32-bit and 64-bit C++Builder).
The compiler ICEs if you look at it funny and the general solution to fixing a build problem is to restart the IDE. If you have a syntax error, you can basically guarantee that it won't report the correct error location (usually it'll give you some system header files).
The debugger is nice enough (it's basically a really shitty reimplementation of 1/10th of GDB, with a more-or-less functional GUI slapped on top) until it crashes, which thankfully is much rarer than the compiler.
Using external libraries is easy enough as long as they're packaged as C++Builder or Delphi components. Unless, of course, you manage to fuck up the install process (quite easy) in which case you'll be editing a few registry keys (yup). If you're trying to use a regular C++ library—assuming, of course, that it sticks to C++98 features and doesn't use SFINAE—then you usually only have to edit the library's code a bit to work around C++Builder's quirks and you're set. Oh yeah, and you can't use C libraries built with MinGW (C++Builder uses its own object file format), which means you're stuck with C89 (and a little bit of C99).
VCL makes the STL look positively dazzling. Templates were inconsistently bolted onto the VCL, so usually you've got TObject* pointers and casting. VCL objects can't be stack allocated, because... reasons? VCL's memory management is extremely unclear, but it's mostly reference counted (explains the heap-only restriction)... probably.
There's a reason nobody's using it. It's a fucking piece of trash that needs to die already.
/rant
At least there's been enough outcry at my workplace that we're switching to C# for the next project.
Such a shame. Borland couldn't compete with MS (partly due to some dirty tricks MS used) and they've been on a downward course for a long time - they sold their developer tools divison a long time ago.
C++ Builder was the C++ version of Delphi, a major productivity booster for Windows development. I remember using version 1.0 - it was truly amazing how fast one could develop UI applications with it. I would say it was about as easy as using Xcode's interface builder, when the competition was basically coding MFC classes (or WinAPI!) by hand. It had database bindings and one could link controls with data sources in a WYSIWYG interface in the time it took to put a button on the screen with MFC.
However, it was expensive and the compiler was not as good as MS's. I never had the chance to use it profesionally, everyone was using Visual C++. As the years passed I forgot about Borland...
Luckily the legacy of rapid application development lives on in Qt: it's open-source, cross-platform, with a strong community and uses modern C++ tooling.
wxWidgets is also good as an alternative to Qt, but with a smaller community. I use it and don't have any problems with it (a few bugs in the wxAui classes though).
I think everyone left Borland after their C++ Architect project was binned, the Kylix attempt ("building font metrics..."), they changed their name and core idea, and the Delphi language designer was head-hunted to design C# for Microsoft (unless I am mistaken??).
They released a PHP editor but I can't see them selling much of that.
I remember that you had to keep the installer lying around in Documents and Settings (Users) for it to install updates or uninstall. So gigs of data just sat there. And it took FOREVER to install.
I remember the Intellisense would do the equivalent of a disk defragment whenever you wanted it to pop up. CodeGuard gave many false positives. The linker would crash frequently. The VCL is mostly Delphi code as far as I remember with C++ bindings in some way?? It had bugs.
The TClientDataSet item would get incredibly slow when it grew to any significant size. STL containers are 4000% superior.
I suppose this is why compiler-extensions were advised against by Bjarne, but necessary when they were introduced as the standard C++ didn't support all the __fastcall stuff Borland wanted to do, I suppose?
The IDE is alright, except the IntelliSense, if you can even call it that, becomes unusably slow in sufficiently large (really, just non-trivial) projects. The 32-bit compiler mostly supports C++98, with a couple C++11 features and a few missing C++98 ones. Don't expect to be able to use many open-source C++ libraries. The 64-bit compiler is a fork of an older version of clang, so you get more C++11 support but some of the Embarcadero extensions are missing (yeah, code isn't even syntactically portable between 32-bit and 64-bit C++Builder).
The compiler ICEs if you look at it funny and the general solution to fixing a build problem is to restart the IDE. If you have a syntax error, you can basically guarantee that it won't report the correct error location (usually it'll give you some system header files).
The debugger is nice enough (it's basically a really shitty reimplementation of 1/10th of GDB, with a more-or-less functional GUI slapped on top) until it crashes, which thankfully is much rarer than the compiler.
Using external libraries is easy enough as long as they're packaged as C++Builder or Delphi components. Unless, of course, you manage to fuck up the install process (quite easy) in which case you'll be editing a few registry keys (yup). If you're trying to use a regular C++ library—assuming, of course, that it sticks to C++98 features and doesn't use SFINAE—then you usually only have to edit the library's code a bit to work around C++Builder's quirks and you're set. Oh yeah, and you can't use C libraries built with MinGW (C++Builder uses its own object file format), which means you're stuck with C89 (and a little bit of C99).
VCL makes the STL look positively dazzling. Templates were inconsistently bolted onto the VCL, so usually you've got TObject* pointers and casting. VCL objects can't be stack allocated, because... reasons? VCL's memory management is extremely unclear, but it's mostly reference counted (explains the heap-only restriction)... probably.
There's a reason nobody's using it. It's a fucking piece of trash that needs to die already.
/rant
At least there's been enough outcry at my workplace that we're switching to C# for the next project.