This is the mail archive of the
mailing list for the libstdc++ project.
Re: RFA: Add libstdc++-v3 support for avr 4/7: fix locale_facets_nonio overloading on struct tm using template
- From: Jonathan Wakely <jwakely at redhat dot com>
- To: Joern Rennecke <joern dot rennecke at embecosm dot com>
- Cc: GCC Patches <gcc-patches at gcc dot gnu dot org>, Denis Chertykov <chertykov at gmail dot com>, Paolo Carlini <paolo dot carlini at oracle dot com>, Ulrich Drepper <drepper at gmail dot com>, Benjamin De Kosnik <bkoz at gnu dot org>, libstdc++ at gcc dot gnu dot org
- Date: Wed, 22 Oct 2014 16:09:29 +0100
- Subject: Re: RFA: Add libstdc++-v3 support for avr 4/7: fix locale_facets_nonio overloading on struct tm using template
- Authentication-results: sourceware.org; auth=none
- References: <CAMqJFCpAKiGDusCxCrh5=Co-=6TFUw91v-22BrRLCYgFexN=cw at mail dot gmail dot com> <20141021162918 dot GP3033 at redhat dot com> <CAMqJFCrA-FusqCrK0CNdetB48G+tOY8g3hkG59Kzpw2TgDTxwA at mail dot gmail dot com>
[CCing the libstdc++ list, all libstdc++ patches should go there as
well as gcc-patches]
On 21/10/14 17:47 +0100, Joern Rennecke wrote:
On 21 October 2014 17:29, Jonathan Wakely <email@example.com> wrote:
>> +typedef typeof (((tm*)0)->tm_sec) __tm_small_int;
I think this should probably use __typeof__ to work with
Ok, makes sense, and it's a straightforward change.
+#else /* For 100% mangling compatibility, use int directly. */
+#define __tm_small_int int
I'd prefer to always use a typedef, which can be a private member of
std::time_get, instead of defining a macro (even a macro using a
Is the typedef mangling compatible with the original "int" type?
Mangled names use the real type, not typedefs. These are three
declarations of the same function, with _Z1fi as the mangled name:
typedef int Int;
typedef int iiiiiiii;
So you can replace the __tm_small_int macro/typedef with a private
typedef inside time_get:
// [same comment as you had before ...]
typedef typeof (((tm*)0)->tm_sec) __tm_small_int;
typedef int __tm_small_int;
* @brief Time format ordering data.
* @ingroup locales
@@ -654,14 +663,16 @@ namespace std _GLIBCXX_VISIBILITY(defaul
ios_base::iostate& __err, tm* __tm) const;
// Extract numeric component of length __len.
+ template <typename _Member_t>
- _M_extract_num(iter_type __beg, iter_type __end, int& __member,
+ _M_extract_num(iter_type __beg, iter_type __end, _Member_t&
int __min, int __max, size_t __len,
ios_base& __io, ios_base::iostate& __err) const;
I think this function is exported from the library, so turning it into
a template would be an ABI change.
The avr needs both an int and and int8_t __member variant of M_extract_num.
So do template instantiations mangle differently from directly defined
Yes, template<class T> void f(T) instantiated for int has the mangled
name _Z1fIiEvT_ so it is an ABI change to change f(int) to f<int>(int).
In that case, what is the preferred solution? Duplicate the code (with all the
maintenance ugliness that entails)?
Would you have to duplicate it all?
Could you add an overload for int8_t that forwards to the int version?
_M_extract_num(iter_type __beg, iter_type __end, int8_t& __member,
int __min, int __max, size_t __len,
ios_base& __io, ios_base::iostate& __err) const
iter_type __ret = _M_extract_num(__beg, __end, __tmp, __min,
__max, __len, __io, __err);
if (__err == ios_base::goodbit)
__member = __tmp;
I think you wouldn't need to do any range checking on the value,
because _M_extract_num checks the max value anyway, so there's no risk
that __member will overflow when converted to int8_t.
Or convert the function definition into an uber-ugly macro that is invoked twice
to get what the template implementation denies us - metaprogramming with
That would be uber-ugly :-)
Define a templated function with a different name, and then define two
overloads as a wrapper?
Does that even work in the case __tm_small_int is a typedef for int?
No, that would be ambiguous (but you could guard the second overload
with #ifdef __AVR__ so it's only defined when it has a different
I think my preference would be the small forwarding function shown
above, would that work?