[fdo-dev] Where to put improvements?
mateusz at loskot.net
Fri Dec 15 19:24:37 EST 2006
Robert Bray wrote:
> Let's start discussing them here on the list. I'd like to get the RFC
> process started for FDO early in the new year, so that will be the
> mechanism for formalizing them and getting them approved by the PSC.
OK, RFC will be good, as we've already discussed.
But the improvements I have currently in mind, are pretty small and
related to places caught fast in the code as potentially dangerous,
while I'm working on the PostGIS provider.
Second sort of improvements is related to improving source code
readability and maintainability, so I think these
should be specified in a separate RFC, as a kind of policies.
OK, back to the initial issue I have had in mind.
Currently, functions like
and other similar functions, copy-constructors and assignment
operators are not exceptions immune.
In case of exceptions, these functions leave state of the original
Here is very simple example of how the SetSQLStatement can be
improved to be fully exceptions immune function,
so an instance of FdoRdbmsSQLCommand is much safer too:
// Sets the SQL statement to be executed as a string.
void FdoRdbmsSQLCommand::SetSQLStatement(const wchar_t* value)
if (NULL != value)
// may throw
wchar_t* tmp = wcscpy(new wchar_t[wcslen(value)+1], value);
// should not throw
// assign new string safely
m_SqlString = tmp;
More information about the Fdo-internals