ws-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache Wiki <wikidi...@apache.org>
Subject [Ws Wiki] Update of "Tuscany/TuscanyCpp/DesignNotes" by GeoffWinn
Date Wed, 28 Feb 2007 13:24:57 GMT
Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Ws Wiki" for change notification.

The following page has been changed by GeoffWinn:
http://wiki.apache.org/ws/Tuscany/TuscanyCpp/DesignNotes

------------------------------------------------------------------------------
+ #pragma section-numbers 1
+ 
  = Logging =
  
  Logging is not mentioned in the V2.01 specification, however, a rudimentary logging capability
is provided in the current implementation, using three classes.
@@ -100, +102 @@

  
  For MSVC 7.1 these should be appended to the list found in Configuration Properties ->
Linker -> Input -> Additional Dependencies
  
+ = Discriminated Types =
+ 
+ Prior to the changes introduced in revision 502599, in response to JIRA
+ TUSCANY-546, the C++ implementation made extensive use of C style macros,
+ particularly in Data``Object``Impl.cpp. This code had been motivated by the
+ requirement for SDO to process a variety of different data types (integer,
+ float, string etc) in very similar ways. Unfortunately, while macro code makes
+ it easy to clone behaviour by instantiating the macro for different datatypes,
+ it has several disdavantages. By far the most serious is the impossibility of
+ debugging code that has been generated by the macro preprocessor, closely
+ followed by the fact that most non-trivial macros are difficult to read and
+ understand. These twin problems lead onto the common result that macro
+ generated code is often inefficient.
+ 
+ TUSCANY-546 remedies these problems by introducing a new class, SDOValue,
+ defined in SDOValue.cpp and SDOValue.h. This class consists fundamentally of a
+ union of all the possible data types that SDO must accommmodate, together with
+ an enumerated type that identifies which particular data type is stored in
+ the current object. The union and enumeration are themselves defined in
+ Data``Type``Info.cpp and Data``Type``Info.h.
+ 
+ Not surprisingly, SDOValue provides constructors to initialise an SDOValue
+ object from any of the primitive data types. There are also retrieval methods
+ that will extract a primitive value from an SDOValue, converting as necessary
+ (and throwing an exception for those conversions that are impossible). For the
+ most part these methods are straightforward. The only slight complications
+ arise when dealing with primitives that are strings of characters. There are
+ three such data types -
+ 
+ String: This is a null terminated sequence of single byte characters. It
+ corresponds to the C notion of a string, and the C++ std::string class.
+ 
+ Wide``String: This is a null terminated sequence of double byte characters. In
+ C++ this might be represented by the std::wstring class, although in this
+ implementation it is represented in the C fashion, using a pointer to a null
+ terminated sequence of wchar_t elements.
+ 
+ Byte``Array: A sequence of bytes that is not terminated by a null character. An
+ associated length value is therefore required.
+ 
+ SDOValue objects represent such values with pointers to other objects or
+ allocations of memory, therefore, copy operators and destructors must allow for
+ the need to copy or delete the items that are at the far end of these
+ pointers.
+ 
+ From then on, the general strategy is straightforward. All methods that are
+ part of the SDO external interface must be preserved. However, as far as
+ possible, other methods that used to be replicated (by macro expansion) for
+ each different datatype, are replaced by a single method that works with
+ SDOValue objects. Where it is necessary to work with the actual primitive data
+ type explicitly, this is normally done via a switch statement. The external
+ methods that were previously generated by macro expansion are replaced by
+ explicit code that is little more than a veneer that converts between the
+ SDOValue that is used internally and the primitive data type that is required
+ by the public interface. Numerous examples of this appear in
+ Data``Object``Impl.cpp, the getBoolean and setBoolean methods being typical.
+ 
+ Code to convert between the various primitive data types is already available
+ in the Type``Impl class. However, this is not ideal since a) as coded it is
+ dependent on the Type``Impl class, even though that isn't strictly necessary and
+ therefore b) it tends to bloat the already large Type``Impl class. The SDOValue
+ code provides it's own conversion methods in the SDO``Data``Converter class. The
+ intention is to migrate all conversions in SDO to the methods in that class,
+ however, that transition is not yet complete.
+ 

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@ws.apache.org
For additional commands, e-mail: general-help@ws.apache.org


Mime
View raw message