< Talk:Policies← Talk:Policies/Library Code Policy D Pointers It should be mentioned, that when using d-pointers, the copy constructor and assignment operator either have to be implemented correctly or they have to be forbidden. The implicit copy constructor and assignment operator copy just the value of the pointer. The pointer to the former Private data will get lost (memory leakage). I hate to point out the obvious, but this is a wiki and you can add this information yourself as easily as comment on it. =) --Aseigo 00:49, 30 January 2007 (CET) Yay, but only, if it weren't locked or you have the necessary permissions. :-P OTOH, I think, it's good, that I put my first thoughts here. The const'ness of the d-pointer prevents the default assignment of being used. --nikolaus 12:47, 30 January 2007 (CET) Const References "Each object parameter that is not a basic type (int, float, bool, enum, or pointers) should be passed by reference-to-const. This is faster, because it is not required to do a copy of the object." How is it faster to copy a reference to a QString than to copy a pointer to a QString::Data (which is the entire non-static contents of a QString)? Someone please explain. Argonel 01:03, 11 August 2007 (CEST) A pointer is a basic type, so this rule does not apply. Think of a reference as nothing else but a pointer with different syntax. API wise passing a const QString& is probably much better than working with a pointer to QString::Data... --Dhaumann 10:39, 11 August 2007 (CEST) We can't work with the QString::Data pointer at all, its private to the QString object, but it is the only data element inside a QString. So whether you pass a const QString& or a QString, you're passing the exact same sort of object. There is no speed increase, in fact I'd expect it to be slower because you have to dereference the const& every time you want to work with it. Argonel 18:10, 11 August 2007 (CEST) Includes Can you please add that Qt includes should look like: include <QtCore/QObject> And that includes from KDE should like like: include <KDE/KFile> Rationale: it desambiguates the includes and makes it easier to port to other build systems. [View source↑] [History↑] Sorting order: last modified first newest threads first oldest threads firstContentsThread titleRepliesLast modified Tool for normalization of SIGNAL/SLOT names020:43, 28 September 2011 Include order: private headers020:39, 28 September 2011 Tool for normalization of SIGNAL/SLOT namesHistory SummarizeThere is a tool included in Qt to either find SIGNAL/SLOT names which are not normalized, or to even automatically correct them. However, you have to compile it on your own: https://qt.gitorious.org/qt/qt/trees/v4.7.3/util/normalize MoreHistory View source Link toMghansen256 20:43, 28 September 2011 Include order: private headersHistory SummarizeYou do not have permission to edit this page, for the following reason: The action you have requested is limited to users in one of the groups: Users, Administrators, trusted, KDEDevelopers. You can view and copy the source of this page. Subject: krazy2 wants a specific order of header/private header and moc file/private header. It would be nice to have some information on this here. Mghansen256 Return to Thread:Talk:Policies/Library Code Policy/Include order: private headers. Retrieved from "https://techbase.kde.org/index.php?title=Talk:Policies/Library_Code_Policy&oldid=43586#Tool_for_normalization_of_SIGNAL.2FSLOT_names_43" This page was last edited on 25 July 2009, at 10:11. Content is available under Creative Commons License SA 4.0 unless otherwise noted.