MinGW is a good (an excellent, actually) compiler / toolchain and I recommend using it with the Code::Blocks IDE (MinGW comes included).
http://www.codeblocks.org/
MinGW is a good (an excellent, actually) compiler / toolchain and I recommend using it with the Code::Blocks IDE (MinGW comes included).
http://www.codeblocks.org/
Good class architecture is not like a Swiss Army Knife; it should be more like a well balanced throwing knife.
- Mike McShaffry
I still write extremely compact code. The secret - don't use MFC or the STL or any 3rd party libraries if you can help it. It also helped that my first computer only had 2.5k of ram and I have spent years programmign microcontrolelrs and PLC's which dont have a lto fo memory to throw at a problem. An additional benefit of course is that sicne my programs are compact they almost alwasy run entirely in the cahce, so they run much faster than teh competition.
He means this:
Attachment 8109Code:#include <iostream> int main() { std::cout << "STL adds bloat. Lots of it."; return 0; }
gcc version 3.4.2 (mingw-special)
When you strip it, the size is reduced to 260kb.
Right, iostreams are part of the standard library, not STL. STL, strictly, is not a library but a set of templates stored in header files.
And secondly, look at a linker map of the resulting executable. I bet you'll find that a lot of that size is taken up by standard runtime support.
Try linking the equivalent C program statically, and see how big that is. Then you'll have something approaching a valid comparison (even though it's still not comparing what I'm talking about, which is the effect of STL on code size)
Attachment 8110Code:#include <vector> #include <string> int main() { std::vector<int> v(10); for (int i=0;i<10;i++) { v[i] = i*(i+i^3); } reverse(v.begin(), v.end()); std::string q = "omgomgom"; return 0; }
It's less, but still. 58kb stripped.
Attachment 8111Code:#include <stdio.h> int main() { puts("C doesn't"); return 0; }
6kb stripped. I don't know how to link to libstdc statically on windows, sorry.
I don't see how anyone would think STL would result in larger source code size, if that's what you're talking about.
Last edited by Doodle77; 05-01-2008 at 06:06 PM.
uh? Try instead adding vector and string functionality to that C code snippet before you try to compare oranges to apples again.
Originally Posted by brewbuck:
Reimplementing a large system in another language to get a 25% performance boost is nonsense. It would be cheaper to just get a computer which is 25% faster.
I don't see why that should make much of a difference. stdio is small. Its going to be around the same size compiled with g++.uh? Try instead adding vector and string functionality to that C code snippet before you try to compare oranges to apples again.
The issue is not between C and C++ code. Lets not get into that endless discussion. Is about using STL and not using STL. C doesn't have STL. so, don't use it has a means for comparison.
Originally Posted by brewbuck:
Reimplementing a large system in another language to get a 25% performance boost is nonsense. It would be cheaper to just get a computer which is 25% faster.
Well then doodle77 could always compile this:
as c++, and it would come out around the same size. Which would be a valid comparion. And if compiling with C or C++ is around the same as far as file size goes then that means he was originally making a valid comparison too :PCode:#include <stdio.h> int main() { puts("C doesn't"); return 0; }
Ok then. You agree it's not an issue of stladdsbloat.exe against cdoesnt.exe. That's a start.
Now, translate that to real-life code and examples.
Originally Posted by brewbuck:
Reimplementing a large system in another language to get a 25% performance boost is nonsense. It would be cheaper to just get a computer which is 25% faster.