Yes, the
>but result in over memory-hungry programming techniques with a
>consequent detriment to speed.
I'm not sure that such problems are directly connected to object
oriented programming techniques. "Bad Programmers can write Bad
Programs in Any Language".
Its also important not to confuse the concept of OOP with the "program
generator/4GL/RAD" approach of packages like MS Visual <Whatever> and
Delphi. Yes - they have a full programing langauge and Windows API
under the hood, so you *can* use them to write any conceivable
application - but all the class libraries/wizzards/helper apps are
pitched at the "corporate programming" market which is almost synonymous
with "databases".
When the PC market talks about Rapid Application Development (RAD) they
really mean "Rapid Database Customization". Acorn users may dispute
this use of the phrase "Application" but it probably encompasses 90% of
commercial programming. Visual C++ does not come with a "MIDI sequencer
Wizzard[1]"... I'm looking seriously at Borland OWL for my next bit of
Windoze programming because, at least on the surface, it looks far more
flexible and modular than MFC (and it supports Win3.1!)
However, OOP concepts do work very well with WIMP interfaces (probably
because they share a common ancestry - Smalltalk introduced both OOP and
the WIMP environment to the world. Even writing a WIMP app in plain C
forces you quite a long way down the OOP path. There's really not much
difference between:
update(&window_instance,box);
and:
window_instance.update(box);
... given an efficient C++ these would generate almost identical code.
The main annoyances in C++ are (a) all the faffing around you have to do
to get WIMP events passed to member functions and (b) the C header file
concept, which really isn't up to it. Java looks to be a little better
in these respects.
[1] (sic) - I *really* want to write an Acorn C++ class library simply
so I can call it "Unseen C" and have a class wiz(z)ard called
Rincewind... :-)
--
Daniel Pead
Email: d...@octpen.demon.co.uk WWW: http://www.octpen.demon.co.uk/
> ... given an efficient C++ these would generate almost identical code.
> The main annoyances in C++ are (a) all the faffing around you have to do
> to get WIMP events passed to member functions and (b) the C header file
> concept, which really isn't up to it. Java looks to be a little better
> in these respects.
Phew, you're not kidding about passing events to member functions. I've
come up with quite a nice transparent way of doing it with templates,
but you have to be careful with bloat, and CFront isn't up to it.
--
\____________________
\ http://www.tcp.co.uk/~tonyh/
The Curling Pages \ The home of WinEd, Bombz and NewsFind for RISC OS
Yeah, right! I've spent a condierable amount of time trying to use clever
techniques to get CFront to do something sensible wrt template callbacks and
registering handlers always resulting in something along the lines of "AT&T
internal error: memof not found" or something - most frustrating.
What compiler have you been using? I've never actually got round to playing
with gcc, can it handle this stuff properly and are there any specific
disadvantages to using it as a drop in replacement (especially now there's
a shared c library interface for it)?
--
Dan Ellis MSc, http://www.apltd.co.uk/
Senior Software Engineer, http://www.pod51.demon.co.uk/
Applied Photophysics Ltd. mailto:del...@apltd.demon.co.uk
At least with RISC-OS there's less than 20 WIMP events, so you could
probably get away with a virtual function for each without humungous
vtables. Unfortunately, the "message" event covers a multitude of
sins...
Its a pity that (AFAIK) even Java doesn't seem to have a neat solution
to this...
For anybody who hasn't got the message (:-)) the problem is that, while
its (e.g.) lovely to express your dialogue box object as:
class MyDialogue : CDialogue {
// wibble
OnOpen(wibble);
OnRedrawRequest(wibble);
OnClose(wibble);
OnOkClicked(wibble);
OnCancelClicked(wibble);
};
... you still need to arrange for those member functions to get called
when the events arrive - it usually comes down to a switch statement or
lookup table for each sub-class (which seems a bit of a let down!).
>For anybody who hasn't got the message (:-)) the problem is that, while
>its (e.g.) lovely to express your dialogue box object as:
>class MyDialogue : CDialogue {
>// wibble
> OnOpen(wibble);
> OnRedrawRequest(wibble);
> OnClose(wibble);
> OnOkClicked(wibble);
> OnCancelClicked(wibble);
>};
>... you still need to arrange for those member functions to get called
>when the events arrive - it usually comes down to a switch statement or
>lookup table for each sub-class (which seems a bit of a let down!).
And before anybody else posts saying that they don't need to do that
for this & that library, then the difference there is that the library
you are using is doing this all for you. I can't see that it is too
hard to do - particularly at a high level - through the use of virtual
functions *provided* that you have good abstract classes with the right
methods. Several people have attempted to build these base level
classes. I don't know what the relative success rates of each is or
whether any of them are any good as I haven't used C++ under RISC OS
yet (all the programs I want to write require complicated templates it
seems and cfront doesn't support them :-/)
--
Stewart Brodie, Electronics & Computer Science, Southampton University.
http://www.ecs.soton.ac.uk/~snb94r/ http://delenn.ecs.soton.ac.uk/
> In article <bf2a5...@tonyh.tcp.co.uk>, Tony Houghton
> <to...@tonyh.tcp.co.uk> writes
> >Phew, you're not kidding about passing events to member functions. I've
> >come up with quite a nice transparent way of doing it with templates,
> >but you have to be careful with bloat, and CFront isn't up to it.
>
> At least with RISC-OS there's less than 20 WIMP events, so you could
> probably get away with a virtual function for each without humungous
> vtables. Unfortunately, the "message" event covers a multitude of
> sins...
Not to mention the Toolbox. No wonder Acorn didn't provide any C++
libraries with it ;).
> I haven't used C++ under RISC OS yet (all the programs I want to write
> require complicated templates it seems and cfront doesn't support them
> :-/)
Why can't you use GCC?
> What compiler have you been using? I've never actually got round to playing
> with gcc, can it handle this stuff properly and are there any specific
> disadvantages to using it as a drop in replacement (especially now there's
> a shared c library interface for it)?
Sorry about the delay, I only got your message dated a whole week ago
today. Talk about slow propagation :-(.
I'm not doing anything with C++ at the moment, I've just been using
Acorn Cv5 lately. I have "played" with GCC, and it certainly is up to
the sort of templates needed for handling events nicely - after all, it
can compile the STL, albeit a hacked version.
I'll use it for any serious C++ stuff I want to do on RISC OS in the
future (I think Acorn have completely given up on supplying development
tools for RISC OS, but I hear it will be a very different story with
Galileo), despite the drawbacks. Namely, I think it's a bit slower than
CFront, and I don't think you can use most of the standard C++ libraries
without UnixLib, so compiled code is going to be big.
--
\_________________
> I'll use it for any serious C++ stuff I want to do on RISC OS in the
> future (I think Acorn have completely given up on supplying development
> tools for RISC OS, but I hear it will be a very different story with
> Galileo)
I asked at the recent show "When will we get a new C compiler" and the
answer was (AFAIR) "Xmas".
--
Element of the day: Neon, symbol Ne, number 10, row 2, group 0.
> In article <b6de7...@tonyh.tcp.co.uk>,
> to...@tonyh.tcp.co.uk (Tony Houghton) wrote:
>
> > I'll use it for any serious C++ stuff I want to do on RISC OS in the
> > future (I think Acorn have completely given up on supplying development
> > tools for RISC OS, but I hear it will be a very different story with
> > Galileo)
>
> I asked at the recent show "When will we get a new C compiler" and the
> answer was (AFAIR) "Xmas".
All very well, but I'm reasonably happy with the C compiler. Will the
new kit include a decent C++ compiler and libraries that are more than
just veneers for the Toolbox? OTOH I think it's highly likely there'll
be a much improved debugger, so that could be worth upgrading for.
--
\____________________