summaryrefslogtreecommitdiffstats
path: root/doc/shclass.doc
diff options
context:
space:
mode:
Diffstat (limited to 'doc/shclass.doc')
-rw-r--r--doc/shclass.doc42
1 files changed, 21 insertions, 21 deletions
diff --git a/doc/shclass.doc b/doc/shclass.doc
index c612c603a..192369c74 100644
--- a/doc/shclass.doc
+++ b/doc/shclass.doc
@@ -79,7 +79,7 @@ the reference count.
Object assignment (with operator=()) for implicitly and explicitly
shared objects is implemented using shallow copies. A deep copy can be
-made by calling a copy() function or by using \l QDeepCopy.
+made by calling a copy() function or by using \l TQDeepCopy.
The benefit of sharing is that a program does not need to duplicate
data unnecessarily, which results in lower memory use and less copying
@@ -92,17 +92,17 @@ that objects share common data. Implicit sharing means that the
sharing mechanism takes place behind the scenes and the programmer
does not need to worry about it.
-\section1 A QByteArray Example
+\section1 A TQByteArray Example
-QByteArray is an example of a shared class that uses explicit sharing.
+TQByteArray is an example of a shared class that uses explicit sharing.
Example:
\code
//Line a= b= c=
- QByteArray a(3),b(2) // 1: {?,?,?} {?,?}
+ TQByteArray a(3),b(2) // 1: {?,?,?} {?,?}
b[0] = 12; b[1] = 34; // 2: {?,?,?} {12,34}
a = b; // 3: {12,34} {12,34}
a[1] = 56; // 4: {12,56} {12,56}
- QByteArray c = a; // 5: {12,56} {12,56} {12,56}
+ TQByteArray c = a; // 5: {12,56} {12,56} {12,56}
a.detach(); // 6: {12,56} {12,56} {12,56}
a[1] = 78; // 7: {12,78} {12,56} {12,56}
b = a.copy(); // 8: {12,78} {12,78} {12,56}
@@ -138,9 +138,9 @@ refer to the same data.
Implicit sharing optimizes memory use and copying of data without
this side effect. So why didn't we implement implicit sharing for all
shared classes? The answer is that a class that allows direct access
-to its internal data (for efficiency reasons), like QByteArray, cannot
+to its internal data (for efficiency reasons), like TQByteArray, cannot
be implicitly shared, because it can be changed without letting
-QByteArray know.
+TQByteArray know.
An implicitly shared class has total control of its internal data. In
any member functions that modify its data, it automatically detaches
@@ -164,37 +164,37 @@ Code fragment:
}
\endcode
-This is clearly not possible for QByteArray, because the programmer
+This is clearly not possible for TQByteArray, because the programmer
can do the following:
\code
- QByteArray array( 10 );
+ TQByteArray array( 10 );
array.fill( 'a' );
array[0] = 'f'; // will modify array
array.data()[1] = 'i'; // will modify array
\endcode
-If we monitor changes in a QByteArray, the QByteArray class would
+If we monitor changes in a TQByteArray, the TQByteArray class would
become unacceptably slow.
\section1 Explicitly Shared Classes
-All classes that are instances of the QMemArray template class are
+All classes that are instances of the TQMemArray template class are
explicitly shared:
\list
-\i \l QBitArray
+\i \l TQBitArray
\i \l QPointArray
-\i \l QByteArray
-\i Any other instantiation of \link QMemArray QMemArray\<type\>\endlink
+\i \l TQByteArray
+\i Any other instantiation of \link TQMemArray TQMemArray\<type\>\endlink
\endlist
These classes have a detach() function that can be called if you want
your object to get a private copy of the shared data. They also have a
copy() function that returns a deep copy with a reference count of 1.
-The same is true for \l TQImage, which does not inherit QMemArray. \l
+The same is true for \l TQImage, which does not inherit TQMemArray. \l
QMovie is also explicitly shared, but it does not support detach() or
copy().
@@ -202,7 +202,7 @@ copy().
The TQt classes that are implicitly shared are:
\list
-\i \l QBitmap
+\i \l TQBitmap
\i \l QBrush
\i \l QCursor
\i \l QFont
@@ -215,7 +215,7 @@ The TQt classes that are implicitly shared are:
\i \l QPicture
\i \l QPixmap
\i \l QRegion
-\i \l QRegExp
+\i \l TQRegExp
\i \l TQString
\i \l TQStringList
\i \l TQValueList
@@ -249,11 +249,11 @@ also happens if anything is \link ::bitBlt() bitBlt()\endlink'ed into
\warning Do not copy an implicitly shared container (TQMap,
TQValueVector, etc.) while you are iterating over it.
-\section1 QCString: implicit or explicit?
+\section1 TQCString: implicit or explicit?
-\l QCString uses a mixture of implicit and explicit sharing. Functions
-inherited from QByteArray, such as data(), employ explicit sharing, while
-those only in QCString detach automatically. Thus, QCString is rather an
+\l TQCString uses a mixture of implicit and explicit sharing. Functions
+inherited from TQByteArray, such as data(), employ explicit sharing, while
+those only in TQCString detach automatically. Thus, TQCString is rather an
"experts only" class, provided mainly to ease porting from TQt 1.x to TQt 2.0.
We recommend that you use \l TQString, a purely implicitly shared class.