64kb

This is a discussion on 64kb within the A Brief History of Cprogramming.com forums, part of the Community Boards category; MinGW is a good (an excellent, actually) compiler / toolchain and I recommend using it with the Code::Blocks IDE (MinGW ...

  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
    Registered User
    Join Date
    Oct 2001
    Posts
    2,129

  3. #18
    Malum in se abachler's Avatar
    Join Date
    Apr 2007
    Posts
    3,189
    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.
    Until you can build a working general purpose reprogrammable computer out of basic components from radio shack, you are not fit to call yourself a programmer in my presence. This is cwhizard, signing off.

  4. #19
    Captain Crash brewbuck's Avatar
    Join Date
    Mar 2007
    Location
    Portland, OR
    Posts
    7,237
    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;
    }
    Name:  stladdsbloat.png
Views: 215
Size:  1.9 KB
    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,068
    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;
    }
    Name:  stladdsbloat.png
Views: 215
Size:  1.9 KB
    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
    Captain Crash brewbuck's Avatar
    Join Date
    Mar 2007
    Location
    Portland, OR
    Posts
    7,237
    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;
    }
    Name:  no-u.png
Views: 104
Size:  2.0 KB

    It's less, but still. 58kb stripped.
    Code:
    #include <stdio.h>
    
    int main() {
      puts("C doesn't");
      return 0;
    }
    Name:  cdoesnt.png
Views: 102
Size:  1.7 KB
    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
    Portugal
    Posts
    7,412
    uh? Try instead adding vector and string functionality to that C code snippet before you try to compare oranges to apples again.
    The programmer’s wife tells him: “Run to the store and pick up a loaf of bread. If they have eggs, get a dozen.”
    The programmer comes home with 12 loaves of bread.


    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
    Portugal
    Posts
    7,412
    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.
    The programmer’s wife tells him: “Run to the store and pick up a loaf of bread. If they have eggs, get a dozen.”
    The programmer comes home with 12 loaves of bread.


    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
    Portugal
    Posts
    7,412
    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.
    The programmer’s wife tells him: “Run to the store and pick up a loaf of bread. If they have eggs, get a dozen.”
    The programmer comes home with 12 loaves of bread.


    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.

Page 2 of 4 FirstFirst 1234 LastLast
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, 03:52 PM
  3. Replies: 2
    Last Post: 01-27-2002, 09: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, 09:28 AM

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21