> I want to require that the output produced does not depend on the iterator
> used otherwise than stated in the proposition.

That would be fine with me. You should write up a defect report and
post it here.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

sebor@roguewave.com wrote:
>> I want to require that the output produced does not depend on the iterator
>> used otherwise than stated in the proposition.
>
> That would be fine with me. You should write up a defect report and
> post it here.
>

I feel that the defect report would be differ from my original posting
only in that magic entry "defect report" instead of "proposition" in the
subject line.  Should I repost with a different subject line or do
something more?

Chris

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

In article <d91g7f$13e$1@h1.uw.edu.pl>,
 kkz@duch.mimuw.edu.pl (Christopher Conrade Zseleghovski) wrote:

> sebor@roguewave.com wrote:
> >> I want to require that the output produced does not depend on the iterator
> >> used otherwise than stated in the proposition.
> >
> > That would be fine with me. You should write up a defect report and
> > post it here.
> >
>
> I feel that the defect report would be differ from my original posting
> only in that magic entry "defect report" instead of "proposition" in the
> subject line.  Should I repost with a different subject line or do
> something more?

I have entered the post dated Jun 7, 2005 with the subject "22.1.1.1.1
Proposition: Clarification of the interaction between a facet and an
iterator" as lwg issue 502.  It will not be publicly available until the
June '05 mailing is posted.

-Howard

Library Working Group Chair

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Append the following point to 22.1.1.1.1:

6. The implementation of a facet of Table 52 parametrized with an
InputIterator/OutputIterator should use that iterator only as character
source/sink respectively.
For a *_get facet, it means that the value received depends only on the
sequence of input characters and not on how they are accessed.
For a *_put facet, it means that the sequence of characters output depends
only on the value to be formatted and not of how the characters are stored.

Motivation:

This requirement seems obvious to me, it is the essence of code modularity.
I have complained to Mr. Plauger that the Dinkumware library does not
observe this principle but he objected that this behaviour is not covered in
the standard.

Christopher Yeleighton


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Well, this is going to be lengthy.  (- Attn. Moderator: If you consider it
to be too long, please forward it to Mr. Barbati instead of returning
because it contains the code snippet he asked for.  Thank you. -)

Pascal-style comments are here to help you understand the order in this
post.  You can think of them as of HTML tags.

(*ref quote="elaborate"*)
(*code*)
#define tcout wcout // or cout, depends whether your programme is
Unicode-based.  Microsoft has overlooked this.

#define tcerr wcerr

#define SPACE 32    // I include "unicode.h" here for symbolic names of
characters

#define PLAUGER_IS_RIGHT // tentatively

ios_base::iostate state = ios_base::goodbit;

time_t now(time(00));

tm atm;

if(!_localtime64_s(&atm, &now)) { // This is how VS 2005 wants me to use the
localtime function.  Isn't that funny?

/* this is nonportable ^ but the portable version has been deprecated */

TCHAR buffer[040];

static char OEM_cp_sz[] = "Polish";

locale OEM_loc(

#ifdef PLAUGER_IS_RIGHT

OEM_cp_sz

#else // my workaround

locale(locale(OEM_cp_sz), new time_put_byname<TCHAR,

LPTSTR>(OEM_cp_sz)),

new time_get_byname<TCHAR, LPTSTR>(OEM_cp_sz)

#endif

);

tcout.imbue(OEM_loc);

tcerr.imbue(OEM_loc);

cout << "Current locale: " << OEM_loc.name() << endl;

if(has_facet<time_put<TCHAR, LPTSTR> >(OEM_loc)) {

LPTSTR eob(use_facet<time_put<TCHAR, LPTSTR>

>(OEM_loc)

.put(buffer, tcout, SPACE, &atm, 'x'));

*eob = 00;

tcout << TEXT("Date in the buffer: ") << buffer << endl;

}

tcout << TEXT("Date in ostream: ");

use_facet<time_put<TCHAR> >(OEM_loc)

.put(time_put<TCHAR>::iter_type(tcout),

tcout, SPACE, &atm, 'x');

tcout << endl;

}

(*/code*)
(*output provider="Dinkumware"*)
Current locale: Polish_Poland.1250

Date in the buffer: 05/25/05

Date in ostream: 2005.04.05

(*/output*)

(*explanation*)

As you can see, the text representations of the dates differ.  However, the
only difference in the way of producing them is in the iterator.

Here is what Mr. Plauger has to say about this case:

(*quote author="pjp@plauger.com"*)

> Rereading the C++ standard, it is unacceptable that time_put<wchar_t,

> I> facets instantiated from the same locale behave differently for

> different iterators (modulo the differences in the iterator itself).

> It violates the

> encapsulation principle. This means that the sequence of commands

>

> *(output iterator) = some wide character

>

> produced by put method must be the same and the only difference should

> be encoded in the action of operator *.

>

> I do not blame you for returning some facet from the locale but that

