Re: Question on proper namespace for strError()

[Alan Conway <ac...@redhat.com>]

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 leaves strError in qpid namespace but puts the platform-specific
implementation in the qpid::sys namespace without putting anything in a
surprising place.

RE: Question on proper namespace for strError()

[Alan Conway <ac...@redhat.com>]

On Mon, 2008-08-04 at 15:30 -0400, Steve Huston wrote:
> Hi Alan,
[snip]
> > 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.

Works for me. 

Cheers,
Alan.

RE: Question on proper namespace for strError()

[Steve Huston <sh...@riverace.com>]

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