public inbox for gcc-prs@sourceware.org help / color / mirror / Atom feed
From: marc_bumble@uml.edu To: gcc-gnats@gcc.gnu.org Cc: marc_bumble@cpinternet.com Subject: c++/8779: C++ allocator calls using stl map class bug? Date: Sun, 01 Dec 2002 19:06:00 -0000 [thread overview] Message-ID: <20021202030111.5286.qmail@sources.redhat.com> (raw) >Number: 8779 >Category: c++ >Synopsis: C++ allocator calls using stl map class bug? >Confidential: no >Severity: serious >Priority: medium >Responsible: unassigned >State: open >Class: sw-bug >Submitter-Id: net >Arrival-Date: Sun Dec 01 19:06:00 PST 2002 >Closed-Date: >Last-Modified: >Originator: Marc Bumble >Release: gcc version 3.2 >Organization: >Environment: /usr/local/build/usr/bin/gcc --version gcc (GCC) 3.2 Copyright (C) 2002 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. /usr/local/build/usr/bin/gcc -v Reading specs from /usr/local/build/usr/bin/../lib/gcc-lib/i686-pc-linux-gnu/3.2/specs Configured with: ../gcc-3.2/configure --prefix=/usr --enable-shared --enable-languages=java,c,c++,f77,objc --enable-threads=posix --with-slibdir=/lib --enable-__cxa_atexit --enable-clocale=gnu Thread model: posix gcc version 3.2 uname -a Linux cadence.glidepath.org 2.4.18 #8 SMP Tue Jul 9 23:27:08 EDT 2002 i686 unknown mkdir ../gcc-build && cd ../gcc-build && ../gcc-3.2/configure --prefix=/usr --enable-shared \ --enable-languages=java,c,c++,f77,objc --enable-threads=posix \ --with-slibdir=/lib --enable-__cxa_atexit \ --enable-clocale=gnu && make bootstrap && make install && ln -s ../usr/bin/cpp /lib && ln -s ../bin/cpp /usr/lib && ln -s gcc /usr/bin/cc >Description: I am not fully sure that there is a compiler issue, but the error looks suspicious. I am writing a C++ allocator. When I attempt to compile an STL map<> class with it, I get an error message which itself looks like it has a mistake. I have not yet worked out a small test case, as the entire allocator probably needs to be provided, but the allocator interface was working fine with gcc 3.0.4. Let me know if you need a sample test case, and I will do my best to provide one. The coding issue which causes the problem appears as: typedef std::map<std::string, Container*, std::less<std::string>, Pool_alloc<std::pair<std::string, Container*>, alloc_type, memory_segment_key> > map_t; // Pointer to the Container map index map_t* map_p; The compiler error messages are: /usr/local/build/usr/include/c++/3.2/bits/stl_tree.h:531: no matching function for call to `allocator_ns::Pool_alloc<std::_Rb_tree_node<std::pair<const std::basic_string<char, std::char_traits<char>, std::allocator<char> >, main(int, char**)::x_vector_t*> >, sharedpooled, (&temp)>::Pool_alloc(const allocator_ns::Pool_alloc<std::pair<const std::basic_string<char, std::char_traits<char>, std::allocator<char> >, main(int, char**)::x_vector_t*>, sharedpooled, (&temp)>&)' ../include/allocator.h:281: candidates are: allocator_ns::Pool_alloc<std::_Rb_tree_node<std::pair<const std::basic_string<char, std::char_traits<char>, std::allocator<char> >, main(int, char**)::x_vector_t*> >, sharedpooled, (&temp)>::Pool_alloc(const allocator_ns::Pool_alloc<std::_Rb_tree_node<std::pair<const std::basic_string<char, std::char_traits<char>, std::allocator<char> >, main(int, char**)::x_vector_t*> >, sharedpooled, (&temp)>&) ../include/allocator.h:359: allocator_ns::Pool_alloc<T, alloc_type, alloc_key>::Pool_alloc() [with T = std::_Rb_tree_node<std::pair<const std::basic_string<char, std::char_traits<char>, std::allocator<char> >, main(int, char**)::x_vector_t*> >, mem_space::AllocatorType alloc_type = sharedpooled, const char*alloc_key = (&temp)] I am not sure why the candidate has the std::_Rb_tree_node<std::pair<const .. part which looks like an error? I think it should just be std::pair<const without the _Rb_tree_node part. Seems like a mistake to me. Or I am way off and just missing something obvious? Please let me know. I will do my best to provide a sucint example if it is required. The size of the allocator code is a little large though, and I am not sure how to make it succint. Thanks you for any assistance with this error, marc >How-To-Repeat: >Fix: >Release-Note: >Audit-Trail: >Unformatted:
next reply other threads:[~2002-12-02 3:06 UTC|newest] Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top 2002-12-01 19:06 marc_bumble [this message] 2002-12-02 11:56 Marc D Bumble 2002-12-02 12:50 bangerth
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20021202030111.5286.qmail@sources.redhat.com \ --to=marc_bumble@uml.edu \ --cc=gcc-gnats@gcc.gnu.org \ --cc=marc_bumble@cpinternet.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).