STL + MSVC++ = big executables ?

I like to use STL. It's not perfect, but it makes life easier.
Several people said that using cout instead of printf and using several container templates instead of pseudo-generic void* C-style containers wouldn't blow my executables to extraordinary large sizes.
In fact, the /are/ blown, and not just some kb.
I'm not sure about who's blowing them up.
Is this because MSVC doesn't know how to optimize templates or is this a C++ specific problem ?
My executables get usually arround 60k - 80k, althought the're just doing a print that 800 bytes of compiled asm would do.
I also experienced that .NET based applications are a /lot/ smaller than my ones. Even with GDI they are arround 15k.
A friend's writing almost straight C and get's API executables with GDI arround 20-30k.
I actually /did/ learn C++ because i wanted to write templated, class based code without getting my executables auto-blown up.

Are your executables also excessively blown up ? What compilers do you use ? Am I just to blind to find the compiler switch ?

>Are your executables also excessively blown up ?
No.

>What compilers do you use ?
I've used MSVC++ for years and I just switched to Borland C++.

>Am I just to blind to find the compiler switch ?
Be sure to change the optimization settings for size or speed in the project menu.

Also, a few things to note about both C++ and STL in particular. C++ will take up more space because of added features that are used to make your life easier. If you use a great deal of virtual functions then you should expect there to be a space tradeoff. If you create many objects of large classes then you have nothing to complain about. Using templates will increase the size of your binary, as will any RTTI feature. The question to ask is will the size increases be worth using the features? The STL can be misused to cause severe bloat if you have large containers of objects instead of pointers to objects or several containers of derived objects instead of pointers to the base object.

-Prelude

It's probable that using any proprietry classes requires linkage to a whole lot more of them, because such classes will make use of other proprietry classes.

A similiar thing happens in BCB. If I write a pure standard C application, I get tiny executables. The second I invoke something like AnsiString, the whole thing shoots up to around 600KB. Not issue generally, because I accept that Windows applications are going to be larger. It's a compromise, a GUI + useful classes versus executable size. Unless I require ultra small exes, I opt for bigger but more powerful. In any case, 600KB to 1MB exes are considered small in Windows.

With today's harddrives of 50-100 GB and computers with 256-1024 MB RAM, worrying about exe-files of 600 kB is almost stupid.

It could be an issue for the remaining modem users - fewer and fewer for each year - but the size of the exes can be compressed rather efficiently using winzip.

Don´t want to get of the topic but what is GDI mentioned in this tread???

Quote:

---

Originally posted by ripper079
Don´t want to get of the topic but what is GDI mentioned in this tread???

---

Graphics Device Interface. Its a subset of the windows API that's responsible for painting windows and everything else to screen

Oh...and I agree with SangDrax - The size difference in not much of an issue these days IMO

Thanks for your replies.

I'm really desillusionated a bit. I thought templates didn't cause runtime overhead. Also i thought classes where at no cost.
I knew only that virtual functions do cause speed penalties every call and size penalties for building the virtual function tables.
They allways say that it's as efficient as C in books and on several sites...

Maybe you're right that size and speed doesn't matter that much in this times.

But i must admit that i didn't go through assembler school, so i can't really estimate what size my executables must be. However, as i write only small applications, I would consider 600k executables to be by far to big for me.