Difference between revisions of "Talk:Policies/Library Code Policy"

Latest revision as of 11:11, 25 July 2009

[edit] 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)

[edit] 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)

[edit] 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.

@@ Line 16: / Line 16: @@
 : 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. [[User:Argonel|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.