Review Request 112039: Add a CPU registers view.

[Milian Wolff]

On Saturday 24 August 2013 11:38:30 Vlas Puhov wrote:
> > > On Aug. 16, 2013, 11:22 a.m., Milian Wolff wrote:
> > > >     remove these two constructors, use
> > > >     
> > > >     Register foo = { foo, value };
> > > >     
> > > >     To achieve what you want.
> > > 
> > > I don't know, IMO:
> > > doSomething(Register (name, value));
> > > is more readable and consumes less space than
> > > Register r = {name, value};
> > > doSomething( r );
> > 
> > fair enough. /me needs to enable C++11 for KDevelop, then we wouldn't have
> > that discussion :]
> > 
> > doSomething({name, value});
> 
> Ok then...
> 
> But afterwards you wrote that I should adhere to c++03:

Yes, my bad. I meant: Keep the ctors, we cannot use C++11 (yet).

> > Feel free to continue with the for-loops
> > for now, until we finally enable c++11.
> 
> So, should I use c++11 features or not??

No, not yet.

> And again I don't understand what's wrong with structure's constructor?

Nothing, I just thought it was not required.

> > That being said, if you explain some more what you want to do (i.e. given
> > A
> > do B to reach state C) then we can think about a better API here.
> 
> The plan is following: when registers are changed we notify a user about it,
> and let him choose what registers he wants to see(if any). Then he queries
> needed.

User being the implementor of the interface, right?

> 1. Registers changed.
> 2. We emit registersInGroupChanged(group) signal.
> 3. User queries registers for groups that he wants to see  by
> registersFromGroup(group, format) function.
> 3.1. Then registersFromGroupInternally(group) is called to prepare needed
> RegistersGroup(Fill in register's names and set needed flags). This
> procedure is architecture specific.
> 3.2. Afterwards updateValuesForRegisters(&registers) is called to fill in
> values for prepared register's group(This procedure is common for all
> architectures).
> 4. Ready RegistersGroup returned to the user.

I'll have to think about this when I have more time, hopefully in the upcoming 
days. But so far I think it could already be simplified by having something 
like this which is overridden:

virtual Registers registersFromGroup(group, format) const;

Base class:
just return the common stuff

Actual implementor:
first call base class, then add specific stuff.

That sounds much simpler and also reduces stuff from the API.

Cheers

-- 
Milian Wolff
mail at milianw.de
http://milianw.de