[Bug c++/61732] New: Derivation from final class incorrectly allowed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61732
Bug ID: 61732
Summary: Derivation from final class incorrectly allowed
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: joaquin at tid dot es
I understand that [class]/3 marks this program as ill-formed:
templateclass Base struct derived:Base{};
struct X final{};
void foo(derivedX*){}
int main()
{
foo(0);
}
Yet it builds and runs fine in GCC 4.8.
[Bug c++/61732] Derivation from final class incorrectly allowed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61732
--- Comment #2 from Joaquín M López Muñoz joaquin at tid dot es ---
Umm... This is not how I read [class]/3 (no mention to instances there). And,
moreover, if your interpretation was right then the following should compile
too:
struct X final{};
struct derived:X{};
void foo(derived*){}
int main()
{
foo(0);
}
but GCC, here, does complain that derived can't derive from X.
[Bug c++/61732] Derivation from final class incorrectly allowed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61732
--- Comment #4 from Joaquín M López Muñoz joaquin at tid dot es ---
I see. The following is slightly off-topic, so please tell me if you can carry
on the discussion offline. Why is such an instantiation error not
SFINAE-protected in the following example?
templateclass Base struct derived:Base{typedef int type;};
struct X final{};
templatetypename T
void foo(T*,typename derivedT::type=0){}
void foo(...){}
int main()
{
X* x;
foo(x);
}
GCC fails to compile with cannot derive from X instead of omitting the
instantiation of fooX and resorting to foo(...) instead.
[Bug c++/60027] New: Problem with braced-init-lists and explicit ctors
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60027
Bug ID: 60027
Summary: Problem with braced-init-lists and explicit ctors
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: joaquin at tid dot es
The following code compiled with -std=c++11:
struct foo
{
foo(int){}
};
struct bar
{
explicit bar(int){}
};
void f(foo){}
void f(bar){}
int main()
{
f({0});
}
yields:
main.cpp:16:8: error: call of overloaded 'f(brace-enclosed initializer
list)' is ambiguous
f({0});
^
main.cpp:16:8: note: candidates are:
main.cpp:11:6: note: void f(foo)
void f(foo){}
^
main.cpp:12:6: note: void f(bar)
void f(bar){}
^
which seems incorrect as bar::bar(int) is explicit.
Joaquín M López Muñoz
Telefónica Digital
[Bug libstdc++/41975] [C++0x] [DR579] unordered_set::erase performs worse when nearly empty
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41975 --- Comment #31 from Joaquín M López Muñoz joaquin at tid dot es 2010-10-06 11:10:12 UTC --- Paolo, I've read the minutes and seems no strong consensus was reached. I think it'd be useful if the issue can be reopened, at least for informative purposes, so that the committe specify whether it's in the spirit of the standard to allow low memory (singly-linked, one word per node) implementations, and if so what the likely implementations are (I understand this is Pablo's third approach). If this is the case the FCD has to be changed so as to allow erase() to throw. Otherwise implementors will know we have to resort to doubly-linked solutions.
[Bug libstdc++/41975] [C++0x] [DR579] unordered_set::erase performs worse when nearly empty
--- Comment #28 from joaquin at tid dot es 2010-09-20 17:34 --- US 113, ES 2, US 118 / Issue 579 have been closed as NAD, thus let's figure out how best obtain O(1) in our implementation... Do you have a rationale for the closing of this NB comments? N3133 shows 579 unchanged. I was told that someone reported about the existence of a O(1) singly-linked list implementation in Rapperswil, but I don't have additional details. I'd wait to get the full picture before going to a doubly-linked list: the commitee had full info on the issue, so if they closed 579 as NAD they are supposed to be able to provide a rationale. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41975
[Bug libstdc++/44480] [C++0x] Linear performance of begin() in unordered associative containers
--- Comment #9 from joaquin at tid dot es 2010-08-12 12:32 --- Hi Paolo, My comments on your last two posts: I think the impact of this is independent of #579: even if erase does not return an iterator, the cached bucket pointer has to be synced. This happens for erase(const key_type) as well as erase(const_iterator). Of course, if erase(const_iterator) returns an iterator then the cached bucket pointer cost is masked (because you need to reach for the next non-empty bucket anyway). And yes, there is a non-negligible impact on doing the cache thing. There was no discussion on this on the committe, so we are basically on our own :-) I agree with you the impact does not affect the O complexity of insert/erase, but it's an impact nonetheless. The testcase provided is this: you have an *empty* container with a large bucket count (because it held a large number of elements before) and keep adding and removing the same element: the resulting performance is linear with the number of buckets. Whether this must be considered or not a pathological use case I don't know. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44480
[Bug libstdc++/44480] [C++0x] Linear performance of begin() in unordered associative containers
--- Comment #11 from joaquin at tid dot es 2010-08-12 14:06 --- Thanks Manuel. It's Joaquín :-) You're welcome. Agreed again. Now I begin to understand this issue ;) Anyway, the patch for our library is almost ready, already passes all my test. I'll apply it later today and start working on the even more serious erase(iterator) issue: during that work I will give more thinking to this one too, see if we can improve the QoI of erase(const key_type) somehow. Let's keep in touch about these issues. Perfect, let's do that. Regarding #579, last I heard from my contact in the committee is that the issue has been finally dismissed and the standard will have an iterator-returning erase(const_iterator). That seems to imply that there exist singly linked lists implementations capable of circumventing the problem, but I haven't seen one yet. Do you have more info (maybe directly from the committee) on this? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44480
[Bug libstdc++/44480] [C++0x] Linear performance of begin() in unordered associative containers
--- Comment #4 from joaquin at tid dot es 2010-07-01 06:56 --- Hi Paolo, I sent a message to the reflector, answer was that currently there's no DR or any other type of issue regarding this that the LWG is aware of, so they have no official stance on the matter :-/ I don't know what other C++ std lib implementors have done here. Are you in a position to check? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44480
[Bug libstdc++/44480] New: Linear performance of begin() in unordered associative containers
The current implementation of begin() for unordered associative containers is linear (a search for the first non-empty bucket is executed each time begin() is called), yet the C++0x drafts specifiy that this should be constant (23.3.1, table 93). Boost.Unordered, for instance, caches the first non-empty bucket on insertion/deletion to meet the O(1) begin() requirement. -- Summary: Linear performance of begin() in unordered associative containers Product: gcc Version: 4.5.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: joaquin at tid dot es http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44480
[Bug libstdc++/44480] [C++0x] Linear performance of begin() in unordered associative containers
--- Comment #2 from joaquin at tid dot es 2010-06-09 20:34 --- Caching can also have undesired consequences: for additional context on the problem, see https://svn.boost.org/trac/boost/ticket/4264 Note that *two* problems are discussed there, one is LWG issue #579 and the other the one being addressed here. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44480
[Bug c++/28371] New: pointer to function type mistaken when template functions are involved
The following snippet:
#include iostream
void foo(){}
templatetypename Tvoid bar(){}
templatetypename T
void test(const T)
{
std::couttypeid(T).name()std::endl;
}
int main()
{
test(foo);
test(barint);
}
produces this oputput on gcc version 3.2 20020927
(prerelease) under Cygwin:
PFvvE
FvvE
But the two lines should be identical --in both
cases, the deduced T should be void(*)().
Although it is not immediately apparent in
the testcase provided, what happens is that the
second type is taken as void(), i.e. the pointer
somehow is dropped.
Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo
--
Summary: pointer to function type mistaken when template
functions are involved
Product: gcc
Version: 3.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: joaquin at tid dot es
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28371
[Bug c++/20453] GCC fails to treat a valid constant expression as a template argument
--- Additional Comments From joaquin at tid dot es 2005-03-14 17:08 ---
(In reply to comment #4)
(In reply to comment #3)
(In reply to comment #2)
I cannot reproduce it either with an obvious change to fix the missing
Too bad. Sorry for reporting this in such an imprecise
manner. The actual problem shows at Boost regression tests
OK, I've got a test case:
#include cstddef
template
std::size_t size_,
std::size_t alignment_ = std::size_t(-1)
struct aligned_storage
{
};
templatetypename T
struct foo
{
aligned_storagesizeof(T) as;
};
int main()
{
foodouble f;
}
Fails with the following:
13: error: '(size_t)((-1))' is not a valid template argument for type 'unsigned
int' because it is a non-constant expression
Regards,
Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20453
[Bug c++/20453] New: GCC fails to treat a valid constant expression as a template argument
This is happening in the compilation of boost::aligned_storage
(boost/aligned_storage.hpp) in the current CVS.
The version of GCC used is 4.0.0 20050309 (prerelease)
I am sorry I can't provide a verified to fail snippet,
since I don't have access to that version of GCC. The
following is an untested attempt to reproduce the
problem in isolated code.
#include cstddef
template
std::size_t size_
, std::size_t alignment_ = std::size_t(-1)
class aligned_storage
{
};
int main()
{
aligned_storage1 as;
}
This produces the following:
'(size_t)((-1))' is not a valid template argument for type 'unsigned int'
because it is a non-constant expression
which AFAICS is an invalid error.
--
Summary: GCC fails to treat a valid constant expression as a
template argument
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: joaquin at tid dot es
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20453
[Bug c++/20453] GCC fails to treat a valid constant expression as a template argument
--- Additional Comments From joaquin at tid dot es 2005-03-13 15:05 --- (In reply to comment #2) I cannot reproduce it either with an obvious change to fix the missing Too bad. Sorry for reporting this in such an imprecise manner. The actual problem shows at Boost regression tests http://tinyurl.com/4hxy5 I'll try to isolate it into a snippet amenable to study, as soon as I find someone with access to that version of the compiler -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20453
