On Jun 29, 1:20 am, Immortal Nephi <Immortal_Ne...@satx.rr.com> wrote:
> On Jun 28, 1:39 pm, James Kanze <james.ka...@gmail.com> wrote:
> > 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 class
> > > > > contain 10 member functions. Put 10 member functions into member
> > > > > function pointer array.
> > > > > One member function uses switch to call 10 member functions. Can
> > > > > 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.
> If you want to use small stand-alone object without using
> class, you can only create one object at this time. The
> flexibaility is less on C style language.
> Class is ideal to show multiple objects. You can use class to
> define more than one object. Think of class CPU { public: }.
> Create an array of four CPU objects. You can expect four CPU
> objects to run at the same time like four emulators are
> running.
If you have an array, you have multiple objects. All we're
talking about is the type of the object.
Of course, with agents, you do introduce an additional level of
indirection; the array contains pointers to objects, and not the
objects themselves, since we need pointers for polymorphism to
work. Which is the additional typing I referred to. It pays
off in added flexibility, however---and to top it off, it's
usually a bit faster.
> > > 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.
> I am sorry that you misunderstand. I do not talk about
> emulator. I talk about indirect memory and direct memory.
> C++ Compiler translates class and *this pointer* into native
> x86 machine language. You can take a look at disassembler.
> You will see *lea instruction* and *mov instruction*.
> Global variables and global functions use *direct memory* so
> you can see *mov instruction*. Member variables and member
> functions inside class use *this pointer*. The class needs to
> read *this pointer* before it can access member variable or
> member function.
With any decent compiler, the this pointer will be in memory,
and on most machines, a based access will be at least as fast,
if not faster, than a direct access. At least on my Sun Sparc,
accessing member variables is faster than accessing global
variables. (The Intel architecture is a bit hindered here by a
lack of registers, so most compilers will only put the this
pointer into a register when optimization is turned on. On the
other hand, no one is going to be using the Intel architecture
if performance is an issue.)
> *lea instruction* is the *this pointer* and *mov instruction*
> is the member variable or member function.
> I recall that class is 25% performance slower than C style
> language because it has extra instruction to be fetched like
> lea instruction.
You recall wrong. If two programs do the same thing, and
performance is an issue, C++ always wins (compared to C, at
least), because of better encapsulation.
--
James Kanze (GABI Software) email:
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34