[Bug libstdc++/40925] New: c++0x std::pairT*,U* constructor doesn't accept (0, 0)
This expression: std::pairT*, U*(0, 0) ... compiles with -std=c++98, but does not compile with -std=c++0x. We have tens, possibly hundreds, of such constructs in our codebase. Either this is a libstdc++ bug or an (I think fairly serious) issue in the changes to std::pair in the C++-0x working paper. If the types in question are known, this can be worked around by using std::make_pairT*,U* instead of std::pairT*,U*. Cases with no nice workaround include: typedef std::mapT*, U M; // Later: m.insert(M::value_type(0, x)); ... and ... std::pairT*, U* pair(0, 0); The former case seems to have no workaround other than listing the types T* and U again. The latter case can be worked around with auto, but we wish to keep our code compiling with -std=c++98 too, for now, so I think we're reduced to repeating the types T* and U*. The compilation error is: /usr/include/c++/4.4/bits/stl_pair.h: In constructor std::pair_T1, _T2::pair(_U1, _U2) [with _U1 = int, _U2 = int, _T1 = T*, _T2 = U*]: /usr/include/c++/4.4/bits/stl_pair.h:90: error: invalid conversion from int to T* Presumably the std::pairT,U::pair(T, U) constructor has been removed in favour of this more general one? -- Summary: c++0x std::pairT*,U* constructor doesn't accept (0, 0) Product: gcc Version: 4.4.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: richard-gccbugzilla at metafoo dot co dot uk http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40925
[Bug libstdc++/40925] c++0x std::pairT*,U* constructor doesn't accept (0, 0)
--- Comment #1 from richard-gccbugzilla at metafoo dot co dot uk
2009-07-31 15:26 ---
Working draft N2914, 20.3.3 says:
template VariableType T1, VariableType T2
struct pair {
[...]
requires CopyConstructibleT1 CopyConstructibleT2 pair(const T1 x,
const T2 y);
... and this is (modulo concept constraints) present in stl_pair.h, but I
imagine that an argument of 0 doesn't select this constructor.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40925
[Bug c++/36486] g++ accepts code with ambiguous overloading
--- Comment #3 from richard-gccbugzilla at metafoo dot co dot uk 2008-06-11 12:58 --- I'm not 100% certain that g++ is at fault. Given that icc, Comeau and MS all reject it, I'm inclined to think that g++ is probably the one which gets this wrong, so I've raised this here first. This hinges on whether f0 and f1 are ordered by the standard partial ordering on function templates. It appears superficially that they are not, since from the arguments to f1 you cannot deduce the template parameters of f0, nor vice versa. However, it appears to depend on interpretation of [temp.deduct.type]/5, which says that The non-deduced contexts are: [...] A template parameter used in the parameter type of a function parameter that has a default argument that is being used in the call for which argument deduction is being done. I'm not sure whether that applies here, but if it does, perhaps that makes f1 more specialized than f0, and this is a bug in all the other compilers. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36486
[Bug c++/36486] New: g++ accepts code with ambiguous overloading
g++ (at least versions 3.3.5, 3.4.4 and 4.1.1) accepts the following code,
which I think is ill-formed:
templatetypename T struct F {};
templatetypename C, typename R
int f(R (C::*f)() const, const FR n = FR()) { return 0; } // f0
templatetypename C, typename R
int f(const R (C::*f)() const, const FR n = FR()) { return 1; } // f1
struct X { const X foo() const { return *this; } };
int main() { return f(X::foo); }
Here, g++ is presumably deciding that f1 is more specialized than f0, despite
f0's arguments not being deducible from f1 (indeed, there is no pair of
argument types (T1, T2) which both f0 and f1 accept).
EDG's frontend rejects the above code.
--
Summary: g++ accepts code with ambiguous overloading
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: richard-gccbugzilla at metafoo dot co dot uk
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36486
[Bug c++/36486] g++ accepts code with ambiguous overloading
--- Comment #1 from richard-gccbugzilla at metafoo dot co dot uk 2008-06-10 14:51 --- FWIW, Microsoft's recent compilers agree that this is ill-formed also. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36486
[Bug c++/21560] #pragma(1) doesn't work on the inner classes inside the temlated class
--- Comment #2 from richard-gccbugzilla at metafoo dot co dot uk 2007-06-11 18:11 --- Dup of 7046. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21560
[Bug c++/30300] Bogus diagnostic for anonymous structs/classes
--- Comment #2 from richard-gccbugzilla at metafoo dot co dot uk
2007-06-05 17:21 ---
Points worthy of note:
1) The OP's code is legal (to my reading of the standard) but meaningless.
Private members in unnamed classes are legal, while private members in
anonymous unions are not. So technically this should be tagged as
rejects-valid.
2) If the code is made meaningful by defining a variable whose type is the
unnamed class, the incorrect diagnostic goes away:
struct A
{
class
{
static int i;
int j;
} k;
};
3) In my opinion, it would be valuable to produce a diagnostic in the situation
of the code in comment#0, as a quality of implementation issue. I'm not sure
whether the standard requires a diagnostic here. Comeau produces an error in
this case (declaration does not declare anything).
--
richard-gccbugzilla at metafoo dot co dot uk changed:
What|Removed |Added
CC||richard-gccbugzilla at
||metafoo dot co dot uk
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30300
