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(®isters) 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