Thread: 64kb

  1. #16
    Supermassive black hole cboard_member's Avatar
    Join Date
    Jul 2005
    Posts
    1,709
    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

  2. #17

  3. #18
    Malum in se abachler's Avatar
    Join Date
    Apr 2007
    Posts
    3,195
    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.

  4. #19
    Officially An Architect brewbuck's Avatar
    Join Date
    Mar 2007
    Location
    Portland, OR
    Posts
    7,396
    Quote Originally Posted by abachler View Post
    The secret - don't use MFC or the STL or any 3rd party libraries if you can help it.
    Care to explain why you think STL leads to code bloat? Have you measured this in realistic situations? Under what compilers and STL libraries did you make those observations?

  5. #20
    Registered User
    Join Date
    Feb 2006
    Posts
    54
    Quote Originally Posted by brewbuck View Post
    Care to explain why you think STL leads to code bloat? Have you measured this in realistic situations? Under what compilers and STL libraries did you make those observations?
    He means this:
    Code:
    #include <iostream>
    
    int main() {
      std::cout << "STL adds bloat. Lots of it.";
      return 0;
    }
    Attachment 8109
    gcc version 3.4.2 (mingw-special)

    When you strip it, the size is reduced to 260kb.

  6. #21
    Devil's Advocate SlyMaelstrom's Avatar
    Join Date
    May 2004
    Location
    Out of scope
    Posts
    4,079
    Quote Originally Posted by Doodle77 View Post
    He means this:
    Code:
    #include <iostream>
    
    int main() {
      std::cout << "STL adds bloat. Lots of it.";
      return 0;
    }
    Attachment 8109
    gcc version 3.4.2 (mingw-special)

    When you strip it, the size is reduced to 260kb.
    Since when is <iostream> part of the Standard Template Library?
    Sent from my iPadŽ

  7. #22
    Officially An Architect brewbuck's Avatar
    Join Date
    Mar 2007
    Location
    Portland, OR
    Posts
    7,396
    Quote Originally Posted by SlyMaelstrom View Post
    Since when is <iostream> part of the Standard Template Library?
    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)

  8. #23
    Registered User
    Join Date
    Feb 2006
    Posts
    54
    Quote Originally Posted by brewbuck View Post
    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)
    Code:
    #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;
    }
    Attachment 8110

    It's less, but still. 58kb stripped.
    Code:
    #include <stdio.h>
    
    int main() {
      puts("C doesn't");
      return 0;
    }
    Attachment 8111
    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.

  9. #24
    (?<!re)tired Mario F.'s Avatar
    Join Date
    May 2006
    Location
    Ireland
    Posts
    8,446
    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.

  10. #25
    Registered User
    Join Date
    Feb 2006
    Posts
    54
    Quote Originally Posted by Mario F. View Post
    uh? Try instead adding vector and string functionality to that C code snippet before you try to compare oranges to apples again.
    I'm not trying to say that I could magically implement everything in STL in less space, I'm just saying that the mere use a string or vector in your c++ program adds 52kb of STL code.

  11. #26
    Dr Dipshi++ mike_g's Avatar
    Join Date
    Oct 2006
    Location
    On me hyperplane
    Posts
    1,218
    uh? Try instead adding vector and string functionality to that C code snippet before you try to compare oranges to apples again.
    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++.

  12. #27
    (?<!re)tired Mario F.'s Avatar
    Join Date
    May 2006
    Location
    Ireland
    Posts
    8,446
    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.

  13. #28
    Registered User
    Join Date
    Feb 2006
    Posts
    54
    Quote Originally Posted by Mario F. View Post
    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.
    Compile the C code as C++, and you get exactly the same result.

  14. #29
    Dr Dipshi++ mike_g's Avatar
    Join Date
    Oct 2006
    Location
    On me hyperplane
    Posts
    1,218
    Well then doodle77 could always compile this:
    Code:
    #include <stdio.h>
    
    int main() {
      puts("C doesn't");
      return 0;
    }
    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 :P

  15. #30
    (?<!re)tired Mario F.'s Avatar
    Join Date
    May 2006
    Location
    Ireland
    Posts
    8,446
    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.

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. "far"?
    By SgtMuffles in forum C Programming
    Replies: 7
    Last Post: 04-05-2005, 07:08 AM
  2. INI 64kb limit
    By iniguy in forum Windows Programming
    Replies: 1
    Last Post: 02-05-2002, 04:52 PM
  3. Replies: 2
    Last Post: 01-27-2002, 10:40 AM
  4. Memory allocation greater than 64KB in TC 3.0
    By Unregistered in forum C Programming
    Replies: 0
    Last Post: 01-27-2002, 10:28 AM