From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25804 invoked by alias); 13 May 2012 22:19:41 -0000 Received: (qmail 25794 invoked by uid 22791); 13 May 2012 22:19:39 -0000 X-SWARE-Spam-Status: No, hits=-3.6 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from localhost (HELO gcc.gnu.org) (127.0.0.1) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sun, 13 May 2012 22:19:24 +0000 From: "eltoder at gmail dot com" To: gcc-bugs@gcc.gnu.org Subject: [Bug libstdc++/53339] New: unordered_map::iterator requires Value to be complete type Date: Sun, 13 May 2012 22:23:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: libstdc++ X-Bugzilla-Keywords: X-Bugzilla-Severity: minor X-Bugzilla-Who: eltoder at gmail dot com X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Changed-Fields: Message-ID: X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated Content-Type: text/plain; charset="UTF-8" MIME-Version: 1.0 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2012-05/txt/msg01370.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53339 Bug #: 53339 Summary: unordered_map::iterator requires Value to be complete type Classification: Unclassified Product: gcc Version: 4.6.3 Status: UNCONFIRMED Severity: minor Priority: P3 Component: libstdc++ AssignedTo: unassigned@gcc.gnu.org ReportedBy: eltoder@gmail.com Created attachment 27393 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27393 Simple test case Sometimes it's useful to refer to map's iterator from map's value, e.g.: #include #include struct LinkedHashMap { struct Entry; typedef std::tr1::unordered_map Storage; typedef Storage::iterator EntryPtr; // <-- fails here struct Entry { EntryPtr prev, next; }; Storage storage_; EntryPtr head_; }; (here we combine hash map with linked list implemented via iterators). It doesn't seem unreasonable to expect this to compile, however it doesn't: In file included from /usr/include/c++/4.6/bits/stl_algobase.h:65:0, from /usr/include/c++/4.6/bits/char_traits.h:41, from /usr/include/c++/4.6/string:42, from linkedhash.cc:1: /usr/include/c++/4.6/bits/stl_pair.h: In instantiation of 'std::pair, LinkedHashMap::Entry>': /usr/include/c++/4.6/bits/stl_function.h:486:12: instantiated from 'std::_Select1st, LinkedHashMap::Entry> >' /usr/include/c++/4.6/tr1/hashtable_policy.h:708:20: instantiated from 'std::tr1::__detail::_Hash_code_base, std::pair, LinkedHashMap::Entry>, std::_Select1st, LinkedHashMap::Entry> >, std::equal_to >, std::tr1::hash >, std::tr1::__detail::_Mod_range_hashing, std::tr1::__detail::_Default_ranged_hash, false>' /usr/include/c++/4.6/tr1/hashtable.h:108:11: instantiated from 'std::tr1::_Hashtable, std::pair, LinkedHashMap::Entry>, std::allocator, LinkedHashMap::Entry> >, std::_Select1st, LinkedHashMap::Entry> >, std::equal_to >, std::tr1::hash >, std::tr1::__detail::_Mod_range_hashing, std::tr1::__detail::_Default_ranged_hash, std::tr1::__detail::_Prime_rehash_policy, false, false, true>' /usr/include/c++/4.6/tr1/unordered_map.h:43:11: instantiated from 'std::tr1::__unordered_map, LinkedHashMap::Entry, std::tr1::hash >, std::equal_to >, std::allocator, LinkedHashMap::Entry> >, false>' /usr/include/c++/4.6/tr1/unordered_map.h:180:11: instantiated from 'std::tr1::unordered_map, LinkedHashMap::Entry>' linkedhash.cc:8:20: instantiated from here /usr/include/c++/4.6/bits/stl_pair.h:93:11: error: 'std::pair<_T1, _T2>::second' has incomplete type linkedhash.cc:6:12: error: forward declaration of 'struct LinkedHashMap::Entry' The problem is that _Select1st > forces instantiation of pair when trying to declare its return type: template struct _Select1st : public unary_function<_Pair, typename _Pair::first_type> // <-- but pair cannot be instantiated until both types are complete. This is can be worked around by using unordered_set or using _Hashtable directly, but * This code compiles if unordered_map is replaced by map. Would be nice to keep them consistent. * There doesn't seem to be any fundamental reason why this doesn't work -- it comes from a minor implementation choice and seems very easy to fix.