[variant] MSVC7.1 produces an Internal Compiler
I had the same problem with MSV7.1 and resolved it by using project setting: /Gm, which is under C/C++/Code Generation. Basically, you need to reduce the debug information. Yan -----Original Message----- From: boost-users-bounces@lists.boost.org [mailto:boost-users-bounces@lists.boost.org] On Behalf Of boost-users-request@lists.boost.org Sent: Tuesday, September 05, 2006 4:46 PM To: boost-users@lists.boost.org Subject: Boost-users Digest, Vol 1018, Issue 3 Send Boost-users mailing list submissions to boost-users@lists.boost.org To subscribe or unsubscribe via the World Wide Web, visit http://lists.boost.org/mailman/listinfo.cgi/boost-users or, via email, send a message with subject or body 'help' to boost-users-request@lists.boost.org You can reach the person managing the list at boost-users-owner@lists.boost.org When replying, please edit your Subject line so it is more specific than "Re: Contents of Boost-users digest..." Today's Topics: 1. [BGL] filtered graph missing vertex function (moritz Hilger) 2. Re: Boost.signals with -pthread (Ra?l Huertas) 3. Re: Building Tests With Boost Test (Roman Neuhauser) 4. Re: [BGL] filtered graph missing vertex function (Stephan Diederich) 5. [variant] MSVC7.1 produces an Internal Compiler error when variant gets too complicated (Eoin) 6. portable way to determine return type from class member function (Peter Piehler) 7. Re: [test] Running either unit tests or normal program based off of command line switches (Jason House) 8. Re: [BGL] filtered graph missing vertex function (moritz Hilger) 9. Using boost::enable_if with template copy constructors (Tim Robertson) ---------------------------------------------------------------------- Message: 1 Date: Tue, 5 Sep 2006 20:23:46 +0200 From: "moritz Hilger" <moritz.hilger@gmail.com> Subject: [Boost-users] [BGL] filtered graph missing vertex function To: boost-users@lists.boost.org Message-ID: <b48649090609051123r104f6e9dtc91a992f64bf9e9c@mail.gmail.com> Content-Type: text/plain; charset="iso-8859-1" is there a particular reason that the filtered graph is missing a vertex_descriptor vertex(vertices_size_type, const& filtered_graph) function? of course this would return exactly the same as the one of the underlying graph, nevertheless it would be handy for code treating filtered graphs the same way as normal ones. greetings moritz
Hello Yan, thank you for the advice unfortunately I am still getting the Internal Compiler Errors. This problem is proving to be quite a show-stopper for my library. Kind regards, Eoin Yan Zhang wrote:
I had the same problem with MSV7.1 and resolved it by using project setting: /Gm, which is under C/C++/Code Generation. Basically, you need to reduce the debug information.
Yan
/Gm does not reduce the debug information -- it enables minimal rebuild. On a number of occasions, I have managed to eliminate Internal Compiler Errors by *disabling* this feature (i.e., using /Gm-). Moshe
-----Original Message----- From: boost-users-bounces@lists.boost.org [mailto:boost-users-bounces@lists.boost.org] On Behalf Of Yan Zhang Sent: Wednesday, September 06, 2006 2:58 AM To: boost-users@lists.boost.org Subject: [Boost-users] [variant] MSVC7.1 produces an Internal Compiler
I had the same problem with MSV7.1 and resolved it by using project setting: /Gm, which is under C/C++/Code Generation. Basically, you need to reduce the debug information.
Yan
-----Original Message----- From: boost-users-bounces@lists.boost.org [mailto:boost-users-bounces@lists.boost.org] On Behalf Of boost-users-request@lists.boost.org Sent: Tuesday, September 05, 2006 4:46 PM To: boost-users@lists.boost.org Subject: Boost-users Digest, Vol 1018, Issue 3
...
Thank you Moshe, I will try this when I home home tonight and report back. Kind regards, Eoin. Moshe Matitya wrote:
/Gm does not reduce the debug information -- it enables minimal rebuild.
On a number of occasions, I have managed to eliminate Internal Compiler Errors by *disabling* this feature (i.e., using /Gm-).
Moshe
-----Original Message----- From: boost-users-bounces@lists.boost.org [mailto:boost-users-bounces@lists.boost.org] On Behalf Of Yan Zhang Sent: Wednesday, September 06, 2006 2:58 AM To: boost-users@lists.boost.org Subject: [Boost-users] [variant] MSVC7.1 produces an Internal Compiler
I had the same problem with MSV7.1 and resolved it by using project setting: /Gm, which is under C/C++/Code Generation. Basically, you need to reduce the debug information.
Yan
-----Original Message----- From: boost-users-bounces@lists.boost.org [mailto:boost-users-bounces@lists.boost.org] On Behalf Of boost-users-request@lists.boost.org Sent: Tuesday, September 05, 2006 4:46 PM To: boost-users@lists.boost.org Subject: Boost-users Digest, Vol 1018, Issue 3
...
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
On a number of occasions, I have managed to eliminate Internal Compiler Errors by *disabling* this feature (i.e., using /Gm-).
Moshe
Thank you for your suggestion, unfortunately the /Gm- option does not get rid of this error.
Also Yan, in response to your most recent suggestion; "Try use /Zi instead of /ZI from C/C++/General/Debug Information Format." I am using a Boost.Buildv2 environment and it sets /Z7 as default in Debug mode, also it was including /Zm800 option already, changing it to the max /Zm2000 has no effect neithe does /ZI. However testing the different options I have gotten the project to compile when I manually changed /Z7 to /Zd, unfortunately I achieved this through a hack in the MSVC toolkit setup, I may suggest something related to this option on the Boost.Build mailing list. However a solution without affecting the way applications build would be preferable.
Ok, a solution finally! I figured that my use of make_recursive_variant and recursive_variant_ was probably at fault as the variant in question is reasonably large, the two recursive types effectively trebled the size of its type description. My solution instead was to use the recursive_wrapper as I show below. It does work slightly differently, specifically you have to reference the member vector or map and I am worried that I'm walking close to a dangerous edge which ICE's could start happening again but the other option is to write my own object hierarchy based solution which would be much cruder. Thanks Yan and Moshe for your suggestions I very much appreciate you taking the time to think about this error. Kind regards, Eoin. struct param_vec; struct param_map; typedef boost::variant< int , std::string, boost::posix_time::ptime, boost::recursive_wrapper<param_vec>, boost::recursive_wrapper<param_map> > param; struct param_vec { param_vec() {} param_vec(std::vector<param> vec) : v(vec) {} std::vector<param> v; }; struct param_map { param_map() {} param_map(std::map<std::string, param> map) : m(map) {} std::map<std::string, param> m; };
participants (3)
-
Eoin -
Moshe Matitya -
Yan Zhang