Rewrote the "adding more data" section to deal with missing destructor
problem. git-svn-id: file:///srv/svn/repos/haiku/trunk/current@1771 a95241bf-73f2-0310-859d-f6bbb57e9c96
This commit is contained in:
@@ -76,6 +76,7 @@ should be binary compatible in no time!
|
|||||||
class BFoo {
|
class BFoo {
|
||||||
public:
|
public:
|
||||||
BFoo();
|
BFoo();
|
||||||
|
~BFoo();
|
||||||
void SomeFunc();
|
void SomeFunc();
|
||||||
private:
|
private:
|
||||||
int32 fBar;
|
int32 fBar;
|
||||||
@@ -117,7 +118,7 @@ should be binary compatible in no time!
|
|||||||
<code>int32</code>s worth of data: <code>fNewData1</code> through
|
<code>int32</code>s worth of data: <code>fNewData1</code> through
|
||||||
<code>fNewData4</code>. The original implementation of BFoo has two extra
|
<code>fNewData4</code>. The original implementation of BFoo has two extra
|
||||||
<code>int32</code>s which we can use, but that leaves us two <code>int32</code>s
|
<code>int32</code>s which we can use, but that leaves us two <code>int32</code>s
|
||||||
short. What to do? The easiest thing to do is create a data structure to hold
|
short. What to do? The easiest thing is to create a data structure to hold
|
||||||
your new data and convert one of the <code>fUnused</code> items into a pointer
|
your new data and convert one of the <code>fUnused</code> items into a pointer
|
||||||
to that structure:
|
to that structure:
|
||||||
<code>
|
<code>
|
||||||
@@ -155,8 +156,12 @@ should be binary compatible in no time!
|
|||||||
}
|
}
|
||||||
</pre>
|
</pre>
|
||||||
</code>
|
</code>
|
||||||
Voila! More data without making the class bigger. Notice the added
|
Voila! More data without making the class bigger. Make sure you're cleaning up
|
||||||
destructor; make sure you're cleaning up your new (dynamically allocated) data.
|
your new (dynamically allocated) data in the destructor. <b>NOTE:</b> this trick
|
||||||
|
will only work if the class originally had a destructor! Adding a destructor
|
||||||
|
after the fact won't work for existing apps (since they won't call it), leading
|
||||||
|
to memory leaks. Fortunately, there are very few instances in the BeAPI where a
|
||||||
|
class doesn't have a destructor already declared.
|
||||||
</li>
|
</li>
|
||||||
</ol>
|
</ol>
|
||||||
|
|
||||||
|
|||||||
Reference in New Issue
Block a user