incubator-stdcxx-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Sebor <se...@roguewave.com>
Subject Re: STDCXX examples fails and reasons [MSVC]
Date Fri, 22 Jun 2007 15:19:35 GMT
Farid Zaripov wrote:
>> -----Original Message-----
>> From: Martin Sebor [mailto:sebor@roguewave.com] 
>> Sent: Thursday, June 21, 2007 8:56 PM
>> To: stdcxx-dev@incubator.apache.org
>> Subject: Re: STDCXX examples fails and reasons [MSVC]
> 
> [...]
> 
>> time_get looks like a bug (or lack of  functionality) in our library
> 
>   time_get::date_order() returns time_get::do_date_order() which always
> returns dateorder () == no_order (loc/_time_get.h; line 137).

Right. We ran out of time when implementing the facet. The
standard doesn't require us to do any better so there hasn't
been a lot of pressure to get back to it and finish the job,
but that doesn't mean we should never do it. From a QoI point
of view we definitely should.

> 
>   Also I observed that time_get::~time_get() should be protected
> (22.2.5.1),
> but in our library the time_get::~time_get() is not declared/defined.

Yes, it is declared as protected in the standard to prevent
standalone facet objects from being constructed. I'm not
sure that's a detectable requirement. Violations of the
requirement are detectable by non-conforming programs,
but I can't think of a way how conformance to it could
be detected -- can you?

> 
>   The same situation with ~time_get_byname(), ~time_put(),
> ~time_put_byname().

Our implementation lets users construct facet objects and use
(at least some) them directly rather than going through the
use_facet interface, which seems like a reasonable thing to
do. Can you think of a reason not to keep this extension?

Martin

Mime
View raw message