Rogue Wave banner
Previous fileTop of DocumentContentsIndexNext file

2.4 Reference Semantics

While designing DBTools.h++, we were faced with deciding whether classes in the library should obey value semantics or reference semantics. Generally speaking, classes that obey value semantics are easier to understand, while those that obey reference semantics are more efficient. Database programming raises other considerations, as in the following code:

Here value semantics would be impossible to implement sensibly. The RWDBTable instances refer to a physical object that resides outside the program domain, the parts table in the database. It makes sense that when we drop the parts2 table on //3, the parts1 object created on //1 is also affected. Here is a more subtle example:

Value semantics dictate that the fetches on //4 and //5 each retrieve the first row of the "parts" table; reference semantics dictate that //4 fetches the first row while //5 fetches the second. In this example, there is a sensible interpretation of value semantics, though we guess that most database programmers would find that interpretation counter-intuitive. In any case, we believe that the most confusing situation of all would be to freely mix value and reference semantics, so we use reference semantics throughout DBTools.h++.


NOTE: With rare exceptions, DBTools.h++ classes obey reference semantics. Copy constructors and assignment operators result in interface objects that share a common implementation.

The exceptions to this design are the concrete classes RWDBStatus and RWDBValue, and the concrete datatypes RWDBDateTime, RWDBDuration, RWDecimalPortable, RWDBBlob, and RWCString. The last two use the copy on write technique as a compromise between efficiency and easy-to-understand semantics. The others are simply copied bitwise.


Previous fileTop of DocumentContentsIndexNext file

©Copyright 2000, Rogue Wave Software, Inc.
Contact Rogue Wave about documentation or support issues.