BGL: INTERNAL COMPILER ERROR in VC7.1
This one was already posted by Nicholas Burlett awhile back (see http://lists.boost.org/MailArchives/boost-users/msg06534.php), but I have some new info that may help. The problem: ========= When compiling code that uses the boost.graph library the VC7.1 compiler shouts: c:\boost_1_32_0\boost\mpl\aux_\preprocessed\plain\apply_wrap.hpp(48) : fatal error C1001: INTERNAL COMPILER ERROR As Nicholas already noted, this seems to be due to some compiler problem with the boost.graph out_edge_iterators since it is caused by the following lines in my code: (FilteredGraphGenerator::FilteredGraph is a typedef of a boost::filtered_graph) typedef boost::graph_traitsFilteredGraphGenerator::FilteredGraph ::out_edge_iterator oedge_iterator; oedge_iterator edgesItr, edgesEnd; boost::tie(edgesItr, edgesEnd) = boost::out_edges(itr->first, m_g.m_filteredGraph); while (edgesItr != edgesEnd) { // do anything! } In fact, it seems to be related to the operator!= between iterators (if the while loop is commented out it compiles). How ever, the error persists even after changing the operator!= to operator== : while (edgesItr == edgesEnd) { // do anything! } ========================================================================== Some findings: =========== * We used to use boost_1_30_0 and the code used to compile PERFECTLY. The problem only appeared after migrating to boost_1_32_0. * Calling directly to the "equal" function in iterator_core_access instead of the operator== works. typedef boost::graph_traitsFilteredGraphGenerator::FilteredGraph ::out_edge_iterator oedge_iterator; oedge_iterator edgesItr, edgesEnd; boost::tie(edgesItr, edgesEnd) = boost::out_edges(itr->first,m_g.m_filteredGraph); while (boost::iterator_core_access::equal(edgesItr, edgesEnd, boost::mpl::true_())) { // do somthing } * The error message location is at the mpl::apply_wrap2 function. Any relation to the mpl::apply2 function used for declaring the operator== in the BOOST_ITERATOR_FACADE_INTEROP_HEAD macro? Have these functions changed since v1.30.0?
Does Boost have a library that defines a file-based container, perhaps
based on a B-tree or equivalent, for very large collections? Or does
anyone know of such a thing, or has there been talk about developing one?
We have a few file-based collections with millions of entries. We don't
especially want to install a database. The file is too large to load into
memory. The file's format could be changed to make it compatible with the
type of collection I'm thinking of, but for the moment, we're doing binary
searches by reading the file on disc. As you might guess, this can be
quite slow, especially when the file is on a DVD and not the HD.
Anyway, I'd like to be able to write something like:
//file.data contains 100,000,000 entries
file_map
There is nothing like that I know of in Boost, but see the link below for an old intro to C++ that goes through the creation of somthing similar (FileArray). http://www.edm2.com/0604/introcpp9.html John.Wismar@autozone.com wrote:
Does Boost have a library that defines a file-based container, perhaps based on a B-tree or equivalent, for very large collections? Or does anyone know of such a thing, or has there been talk about developing one?
-- Jim Lear (512) 228-5532 (work) (512) 293-7248 (cell) This document/email may contain confidential, proprietary or privileged information and is intended only for use of the addressee/recipient named above. No confidentiality or privilege is waived or lost by any error in transmission of this document/email. If you are not the intended recipient of this document/email of Legerity, Inc., you are hereby notified that you must not use, disseminate, or copy it in any form or take any action in reliance on it. If you have received this document/email in error, please immediately notify me at (512) 228-5760 and permanently destroy/delete the original document/email and any copy of the document/email and printout thereof.
Does Boost have a library that defines a file-based container, perhaps based on a B-tree or equivalent, for very large collections? Or does anyone know of such a thing, or has there been talk about developing one?
We have a few file-based collections with millions of entries. We don't especially want to install a database. The file is too large to load into memory. The file's format could be changed to make it compatible with the type of collection I'm thinking of, but for the moment, we're doing binary searches by reading the file on disc. As you might guess, this can be quite slow, especially when the file is on a DVD and not the HD.
Not in Boost now (though it is considered by author): http://i10www.ira.uka.de/dementiev/stxxl.shtml /Pavel
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Pavel Vozenilek wrote: |>We have a few file-based collections with millions of entries. We |>don't especially want to install a database. While I understand you not wanting to install a database, I've seen several programs use SQLLite as a storage mechanism, without forcing the user to install a "3rd party" package. http://www.sqlite.org/ Hope this helps, _Ryan Wilcox - -- ================================================================ Wilcox Development Solutions: http://www.wilcoxd.com Toolsmiths for the Internet Age PGP: 0x2F4E9C31 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (Darwin) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCHivebYO0qC9OnDERAvM1AKC2z9kW6QbjasOD59CMoo+q0PoL1wCfTklf XMmV9P5lwLVi8HybhwfvRQg= =Ghze -----END PGP SIGNATURE-----
Ryan Wilcox wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Pavel Vozenilek wrote: |>We have a few file-based collections with millions of entries. We |>don't especially want to install a database.
While I understand you not wanting to install a database, I've seen several programs use SQLLite as a storage mechanism, without forcing the user to install a "3rd party" package.
There are fair number of embedded databases. For example I use GigaBASE from... http://www.garret.ru/~knizhnik/databases.html --grafik
Hello, I have a string "abc{123}de{456}fghijk{789}", and I want to find the content within all the { }s, and replace them with other string, I thought it is easy to realize this with string algorithm, but can not figure out, could anyone help? Thanks ____________________________________________________________________________________ The fish are biting. Get more visitors on your site using Yahoo! Search Marketing. http://searchmarketing.yahoo.com/arp/sponsoredsearch_v2.php
Hello, Easiest solution would be to use regular expression. You can use Boost.Regex library directly or you can use the wrappers provided in Boost.StringAlgo. Alternatively, you can define your own "finder" that will lookup expressions bracketed in {}s. And then pass it the generic find_format_all algorithm. Links: http://www.boost.org/doc/html/string_algo/concept.html#string_algo.finder_co... http://www.boost.org/doc/html/boost/algorithm/find_format_all.html http://www.boost.org/doc/html/string_algo/reference.html#header.boost.algori... Best Regards, Pavol. Jeff Wang wrote:
Hello, I have a string "abc{123}de{456}fghijk{789}", and I want to find the content within all the { }s, and replace them with other string, I thought it is easy to realize this with string algorithm, but can not figure out, could anyone help? Thanks
____________________________________________________________________________________ The fish are biting. Get more visitors on your site using Yahoo! Search Marketing. http://searchmarketing.yahoo.com/arp/sponsoredsearch_v2.php _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
John.Wismar@autozone.com wrote:
Does Boost have a library that defines a file-based container, perhaps based on a B-tree or equivalent, for very large collections? Or does anyone know of such a thing, or has there been talk about developing one?
Maybe you could try mySql which works with btree files, I think, then on top of that, something like OTL or DTL which provides C++-like iterators ? But of course, this would slower than the library you describe.
participants (9)
-
Jeff Wang -
Jim Lear -
John.Wismar＠autozone.com -
Pavel Vozenilek -
Pavol Droba -
remi.chateauneu＠gmx.de -
Rene Rivera -
Ryan Wilcox -
Yariv Tal