64kb

[brewbuck]

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 comparison between C and C++ equivalents of the same task is very relevant, because there is a lot of shared runtime between C and C++. In other words:

code_size(C) = implementation(C) + runtime;
code_size(C++) = implementation(C++) + runtime;

In order to figure out how big "runtime" is, you have to try it both ways. Once you have this figure, you have to subtract it out, before making any statements about the code size induced by STL.

Try linking this statically (it's C, not C++):

int main()
{
    printf("Hello, world!\n");
    return 0;
}

On my system, the resulting binary is over 500k in size. So just because the C++ version is large doesn't necessarily mean anything at all. C can be bloated, too. The problem is not the language itself, but the toolchain.

[Mario F.]

Excellent brewbuck. But only as a means to an end.

The original argument was about not using the STL to produce smaller code. Which basically means the option to use STL is there.

As such, C is irrelevant to this discussion in the way it was being presented. Particularly the whole STL-Bloats-Code versus C-Doesn't.

[brewbuck]

As such, C is irrelevant to this discussion in the way it was being presented. Particularly the whole STL-Bloats-Code versus C-Doesn't.

I'm using C as a means of discovering the value of a particular variable in the equation. I am not at all trying to compare C vs. C++.

My point is that you cannot use the size of a statically linked binary as proof that STL produces code bloat, when a simple C program that prints "Hello world" is also linking statically to 500k. By that logic, basic C is bloated, and I hope everybody would agree that that's untrue.

It indicates something about static linking, and the complexity of modern runtime libraries, it says nothing about the code size of STL.

[manav]

do not divert the original discussion!

Earlier softwares were smaller, simply because they had less features, were less powerful.

[matsp]

do not divert the original discussion!

Earlier softwares were smaller, simply because they had less features, were less powerful.

And because they had to support less hardware variants - perhaps you had to do the "if (colourDisplay) base = mkptr(0xA000, 0x0000); else base = mkptr(0xB800, 0x0000)", but that's about it when it came to "support variations of hardware".

--
Mats

[Mario F.]

do not divert the original discussion!

Earlier softwares were smaller, simply because they had less features, were less powerful.

The original discussion is still being... discussed. Abachler argument and the discussion that followed was pertinent. Your own answer adds nothing new as what you said is only repetition of what has been said before.

I'm using C as a means of discovering the value of a particular variable in the equation. I am not at all trying to compare C vs. C++.

I understood that brewbuck. And I appreciated your thoughts on that. It was what was being said before that made my ears perk; that is, the not so subtle innuendo behind stladdsbloat.exe and cdoesnt.exe

[manav]

Can someone tell me why on very old timers computers ha, a programmer could write up some code and it would be so small compared today. 500kb?

Because old time softwares were having less features and were less powerful!

That was the correct answer, so, if I repeated or not, matters less.

The original discussion is still being... discussed. Abachler argument and the discussion that followed was pertinent. Your own answer adds nothing new as what you said is only repetition of what has been said before.

But later discussions try to prove, if new software is pure bloat or not! If C is better or C++? Who is doing more bloat?

By the way no body is forcing to use boost library just to use a to upper case function, you can build your own. Older days it was done like 'a' ^= 32.
But now, with all the unicode and other stuff, makes it bigger, yet better and more powerful.

That's the basic difference between old and new!

[mike_g]

By the way no body is forcing to use boost library just to use a to upper case function, you can build your own. Older days it was done like 'a' ^= 32

Actually that will switch the case; nt convert to upper case. it will also only work on ASCII encoding, on an encoding that uses the 32 bit to signify the case.

[brewbuck]

But later discussions try to prove, if new software is pure bloat or not! If C is better or C++? Who is doing more bloat?

No, that's not what was being discussed. The comparison with C was for the purposes of factoring out "common bloat" inherent to ALL compiled programs, not just C++.

If you went to a country where every citizen weighed over 500 pounds, it would be weird to point at a particular person and say "That guy's fat!" They're ALL fat.

A better gauge of code size is the size of the object files, not the final, linked binary. You can't blame the runtime for introducing a ton of code when you choose to link statically -- that's why people don't link statically anymore.

[abachler]

He means this:

#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.

I mean when I write 3000 lines of code it compiles to 150kb. I know a lot of my preferences and suggestions cause a lot of eye rolling, but I get the results and the performance. So what if it takes me 3 weeks to impliment something another programmer can do in 2 days, my code runs 10 times faster than hers and makes some projects feasable that otherwise wouldnt be. You use cout, bam code bloat, because the lib just impliments cout using printf. You use string instead of BYTE*, bam code bloat, because the compiler adds all the functions that you dont use. You use MFC, bam code bloat because etc etc etc. Each little thing might only add 20kb here and there, but it adds up.

[AcerN30]

Any chance of a 10KB program?

[SlyMaelstrom]

Any chance of a 10KB program?

Write something in assembler?

It's also worth it to mention that 64Kb (kilobit) is smaller than 10KB (kilobyte). Watch your cases.

This has been mentioned before, but to give you an idea of how small modern programs can get... here is a 98KB 3D FPS that is completely procedural.

http://www.vgpro.com/file/18896_kkrieger-beta.zip.html

I mention this also because I love this 2006 quote.

Needs high end user PC to play. Minimum specs are: 128MB graphics Card with pixel shader 1.3, 512MB ram, and Athlon 1.5Ghz

[AcerN30]

This might sound funny, but what exactly is the Assembler?

I was thinking a very basic game with no levels or something like that.

[abachler]

Any chance of a 10KB program?

smallest program I ever wrote was 12 bytes. It changed the file attributes on a file using a dos INT21h call. It even had keyboard input to select the attribute mask.

This might sound funny, but what exactly is the Assembler?
I was thinking a very basic game with no levels or something like that.

Assembly language tool used to write directly in assembly and/or compile assembly. VS includes an inline assembler. Lets you write directly in processor dependant mnemonics. Requires low level knowledge of the processor itself.

[mike_g]

You dont have to use assembler to create programs < 10k if you dynamically link your libraries like brewbuck said. Theres a load of 4k graphics progs here. Quite a few are done in C. ASM can go really small, some of the 256 byte stuff on there is really impressive. Stuff that drops below that, well, generally cant do much really.