We are making a lot of memory model changes in order to get over some difficult issues. These issues start with axiscpp-149. They then expand to take in simple typees and complex types.
The gist of the problem is this -
Firstly, this appears to be a windows problem but might well affect all compilers - we just haven't tested.
Our libs are compiled with say VC71.
The customer compiles their stubs with say VC70.
When the customers stub comes to delete a value that's been created inside the engine e.g. a String then they can't because it's not on their heap.
So, we are implementing a new memory model so that either, the customer always gets a clone of the memory - in which case it's in their heap or the memory is created in their heap already.
You will see many changes to the model in the new week or so. We see this as a must fix and are doing it under the umbrella of 149 which has been outstanding for too long.
The issues below are part of the first fix to the String model. Fred was doing this yesterday and will get onto it immediately.
thanks,
John.
| "Chinthana C. Dinapala"
<[EMAIL PROTECTED]>
04/11/2005 07:27
|
|
Hi guys,
Today following tests are Client Compilation fails with this error.
E.g. XSD_NMTOKEN
[cc] XSD_NMTOKENPort.cpp
[cc] C:\obj\test\generated\cpp\XSD_NMTOKEN\XSD_NMTOKENPort.cpp(164) : error C2440: '=' : cannot convert from 'char ** ' to 'char *'
[cc] Types pointed to are unrelated; conversion requires reinterpret_cast, C-style cast or function-style cast
[cc] OptionalAttributeElement.cpp
[cc] SimpleComplexType.cpp
XSDElementNil
XSDTimeNil
XSD_ENTITIES
XSD_ENTITY
XSD_ID
XSD_IDREF
XSD_IDREF
XSD_IDREFS
XSD_IDREFS1
XSD_NCName
XSD_NMTOKEN
XSD_NMTOKEN1
XSD_NMTOKENS
XSD_NMTOKENS1
XSD_NOTATION
XSD_Name
XSD_QName
XSD_anyURI
XSD_anyURI2
XSD_anyURIfault
XSD_anyURInonUTF8
XSD_integer
XSD_language
XSD_negativeInteger
XSD_nonPositiveInteger
XSD_normalizedString
XSD_token
Thanks
Chinthana
