We are back to models again 
. In Qt you may find a lot of flexibilities for Model-View programming. Especially due to proxies to do filtering, sorting or even rearranging data (see Jongling Qt models) to be organized in any way that is good for you. You can have one data source model which you then split in “flows” of data with chains of proxy models which have ends at views. For example friend of mine found that it is very effective to have one single model for all data loaded which then goes in 3-4 chains of about 15 proxy models in totals. Why so much? – Every proxy is as much simple operation as possible, for example: filter, ungroup, transpose, etc. Each simple operation much easier to implement, debug and prove effectiveness. But by joining them in chain you can make any complicated operations. You have to track complexity that you get at the end of chain – i.e. sorting proxy will add O(n*log(n)), but if you make filtering before sorting, then it goes faster.
But you may encounter one area which is totally uncovered – there is no way of joining of models into one composition proxy model. So I would like to present some “Gem” for Qt model-view programmers: RowsJoinerProxy class. It does very simple thing: join all top level rows from first source model, second, etc. It does not affect children, so all hierarchies of source models are kept. For root columns it uses qMax(columCount() of roots of source models). Rows inserts, rows removals, data changes of source models are recognized and mapped. Column operations are not supported at the moment, so I may update it later. Inserting/Removing source model from proxy makes model reset, though it can be improved later to do just rows removal.
Stack vs Heap, Pimpl, performance
This post is mostly about C++ but because it involves practices often used with Qt programming too, I tagged it with Qt. Also should be interesting for C++ gurus
So, you know that Qt uses Pimpl (Private Implementation or Opaque pointer) which is very effective mechanism to keep binary compatibility between Qt versions. I use it very often too, but mostly not because of binary compatibility needs, but because of possibility of hiding internals and implementations especialities into cpp files.
And there is something even more important, such practice allows to avoid including 3-rd party headers from your headers – your API – you know, it can often happen that you need some “utility” api, but because of including the header it leads to bring bunch of unexpected includes coming from this “utility”. Even worse, these 3-rd party headers that you probably can not even control, bring unexpected defines, pragmas etc that can makes you puzzled for hours to understand why?, how? and in which order? it conflicts with your coding.
Using d pointer (Private Implementation) allows really avoid including these unneeded headers, but recently in huge project it makes me to think about performance issues. Read More »