[Bug libstdc++/56170] Extension debug_allocator seems non-compliant w.r.t. rebind
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56170 --- Comment #9 from Ami Tavory 2013-03-26 21:40:03 UTC --- Great, many thanks!
[Bug c++/24054] New: std::tr1::unordered_map's erase does not seem to return a value
/usr/include/c++/4.0.0/tr1/hashtable lines 1345-1365 is a hash-table's erase
method declared to return a size_type. The method does not seem to return any
value, though; g++ warns about this when I try to use std::tr1::unordered_map's
erase.
g++ --version outputs: g++ (GCC) 4.0.0 20050519 (Red Hat 4.0.0-8)
Thanks!
--
Summary: std::tr1::unordered_map's erase does not seem to return
a value
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: atavory at gmail dot com
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24054
[Bug c++/24061] New: Documentation in /tr1/hashtable proposes possibly misleading change
/tr1/hashtable lines 1318-132 documents hashtable::erase(const_iterator i)
It states:
"The return type should be const_iterator,
and it should return the iterator following the one we've erased.
That would simplify range erase."
However, if erase would return an iterator, range-erase would not work the way
the comment suggests. The comment (probably) refers to code like the following
(attempting to erase values whose key is larger than 20):
for(typename T::iterator i = t.begin(); i != t.end();)
if(i->first > 20)
i = t.erase(i); // (*)
else
++i;
This looks simple, but it probably won't work. The line marked by (*) might
resize the container, which will rehash/reposition all values. The iterator i
might point to values already accessed, or might have skipped passt values not
yet accessed, or both. tr1 is correct: t.erase(i) cannot return any meaningful
iterator.
--
Summary: Documentation in /tr1/hashtable proposes possibly
misleading change
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: atavory at gmail dot com
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24061
[Bug libstdc++/24064] New: tr1::unordered_map seems to seg-fault when caching hash values
The following snippet of code seg-faults: typedef std::tr1::unordered_map< int, char, __gnu_cxx::hash< int>, std::equal_to< int>, std::allocator< std::pair< const int, char> >, true> // (*) map_t; map_t m; int i; for(i = 0; i < 1000; ++i) m[i] = 'a'; for(i = 0; i < 1000; ++i) ++m.find(i)->second; If, however, the value in the line marked with (*) is changed to false (i.e., the container does not cache hash values), it runs fine. g++ --version outputs: g++ (GCC) 4.0.0 20050519 (Red Hat 4.0.0-8) Thanks! -- Summary: tr1::unordered_map seems to seg-fault when caching hash values Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: libstdc++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: atavory at gmail dot com CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24064
[Bug libstdc++/24061] Documentation in /tr1/hashtable proposes possibly misleading change
--- Additional Comments From atavory at gmail dot com 2005-09-26 22:22 --- (In reply to comments #2 and #3: Actually, on second thought, I'm not sure we should give up consistency so easily only because the it = t.erase(it) idiom cannot be meaningfully used together with unordered containers: otherwise, why, f.i., vector::erase returns an iterator?!?!) For hash-based containers, i = t.erase(i) is effectively similar to: t.erase(i->first) // or t.erase(*i) i = t.begin(); std::advance(i, ::rand() % t.size()); (In fact, it's even somewhat worse than the above.) How could the return value be useful? Conversely, i = t.erase(i) makes sense for both tree-based containers or vectors, as it can be used in snippets such as the one in the original post. The problem is not, IMHO, whether the container is ordered or not (e.g., an unsorted std::vector). The problem is whether the container's sequence is well defined. Prior to hash-tables, the STL had only containers with well-defined sequences. (Put differently, one can think of a vector (or even a list) as an "associative container" mapping 1 .. t.size() - 1 to the values of t.) So, IMHO, this isn't giving up consistency; it's just reflecting inherent inconsistency through an inconsistent interface. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24061
[Bug libstdc++/56170] New: Extension debug_allocator seems non-compliant w.r.t. rebind
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56170
Bug #: 56170
Summary: Extension debug_allocator seems non-compliant w.r.t.
rebind
Classification: Unclassified
Product: gcc
Version: 4.7.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: atav...@gmail.com
It seems that the useful debug_allocator can only be used directly, not through
rebinding. If so, this limits its use in many situations.
E.g., here is some code that tries to use it with a list:
#include
#include
using namespace std;
int main()
{
list > > a;
return 0;
}
and here is the output:
In file included from /usr/include/c++/4.7/list:64:0,
from gcc.cpp:1:
/usr/include/c++/4.7/bits/stl_list.h: In instantiation of ‘class
std::_List_base > >’:
/usr/include/c++/4.7/bits/stl_list.h:436:11: required from ‘class
std::list > >’
gcc.cpp:8:66: required from here
/usr/include/c++/4.7/bits/stl_list.h:307:9: error: no class template named
‘rebind’ in ‘class __gnu_cxx::debug_allocator >’
/usr/include/c++/4.7/bits/stl_list.h:309:60: error: no class template named
‘rebind’ in ‘class __gnu_cxx::debug_allocator >’
/usr/include/c++/4.7/bits/stl_list.h: In instantiation of ‘class std::list > >’:
gcc.cpp:8:66: required from here
/usr/include/c++/4.7/bits/stl_list.h:469:20: error: no members matching
‘std::list > >::_Base {aka
std::_List_base >
>}::_M_get_Tp_allocator’ in ‘std::list > >::_Base {aka class
std::_List_base > >}’
/usr/include/c++/4.7/bits/stl_list.h:470:20: error: no members matching
‘std::list > >::_Base {aka
std::_List_base >
>}::_M_get_Node_allocator’ in ‘std::list > >::_Base {aka class
std::_List_base > >}’
In file included from /usr/include/c++/4.7/list:65:0,
from gcc.cpp:1:
/usr/include/c++/4.7/bits/list.tcc: In instantiation of ‘void
std::_List_base<_Tp, _Alloc>::_M_clear() [with _Tp = int; _Alloc =
__gnu_cxx::debug_allocator >]’:
/usr/include/c++/4.7/bits/stl_list.h:379:9: required from
‘std::_List_base<_Tp, _Alloc>::~_List_base() [with _Tp = int; _Alloc =
__gnu_cxx::debug_allocator >]’
/usr/include/c++/4.7/bits/stl_list.h:436:11: required from here
/usr/include/c++/4.7/bits/list.tcc:78:4: error: ‘_M_get_Tp_allocator’ was not
declared in this scope
In file included from /usr/include/c++/4.7/list:64:0,
from gcc.cpp:1:
/usr/include/c++/4.7/bits/stl_list.h: In instantiation of ‘std::_List_base<_Tp,
_Alloc>::_List_impl::_List_impl() [with _Tp = int; _Alloc =
__gnu_cxx::debug_allocator >]’:
/usr/include/c++/4.7/bits/stl_list.h:361:17: required from
‘std::_List_base<_Tp, _Alloc>::_List_base() [with _Tp = int; _Alloc =
__gnu_cxx::debug_allocator >]’
/usr/include/c++/4.7/bits/stl_list.h:522:15: required from ‘std::list<_Tp,
_Alloc>::list() [with _Tp = int; _Alloc =
__gnu_cxx::debug_allocator >]’
gcc.cpp:8:66: required from here
/usr/include/c++/4.7/bits/stl_list.h:317:32: error: no class template named
‘rebind’ in ‘class __gnu_cxx::debug_allocator >’
atavory@atavory-len:~$ g++ gcc.cpp > tmp.txt
atavory@atavory-len:~$ g++ gcc.cpp > tmp.txt
In file included from /usr/include/c++/4.7/list:64:0,
from gcc.cpp:1:
/usr/include/c++/4.7/bits/stl_list.h: In instantiation of ‘class
std::_List_base > >’:
/usr/include/c++/4.7/bits/stl_list.h:436:11: required from ‘class
std::list > >’
gcc.cpp:8:66: required from here
/usr/include/c++/4.7/bits/stl_list.h:307:9: error: no class template named
‘rebind’ in ‘class __gnu_cxx::debug_allocator >’
/usr/include/c++/4.7/bits/stl_list.h:309:60: error: no class template named
‘rebind’ in ‘class __gnu_cxx::debug_allocator >’
/usr/include/c++/4.7/bits/stl_list.h: In instantiation of ‘class std::list > >’:
gcc.cpp:8:66: required from here
/usr/include/c++/4.7/bits/stl_list.h:469:20: error: no members matching
‘std::list > >::_Base {aka
std::_List_base >
>}::_M_get_Tp_allocator’ in ‘std::list > >::_Base {aka class
std::_List_base > >}’
/usr/include/c++/4.7/bits/stl_list.h:470:20: error: no members matching
‘std::list > >::_Base {aka
std::_List_base >
>}::_M_get_Node_allocator’ in ‘std::list > >::_Base {aka class
std::_List_base > >}’
In file included from /usr/include/c++/4.7/list:65:0,
from gcc.cpp:1:
/usr/include/c++/4.7/bits/list.tcc: In instantiation of ‘void
std::_List_base<_Tp, _Alloc>::_M_clear() [with _Tp = int; _Alloc =
__gnu_cxx::debug_allocator >]’:
/usr/include/c++/4.7/bits/stl_list.h:379:9: required from
‘std::_List_base<_Tp, _Alloc>::~_List_base() [with _Tp = int; _Alloc =
__gnu_cxx::debug_allocator >]’
/usr/include/c++/4.7/bits/stl_list.h:436:11: required from here
/usr/include/c++/4.7/bits/list.tcc:78:4: error: ‘_M_get_Tp_allocator’ was not
declared in this scope
In file included from /usr/include/c++/4.7/list:64:0,
from gcc.cpp:1:
/usr/include/c++/4.7/bits/stl_list.h: In insta
[Bug libstdc++/56170] Extension debug_allocator seems non-compliant w.r.t. rebind
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56170 --- Comment #6 from Ami Tavory 2013-02-02 07:24:16 UTC --- Hi Paolo (again) and Jonathan, Thanks for offering to add the missing functionality, Jonathan. I was wondering if there might be an interest to add _AllocatorConcept to boost_concept_check.h. Asides from helping with diagnosing allocator non-compliance, it might help with the more common case of template parameter mixup (it's not impossibly hard to code - as an STL client - some_stl_container while getting them mixed up and sending as Allocator something completely different). If there's an interest, I could try to get a go at this in a few weeks.
