Re: Object interfaces to Vsta

Spoke Lars Pensjo thus:
>
> Wouldn't it be a good idea to create an object oriented interface to
> system services, libraries etc ? Now should be the right time to do this,
> before Vsta grows too much.

The *architecture* is already quite "object oriented"; you have servers (objects)
which communicate with each other via messages (methods) via some protocol
(interface). The only real benefits in *implementing* in a language like c++
are some notational conveniences and better support for compile time interface
checking. The costs are: a larger, heavier, buggier, slower tool set;
c++ linking semantics (like multiple pass linking, name mangling); and having
to live with a language which is a moving target for the ANSI standardisation
committee (some of the more pessimistic people I work with doubt C++ will ever
become standardised; there are just too many undefined constructs, and more
keep appearing as existing ones are defined).

Also, as far as the kenel programming is concerned, there are some C++
features that are just too risky to use, like static constructors.

> What are the possibilities to also port g++ to the Vsta environment ?

I guess that g++ itself wouldn't be much harder than gcc. Making libg++
thread-safe could require some work. There are some iostream functions,
for example format() which are just not thread-safe. They may fallen out of
favor these days, I haven't been keeping up with developments in C++ for
a year or so.

> For example, most servers use quite a lot of common code. How about making a
> class for this ?
>
> Define a basic class for client process message management. This class would
> handle the switch-statement, and then call virtual member functions
> depending on the message type.
>
> It is now quite easy to override the function whose behaviour
> you want to change. This is also a better solution than a C-mechanism
> where you register call-back functions.

For trivial servers, yes, but it's not a great benefit. All you're doing is
pushing a smallish switch statement into the library. Also note that C++ only
supports static classing, i.e. you can't change methods on the fly. As soon
as your server has states like ``uninitialised'' and ``waiting-for-response''
you revert to standard procedural code.
 
> There is some overhead as functions will be called indirectly through pointers
> instead of code being executed inline in the switch statement, but I really
> think it is minor.

Yep.
 
> An example how it could look:
>
> [ ... ]
>
> This class should probably be split into two, where the base class doesn't
> handle hashing of clients.

These ideas are well and good, but I don't think it's useful enough to mandate
requiring C++ to build vsta. Incidentally, don't get me wrong ... I quite
like programming in C++, but I think it's one of those right tools for he
right problem things.

Where I think C++ class could be more useful is in the encapsulation of
connections to servers, where the interface to the class represents the
interface to the server .... but at the moment I'm just waving my hands and
don't really have any concrete ideas :-)

Cheers,

Christopher Fraser
chrisf@sw.oz.au
Received on Wed Aug 17 19:31:07 1994