Re: Object interfaces to Vsta

From: Dave Hudson <dave_at_nospam.org>
Date: Wed Aug 17 1994 - 05:48:23 PDT

Jonathon Tidswell wrote:
>
>
> ----------
> > From: Lars Pensjo <lars@distinct.se>
> > To: <vsta@cisco.com>
> > Subject: Object interfaces to Vsta
> > Date: Wednesday, 17 August 1994 10:18
> >
> >
> > 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.
> It depends on which OO language people wish to use.
> I don't accept, a priori, that C++ is the "right" OO language, it
> depends, at least in
> part, on what you wish to use the OO language for.
> Do you wish to develop system services in an OO environment or just provide an
> OO environment for people to experiment/work in.
> [ Note I am (possibly inappropriately) distinguishing system from non-system
> services. ]

I'd really like to get an Oberon-2 compiler running on VSTa (already
discussing it with the guys who did Linux Oberon), but that would be to see
how well it worked - not to convert the existing code over. One of the
things I really like about VSTa's message passing system is that I don't
have to implement every server in exactly the same way and with the same
tools - I've always wanted to be able to experiment.

FWIW I think that the distinction between system and non-system services is
a little grey - the only thing I'd really be worried about tampering with
would be the kernel.

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

Shouldn't be too difficult - it already ports to DOS. When I did my run on
GNU tools a couple of months back, if it ported to DOS it was easiest to start
with that as a base and remove any of the code that stopped things like
pipes from being used. When 1.4's available the extra library code should
make this fairly simple for anyone who'd care to try. I'm not sure how
close we'll be to running configure scripts (pretty close I think), but at
the worst we'd just need to run them on a Linux or xxxBSD box and then do a
little bit of hand editing the makefiles.

> > For example, most servers use quite a lot of common code. How about making a
> > class for this ?
> Please don't assume all people "love" objects.
> Also see the long running discussion on g++ vs gcc in the Linux community.
> [ Partial summary: Linus used C++ for its better type checking, but the
> community
> wanted C because on their poor slow machines g++ compiles took hours or days
> not minutes --- g++ was too resource hungry --- it ended up with lots
> of #ifdef's. ]

I think the other part of this debate (I don't know if you read the Linux
kernel channel) was that g++ kept generating the wrong code and introducing
obscure bugs/races. I don't know about 2.6.0 though - anyone tried it yet?

> > 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.
> My understanding is that virtual class methods are function pointer
> struct members.

Perhaps the best way to determine the effects would be to cross compile a
server with this sort of class library. I'd think a good idea would be to
code a dummy server that provides access to a single data file (as a
primitive file server) - it should only take a couple of hours to code one
in C. If we then have an identical C++ based server we can measure
preformance on accesses to both servers (and we can also look at how large
both are). (Just for completeness I think both the C and C++ servers should
be compiled on the same version of gcc/g++ and with the same optimisations
set).

I'm not trying to make any philosophical points here - it just seems like a
good way to get some sort of practical answer to something that seems to be
causing more religious wars in the newsgroups by the day :-(

                Regards,
                Dave
Received on Wed Aug 17 05:07:18 1994

This archive was generated by hypermail 2.1.8 : Wed Sep 21 2005 - 21:04:28 PDT