PR 13631 Problems in messages
Jonathan Wakely
jwakely@redhat.com
Tue Dec 2 10:55:00 GMT 2014
On 01/12/14 22:42 +0100, François Dumont wrote:
>Hi
>
> Here is another proposal that consider all your remarks except
>one. I finally prefer to go with std::vector of pointers. Dynamically
>allocating Catalog_info allow to avoid numerous copies of locale when
>we find this pointer from the catalog info.
>
>
>>+ result_type
>>>+ _M_get(catalog_id __c) const
>>>+ {
>>>+ __gnu_cxx::__scoped_lock lock(_M_mutex);
>>>+
>>>+ const catalog_info* __entry =
>>>+ lower_bound(_M_map, _M_map + _M_nb_entry, __c, _Comp());
>>>+ if (__entry != _M_map + _M_nb_entry && __entry->_M_id == __c)
>>>+ return result_type(__entry->_M_domain, __entry->_M_locale);
>>>+ return result_type(0, locale());
>>
>>I assume the second return was just for testing, it should be removed.
>
>I don't get this one. I still need to return something when I can't
>find the catalog so the 2 return statements.
I thought I remembered seeing two returns at the same level of
indentation, but obviously they are not! Maybe I was looking it it in
gmail's attachment viewer which eats leading whitespace. Ignore that
comment, sorry.
>>Index: config/locale/gnu/messages_members.h
>>>===================================================================
>>>--- config/locale/gnu/messages_members.h (revision 218027)
>>>+++ config/locale/gnu/messages_members.h (working copy)
>>>@@ -83,22 +83,6 @@
>>> _S_destroy_c_locale(_M_c_locale_messages); }
>>>
>>>- template<typename _CharT>
>>>- typename messages<_CharT>::catalog -
>>>messages<_CharT>::do_open(const basic_string<char>& __s, -
>>>const locale&) const
>>>- { - // No error checking is done, assume the catalog
>>>exists and can
>>>- // be used.
>>>- textdomain(__s.c_str());
>>>- return 0;
>>>- }
>>>-
>>>- template<typename _CharT>
>>>- void - messages<_CharT>::do_close(catalog) const - { }
>>>-
>>> // messages_byname
>>> template<typename _CharT>
>>> messages_byname<_CharT>::messages_byname(const char* __s,
>>>size_t __refs)
>>
>>Unless I'm misreading this patch, you've removed the definitions of
>>messages<_CharT>::do_open() and messages<_CharT>::do_close() for the
>>primary template. They would stil be needed if users instantiate e.g.
>>messages<char16_t> or messages<signed char>.
>
>Yes but do you confirm that it is already the same problem with do_get ?
Yes, I'm just wondering why make the situation worse than it already
is. Does leaving the default definitions cause a problem?
If some user has got code that uses messages<signed char> and they
provide a definition for messages<signed char>::do_get() their code
will break if do_open and do_close disappear. (Realistically I doubt
anyone is doing that though, it may not even work.)
>In my opinion we could provide template implementations of all those
>methods relying on codecvt<_CharT, char, mbstate_t>, even for do_get.
>But in this case some implementation details will be exposed in the
>header files and additional symbols will have to be exported I think.
>
>In fact I have already started doing something like that but then
>start facing issue accessing nl_langinfo_l. Shall I go further and
>provide a patch doing this ?
IMHO no.
>+ catalog
>+ _M_add(const string& __domain, locale __l)
>+ {
>+ __gnu_cxx::__scoped_lock lock(_M_mutex);
>+
>+ // The counter is not likely to roll unless catalogs keep on being
>+ // opened/closed which is consider as an application mistake for the
>+ // moment.
>+ if (_M_catalog_counter == numeric_limits<catalog>::max())
>+ return -1;
>+
>+ _M_infos.push_back(new Catalog_info(_M_catalog_counter++, __domain, __l));
>+ return _M_infos.back()->_M_id;
This is not exception safe. You can use auto_ptr to fix it:
std::auto_ptr<Catalog_info> info(new Catalog_info(_M_catalog_counter++,
__domain, __l));
_M_infos.push_back(info.get());
return info.release()->_M_id;
More information about the Libstdc++
mailing list