Return a string in COM methods.

In a typical com function which returns a string, people could make an error easily like the following one:

STDMETHODIMP MyClass::MyFunction(BSTR* pRet)
{
// This is how I return a string - is this incorrect?
std::string myString;
CComBSTR bstr (A2W (myString.c_str()));
*pRet = bstr;
return S_OK;
}

Issue with this is : while pRet points to the bstr , but bstr is defined inside the function scope, so when it goes out of the scope, the CComBSTR destructor will be called like this:

~CComBSTR() throw()
{
::SysFreeString(m_str);
}
which now makes pRet point to a dangling pointer.

An appropriate way is detach the m_str from the CComBSTR , so even when the destructor is called, the m_str won't be destroyed.

BSTR Detach() throw()
{
BSTR s = m_str;
m_str = NULL;
return s;
}

Forward declaration of a template class.

Forward declaration of a template class.

This issue confused me a little bit when I try to declare a template-based class as a friend class of another class.

The issue is like this:

<template class T>
Class A
{
Public:
Private:
}

Class B
{
Public:
Private:
     int m_b;
}

And Class A wants to access the private member m_b in Class B, the forward declaration of A will be like this:
template <class T>  class A

Exception Handling Model

Exception Handling Model /Ehs and /Eha

The exception handling model specifies the model of exception handler used by the computer.

Eha : The exception handler catches the asynchronous structured exceptions and tells the compiler to assume that extern C function do throw an exception.

Ehs: The exception handler doesn’t catch the asynchronous exceptions and tells the compiler to assume that extern C functions do throw an exception.

Ehc: It can be used either with the Eha or Ehs, but it assumes that extern C functions never throw an exception.

XmlDocument.Load and XmlDocument.LoadXml

I was playing around the xml tree view control which I found from the codeproject, but keeping getting "The data at the root level is invalid".

Later on, I find I am confused between XmlDocument.Load and XmlDocument.LoadXml, the former always load an xml file based on the file name, while the later will accept the actual xml document.

JST Robust issue

JTS union may *not* be commutative or associative in the strict sense. In other words, different ordering of the operands may produce slightly different results. This is an unavoidable result of using finite-precision arithmetic to compute operations which inherently require higher precision.

The difference should normally be *very* minor, however. The one time this is not the case is when the first operation produces a robustness error. In this case obviously the two results can be very different (e.g. an exception, versus an actual return value).

> Is this simply a bug that has been fixed?

Yes, this probably reflects an improvement that was made in the intersection calculation.

> Should a union of two valid Geometry's always yield a valid Geometry?

Yes, if the operation completes successfully, the result will always be a valid Geometry. Unfortunately, in the current implementation, sometimes overlay operations can also result in robustness errors. (This is something I'm hoping to fix in a future release).

I notice that your data seems to be fairly limited in precision. You might try using a fixed precision model - this can sometimes alleviate robustness problems.

Martin Davis, Senior Technical Architect
Vivid Solutions Inc. www.vividsolutions.com
Suite #1A-2328 Government Street Victoria, B.C. V8T 5G5
Phone: (250) 385 6040 - Local 308 Fax: (250) 385 6046