[xsd-users] RE: Access Violation when deleting objects
bruno.marotta at fortis.com
bruno.marotta at fortis.com
Tue Nov 13 07:28:46 EST 2007
Hi Boris,
thanks for the answers. About the memory I've found out. It is not linked to XSD at all. It is just a Microsoft thing where both the dll and executable should share the memory configuration.
About the string question as you may see here bellow the AssumedRecoveryLookup is a pure and simple string class. And it is only used on the asset class. So, why must it be a class and just a simple property from the Asset with type xml_schema::string? Isn't the transformation adding too much code for nothing? (if I go to cxx, the AssumedRecoveryLookup doesn't add any feature to the string class. What is its purpose then?)
(...)
class __declspec(dllexport) Asset (...)
// AssumedRecoveryLookup
//
typedef ::AssumedRecoveryLookup AssumedRecoveryLookup_type;
typedef ::xsd::cxx::tree::optional< AssumedRecoveryLookup_type > AssumedRecoveryLookup_optional;
typedef ::xsd::cxx::tree::traits< AssumedRecoveryLookup_type, char > AssumedRecoveryLookup_traits;
const AssumedRecoveryLookup_optional&
AssumedRecoveryLookup () const;
AssumedRecoveryLookup_optional&
AssumedRecoveryLookup ();
void
AssumedRecoveryLookup (const AssumedRecoveryLookup_type& x);
void
AssumedRecoveryLookup (const AssumedRecoveryLookup_optional& x);
void
AssumedRecoveryLookup (::std::auto_ptr< AssumedRecoveryLookup_type > p);
(...)
class __declspec(dllexport) AssumedRecoveryLookup: public ::xml_schema::string
{
public:
// Constructors.
//
AssumedRecoveryLookup ();
AssumedRecoveryLookup (const ::xml_schema::string&);
AssumedRecoveryLookup (const ::xercesc::DOMElement& e,
::xml_schema::flags f = 0,
::xml_schema::type* c = 0);
AssumedRecoveryLookup (const ::xercesc::DOMAttr& a,
::xml_schema::flags f = 0,
::xml_schema::type* c = 0);
AssumedRecoveryLookup (const ::std::string& s,
const ::xercesc::DOMElement* e,
::xml_schema::flags f = 0,
::xml_schema::type* c = 0);
AssumedRecoveryLookup (const AssumedRecoveryLookup& x,
::xml_schema::flags f = 0,
::xml_schema::type* c = 0);
virtual AssumedRecoveryLookup*
_clone (::xml_schema::flags f = 0,
::xml_schema::type* c = 0) const;
};
(...)
-----Original Message-----
From: Boris Kolpackov [mailto:boris at codesynthesis.com]
Sent: Tuesday, November 13, 2007 12:55 PM
To: Marotta Bruno
Cc: xsd-users at codesynthesis.com
Subject: Re: Access Violation when deleting objects
Hi Bruno,
In the future please send technical questions like these to the
xsd-users mailing list (which I've CC'ed) instead of to me directly.
This way a) other developers who may have experienced a similar
problem can provide you with a solution b) questions and answers
will be archived and available to others with similar problems.
bruno.marotta at fortis.com <bruno.marotta at fortis.com> writes:
> I am still playing with your XSD classes. I think that I don't have
> to tell that I found them great.
Thanks, I am glad you like it.
> Not quite so easy to use, but when you get to known it flows smoothly.
Is it difficult to use before you've read the Getting Started Guide[1] or
after?
[1] http://www.codesynthesis.com/projects/xsd/documentation/cxx/tree/guide/
> The thing is, now I am separting the interfaces on a dll, so I used
> the export option from the xsd generation. But, when some classes
> are freed, it throws an access violation. As these are hard to debug,
> I've starting decouping until I really isolated the problem. Basically
> I have one class like this:
>
> class __declspec(dllexport) ObligorID: public ::xml_schema::string
Do you really have __declspec(dllexport) there or is it some CPP macro
that changes from __declspec(dllexport) to __declspec(dllimport)?
> {
> public:
> // Constructors.
> //
> ObligorID ();
>
> ObligorID (const ::xml_schema::string&);
>
> ObligorID (const ::xercesc::DOMElement& e,
> ::xml_schema::flags f = 0,
> ::xml_schema::type* c = 0);
>
> ObligorID (const ::xercesc::DOMAttr& a,
> ::xml_schema::flags f = 0,
> ::xml_schema::type* c = 0);
>
> ObligorID (const ::std::string& s,
> const ::xercesc::DOMElement* e,
> ::xml_schema::flags f = 0,
> ::xml_schema::type* c = 0);
>
> ObligorID (const ObligorID& x,
> ::xml_schema::flags f = 0,
> ::xml_schema::type* c = 0);
>
> virtual ObligorID*
> _clone (::xml_schema::flags f = 0,
> ::xml_schema::type* c = 0) const;
> };
>
> Which is fairly simple. On the executable where I call the dll, if I
> do a simple:
>
> ObligorID* obl = new ObligorID("131 xxxxxxxxxxxxxwxxxx");
> delete obl;
>
> As the first entries of the main, I get an exception on the delete.
> Do you have any idea where does this came from?
That's very strange. The usual suspect would be the cross-DLL memory
allocation/deallocation but here you create and delete the object in
main() so this can't be it. Just to confirm, can you change the
generated object code type in both your application and DLL to use
the DLL runtime and see if there is any change?
You may also want to step into the "delete obl" statement in the
debugger and see what's going on and where it crashes. Or you can
send me a small example that reproduces this problem and I will
take a look.
> Also, I am wondering why on the getters and setters of the classes
> sometimes you can simply pass a string (for the dates, for instance)
> and sometimes you mas pass an instantiated object from a string. Example:
>
> asset.MaturityDate("2005-01-01"); // Nice way of doing it
> asset.AssumedRecoveryLookup(AssumedRecoveryLookup("N")); // Why can't I just pass the "N"?
C++ does not allow chains of implicit conversions. In other words, if
you have class A that has an (implicit) constructor from const char*
and class B that has an (implicit) constructor from A and you have a
function f() with argument of type B, then you cannot pass "foo" to
it because that would require a chain of conversions:
const char*-> A -> B
In the above example, MaturityDate() has an argument which can be
implicitly constructed from a string literal while AssumedRecoveryLookup()
does not. Can you tell me what the AssumedRecoveryLookup schema type
looks like?
Boris
= = = = = = = = = = = = = = = = = = = = = = = = =
Fortis disclaimer :
http://www.fortis.be/legal/disclaimer.htm
Privacy policy related to banking activities of Fortis:
http://www.fortis.be/legal/privacy_policy.htm
= = = = = = = = = = = = = = = = = = = = = = = = =
More information about the xsd-users
mailing list