Review Request 112039: Add a CPU registers view.

Vlas Puhov vlas.puhov at mail.ru
Sat Aug 24 07:38:30 UTC 2013


> > 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:

> 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??

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

> 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.

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.


Thanks
-- 
Vlas Puhov


More information about the KDevelop-devel mailing list