Boost logo

Boost :

Subject: Re: [boost] [Boost-users] [typeindex v3.0] Peer review begins Mon 21st ends Wed 30th
From: Antony Polukhin (antoshkka_at_[hidden])
Date: 2014-04-25 06:15:52

2014-04-25 12:44 GMT+04:00 Dominique Devienne <ddevienne_at_[hidden]>:

> On Fri, Apr 25, 2014 at 10:22 AM, Antony Polukhin <antoshkka_at_[hidden]>
> wrote:
> > 2014-04-25 11:25 GMT+04:00 Dominique Devienne <ddevienne_at_[hidden]>:
> >> Or the name of a template full specialization?
> You didn't reply to that one. Would we get/see the angled brackets and
> commas for example? What about nested template arguments? Nested
> brackets?

Oh yes, of course. For example `type_id<f<std::binary_function<int, int,
int> > >().pretty_name()` will output:
f<std::binary_function<int, int, int> >
f is defined as `template <class T> class f{};`

So all the templates will be visible.

>> But what bothered me a little was the note about the fact that
> >> pretty_name() was not consistent across platforms/compilers.
> >
> > Unfortunately this definitely won't be fixed in nearest releases.
> OK, I understand. But please note that Boost has a history of
> smoothing out compiler/platform differences, and that it's actually a
> large part of its success IMHO. So this is a bit disappointing to me,
> but of course it is by no means a -1 vote. I'm +1 on boost::typeindex,
> definitely.
> > Making a generic solution will consume too much time for each compiler
> and
> > anyway there's no portable way of doing so for anonymous namespaces.
> As noted above, I view Boost as *the* portable way to such facilities,
> which of course must be implemented specifically for different
> compilers (although I suspect the patterns are similar across
> compilers, so an 80% solution that works on the major compilers would
> be good enough for me).
> > There is a an ability to make your own type_indexes, so this could be
> fixed
> > by user manually.
> But that defeats the "purpose" IMHO. Sure, we build on far fewer
> compilers and OSs than Boost at large, so it might be easier to do for
> us than for you, but the 80% solution I mention above could at least
> be included at some point, no?

Sounds reasonable. I'll add that feature someday and document the compilers
that provide portable type names.

Best regards,
Antony Polukhin

Boost list run by bdawes at, gregod at, cpdaniel at, john at