I've finally gotten around to compiling your example with MSVC. A complete compile link cycle takes 10 seconds on my 3.2GHz Pentium 4, with a very small bump (50MB) in the memory graph (my box has 1GB).
Regarding the large binary sizes you reported by private email: With MSVC the executable is 200KB, but I do remember that I sometimes had very large binaries with mingw. I guess this is somehow connected with the compiler/linker taking so long. Might be worth reporting to the gcc developers. Unfortunately, I don't have much time to spend on statechart at the moment as my job is currently very demanding and I'm also in the process of moving to new hardware. So I'm afraid I won't be able to look into this more deeply in the next few weeks.
Correct. My point was that it's often very easy to find that single line that needs fixing. Just work yourself up the instantiations until you find a line in your code (as opposed to library code).
> This drives me nuts, a simple 200-line *.cpp file using boost::stateschart compiles > for about 30 seconds,
What compiler are you using? I've observed *huge* differences (>300%) in compile time, depending on the make of the compiler and optimization settings. Also, I would be very interested in the 200 lines that cause such a long compile time. Optimizing the TMP part of statechart so that compile time is reduced has been on my TODO list for quite some time now. Reports of unbearable compile times would certainly increase the priority of that work item!
> and syntax errors result in 400+ character lines with recursive template codes etc
Slashdot Mirror
Hello again
I've finally gotten around to compiling your example with MSVC. A complete compile link cycle takes 10 seconds on my 3.2GHz Pentium 4, with a very small bump (50MB) in the memory graph (my box has 1GB).
Regarding the large binary sizes you reported by private email:
With MSVC the executable is 200KB, but I do remember that I sometimes had very large binaries with mingw. I guess this is somehow connected with the compiler/linker taking so long. Might be worth reporting to the gcc developers. Unfortunately, I don't have much time to spend on statechart at the moment as my job is currently very demanding and I'm also in the process of moving to new hardware. So I'm afraid I won't be able to look into this more deeply in the next few weeks.
Andreas
> I think the relatively small amount of RAM (512Mb) may be responsible since I use Eclipse as my
# CompilerError and it confirms
> main IDE and it usually takes 150-250 megs.
In that case I'm not surprised, TMP code tends to use heaps of RAM for even moderately complicated problems.
> I can mail you the source that results in insane compile times, my email is
> [my nickname on slashdot]@gmail.com
Ok, I'll contact you offline.
> I've looked at http://www.boost.org/libs/statechart/doc/faq.html
> what I said - an error in code using the Boost library results in 6-8 long compiler errors and
> only one of them actually needs to be fixed.
Correct. My point was that it's often very easy to find that single line that needs fixing. Just work yourself up the instantiations until you find a line in your code (as opposed to library code).
Hi
# CompilerError?
> This drives me nuts, a simple 200-line *.cpp file using boost::stateschart compiles
> for about 30 seconds,
What compiler are you using? I've observed *huge* differences (>300%) in compile time, depending on the make of the compiler and optimization settings. Also, I would be very interested in the 200 lines that cause such a long compile time. Optimizing the TMP part of statechart so that compile time is reduced has been on my TODO list for quite some time now. Reports of unbearable compile times would certainly increase the priority of that work item!
> and syntax errors result in 400+ character lines with recursive template codes etc
Have you had a look at http://www.boost.org/libs/statechart/doc/faq.html
Thanks & Regards,
Andreas