stdcxx-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Farid Zaripov" <Farid_Zari...@epam.com>
Subject RE: STDCXX examples fails and reasons [MSVC]
Date Mon, 25 Jun 2007 16:28:13 GMT
> -----Original Message-----
> From: Martin Sebor [mailto:sebor@roguewave.com] 
> Sent: Friday, June 22, 2007 6:20 PM
> To: stdcxx-dev@incubator.apache.org
> Subject: Re: STDCXX examples fails and reasons [MSVC]
> 
> 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.

  Ok. I have created the issue STDCXX-459.

> >   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?

  It would be difficult. :)

 
> >   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?

  No :)

  Btw below is a part of the conforming program (taken from
time_get.cpp)?

-------------------
    const std::time_get<char, Iter> &tg =
        std::use_facet<std::time_get<char, Iter> >(std::locale ("C"));

    // Display time_base::dateorder value.
    std::cout << "time_base::dateorder == " << tg.date_order () <<
".\n";
-------------------

  This fragment fails on Dinkumware STL because of tg.date_order() uses
(internal)
pointer to the destroyed locale object.

Farid.

Mime
View raw message