Neven wrote:
> I thought 'friend' in C++ is required for the overloading of operators
> (long time since i did any C++)
Yes, friend is often _used_ when overloading operators where the operator is
on one class and is adding or assigning in another class and wants to reach
inside the private 'other class' state to tweak it i.e. clobber a reference
count.
But essentially, friend allows another class (or method/function) to reach
in and 'see' and/or 'change' things that are normally private and
inaccessable.
> The reality of OO languages is that they are not the most efficient in
> execution
> (which is why you will not see real time control systems written in C++,
> Delphi, C#, Java et al)
Is this the 'C++ is slower and more bloated than C' misconception or is this
the 'assembler is the only language for real-time control' one?
Java and C# are usually implemented on virtual machine architectures (not
that they _have_ to be) so I'd say they're out for real-time control.
But the C++ is slower/bloated misconception is common and wrong. Read 'The
C++ Object Model' by Stanley Lippman which shows how good C++ (or Delphi) is
_just_ as efficient as good C and the work they do through to ensure it.
With C++ and a good C++ compiler, you can code at a higher level of
abstraction and get strong performance that would normally require some
fairly unmaintainable code to be written in C.
Hand-coded structures, jump tables and other such wierdness are hard to keep
straight by hand - I've known people who did it in C (Yee-haa!) but their
projects had some really nasty and subtle bugs in them (which got fixed
_eventually_) but the projects died on the vine when they left. No-one else
could handle maintaining them.
Maintainability is as important a code quality metric as Performance.
Focussing too much on either to the detriment of the other is bad for a
project.
Good use of C++ can offer higher maintainability _without_ costing you
performance. And in certain control applications, dealing with complexity is
a bigger threat (to project success) than response time. I'll take correct
but a little slow over 'fast and wrong' any day - at least you _know_ what
the problem is.
> It is funny but they same problems are facing DB developers - that the OO
> databases are horribly inefficient
> compared with relational ones (there is something about Heterogenous data
> that makes it difficult to process)
That's somewhat of a different issue - data modelling in a different
paradigm always involves trade-offs. It a case of knowing your tool. Since
most data is fairly homogenous, a full semantic relational model will often
be a better design trade-off than a full object DB data model.
Object databases are often implemented as big chunks of persistent virtual
memory so that VM paging can be using for locality of reference optimisation
since they have no explicit indication of when things are read.
As a result of the VM page design, they often have no explicit indication of
when things should be written (persisted) and even then, they have
everything done in 4K page frame chunks which is somewhat inefficient for
small tuples.
If you data model is heterogenous enough to need object models to avoid
piles of unmaintainable object-relational mapping code, you can avoid all
the O<->R mapping gunk but you'll pay for the VM swapping design.
TANSTAAFL.
> [22 pages of further rambling on the dialectic of computer
> systems control
> vs flexibility edited out here]
Heh :-)
> To conclude this is nothing wrong with Delphi (or TCollection) just you
> expectation of it
Whose expectation? Mine?
I'm not sure how this bit follows from the former stuff.
TTFN,
Paul.
---------------------------------------------------------------------------
New Zealand Delphi Users group - Delphi List - [EMAIL PROTECTED]
Website: http://www.delphi.org.nz
To UnSub, send email to: [EMAIL PROTECTED]
with body of "unsubscribe delphi"
