Mail Archives: djgpp/1996/12/23/06:03:18
Shawn Hargreaves wrote: (see below)
I agree this time. The speed of compiled C++ code depends on the
complexity of your class hierarchies. Overloading, lots of virtual
functions,
copy constructors and that sort of things are slow-downers.
C++ can be used for convenience, for hiding implementation of
parts of the code,or ... blah blah you all probably know this stuff.
There'll probably be a holy war on this subject for a long time.
Most C/C++ compilers however allow C and C++ code to be mixed. It won't
hurt to use C++ code in your C program or vise versa, as long as you
keep an eye on performance.
But hey, if you really want fast code, you should be concerned about
efficient software design, optimizing algorithms and clever data
structures. Do you know Edsgar Dijkstra? *Old* example: a bad designed
algorithm in C will be slower than an efficient algo in C++ (or BASIC,
bleh),
even with complex class hierarchies, virtual functions and copy
constuctors.
DISCLAIMER:
*I'm NOT saying that allegro is not properly designed, actually, I did
net test it yet, so this is not an attack to allegro*
>
> GEORGE ARUGAY MONTEMAYOR <gmontem AT mercury DOT sfsu DOT edu> writes:
> >shaman AT nlc DOT net DOT au wrote:
> >: Another question: Why is allegro pure C? Why not C++? Some of the
> >: things in allegro are just crying out for proper OO. Take the bitmaps
> >: for example. Now we have "create_bitmap" and "destroy_bitmap". Why not
> >
> >One word: speed. OO is slow.
>
> <enter holy war mode>
>
> I don't believe that, as long as you know what you are doing and only
> use OO features where they are appropriate. Most of the things that
> cause overhead (passing the 'this' pointer to member functions, calling
> virtual functions, etc), should only be used if they are needed, in
> which case they replace another construct which would have produced
> exactly the same overhead in C. Of course, it's easy to write bad, slow
> C++ code, but that is true of any language.
>
> <end holy war mode>
>
> But that isn't the point. The reason I wrote Allegro in C is that
> because people do disagree about this issue, and C code can be used from
> both C and C++. If you want to write wrappers for things like the bitmap
> structure I'd encourage you to do so, and release it as an add-on
> package. Uusing inline member functions it should be possible to add
> wrapper classes to the existing code with pretty much zero overhead.
>
> I did provide one C++ class, the 'fix' object which encapsulates the
> fixed point math functions. I didn't do any others, because I didn't
> think they were really neccessary.
>
> In fact, a lot of object oriented techniques are already used
> internally. In particuar, all the drawing functions are vectored through
> a set of pointers, to handle drawing onto different types of bitmap
> (mode-X, linear, and at some point in the future probably truecolor as
> well). So every time you call rectfill() or blit(), the resulting code
> will be identical to a virtual function call in C++...
>
> /*
> * Shawn Hargreaves - shawn AT talula DOT demon DOT co DOT uk - http://www.talula.demon.co.uk/
> * Ghoti: 'gh' as in 'enough', 'o' as in 'women', and 'ti' as in nation'.
> */
--
-------------------------------------------
email: <mailto:R DOT L DOT F DOT v DOT Paasen AT stud DOT tue DOT nl>
www: <http://huizen.dds.nl/~buddha/>
- Raw text -