qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Steve Huston" <shus...@riverace.com>
Subject RE: Question on proper namespace for strError()
Date Mon, 04 Aug 2008 19:30:59 GMT
Hi Alan,

> -----Original Message-----
> From: Alan Conway [mailto:aconway@redhat.com] 
> Sent: Monday, August 04, 2008 2:53 PM
> To: qpid-dev@incubator.apache.org
> Cc: 'Andrew Stitcher'
> Subject: Re: Question on proper namespace for strError()
> 
> 
> On Mon, 2008-07-28 at 15:08 -0400, Steve Huston wrote:
> > Hi Andrew,
> > 
> > During our talk about how to approach Windows porting where
> > platform-specific issues arise, the general approach is to 
> reimplement
> > in the affected qpid/sys subdirectory. That has gone very well,
and
> > patches are forthcoming via JIRA.
> > 
> > There's one issue remaining and I'm not sure how you'd like 
> to handle
> > this. In qpid/Exception.{h cpp} there's a qpid::strError()
function,
> > often used with exceptions, to look up the message string 
> for an errno
> > value.
> > 
> > Of course, this is different on Windows. This would lend itself to
> > reimplementing the strError() function in the posix and windows
> > subdirectories, but this function is in the qpid namespace, not
> > qpid::sys. I see two ways to resolve this:
> > 
> > 1. Move the function to qpid::sys. I began down this path 
> and have the
> > broker and client building on Windows and Linux with it, 
> but the test
> > programs also refer to qpid::strError(). Are users 
> expecting to find a
> > qpid::strError()?
> > 
> > 2. Leave it in qpid, but implement it in qpid/sys/posix and
> > qpid/sys/windows. This doesn't disrupt existing code, but leaves
the
> > implementation in a "non standard" place.
> > 
> > What do you think the best way to proceed on this is?
> 
> How about implementing qpid::strError as a call to 
> qpid::sys::strError?

That could work also. As it stands now, subsequent to another email
exchange, it was moved to qpid::sys::strError because it's a sys-level
wrapper. It's going clean on trunk.

-Steve



Mime
View raw message