Page #38 (Chapter 2. Designing Interfaces)

< BACK  NEXT >
[oR]

Why a New Language?

In the previous chapter we learned that separating interfaces from implementation provided a level of indirection that a) allowed the vendor to change the implementation class without requiring the client to recompile, and b) allowed the vendor to select a C++ compiler of his choice.

Given that most components are written and will continue to be written in C++, at first thought it doesn t make sense to use a new language for defining interfaces. Why must one go through the pain of mastering yet another language?

The reason is the inadequacy of C++ language for some of the goals that COM wanted to achieve. Let s examine these goals in detail and see why some of these goals cannot be achieved if C++ is used as a language for defining interfaces.

Programming Language Independence

Although C++ is an extremely useful programming language, there are other programming languages that are better suited to the task at hand. It doesn t make sense to restrict the developers to just C++. After all, we took extra steps to ensure that the client and the component do not know each other s implementation details. It seems logical that both of them should be able to use a programming language of their choice.

Logical indeed! The question, then, is: How can you define an interface that any programming language can understand? If interfaces are defined in C++, we are forcing the clients to work in C++.

One could possibly provide a tool to translate the C++ interface definition into every possible programming language. As the binary signature of the C++ interface definition is just a simple vptr/vtbl (see Chapter 1), one could conceivably do the translation for a large class of languages.

A major problem with this technique is that C (and C++ as an extension) is fraught with ambiguities. Consider, for example, the following C declaration:

 long* plValue; 

Under C, this could refer to either a pointer to a single long, or the beginning of an array of longs.

Such an ambiguity, though very delightful to hardcore C developers, cannot be left unresolved if the declaration has to be mapped to other languages.

There is yet another ambiguity. The above declaration, when used as a method parameter, does not indicate if a value is being passed as input, or if the value is to be filled as output, or both.

Such ambiguities make it less ideal for mapping C++-style interface definitions to other languages.

Remote Transparency

Besides gaining programming language independence, it would be nice to facilitate the communication between client and servers, even when they do not share the same process space. At the same time, we should not overburden the software developers with the details of data handling between the two processes. Both the processes can run either on the same machine or, as a natural extension, on two different machines on the network. In order to achieve such interprocess or location transparency, one may have to provide extra information to COM infrastructure. An interface defined in C++ is not adequate enough to provide this additional information.

Given these goals for COM, the C++ language is not a good choice for defining interfaces. We need a different language, a language that does not have the inadequacies of C++.


< BACK  NEXT >


COM+ Programming. A Practical Guide Using Visual C++ and ATL
COM+ Programming. A Practical Guide Using Visual C++ and ATL
ISBN: 130886742
EAN: N/A
Year: 2000
Pages: 129

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net