PE> Show me the C++ code you think would be slower if written in C. Or
PE> better  still, write both the C and C++ versions, and have a look 
PE> at the assembler generated for each, and look at the 
PE> relative code.  They should be the same (speedwise).  BFN.  

FA> NO WAY, NO HOW am i getting into a C vs. C++ argument, 
FA> but if i had to use 

PE> Doing "performance tuning" without the grottiness of 
PE> actually using profiler, looking at assembler etc, eh?  :-)

FA> I'm not all that paranoid about speed in textmode. 

I don't mind if you don't care about speed.  I do mind if you say that
something is faster in C++ than C, without actually using a profiler of
test program before making that statement.  :-)

FA> Did you have to do a 
FA> lot of tuning on Msged, and if so was it worth it ?

The things that were taking a long time, were:

1. rescanning of the messagebase, which I changed by using a binary search
instead of sequential search of the index file.

2. message list, which I fixed by not chasing up reply-links when all I
wanted was the from, to + subject.

The second of those was certainly worth it.  I'm not sure about the first
one, it was too long ago and I was too drunk.

FA> Talking about profilers, with release 4++ on, Borland decided that we
FA> don't need one anymore. 

I don't think they give you an assembler, either.  They bundle both of them
separately now, I believe.

FA> I tend to disagree, so do you know of a generic  
FA> profiler ? (if there can be such thing)

I thought there was something called TCPROF and PROFIL42 or something.
Which aren't quite "generic", but I think it may be possible to
write a symbol-table conversion program on them to make them work.

FA> My TurboC prof won't touch the BC4 code, perhaps it knows s'thing.:)

Of course, whilst you're writing portable C code, it doesn't matter which
compiler you normally compile with normally, if you have a compiler
particularly suited to profiling, you can switch to it.

PE> You do realise that the original C++ was just a translator that
PE> produced C  code, don't you?  Ergo, whatever was done in C++ can be 

FA> No i didn't. By the time i got to it, it had virtual functions, 
FA> overloading etc..
FA> AMOF o/loading has to be the most appealing thing (to me) about C++.

It had all those things in CFRONT, I believe.

FA> It does look more efficient from there on. But that setting tables business
FA> took about a 1/4 of the assmebly space. 

There's no point looking into the "from there on" efficiency
until the whole thing has been profiled, C++ is faster, and you want to
find out why.  :-)  BFN.  Paul.
@EOT:

---