Hi,

the destructor of wstring_convert shall delete the codecvt which was
given to the ctor (or constructed by default argument).

22.3.3.2.2 Paragraph 3 says:
[...]is performed by an object of class Codecvt<Elem, char,
std::mbstate_t>, which meets the requirements of the standard
code-conversion facet std::codecvt<Elem, char, std::mbstate_t>.[...]

The section about codecvt isn't really clear about the destructors
visability (and in derived classes), but because codecvt's destructor is
declared as protected and is protected in all other facets/examples too,
I think thats a requirement.

In fact, (user-defined) facets which meets this requirement (they do,
all codecvt implementations I've seen uses protected destructors) can
not be used together with wstring_convert - which means that the whole
wstring_convert idea will be moot.


This issue was first discussed here:
http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#721

Have I something overlooked or is it still a defect?


Regards,

Daniel Vogelbacher

--
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use
mailto:std-c++@netlab.cs.rpi.edu<std-c%2B%2B@netlab.cs.rpi.edu>
]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

On 1 Feb, 04:22, Daniel Vogelbacher <dan...@vogelbacher.name> wrote:
> Hi,
>
> the destructor of wstring_convert shall delete the codecvt which was
> given to the ctor (or constructed by default argument).
>
> 22.3.3.2.2 Paragraph 3 says:
> [...]is performed by an object of class Codecvt<Elem, char,
> std::mbstate_t>, which meets the requirements of the standard
> code-conversion facet std::codecvt<Elem, char, std::mbstate_t>.[...]
>
> The section about codecvt isn't really clear about the destructors
> visability (and in derived classes), but because codecvt's destructor is
> declared as protected and is protected in all other facets/examples too,
> I think thats a requirement.
>
> In fact, (user-defined) facets which meets this requirement (they do,
> all codecvt implementations I've seen uses protected destructors) can
> not be used together with wstring_convert - which means that the whole
> wstring_convert idea will be moot.
>
> This issue was first discussed here:http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#721
>
> Have I something overlooked or is it still a defect?
>
> Regards,
>
> Daniel Vogelbacher
>

Sorry that this is not an answer, but more a follow up... I was having
the same thoughts on this.
It seemed nice at first to have wstring_convert, especially in
combination with the required specializations for codecvt as defined
in N3000 (Table 76 (22.3.1.1.1))

But if it turns out that those facets cannot be used and I have to
define my own, it's not going to be of much help. There's the
protected destructor issue as mentioned above and issue 382 jumps to
my mind again ( http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#382
) ; how do I implement the do_in and the do_out then?

Regards,
Walter

--
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@netlab.cs.rpi.edu]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Walter van der Hee wrote:
> On 1 Feb, 04:22, Daniel Vogelbacher <dan...@vogelbacher.name> wrote:
>>
>> In fact, (user-defined) facets which meets this requirement (they
>> do,
>> all codecvt implementations I've seen uses protected destructors)
>> can
>> not be used together with wstring_convert - which means that the
>> whole
>> wstring_convert idea will be moot.
>>
>> This issue was first discussed
>> here:http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#721
>>
>> Have I something overlooked or is it still a defect?
>>
>> Regards,
>>
>> Daniel Vogelbacher
>>
>
> Sorry that this is not an answer, but more a follow up... I was
> having
> the same thoughts on this.
> It seemed nice at first to have wstring_convert, especially in
> combination with the required specializations for codecvt as defined
> in N3000 (Table 76 (22.3.1.1.1))
>
> But if it turns out that those facets cannot be used and I have to
> define my own, it's not going to be of much help.

You don't have to do much in your own facet, just derive from the
standard facet and provide a public destructor. The issue 721 is about
that - why should we have to?


Bo Persson



--
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use
mailto:std-c++@netlab.cs.rpi.edu<std-c%2B%2B@netlab.cs.rpi.edu>
]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]