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 acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk