Talk:Policies/Library Code Policy - Revision history

Tampakrap: Be more explicit in the includes

2009-07-25T10:11:58Z

Be more explicit in the includes

Argonel at 16:10, 11 August 2007

2007-08-11T16:10:48Z

Dhaumann at 08:39, 11 August 2007

2007-08-11T08:39:21Z

Argonel at 23:03, 10 August 2007

2007-08-10T23:03:57Z

Nikolaus: /* D Pointers */

2007-01-30T11:47:10Z

‎D Pointers

Aseigo at 23:49, 29 January 2007

2007-01-29T23:49:37Z

Nikolaus: /* D Pointers */

2007-01-29T20:05:16Z

‎D Pointers

Nikolaus at 19:59, 29 January 2007

2007-01-29T19:59:13Z

New page

== 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). By declaring the d pointer as const, the assignment is actually no problem, but it would be cleaner to declare the operator as private.

← Older revision		Revision as of 10:11, 25 July 2009
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)		: 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.

← Older revision		Revision as of 16:10, 11 August 2007
Line 14:		Line 14:

	:: 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... --[[User:Dhaumann\|Dhaumann]] 10:39, 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... --[[User:Dhaumann\|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. [[User:Argonel\|Argonel]] 18:10, 11 August 2007 (CEST)

← Older revision		Revision as of 08:39, 11 August 2007
Line 12:		Line 12:

	: 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. [[User:Argonel\|Argonel]] 01:03, 11 August 2007 (CEST)		: 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. [[User:Argonel\|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... --[[User:Dhaumann\|Dhaumann]] 10:39, 11 August 2007 (CEST)

← Older revision		Revision as of 23:03, 10 August 2007
Line 6:		Line 6:
	::Yay, but only, if it weren't locked or you have the necessary permissions. :-P		::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. --[[User:Nikolaus\|nikolaus]] 12:47, 30 January 2007 (CET)		::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. --[[User:Nikolaus\|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. [[User:Argonel\|Argonel]] 01:03, 11 August 2007 (CEST)

← Older revision		Revision as of 11:47, 30 January 2007
Line 3:		Line 3:

	: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. =) --[[User:Aseigo\|Aseigo]] 00:49, 30 January 2007 (CET)		: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. =) --[[User:Aseigo\|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. --[[User:Nikolaus\|nikolaus]] 12:47, 30 January 2007 (CET)

← Older revision		Revision as of 23:49, 29 January 2007
Line 1:		Line 1:
	== D Pointers ==		== 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).		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. =) --[[User:Aseigo\|Aseigo]] 00:49, 30 January 2007 (CET)

← Older revision		Revision as of 20:05, 29 January 2007
Line 1:		Line 1:
	== D Pointers ==		== 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)~~. By declaring the d pointer as const, the assignment is actually no problem, but it would be cleaner to declare the operator as private~~.	+	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).