[fdo-dev] Pre-conditions and unsafe constuctions

Traian Stanev traian.stanev at autodesk.com
Thu Dec 7 11:32:06 EST 2006

Hi Mateusz.

I think you're overthinking it. Use whatever cast will do the job



-----Original Message-----
From: Mateusz Loskot [mailto:mateusz at loskot.net] 
Sent: Thursday, December 07, 2006 10:54 AM
To: dev at fdo.osgeo.org
Subject: Re: [fdo-dev] Pre-conditions and unsafe constuctions


Here is another construction I'd like to get some explanation about.
In function FdoRdbmsMySqlConnection::NewSchemaManager(), there is
following construction:

FdoSmPhMySqlMgrP physMgr =

According to my understanding of the SmartCast<T>() implemen, it is
acceptable to return NULL from this call.
Next, FdoSmPhMgrP (FdoPtr-based type) is initialized with NULL.

Again, FdoPtr<T>::operator-> will throw "encrypted" exception not
explaining the real problem: Type of FdpoSmPhMgr is not castable to
FdoSmPhMySqlMgr type, what in turn means a real design problem occured.

Why SmartCast<T>() function, if present anyway, does not check for NULL
and throw domain-related error like "Types are unrelated and can not be
downcasted" or similar?

Otherwise, I can't see the real benefits of SmartCast<T>() and even it
makes code error prone, because it allows chain-calls of operator->()
without having real control on pointers validation.

I'm just curious about rationale of these constructions and I wonder if
I am allowed to not to use SmartCast and DownCast functions in PostGIS
provider but use dynamic_cast and throw some FDO exception if types are
unrelated so not castable.

Am I allowed?

Mateusz Loskot

To unsubscribe, e-mail: dev-unsubscribe at fdo.osgeo.org For additional
commands, e-mail: dev-help at fdo.osgeo.org

More information about the Fdo-internals mailing list