Teach Yourself Borland C++ in 14 Days - portal

490 Day 14
Pascal. After all, they had a loyal base of customers that might not take kindly to
enhancements to the language they had come to know and love. Still, Borland was in a solid
position in the Pascal market and went ahead with their plans. The result was the smash hit
Delphi (the Borland internal code name stuck and became the official product name).
But modifying C++ is another matter entirely. As I said at the beginning of the chapter, the
world had been crying for a RAD C++ product for a long time, so it was not a question of
whether such a product was needed, but more a question of how to go about it. Simply put,
the component model that was so brilliantly implemented in Delphi could not be emulated
in C++ given the current structure of the language. Something had to give.
The problems associated with modifying the C++ language are many. First, there is a C++
standards committee. It is this committee’s job to decide what features should be in the C++
language and how those features should be implemented (there is no such committee for
Pascal or BASIC). I could write an entire chapter on whether this system actually works, but
I’ll spare you the details. Suffice it to say that simply because a C++ standards committee exists
means that messing with the C++ language can be expected to be met with some criticism.
On the other hand, compiler vendors all implement extensions to the C++ language in some
form or another. The theory is that you should be able to take an MFC program, for example,
and compile it with any C++ compiler. After all, that’s why there is a standard, right?
Unfortunately, it doesn’t work that way. For whatever reason, MFC contains a fair number
of nonstandard extensions to C++ so you cannot, for instance, compile MFC with the
Borland compiler without some tweaking (Borland C++ 5.0 does have the ability to compile
MFC programs, although Borland had to bend a lot of C++ rules to allow compiling of MFC
programs). So, as you can see, it’s a less-than-perfect world in which C++ operates to begin
with. Since all C++ compiler vendors extend C++ in one way or another, the debate then gets
to be one of degree. Company A extended C++ more than did Company B, so Company A
has the better C++ compiler. A pointless debate, in my opinion.
One of the other problems with extending the C++ language is public perception. Since C++
is rumored to have a “standard” (yes, I use the word loosely), modifying it in any way might
unnerve some dyed-in-the-wool C++ programmers. This is probably a better reason to tread
lightly when thinking about C++ language extensions than the standards issue. After all, those
people are your customers and you better have a handle on what they think before you start
extending their programming language of choice. As I said before, Borland conducted
surveys to determine the public’s feelings on this issue. Rest assured that they did not arrive
at their decision without a great deal of corporate soul searching. The result of the surveys
indicated that many programmers would be willing to accept language extensions to have a
true RAD product for C++. To them the language debate was not as important as the prospect
of increased productivity.