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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
