by Marco Cantu
This review of C++Builder 1 was originally published by Marco Cantù in 1997. It’s reproduced by kind permission of the author. It is reproduced verbatim from the original.
When Delphi was first released many programmers complained: “Why isn’t it based on the C++ language?”. Some of them (including myself) replied: “Simply because this is not possible, due to many missing features of the C++ language”. Now that Borland has released C++Builder, or Delphi for C++, you might think I’m going to start finding excuses for my wrong statement. I’m not! I still think my statement is correct. In fact Borland C++ Builder is not based on the ANSI C++ language, but on a heavily extended version of this language, which includes almost all the major features of the Object Pascal language found in Delphi.
In this article I’m going to discuss all these language extensions in details, providing some background for programmers with no experience with Delphi. I’m not going to cover all of the new C++Builder features, such as the macros used to implement open-array parameters or the template used to clone Pascal sets. I’m going to focus only on the core features.
One of the key elements of visual programming is the idea of the properties of an object. But what is a property? A property is a name with a type, related to some data or data access member functions of a class.
One of the basic ideas of OOP is that data members should always be private. Then you’ll often write public member functions to get and set that private value. If you later modify the implementation, you can easily change the code of these access functions, and avoid any change in the code which uses the class.
Here is a basic example (written following the standard naming conventions for properties, fields, and access functions):
private:
int fTotal;
protected:
void __fastcall SetTotal (int Value);
int __fastcall GetTotal ();
The code of these two member functions (not shown) simply sets or returns the value of the private data member fTotal.. You can use them in the following way:
int x = Form1->GetTotal();
Form1->SetTotal (x + 5);
This is the standard C++ approach. In C++Builder we can define inside a class a property wrapping these access functions:
public:
__property int Total = {
read = GetTotal,
write = SetTotal };
This means we can now access to this value in a more uniform way, since we use the same notation both for reading or writing the property:
int x = Form1->Total;
Form1->Total = x + 5;
Depending on its role in a statement, the expression Form1->Total is translated by the compiler in a call to the read or the write function. Actually the compiler can translate a similar expression also into a direct data access. Look at the following property declaration:
private:
int fValue;
public:
__property int Value = {
read = fValue,
write = fValue };
Although this code seems strange at first, it fully demonstrate the role of properties as an encapsulation mechanism. In fact, we can later change the declaration of this property introducing one of two functions instead of direct data access. In this event, we’ll need to recompile the code of the classes which use this property, but we won’t need to modify it.
Obviously access functions are not restricted to read and write private data, but can do anything. One of the typical effect of write functions is to update the user interface. Here is a new version of the Value property, followed by the code of its write function (written following the standard style):
__property int Value = {
read = fValue,
write = SetValue };
void __fastcall TForm1::SetValue (int newValue)
{
if (fValue != newValue)
{
fValue = newValue;
Label2->Caption = "Value = " +
IntToStr (fValue);
};
};Now if we write the following statements:
Value = Value + 2;
Value += 2;
Value ++;
the effect of the change in the data will reflect automatically in the user interface. Notice that this works also with operators. When you apply the increment operator (++) to the property its value is read and the Set method is called. I really think properties are a sound OOP encapsulation mechanism!
Beside the basic structure we have seen, property declarations allow you many alternatives. A fundamental idea is that properties have a data type, but are limited to a given set of data types (including most of the predefined types, strings, and classes).
Properties can be read-write as in the examples above, but they can also be read-only or write-only. What is common is to see read-only properties, that is values you can read but not change. An obvious example of a read-only property in the VCL (the Visual Component Library, Delphi’s class hierarchy used also by C++Builder) is the Handle property of window based controls. You might want to ask to a control its Windows handle, when you want to call Windows API functions directly, but you are not supposed to change the handle of a window. To define a read-only property you simply omit the write declaration:
__property int ReadValue = {
read = GetReadValue };It is possible to declare array properties, that is properties with an index. In this case the required read and write functions have an extra parameter, the index itself. This index must also be used to access to the values, since you cannot access to the array as a whole. The array might not exist as an actual field of the class: when you read the Items of a list box you are actually asking to Windows the value of the item (which is not duplicated inside the TListBox object). It also possible to declare array properties with multiple indexes (see as an example the Pixels property of the TCanvas class of the VCL).
Properties can be declared using any of the access specifiers, including private (although this makes little sense), protected, and public, plus the two new specifiers: __published and __automated. Read-only properties cannot be published, by the way.
A published field or method is not only available at runtime (as a public element) , but also at design-time. The Borland C++Builder compiler generates Delphi-style Runtime Type Identification (RTTI) for published properties of class derived from TPersistent. This type information is used by the design time environment, starting with the Object Inspector, but it is also available to programmers who want to delve into the undocumented TypInfo unit.
The published keyword is generally used for properties or events, but forms generally have a published interface including also sub-components and event-handler methods. This information is automatically parsed by the development environment and made available in the Object Inspector even before you compile the program.
For example, while the published interface of a component is used by the Object Inspector to show and edit property values at design time, the published interface of a form is used by the Object Inspector to find components compatible with a given data type and member functions compatible with a given event.
There is a fifth access specifier, automated, which is used to define a public interface with corresponding OLE Automation type information, making it possible to create OLE Automation Servers. The __automated keyword is used in TAutoObject subclasses.
Keep also in mind that the visibility of a property can be extended in derived classes. A protected property, for example, can be re-declared as a published property. To accomplish this you don’t need to redefine the property, and only to re-declare it (Borland use the term “hoisted properties” to indicate this behavior). When re-declaring a property you can also change it, for example modifying its default value.
When properties are of a “pointer to a member function” data type (also known as a closure) they are called events. But what is a closure? Another addition to the standard C++ language. A closure is a sort of member function pointer. Actually it associates a pointer to a member function with a pointer to a class instance, an object. The pointer to the class instance is used as the this pointer when calling the associated member function. This is the definition of a closure:
typedef void __fastcall (__closure *TNotifyEvent)(TObject* Sender);
Since in C++ member function pointers are available as well, but seldom used, you might wonder what do we need this awkward stuff for? Closures really matter in the Delphi model. In fact events are closures, holding the value of a member function of the form hosting the related component. For example, a button has a closure, named OnClick, and you can assign a member function of the form to it. When a user clicks on the button, this member function is executed, even if you have defined it inside another class (typically, in the form). Here is what you can write (and C++ Builder usually writes for you):
BtnBeep->OnClick = BtnHelloClick;
BtnHello->OnClick = BtnBeepClick;
The code above exchanges two event handlers at runtime. You can also explicitly declare a variable of a closure type, as the common TNotifyEvent type, and use it to exchange the handlers of two events:
TNotifyEvent event = BtnBeep->OnClick;
BtnBeep->OnClick = BtnHello->OnClick;
BtnHello->OnClick = event;
This means you can assign a member function (as BtnHelloClick) to a closure or event both at design time and at runtime.
The classes of the derived from TPersistent have another important features. You can save objects of these classes to a stream. The VCL doesn’t save the internal data of an object, but simply saves the values of all of its published properties (and events). When the object is loaded, the VCL first creates a new object, than re-assigns each of its properties (and events). The most obvious example of objects streaming is the usage of DFM files. These binary files store the properties and the components of a form, and I suggest you to load them in C++Builder editor to study their textual version (you can also use the command line CONVERT.EXE program to turn a DFM file into a TXT file or vice verse)
The streaming process can be customized in different ways: adding a default or a stored clause to the declaration of properties, or overriding the DefineProperties method. When you add a property to a component you generally add to the definition a default clause. If the value of a property matches its default value, the property is not saved to a stream along with the other properties of an object. The constructor of the class must initialize the property to the same default value, or this technique won’t work. The stored directive, instead, indicates if a property must be saved to file along with the object or not. The stored directive might be followed by a boolean value, or a member function returning a boolean result (so you can choose whether to save the value or not depending on the current status of the object). Finally, the DefineProperties method allows you to create pseudo-properties, adding extra values to the streamed object, and reloading them properly.
Beside RTTI information generated by the __published keyword, each object has several methods you can use to query itself. These methods are part of the TObject class, the base class of every VCL-based object. You can see the list of the methods of the class TObject (including static member functions) in Table 1.
Table 1: TObject member functions
// public member functions
TObject Free ClassType
CleanupInstance FieldAddress AfterConstruction
BeforeDestruction Dispatch DefaultHandler
FreeInstance ~TObject
// static public members function
InitInstance ClassName ClassNameIs
ClassParent ClassInfo InstanceSize
InheritsFrom MethodAddress MethodName
To check if a class is of a given type, you can use the ClassType method. This is quite common with the Sender parameter of an event handler. This parameters refers to the object which has generated the event, but is of the generic TObject type. When you associate the same method to events of different objects, you might want to check the type of the object which has caused the event:
if (Sender->ClassType() == __classid(TButton))
Beep();
The __classid is another keyword added to C++Builder. It returns the metaclass of the object (see the next section). The alternative (not always valid) is to use the Sender parameter of an event handler and cast it to a given data type, using the standard C++ dynamic_cast technique. This makes sense if we know the data type or that of a common ancestor class, as in this case:
TWinControl* wc = dynamic_cast<TWinControl*> (Sender);
if (wc != 0)
wc->Left = wc->Left + 2;
As I’ve mentioned, beside these RTTI capabilities, Delphi and C++ Builder share extensive type information, available at runtime for every object of a class derived from TObject and having published fields, properties, or methods. For example, you can access to a property dynamically, by name; you can get the list of the names of the properties of a class; you can get the list of parameters of a closure. This allows programmers to build very powerful add-on tools to the environment, and is used by the system itself as a basis of the visual development tools, starting with the Object Inspector (I’ve actually built a runtime clone of the Object Inspector).
Delphi introduced the concept of class reference, a pointer to the type information of a class. In C++ Builder this has been mapped into the idea of a TMetaclass class, and the TClass type is nothing but a pointer to this metaclass. In Delphi TClass has a similar role but a different definition (although the two implementations are totally compatible).
The methods available for a metaclass correspond exactly to the static methods of the TObject class (in fact, there is no TMetaclass class in Delphi, but class reference, which can use the static methods of TObject directly). Once you have a TClass variable, you can assign to it a class, extracted from the object (with the ClassType function) or obtained from the class itself by using the __classid keyword. Here is an example:
TClass myclass = __classid (TEdit);
You can use a metaclass almost as you use a class reference in Delphi. What is not possible in C++Builder is to create a new object based on a metaclass. This is odd: C++Builder allows you to define virtual constructors, but then provides no way of calling them, unless you call a Delphi method. This is what happens when you define a new component in C++Builder and then let the VCL handle it (for example, when you load a component from a stream its virtual constructor is called).
To create an object from a class reference we need to add a simple Pascal unit to our C++Builder application. Here is the code of the Pascal function we can use:
function DynCreate (myclass: TComponentClass;
Owner: TComponent): TComponent;
begin
Result := myclass.Create (Owner);
end;
We can use this function is a C++Builder application. This is the plain code you can use to create a component of a given class at runtime, and place it inside a ScrollBox control:
void __fastcall TForm1::BtnNewEditClick(TObject *Sender)
{
TEdit* edit = new TEdit (this);
edit->Parent = ScrollBox1;
edit->Left = random (ScrollBox1->Width);
edit->Top = random (ScrollBox1->Height);
edit->Text = "Edit" + IntToStr (++Counter);
}
This is the code you can use to create a component of the same type of the Sender object:
void __fastcall TForm1::OnDynNew(TObject *Sender)
{
TClass myclass = Sender->ClassType();
// illegal:
// TComponent* Comp = new myclass (this);
TComponent* Comp = DynCreate (myclass, this);
TControl* Control1 = dynamic_cast<TControl*> (Comp);
if (Control1 != 0)
{
Control1->Parent = ScrollBox1;
Control1->Left = random (ScrollBox1->Width);
Control1->Top = random (ScrollBox1->Height);
Control1->Name = "Comp" + IntToStr (++Counter);
}
};
As we have seen, Borland added many news features to the C++ language in C++ Builder to make this language compatible with Object Pascal, and tailored for component-based programming. Extending C++ this way may seem a little awkward, since we are trying to map the constructs of a language into another language. However, the easy of use of the environment and the visual development are probably worth this extra complexity, which most of the times remains behind the scenes.
At the same time C++ Builder retains full compatibility with the ANSI C++ standard, including templates and the STL (to name two features not available to Delphi programmers), and allows you to mix VCL-based code with MFC or OWL code, although this makes sense only if you have existing applications. The VCL library, in fact, allows you to leverage visual programming and work at a higher abstraction than the typical C++ Windows class libraries.
There are many other differences between Delphi and C++Builder, but the implementation of properties is the feature with the highest impact in term of C++ language extensions. Most of the other issues (message maps, sets, and open array parameters, to name just a few) have been solved using existing C++ keywords and language features.
Marco Cantù is a freelance writer and consultant, based in Italy. He has written programming books on both C++ and Delphi, translated in 10 languages worldwide. He contributes to several magazines, enjoys speaking at conferences, and teaches advanced Delphi and C++Builder seminars worldwide. You can reach him at 100273.2610@ compuserve.com or http:// ourworld. compuserve. com/ homepages /marcocantu.
This review of C++Builder 1 was originally published by Marco Cantù in 1997. It’s reproduced by kind permission of the author. Note that this is reproduced verbatim — which also means the profile and Compuserve email above is out of date! Marco works today for Embarcadero on Delphi, C++Builder’s sister product, and as the IDE & Code Tooling lead.
C++Builder celebrates 25 years on Feb 26, 2022!
Embarcadero have created a fantastic poster showing C++Builder’s history in a timeline with other key development events. This is perfect for printing out and placing on a wall near your desk, or even just opening as a PDF and browsing. It’s massive and detailed.
Industries from engineering to scientific research, textiles to green electricity, museums to department stores, everyday useful apps that you might not even know are made with C++Builder up to industrial grade software deployed across entire countries and used by millions: you’ve used software made by C++Builder, and those developers got their job done fast, and done well, due to its productivity and libraries.
It began 25 years ago. It’s only grown. And you can use it today.