Farid Zaripov wrote:
[...]
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.

Thanks!


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. :)

Difficult is not impossible :) If you think it's possible we
have a conformance problem. Otherwise, if you don't believe
it's possible, we're fine.


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

It's not a conforming program. The locale must stay around as
long as the last reference to the facet obtained from it. The
tests that fail to follow this rule should be changed.


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

Right, and that's allowed.

Martin

Reply via email to