Re: [Mingw-users] Re: Binaries size / GNU STL Evil?

[Oscar F. <of...@wa...>]

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