|
From: Oscar F. <of...@wa...> - 2003-06-27 16:27:27
|
Danny Smith <dan...@cl...> writes:
> ----- Original Message -----
> From: "Wu Yongwei" <ad...@ne...>
> To: <min...@li...>
> Sent: Friday, 27 June 2003 03:23
> Subject: [Mingw-users] Re: Binaries size / GNU STL Evil?
>
>
>> Danny, I wonder is it possible that you make a local patch to separate
>> __throw_ios_failure? I am afraid FSF will not accept such kind of
>> patch. After all, it is a non-issue on Linux, since generally dynamic
>> linking is used. (However, if one uses static linking, the resulting
>> executable under GCC 3.2 is even more bulky: 830340 bytes using only
>> vector and 426188 bytes using also Luke's local __throw_bad_alloc.
>> Before stripping, the former size is a surprising 3713993. Frankly
>> speaking, I think it is bad design. I really like SGI STL and STLport
>> better. -- I suppose they won't care the size problem on Windows.)
>>
>> Though, it is not that important to me. Just an opinion, if you think
>> it does not cost much trouble.
>>
>> Best regards,
>>
>
> It's not important to me either.
>
> With gcc 3.3, this testcase
>
> // bloat.cc
> #include <vector>
> int main()
> {
> std::vector<int> v;
> return 0;
> }
> compiled with
> g++ -s -O2 -o bloat.exe bloat.cc
> using static libstdc++
> gives an executable of about 5kb. Much of that is startup code. So I
> don't see much room for size improvement.
I don't have gcc 3.3 MinGW, but your test case on NetBSD shows that
the compiler knows that 'v' is not used and it is ignored on code
generation, so no libstdc++ is used at all.
A more realistic test is this:
#include <vector>
#include <stdio.h>
int main()
{
std::vector<int> v;
v.push_back(10);
printf("%d\n", v[0]);
return 0;
}
[snip]
--
Oscar
|