[Bug libstdc++/51823] [DR 198] [DR 2204] reverse iterator returns uninitialized values
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51823 --- Comment #16 from Dave Abrahams dave at boostpro dot com 2012-12-14 16:34:31 UTC --- Normative text vs. non-normative note == no contest, IMO. But I guess it doesn't hurt to have the bug open if it doesn't mean any changes to the library.
[Bug c++/55581] Too-eager instantiation
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55581
--- Comment #1 from Dave Abrahams dave at boostpro dot com 2012-12-04
19:30:40 UTC ---
Actually, here's a simpler test case:
template long N
struct mooch
{
moochN-1 operator-();
};
template
struct mooch0
{
int x;
mooch0* operator-();
};
mooch10 a; // compiles with depth 1
decltype(a.operator-()) y; // compiles with depth 1
decltype(a-x) z; // BOOM
[Bug c++/55581] New: Too-eager instantiation
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55581
Bug #: 55581
Summary: Too-eager instantiation
Classification: Unclassified
Product: gcc
Version: 4.7.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: d...@boostpro.com
IMO this program should compile with -ftemplate-depth=1, as it does on Clang.
[Sorry for the inline code; technical difficulties prevent me from adding an
attachment before I reboot my machine]
template long N
struct mooch
{
struct arrow
{
moochN-1 operator-();
};
arrow operator-();
};
template
struct mooch0
{
int x;
mooch0* operator-();
};
mooch1 a; // compiles with -ftemplate-depth 1
decltype(a.operator-()) y; // compiles with -ftemplate-depth 1
decltype(a-x) z; // requires -ftemplate-depth=2 on g++ but not
on clang++
[Bug c++/55206] New: GCC Reports Ambiguity; clang and comeau disagree
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55206 Bug #: 55206 Summary: GCC Reports Ambiguity; clang and comeau disagree Classification: Unclassified Product: gcc Version: 4.7.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: d...@boostpro.com I apologize for not doing the hunt to figure out what the standard says on this one, but since GCC is the outlier I'm reporting it here. The error is: g++ -I ~/src/boost/svn/release -Wall -Wextra -pedantic -Wno-long-long -Wno-unused-parameter -Wno-unused -Wno-parentheses -D_GLIBCXX_DEBUG -g -O0 shared.cpp -o shared In file included from /Users/dave/src/boost/svn/release/boost/make_shared.hpp:15:0, from shared.cpp:24: /Users/dave/src/boost/svn/release/boost/smart_ptr/make_shared.hpp: In instantiation of 'boost::shared_ptrT boost::make_shared(const A1) [with T = json_storejson_string; A1 = boost::rvjson_string]': shared.cpp:261:65: required from 'static json_value::stored_type json_value::make_storage(T, boost::false_type, boost::false_type) [with T = json_string; json_value::stored_type = boost::shared_ptrjson_base; boost::false_type = boost::integral_constantbool, false]' shared.cpp:176:9: required from 'json_value::json_value(T) [with T = json_string]' shared.cpp:300:41: required from here /Users/dave/src/boost/svn/release/boost/smart_ptr/make_shared.hpp:660:5: error: call of overloaded 'json_string(const boost::rvjson_string)' is ambiguous /Users/dave/src/boost/svn/release/boost/smart_ptr/make_shared.hpp:660:5: note: candidates are: shared.cpp:65:5: note: json_string::json_string(const json_string) shared.cpp:61:5: note: json_string::json_string(json_string::rep_t) shared.cpp:145:5: error: initializing argument 1 of 'json_storeT::json_store(T) [with T = json_string]' make: *** [shared] Error 1 Compilation exited abnormally with code 2 at Sun Nov 4 08:45:44
[Bug c++/55206] GCC Reports Ambiguity; clang and comeau disagree
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55206 --- Comment #2 from Dave Abrahams dave at boostpro dot com 2012-11-04 16:47:37 UTC --- I hate bugzilla for always tempting me to think I can add attachments when first submitting a bug, and then refusing the attachment because it's too big. Voilà https://raw.github.com/gist/4012559/b670d1e44ccd1fa1da65f1efd7e09b6b0a471b4a/bug.cpp
[Bug c++/55206] GCC Reports Ambiguity; clang and comeau disagree
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55206 --- Comment #3 from Dave Abrahams dave at boostpro dot com 2012-11-04 16:48:39 UTC --- PS my apologies again for the size. Just no time to reduce it now.
[Bug libstdc++/51823] [DR 198] reverse iterator returns uninitialized values
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51823 Dave Abrahams dave at boostpro dot com changed: What|Removed |Added CC||dave at boostpro dot com --- Comment #13 from Dave Abrahams dave at boostpro dot com 2012-10-30 23:48:36 UTC --- I think this bug is invalid, because the iterator being wrapped doesn't model ForwardIterator due to I found 24.2.5 [forward.iterators]/6, where it says: If a and b are both dereferenceable, then a == b if and only if *a and *b are bound to the same object.
[Bug c++/54706] New: -fsyntax-only suppresses a compilation error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54706
Bug #: 54706
Summary: -fsyntax-only suppresses a compilation error
Classification: Unclassified
Product: gcc
Version: 4.7.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: d...@boostpro.com
Compile the following with -std=c++11 both with and without -fsyntax-only and
note the difference:
templateclass...Fs struct pair;
templateclass F1, class...Fs
struct pairF1, Fs... : F1, Fs...
{
typedef pair type;
};
templateclass...Fs
typename pairFs...::type make(Fs...x)
{ return pairFs...(x...); }
struct X {}; struct Y{};
auto a = make(X(),Y());
[Bug c++/54706] -fsyntax-only suppresses a compilation error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54706 --- Comment #3 from Dave Abrahams dave at boostpro dot com 2012-09-25 19:55:31 UTC --- (In reply to comment #1) As already discussed in another PR, with -fsyntax-only no template instantiation occurs. Can be that? Certainly that explains it. In any case, let's add Jason in CC about the instantiation issue, quite a few people are not so happy about it. Maybe a good occasion to clarify that (very old, AFAIK) choice... Or change it, or provide another option. Clang's -fsyntax-only does instantiate, BTW.
[Bug c++/51501] decltype over-agressive SFINAE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51501 --- Comment #6 from Dave Abrahams dave at boostpro dot com 2012-08-18 23:18:21 UTC --- Jason, are you submitting (or is there already) an issue for this?
[Bug c++/52869] New: this not being allowed in noexcept clauses
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52869
Bug #: 52869
Summary: this not being allowed in noexcept clauses
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: d...@boostpro.com
Given the following, GCC says: error: invalid use of 'this' at top level
However, according to [expr.prim.general]/3 'this'
should be valid in the exception-specification as it comes after the
member function's optional cv-qualifier-seq.
#define RETURNS(...) noexcept(noexcept(__VA_ARGS__)) - decltype(__VA_ARGS__)
{ return (__VA_ARGS__); }
struct mul_ {
int operator()() const { return 1; }
template typename A
A operator()(A const a) const noexcept(A(std::move(a))) { return a; }
template typename A, typename B, typename... C
auto operator()(A const a, B const b, C const ... c) const
RETURNS((*this)(a * b, c...))
};
[Bug c++/52875] New: ADL failure + ICE in decltype
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52875 Bug #: 52875 Summary: ADL failure + ICE in decltype Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: d...@boostpro.com Created attachment 27095 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27095 reproducer I get: y.cpp: In substitution of 'templateclass T decltype (swap(x.a, y.a)) swap(T, T) [with T = A]': y.cpp:11:17: required by substitution of 'templateclass T decltype (swap(x.a, y.a)) swap(T, T) [with T = B]' y.cpp:20:14: required from here y.cpp:11:17: error: 'swap' was not declared in this scope y.cpp:11:17: note: suggested alternative: y.cpp:11:17: note: 'swap' y.cpp: In substitution of 'templateclass T decltype (swap(x.a, y.a)) swap(T, T) [with T = A]': y.cpp:11:17: required from here y.cpp:11:17: error: 'swap' was not declared in this scope y.cpp:11:17: note: suggested alternative: y.cpp:11:17: note: 'swap' ' Internal compiler error: Error reporting routines re-entered. Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions.
[Bug c++/52844] New: ICE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52844
Bug #: 52844
Summary: ICE
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: d...@boostpro.com
Created attachment 27076
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27076
Preprocessed source that triggers the bug
x.cpp: In substitution of 'templateclass F, class ... T decltype
(apply_tuple_(f, t, typename range_clong unsigned int, 0ul, sizeof (T
...)::type())) apply_tuple(F, const std::tuple_Elements ...) [with F = int
(*)(int, int); T = {int, int}]':
x.cpp:99:47: required from here
x.cpp:93:6: internal compiler error: in unify_one_argument, at cp/pt.c:15203
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
[Bug c++/52844] ICE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52844 --- Comment #1 from Dave Abrahams dave at boostpro dot com 2012-04-03 15:06:08 UTC --- I think the problem is simple: missing initial type argument to vector_c in: template typename F, typename Tuple , std::size_t ...Is auto apply_tuple(F f, Tuple const t, vector_cIs...)
[Bug libstdc++/51617] [C++0x] async(f) isn't.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51617 --- Comment #4 from Dave Abrahams dave at boostpro dot com 2011-12-19 10:58:46 UTC --- (In reply to comment #2) Yes, this was an intentional choice (as I described in message c++std-lib-30840) to ensure the system doesn't get killed by a fork bomb, e.g. writing a parallel sort algorithm using async which launches a new thread for every partition. I tried it, it wasn't pretty :) Hey, cool; I tried it too. I mean, when I discovered async wasn't async. :-) At some point I will use getloadavg() or equivalent functionality to check the system load and decide whether to launch a new thread or not, until then the safer choice is to require a user to explicitly request it (then it's the user's fault if they fork bomb their machine!) Yeah, but in the meantime you could also just limit async() threads to hardware_concurrency() using the technique shown in my attachment. It wouldn't necessarily guarantee good performance but it would be enough to prevent async from fork bombing while still allowing some semi-intelligent amount of parallelism.
[Bug libstdc++/51618] synchronous futures are slow
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51618 --- Comment #2 from Dave Abrahams dave at boostpro dot com 2011-12-19 12:11:33 UTC --- on Mon Dec 19 2011, redi at gcc dot gnu.org gcc-bugzilla-AT-gcc.gnu.org wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51618 --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org 2011-12-19 11:51:52 UTC --- Could you expand on what you mean by no attached synchronization? There's not much to say. Attached is probably superfluous. If a global future visible to all threads stores a deferred function then it still needs synchronization to ensure only one thread can invoke the deferred function and that other threads will wait for it to complete. I'm confused. IIUC even shared_futures aren't supposed to be accessed concurrently from multiple threads. Why would multiple threads be accessing a single plain future? std::async is not meant to be the fastest or most flexible solution, it's meant to be a simple way to exploit a limited amount of concurrency, without breaking the Kona compromise. Better solutions are suitable for TR2. I know it's not supposed to be the fastest, but it seems as though it can be optimized. If a trivial parallel mergesort using async can run 3x faster than it does now, that's a huge win for users: it means they can put off trying complex and/or dangerous alternatives.
[Bug libstdc++/51618] synchronous futures are slow
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51618 --- Comment #4 from Dave Abrahams dave at boostpro dot com 2011-12-19 13:24:16 UTC --- Not a problem; thanks for looking.
[Bug c++/51617] New: [C++0x] async(f) isn't.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51617 Bug #: 51617 Summary: [C++0x] async(f) isn't. Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: d...@boostpro.com Created attachment 26132 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26132 demonstration I am finding I have to explicitly pass a launch policy to get async to run anything in a thread. For example, when I time the attached with -DFORCE_PARALLEL I get /tmp/tst 81.54s user 0.23s system 628% cpu 13.001 total and without it I get: /tmp/tst 41.29s user 0.05s system 99% cpu 41.343 total See also bug 49204
[Bug c++/51617] [C++0x] async(f) isn't.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51617 --- Comment #1 from Dave Abrahams dave at boostpro dot com 2011-12-19 05:11:20 UTC --- I should add this (non-normative, but still) note from [futures.async]: [ Note: If this policy is specified together with other policies, such as when using a policy value of launch::async | launch::deferred, implementations should defer invocation or the selection of the policy when no more concurrency can be effectively exploited. — end note ]
[Bug libstdc++/51618] New: synchronous futures are slow
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51618 Bug #: 51618 Summary: synchronous futures are slow Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: d...@boostpro.com Created attachment 26133 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26133 demo The attached program demonstrates; if you compile with -DNO_SYNCHRONOUS_FUTURE it will run much faster. I don't know if this should be considered a performance bug or not, but it seems to me that in principle it should be possible to make synchronous futures much faster than that; they could type-erase an object with no attached synchronization, right?
[Bug c++/51553] New: brace initialization and conversion operators
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51553
Bug #: 51553
Summary: brace initialization and conversion operators
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: d...@boostpro.com
Please consider this test case:
- schnipp
struct X
{
X();
};
struct Y
{
operator X() const;
};
struct Z
{
explicit operator X() const;
};
X a = { Y() }; // #1. error: could not convert '{Y()}' from 'brace-enclosed
initializer list' to 'X'
X aa = Y(); // #1a. OK
X b{ Y() }; // #2. error: no matching function for call to
'X::X(brace-enclosed initializer list)'
X bb(Y()); // #2a. OK
X c = { Z() }; // #3 error: could not convert '{Z()}' from 'brace-enclosed
initializer list' to 'X'
X cc = Z(); // #3a. error: conversion from 'Z' to non-scalar type 'X'
requested
X d{ Z() }; // #4 error: no matching function for call to
'X::X(brace-enclosed initializer list)'
X dd( Z() );// OK
- schnapp
I can't find anything in the standard that justifies a difference between the
brace- and braceless-initialization cases. Even in case #3, the difference in
error message leads me to think the code may be failing for the wrong reasons.
[Bug c++/51561] New: Compilation segfault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51561 Bug #: 51561 Summary: Compilation segfault Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: d...@boostpro.com Tried to compile this with -std=c++11
[Bug c++/51561] Compilation segfault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51561 --- Comment #1 from Dave Abrahams dave at boostpro dot com 2011-12-15 00:53:24 UTC --- Created attachment 26097 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26097 reproducer
[Bug c++/51561] Compilation segfault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51561 --- Comment #2 from Dave Abrahams dave at boostpro dot com 2011-12-15 00:58:37 UTC --- Close this please! So sorry; I was totally misinterpreting what I saw. There's no compiler crash.
[Bug c++/51561] Compilation segfault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51561 Dave Abrahams dave at boostpro dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #3 from Dave Abrahams dave at boostpro dot com 2011-12-15 00:59:19 UTC --- Hey look; I can close it myself!
[Bug c++/51530] New: internal compiler error: in unify, at cp/pt.c:16854
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51530 Bug #: 51530 Summary: internal compiler error: in unify, at cp/pt.c:16854 Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: d...@boostpro.com Please compile the enclosed with -std=c++11
[Bug c++/51530] internal compiler error: in unify, at cp/pt.c:16854
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51530 --- Comment #1 from Dave Abrahams dave at boostpro dot com 2011-12-13 17:46:22 UTC --- Created attachment 26072 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26072 reproducer
[Bug c++/51501] decltype over-agressive SFINAE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51501 --- Comment #3 from Dave Abrahams dave at boostpro dot com 2011-12-11 10:32:25 UTC --- (In reply to comment #2) Could this be related to Bug 45873? Not if your explanation in http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45873#c2 is correct, I think. This is a straightforward pack expansion with no change in the number of arguments.
[Bug c++/48051] sorry, unimplemented: mangling overload
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48051 --- Comment #1 from Dave Abrahams dave at boostpro dot com 2011-12-10 19:19:02 UTC --- Created attachment 26044 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26044 Another test case Sorry, it's a bit long. Hopefully fixing the others handles this one too.
[Bug c++/47335] [C++0x] sorry, unimplemented: mangling overload
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47335 Dave Abrahams dave at boostpro dot com changed: What|Removed |Added CC||dave at boostpro dot com --- Comment #3 from Dave Abrahams dave at boostpro dot com 2011-12-10 19:20:24 UTC --- I believe this should be a duplicate of bug 48051, not bug 49044... as that one is closed solving just the ICE problem.
[Bug c++/51501] New: decltype over-agressive SFINAE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51501 Bug #: 51501 Summary: decltype over-agressive SFINAE Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: d...@boostpro.com Please see attached, which fails to compile. If you compile with -DWORKAROUND you can prove to yourself that it ought to compile.
[Bug c++/51501] decltype over-agressive SFINAE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51501 --- Comment #1 from Dave Abrahams dave at boostpro dot com 2011-12-10 21:06:14 UTC --- Created attachment 26045 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26045 test case compile with -std=c++11 to see the failure. Additionally add -DWORKAROUND to demonstrate why it ought to work.
[Bug libstdc++/51452] has_nothrow_.*constructor bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51452 Dave Abrahams dave at boostpro dot com changed: What|Removed |Added CC||dave at boostpro dot com --- Comment #10 from Dave Abrahams dave at boostpro dot com 2011-12-09 18:11:41 UTC --- (In reply to comment #9) Ah good, let's resolve as duplicate then. Thanks Daniel. *** This bug has been marked as a duplicate of bug 51295 *** But wait! The example I gave was not a test case! The point was that it shows a defect in traits that detect nothrow constructibility. This bug should be re-opened.
[Bug c++/51489] New: constexpr not working consistently
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51489
Bug #: 51489
Summary: constexpr not working consistently
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: d...@boostpro.com
I think this is a bug, and the program should compile.
struct array
{
constexpr array() :x(0) {}
constexpr int const* begin() { return x; }
int x;
};
constexpr array aa;
constexpr auto b = aa.begin();
static_assert(b-b == 0, compiles just fine);
static_assert(aa.begin()-aa.begin() == 0, compiler thinks it's not a
constant expression);
[Bug c++/51478] constexpr not doing short-circuit evaluation
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51478 Dave Abrahams dave at boostpro dot com changed: What|Removed |Added CC||dave at boostpro dot com --- Comment #1 from Dave Abrahams dave at boostpro dot com 2011-12-09 04:34:33 UTC --- Actually I think I was wrong to report this and it probably isn't a bug. Feel free to close it.
[Bug c++/25185] deep typedef substitution in error message
--- Comment #23 from dave at boostpro dot com 2009-04-06 09:35 ---
Subject: Re: deep typedef substitution in error message
On Apr 3, 2009, at 11:45 PM, jason at redhat dot com wrote:
Also, I'm not thrilled that
boost::sequence::detail::range_makerElements, Begin, End,
CalcSize::type
is still present in the signature, even if it's explained below.
Carried to an extreme, you get EDG's nasty nested
={...={...={...}}}
type descriptions. Do you need to do that? Why not just spell out
the
return type?
Because that's the return type specified in the declaration. The
alternative would be for it to say
boost::sequence::range_::rangeElements, Begin, End, typename
boost::result_ofCalcSize()::type
like it used to; do you prefer that?
No, because that contains ::type
I'd want to see
boost::sequence::range_::rangeElements, Begin, End,
mpl_::integral_cunsigned int,5u
It seemed to me that we might as
well just print the typedef in the signature and give the fully
instantiated type in the bindings list rather than give a
still-dependent type in the signature and explain any component
typenames in the bindings list, but I don't feel strongly about that.
I'm confused as to why you think you need to give a still-dependent
type in the signature
--
David Abrahams
BoostPro Computing
http://boostpro.com
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25185
[Bug c++/25185] deep typedef substitution in error message
--- Comment #20 from dave at boostpro dot com 2009-04-04 01:33 ---
Subject: Re: deep typedef substitution in error message
on Fri Apr 03 2009, jason at gcc dot gnu dot org
gcc-bugzilla-AT-gcc.gnu.org wrote:
--- Comment #19 from jason at gcc dot gnu dot org 2009-04-03 21:45
---
Fixing that issue (we weren't canonicalizing deduced type arguments) and also
catching typedefs that aren't typenames gives
../../../../boost/sequence/make_range.hpp:60: instantiated from
Âboost::sequence::detail::range_makerElements, Begin, End, CalcSize::type
boost::sequence::detail::range_makerElements, Begin, End,
CalcSize::operator()(const L, const B, const E, const C) const [with L =
boost::sequence::identity_property_map; B = char*; E = char*; C =
boost::sequence::detail::size_differenceboost::arraychar, 11u, const
boost::arraychar, 6u ; Elements = boost::sequence::identity_property_map;
Begin = char*; End = char*; CalcSize =
boost::sequence::detail::size_differenceboost::arraychar, 11u,
boost::arraychar, 6u ; boost::sequence::detail::range_makerElements,
Begin,
End, CalcSize::type =
boost::sequence::range_::rangeboost::sequence::identity_property_map, char*,
char*, mpl_::integral_cunsigned int, 5u ; typename
boost::result_ofCalcSize()::type = mpl_::integral_cunsigned int, 5u]Â
Does that look better?
Hum, let me try to reformat that so I can understand it
../../../../boost/sequence/make_range.hpp:60: instantiated from
boost::sequence::detail::range_makerElements, Begin, End, CalcSize::type
boost::sequence::detail::range_maker
Elements, Begin, End, CalcSize
::operator()(const L, const B, const E, const C) const
[with
L = boost::sequence::identity_property_map;
B = char*;
E = char*;
C = boost::sequence::detail::size_difference
boost::arraychar, 11u, const boost::arraychar, 6u ;
Elements = boost::sequence::identity_property_map;
Begin = char*;
End = char*;
CalcSize = boost::sequence::detail::size_difference
boost::arraychar, 11u, boost::arraychar, 6u ;
boost::sequence::detail::range_makerElements, Begin, End, CalcSize::type
= boost::sequence::range_::range
boost::sequence::identity_property_map, char*, char*,
mpl_::integral_cunsigned int, 5u ;
typename boost::result_ofCalcSize()::type = mpl_::integral_cunsigned
int, 5u
]
Well, I find that a little confusing. Why is it explaining to me what
typename boost::result_ofCalcSize()::type
is? I don't see that type anywhere else in there. Also, I'm not
thrilled that
boost::sequence::detail::range_makerElements, Begin, End, CalcSize::type
is still present in the signature, even if it's explained below.
Carried to an extreme, you get EDG's nasty nested
={...={...={...}}}
type descriptions. Do you need to do that? Why not just spell out the
return type?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25185
