On 9/15/12 1:51 PM, Stefan Teleman wrote:
On Sat, Sep 15, 2012 at 9:01 AM, Liviu Nicoara <nikko...@hates.ms> wrote:
That is funny. What compiler are you using? What does the following test
case return for you?
It's the Intel compiler with the patched stdcxx for the wrong case
and GCC 4.7.1 + GNU libstdc++ for the correct case.
GCC + GNU libstdc++ are correct.
The patched facet does not call the protected do_*() virtual functions
from their public counterparts, as it is required to do by the
Standard. Instead, it returns the data mebers directly (the data
members were initialized in the constructor). That is the patch you
proposed, which is indeed much better performing than using a mutex
lock. Unfortunately, in doing so, overriding the virtual functions in
a derived facet type becomes pointless.
Ahh, I see now. You are indeed right, that patch is defective. I was under the
impression that we were discussing the (later) attachment
stdcxx-1056-timings.tgz which contains a perfectly forwarding implementation of
the facet public grouping method. The timings I attached there were the ones I
thought we were discussing all along.
Now, to clear the confusion I created: the timing numbers I posted in the
attachment stdcxx-1056-timings.tgz to STDCXX-1066 (09/11/2012) showed that a
perfectly forwarding, no caching public interface (exemplified by a changed
grouping) performs better than the current implementation. It was that test case
that I hoped you could time, perhaps on SPARC, in both MT and ST builds. The
t.cpp program is for MT, s.cpp for ST.
Please let me know if this clarifies things. I apologize for the
misunderstanding.
Liviu
