Fog Creek Software
Discussion Board

C++ Builder - any good?


I have come from a predominantely xbase background and I have used dbase recently.

Because of the Borland origins dbase's IDE is very similar to C++ builders.

It seems that I can hit the ground running and convert my stuff to C++ with some ease.

What are other peoples opinions of C++ builder?

Mike Grace
Friday, November 22, 2002

Builder is a fantastic RAD tool, both for GUI and database apps.  I have only used builder 5, so I'm a bit behind, but it seems pretty darn good. 

The IDE itself is lightyears behind Visual Studio.NET (even Visual C++ 6.0 as far as I'm concerned).

But you can't beat it for RAD.


Gregor Brandt
Friday, November 22, 2002

C++ is a difficult language

I suggest you look at Delphi which has the exact same IDE and paradigms (C++ Builder is "Delphi in C++") but is based on (IMHO) a simpler language: ObjectPascal.

Robert Chevallier
Friday, November 22, 2002

I never used to like pascal at college but I would be willing to give it a try.

Does delphi still have a future, i.e. are Borland still fully behind it?

Mike Grace
Friday, November 22, 2002

Delphi seems to be quite healthy, although it's not very in industry demand. C++ Builder is in even lower demand. Which is suprising..

I recently did some work in C++Builder for the first time, and I have to say, it was stormingly nice.

It's like MFC/Visual Studio, but not a stunning pain in the neck - all the nice promises actually work. And it doesn't assume that labelling function parameters with hungarian notation tells you what would be a good thing to pass. And the thread classes work nicely. In fact so nicely I nicked the API and re-implemented it using pthreads for UNIX C++ thread work...

My only issue is the restrictions about multiple inheritance involving types written in the framework (which don't support it), but I got round that in the end.

I'd have to say it is by FAR the most approachable of the Windows C++ development environments. The toolkit is a perfect example of what happens when you sit down and think about these things.

And you can get free copies to play with - the latest - 1 version turns up on magazine cover disks and things.

Katie Lucas
Friday, November 22, 2002

I've used both C++ Builder and Delphi, and I consider myself a C/C++ kind of developer.  That said, Delphi is the way to go, as the component library (VCL) and all the third party components are written in Object Pascal, and some of the interfaces simply require "Pascal thinking" if you know what I mean.  So, you might as well code the whole app up using Delphi and be in Object Pascal mode all the time.

George Leroy Tirebiter
Friday, November 22, 2002

In the past some people here have used it on small exploratory projects with great success.

Just me (Sir to you)
Friday, November 22, 2002

Delphi is the current home for almost all of the Clipper/xBase crowd.  I have used it for all of my database projects since moving to windows.

a former Clipper/xBase coder

Friday, November 22, 2002

Clipper! Clipper! Rah! Rah! Rah!

Why the heck isn't it more widespread?  Blazingly fast DB work both in terms of development time and execution speed. 

I've only looked at it briefly in order to some maintenance on a 10 year old program, but what I saw was very nice.  When I asked the guys why we didn't still use it, the only answer I could get was "what, are you crazy"?

Friday, November 22, 2002

"Clipper, Clipper, Rah! Rah! Rah!"

You're crazy because DOS just isn't being done anymore in the US, not at least in the mainstream or anything approaching it.

I developed in Clipper for about fifteen years.  I found myself becoming farther and farther behind the eight ball in terms of employability the longer I stayed with Clipper.  Yes, it is blazingly fast. However, so is Delphi, and technologically it's current whereas the latest build of Clipper.exe was done in 1992 or thereabouts.

Regarding C++ Builder vs. Delphi: I'd suggest Delphi too.  Its language is simpler to understand and get going in than C.  It enjoys a wide following with former xBase developers.

If you're looking for a database to tie into with Delphi, I'd recommend the Advantage Database Server from Extended Systems, . It's a true client/server solution that supports DBFNTX, DBFCDX, and their own proprietary .ADT format.  You get a robust SQL implementation as well.  Additionally, you can "convert" your existing Clipper apps to run in Advantage with about 10 lines of code.

Karl Perry
Friday, November 22, 2002

I use CA-Clipper for my POS software. 

Friday, November 22, 2002

Clipper fell out of favor just like most xBase languages since they where not relational databases.

The clipper engine could not, and did not manage any of the relational data for you. The same went for most x-base variants. As these x-base products got sql, that really helped on the query, and report side. (I was a FoxPro developer for a few years back in the 2.6 days just before windows).

As for using Delphi for database development, any reason why it would be a better choice over dedicated database systems like Visual Fox Pro, or even ms-access (which both today can manage relational stuff well).

I was always under the impression the Delphi is a general development system like VB, and thus like VB is going to be very costly when used to development database applications.

Ms-access for example uses the same code base as VB (the ado, dao and all the data library stuff is the same). In fact, when you use ms-access the programming languages for everything is in fact the same language as VB.

Why then does a project in VB take 2-3 times as long to complete as compared to ms-access? Why?…they both use the same language? (we are talking about data centric applications here). There should be no difference since they both use the same language?

What is the critical difference since they both use the same language?

The answer is very simple:
Ms-access is a database or data-centric based system. In addition, the forms model in ms-access is MUCH MORE complex then is the form model used in straight VB (in other words, there is 30 to 40% more events and properties for ms-access forms then is in VB forms.  This means that ms-access has a much steeper learning curve then does VB. In addition, the real key here is that ms-access has the concept of data bound forms, and that concept does NOT EXIST at all VB. Thus you get tons of additional events for forms like “before update”, “on current”, “on insert”, “on delete”, “before delete”…this list is real long…). Thus, more events/properties  for forms, and the fact that they can be data bound is the main reason why ms-access is so much more of a RAD tool then just VB.

Right now, a project in ms-access that costs $12,000 will cost $25 to $30 grand in VB. That math is not very good…

Now, since VB is not a very good database product, then why would Kylix be? Does Delphi/Kylix have any dramatic features (like ms-access does) to increase programmer productivity when building a data centric application?

In other words, is the productivity of Delphi for database stuff the same as VB, or is it in the same league as ms-access/ Visual Fox Pro type product? (and why would this be so?).

Albert D. Kallal
Edmonton, Alberta Canada

Albert D. Kallal
Saturday, November 23, 2002

"Does Delphi/Kylix have any dramatic features (like ms-access does) to increase programmer productivity when building a data centric application?"

Yes, it does. In fact, you can create a very complex database driven program with a few lines of code, if any. This is not because Delphi is oriented to database work, but because of the VCL and its data aware controls. You can create fully functional database programs with Delphi in minutes, not hours.

Leonardo Herrera
Saturday, November 23, 2002

Well, I seen nothing in Delphi that is going to be any order of productivity better then the data bound controls and wizards you have in VB.

While both VB and Delphi can be considered rad tools, they are not data centric products.

This issue of data bound forms is quite critical to the issue here. It means that the whole product is designed around a form that is data aware. This concept means that whole design of the form responds to events, and this includes the data behind the form. This concept is so different then just a form with a bunch of data controls added that get bound to a database object. For the form to become data aware, you now have to write TONS of code to add methods to the form.

Try placing a simple form on a screen (not data bound in any way). Have a text box on that that form simply prompts for a invoice id (again, no data binding of any kind here for the form, or the text box). Now after the invoice number is entered, then launch open the invoice form (of course to that invoice id). This is a common task repeated over hundreds of times in a data centric application. The invoice form also might be launched from the example above screen, or it might be in response to a double click on some data grid that displays invoices for today. In either case, the process is a simple:

    “open of a form to a particular invoice”

With data bound forms, the code to open to that invoice form is only one line of code. In the after update event of our prompt box (on our first form for example ), we get.

Docmd.OpenFrom “invoice”,,,”Invoice = “ & me.Iprompt

That is it. The above will open the invoice form, and the “where” clause of the form (which is a SQL “where” clause without the word “where”)  will restrict the dataset to our single invoice. The invoice can then be closed, and we are now back to our original prompt screen. This process works equally well from a grid also. Note that a data grid in ms-access is actually a form, but in continues mode. This again is another killer feature of ms-access, in that forms can be switch into continues mode, and the all the controls repeat for you as grid. In vb, you have to use a grid control, or use a control array and “clone” the controls. Either approach does not give the same event model that you get in a ms-access form.

Now of course, the above is a simple example, and as things get more complex, then the difference between an environment with data bound forms, and those that do not becomes larger and larger as the project progresses. My above hint at using continues forms for datagrids is a perfect example. Some example screen shots of continues forms can be seen at:

In the above examples used, I use standard forms, but they where in continues mode (and thus the buttons and data repeats and looks like grid control). This form thus take minimal code.

Sure, you can add some “property” or method to the invoice form that allows you to send the invoice screen to the particular invoice, but then that is taking code. Code that someone has to write. And you will have to do this for each form. Also, the “event” or time that code runs is not the right event.

Now, that we have the above working with one line of code, we now must add code to check if the invoice exists and tell the user. Again, this is only a simple addition of a if statement, and use of the “cancel” option in the invoice form. In addition, we would use the cancel option in the on-open event for the form. You also have the standard on-load event that you have in VB. We have both events, and they BOTH can work with the data. Each of these events has a distinct and separate use.

The code to check for the invoice would look like:

If me.RecordSetClone.RecordCount = 0 then
  Cancel = true
  Msgbox “no invoice”
End if

Again, that is it. I did not even have to declare ONE variable in all my above examples so far.  (cancel is a event var in the on-open event).

Just how do you check for the existence of the invoice number in one line of code, without having to even declare one variable?

Note that these * two * open events (on-open/on-load) are also data aware. In VB your forms loads, and * T H E N * you start loading up the recordsets/controls. It is at that point you will have to check for the existence of the invoice and prompt the user. WAY more work. Not even in the same league.

I could bring up a 100 more examples like the above where products like VB will take way more code. And the examples get progressively worse for products like VB. This is especially in the case when we start using the “on current” and before update events for the form. The data bound form it self becomes a object which has tons of data aware events and properties (you are of course allowed multiple instances of the form, as they are of course simple class objects – like they are in most development systems).

Data centric products like ms-access exist to day because they simply do a  job better when writing business applications. Microsoft for years has attempted to add wizard after wizard and features to VB in an attempt to mitigate the how much work this takes. The results are not very good.

If VB or products like Delphi had anywhere near the same level of productivity as products like ms-access, then there would be no market for products like ms-access. This is despite the fact that VB and ms-access both use the same programming language (in other words, just add a bunch of wizards to VB and you would be done..right?…well wrong!!). As mentioned, both VB and ms-access use the same language.

This is not a issue of the programming language.

I still have not seen anything here in Delphi that is better than VB for database stuff. And VB is off of ms-access by at least a factor of 3. I see the issue of productivity comparisons of Delphi of that with VB, and not data centric applications like ms-access or Visual Fox pro.

By the way, I did write a payroll system in Pascal years ago. The idea of using Pascal for a development language is not a problem for me at all.

If anyone can show me that Delpi/Kylix is several orders better then is VB for data centric applctions..then I will probably start using it. (since the cross platform stuff is very appealing to me).

I have used a ton of different systems over the years. From using APL or MTS at University while taking computing science to writing payroll systems in Pascal. I have used a ton of platforms. In fact, I also do have my personal favorites also. My personal favorite system so far has been the Pick system. This is a post relational system, and is a much better model then is the traditional SQL relational data model that we use. My comments on pick can be read at:

However, while the above is a personal favorite, that is not the issue here. I stopped arguing about favorite systems and languages around the time I got out of high school.

I too also was a x-base programmer (FoxPro). I was not aware that a good many of the x-base developers wound up using Delpi for their database products. I sure did see a lot jump over from Clipper to FoxPro. However, this migration of x-base developers to Delphi was mentioned at the top of this thread, and is the first time I have heard this.

Perhaps I am mistaken, and maybe Delphi is a product that leans more towards data centric applications then a products like VB. I am still open to the fact that Delphi may be several orders of magnitudes better then VB, but I have not seen any evidence of this fact. If this is the case, then so be it, but I sure do not see this right now.

Is Delphi really a better and more data centric IDE then is VB?

Albert D. Kallal
Edmonton, Alberta Canada

Albert D. Kallal
Sunday, November 24, 2002

As a Delphi database programmer, I can tell you three things for sure. To begin with, Delphi is true RAD OPP in every sense of the word. VB is not! Also, it has recently come to my attention that the number of third party components made to work specifically for Delphi far exceeds that made for VB. And finally, I'll take a relational database built in Delphi using DBISAM tables over any database built in MS Access any day of the week.

Marty Potokar
Sunday, November 24, 2002

Delphi isn't better than Access for small projects. 

I always think of Delphi sitting between VB6 and C++: you can start with the nice easy drag/drop data-bound stuff like VB6, but you can move all the way to massively layered OO systems which spit on data-aware controls.  Of course, this is exactly where J++ and now C# are aimed. 

With Access, I've never seen a large project which doesn't look like a maintenance nightmare.  With VB6 I always felt that I would run up against a brick wall soon.  With VC++ I never knew where to start. 

Monday, November 25, 2002

Perhaps I am mistaken, and maybe Delphi is a product that leans more towards data centric applications then a products like VB. I am still open to the fact that Delphi may be several orders of magnitudes better then VB, but I have not seen any evidence of this fact. If this is the case, then so be it, but I sure do not see this right now.

I think the main point, the main difference, between ms-access and Delphi is that in Access you're limited in the "size" (scope) of the projects you can realistically aim to. Only 100% "data-aware", small projects can fly with Access. For that kind of apps, yes, access flies. You have a quick way of setinng your data model and then building around it.

Of course, _if_ the app has to do something more than basic data processing, you're out of luck. OR if you need to access a DB system that is bigger / more powerful than Access.

I see the difference as one between Word and a DTP system. Word lets you do quite a lot of things, writing-related, very quicly and conveniently. You can even strech its abilities and get quite professional-looking docs with it. But if what you want is to be able to produce _any_ kind of document, with the required finish and bells & wishtles, then a product like Quark / InDesign is a must.

Of course, using Quark to write a memo is quite overkill. And using Word to typeset a book is, if possible, a sure way of asking for trouble.

So, if you only need a very defined set of data manipulation, and it's within the "target market" of MS - Access, then that's easier, quicker, more convenient.  Of course, if the app then grows and scales (as most in-house app end up doing, in my experience, until they resemble the original app in very little), then you'll end up hitting the limits of Access sooner or later.

Delphi, on the other hand, gives you a full fledged programming eviroment, with a world-class OOP language, and a _wonderfull_ class libraries (VCL and CLX for x-platform development).  The data-aware controls and classes are very easy to use, and save you tons and tons of work (it's easier do to most DB-related things with them than with VB, IMHO); maybe not as dead-simple as in access, but the power to be able to do much more has a price, albeit a tiny one, IMO.

And, of course, with Delphi you can extend your app at a later time, to add "little" things as web-awareness, Web Services, client /server protocols, etc etc... And "porting" to different DBs is made quite easy because of the data manipulation layer, so you can code your app in a way that's not tied to a particular DB.

But of course, the only person that knows if the trade-offs are woth it is you. I tend to believe it's worth a little more power, but then that's me :) (Besides, I tend to think that working with Buidler / Delphi is great, but then that's my own bias :)

my 0,00002

Javier Jarava
Monday, November 25, 2002

"What are other peoples opinions of C++ builder ?"

I'm currently using C++ Builder and I think is simply the best tool that I have ever used under Windows.

You gain:
Power of C++ (OO,fast)
Very RAD enviroment (Visual Basic level)
The elegance of Borland Libraries

With Kylyx you can probably (never tried myself) run your project under Linux.

just my two cents

P.S. Sorry for my poor english

Giorgio Pallocca
Monday, November 25, 2002

Thank you all for your input.

Will C++ builder be available for Linux and the MAC?

Mike Grace
Tuesday, November 26, 2002

It's already available for Linux, see . It's doubtful there will ever be a Mac version, although I'd sure love to see one.

Frederik Slijkerman
Tuesday, November 26, 2002

Hi all,

Is Delphi really a better and more data centric IDE then is VB?

I agree that ms-access is sometimes more apropriate dev tool for small DB-centric applications over Delphi , but not VB. In Delphi besides being trully OO development tool, DB-aware controls actually works, so you can quickly drag-n-drop simple applications. Then it has variety of built-in report generators (QuickReports and Rave included in the box + much more on the web) and variety of database engines. This is just for simple applications. Then in high-end versions of Delphi 7 (Enterprise and Architect) you can find UML case tools, from which it is possible to genereate complete application from UML specs.

Tuesday, November 26, 2002

    I'm working to a project in C++Builder and I need some help for a thing: I have a TRichEdit on a form. How can I make a single line coloured in that RichEdit, and the rest of the lines to remain the same? (for example, as if you would put a breakpoint in the source code editor in CBuilder: the editor is white and a single line is red)

Tuesday, June 8, 2004

*  Recent Topics

*  Fog Creek Home