Re: Write Function Pointer Array
On Jun 28, 6:55 pm, Immortal Nephi <Immortal_Ne...@satx.rr.com> wrote:
On Jun 28, 2:23 am, James Kanze <james.ka...@gmail.com> wrote:
On Jun 28, 3:07 am, Immortal Nephi <Immortal_Ne...@satx.rr.com> wrote:
I would like to design an object using class. How can this clas=
s
contain 10 member functions. Put 10 member functions into member
function pointer array.
One member function uses switch to call 10 member functions. Ca=
n
switch be replaced to member function pointer array?
Yes, but why? What controls the choice? On the whole member
function pointers are awkward and complex; a number of otherwise
competent C++ programmers seem to have problems with them,
because of the syntax. I use them from time to time, but my
experience has been that as the class evolves, they end up being
replaced by "agents", small stand-alone objects which call the
function (and possibly contain additional data).
Thank you very much for your assistance. Yes, you do answer
my question right. Can you please describe what you mean
"agents"?
Small stand-alone objects, which (probably) call the funnction
actually desired. The advantage of this, as opposed to pointers
to member functions, is that the objects can contain additional
data. Thus, you can add cases where two keys call the same
function, but with different arguments.
Agents will generally all derive from a common abstract base
class, with a single function which performs the desired
operation. The array will be of pointers to this base class.
It requires a little bit more typing to set up, but it's a lot
more flexible, and for most C++ programmers that I've
encountered, a lot more readable.
Member Function Pointer Array is ideal for CPU's Opcode
emulator like dispatch() or fetch().
Anyway, supposing the calling function receives an int:
void
MyClass::dispatch( int key )
{
static void (MyClass::* const table[])() =
{
&MyClass::f1,
&MyClass::f2,
// ...
} ;
assert( key >= 0 && key < size( table ) ) ;
(this->*table[ key ])() ;
}
dispatch() function as above makes sense. Many C programmers
tell that C++ class is slower. They want to stick global
variable and global functions for performance reason.
According to my research, global functions have *direct*
memory. The member functions have *indirect* memory. It
means that member function must receive memory address from
*this pointer* before member function can be called.
C++ programmers wants to convert global variable and global
function into C++ class. They say that C++ class is about 25%
slower performance than C style source code because extra
instruction needs to access indirection.
It is the time to start designing CPU's opcode emulator on C++
class. They expect faster Intel / AMD CPUs or other machines
with the speed of 4 GHz and beyond.
I'm not really sure I understand. An emulator, today, doesn't
emulate single instructions; it emulates blocks of code. And
its speed is determined by the size of the blocks, and how
effectively it can deduce the actual semantics of the block, and
convert that into native code.
Desinging class is a lot of easier to reduce debugging time
and less prone error.
Do you agree to continue using C++ style language today?
I'm in favor of using the most effective tool to do the job.
For large projects, C++ is certainly one of the leading
candidates---another possibility might include Ada 95. I can't
imagine any situation where one would select C, however.
[...]
James Kanze (GABI Software)
I am curious what do you call "GABI Software"?
It's the name I trade under. (I'm a freelance professional,
providing services on a contract basis.)
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34