Hmmm, I promised myself not to enter further C/C++
discussions and I think the discussions should stop
but I'd like measured data.
E.g. the keyboard.cc class becomes 4% LARGER when the
SMF hack flag is set to 1.
The reason is obvious:
replacing
this->a++
by
statica++
replaces space efficient pointer based addressing with
a 1 byte offset by space inefficient addressing with 4 byte
absolute adresses. In general larger code runs more slowly
than more compact code, but in this context pushing the
this and loading the this in a basepointer might be sufficient
to make the static variant slightly faster...
The basepointer + 1 byte offset is the standard stack addressing
and this is one of the reasons why stack based variables are
so efficient. The other reason is locality of data references.
Stack data is almost garantueed to be in the L1 cache, because
those cachelines are often touched. SO STACK BASED DATA IS A
GOOD THING.
It might be comforting to know for the C++ advocates that their
code is at least smaller than the SMF (C) hack. Ofcourse in C
you can always use the C++ approach and code the this pointer
by hand and gain the same advantages (and disadvantages).
That having said, I hope that I'm allowed to use pointers to
structures in my C code for the cases I want more than one
instance of a datastructure! I'm sure I am, 'cause even
Kevin can't write plex86 code without avoiding these pointer
to structures C feature.
So the this pointer discussion is probably the only
invalid argument against using C++ because off the
mentioned reasons.
Let's stop arguing and start coding in C. C++ is basicly
a very advanced preprocessor, but nice code for smaller
projects can still be written effectively in C.
The nr of lines of the finished plex will be relatively
small, so it can be done in C without major headaches.
I think my question to Kevin about using dbopen() is lost in the
discussion noise. How about using it to replace the STL map?
Do you (or someone else) have other suggestions for C libraries,
I'm sure there are plenty...
Tom