> the facet does not behave as it should, accordingly, it is unsupported

> by your library. In this case, you should rather throw an exception

> (although I really see no reason for not supporting arbitrary facets).

You're in the area of undefined behavior here. Perhaps you don't like how we
defined it, but it's within our right to do what we did. If you find it
unacceptable, don't use the feature.

P.J. Plauger

(*/quote*)

As you can see, what is obvious for me and you is not obvious at all for Mr.
Plauger - and he is an important and influential developer.

(*/ref*)
(*ref quote="PS"*)
Mr. Barbati's answer does not show up on my news server.  I know quotes of
it from Mr. Kanze' reply.
(*/ref*)

Chris

Uzytkownik "Alberto Barbati" <AlbertoBarbati@libero.it> napisal w wiadomosci
news:3ippe.138899$IN.2400861@twister2.libero.it...
Krzysztof    elechowski wrote:
> Append the following point to 22.1.1.1.1:
>
> 6. The implementation of a facet of Table 52 parametrized with an
> InputIterator/OutputIterator should use that iterator only as character
> source/sink respectively.
> For a *_get facet, it means that the value received depends only on the
> sequence of input characters and not on how they are accessed.
> For a *_put facet, it means that the sequence of characters output depends
> only on the value to be formatted and not of how the characters are
> stored.
>
> Motivation:
>
> This requirement seems obvious to me, it is the essence of code
> modularity.
> I have complained to Mr. Plauger that the Dinkumware library does not
> observe this principle but he objected that this behaviour is not covered
> in
> the standard.
>

This requirement is so obvious to me either, that, frankly, I don't
understand why do you think such a clarification is needed. I don't
understand how a conforming implementation could violate such
requirement. Could you please elaborate?

Alberto

PS: about the need to access the stream's locale in addition to the
iterator, I have already answered in another thread. (Short answer: it
can't be avoided.)

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

FWIW, unless I'm missing something in your example I don't think this
is undefined behavior. Tables 51 and 52 list the specializations of
facets required to be provided by an implementation. This list includes
specializations on all valid Input and Output Iterators. 22.2.5, p1
specifies that all such specializations follow the requirements
outlined in that section. The behavior may be implementation-defined
for named locales (which does allow the behavior you're pointing out),
but from a QoI standpoint, producing anything other than what you get
with strftime("%x") in this case is, IMO, a bug.

I modified your program a bit and tested it with our implementation on
Solaris and with GNU libstdc++ on Linux. It produces the expected
output, i.e.,

Expected: "1900-01-00"
Got:      "1900-01-00"
wcsftime: "1900-01-00"


#include <clocale>
#include <ctime>
#include <cwchar>
#include <locale>
#include <iostream>

int main ()
{
    const std::locale pl =
        std::locale (std::locale ("pl_PL"),
                     new std::time_put_byname<wchar_t,
wchar_t*>("pl_PL"));

    std::wcout.imbue (pl);

    wchar_t buf [64];
    const std::tm t = { };

    *std::use_facet<std::time_put<wchar_t, wchar_t*> >(pl)
        .put (buf, std::wcout, std::wcout.fill (), &t, L'x') = L'\0';

    std::wcout << "Expected: \"" << buf
               << "\"\nGot:      \"";

    std::use_facet<std::time_put<wchar_t> >(pl)
        .put (std::ostreambuf_iterator<wchar_t>(std::wcout),
              std::wcout, std::wcout.fill (), &t, L'x');

    std::wcout << "\"\nwcsftime: \"";

    std::setlocale (LC_ALL, "pl_PL");
    std::wcsftime (buf, sizeof buf / sizeof *buf, L"%x", &t);
    std::wcout << buf << "\"\n";
}

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Uzytkownik <sebor@roguewave.com> napisal w wiadomosci
news:1118432129.408688.202530@g43g2000cwa.googlegroups.com...
> FWIW, unless I'm missing something in your example I don't think this
> is undefined behavior. Tables 51 and 52 list the specializations of
> facets required to be provided by an implementation. This list includes
> specializations on all valid Input and Output Iterators. 22.2.5, p1
> specifies that all such specializations follow the requirements
> outlined in that section. The behavior may be implementation-defined
> for named locales (which does allow the behavior you're pointing out),
> but from a QoI standpoint, producing anything other than what you get
> with strftime("%x") in this case is, IMO, a bug.

I am aware of the fact that the behaviour is implementation-defined for
named locales.  However, I want to introduce some additional requirement: I
want to require that the output produced does not depend on the iterator
used otherwise than stated in the proposition.  It is insane.

Chris

>    *std::use_facet<std::time_put<wchar_t, wchar_t*> >(pl)
>        .put (buf, std::wcout, std::wcout.fill (), &t, L'x') = L'\0';

Thanks for the hint about using wcout.fill() instead of SPACE.  It seems
much more appropriate.



---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]