On Monday 07 December 2009 17:14:40 Alan Grimes wrote: > Yeah, my vote is for the shortest code whenever possible. This has a > number of advantages. However I also prefer STL wherever possible > because it won't be changing in QT5... :) Okay, the container-classes changed their api, slightly in Qt4, but (there's always a but ;)) with good reasons. The work needed to go to the new API is quite minimal. The classes are changed to be more compatible with java container classes, as well as STL ones. Believe me, changes in the container API are not our problem ;) And I believe, the API will be the same in Qt5, also. I have not heard of any objections against this API ;)
> That said, some of my conversions to STL were ill advised. =( Well, I think, this is because the STL container classes expose you more to the complexity of C++. The Qt API encourages you to use pointers, only when really necessary (many things can be expressed equally using references). This should result in more stable code. And it also encourages you to use the const keyword, whenever possible. This also helps reducing common mistakes, like doing stuff like "if ( myObj1 = myObj2 ). (This won't compile, when myObj1 is declared as const ;)) That's why I think, the Qt API helps to write better code. I saw a construct in the code, reading: "Cell **m_cell;" or something like that. WTF? ;) This is not C, it's C++. Such expressions should really be avoided and I can't think of any example, where there is no other way of expressing this. Okay, just my 2ct. bye then julian
signature.asc
Description: This is a digitally signed message part.
------------------------------------------------------------------------------ Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev
_______________________________________________ Ktechlab-devel mailing list Ktechlab-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ktechlab-devel
