On Wed, Jul 3, 2013 at 10:18 PM, Antony Polukhin
I'll just explain what confuses me: * Stripped logger library is bigger than any other Boost library.
So what?
* Logger library contains implementation of call_once, thread local storage, atomics, nonblocking queues... IMO it is not the right place for that functionality. It must be merged with Boost.Thread, Boost.Atomic and other Boost libraries if Boost.Log implementation is better.
Ok, let's see how much space they take. This is what the static debug libs consist of: libboost_log-vc110-mt-gd-1_55.lib: 1 445 620 attribute_name.obj 822 355 attribute_set.obj 894 604 attribute_value_set.obj 706 555 code_conversion.obj 1 859 847 core.obj 3 613 753 date_time_format_parser.obj 555 378 debug_output_backend.obj 570 930 default_attribute_names.obj 1 663 193 default_sink.obj 424 925 dump.obj 420 758 dump_avx2.obj 415 277 dump_ssse3.obj 621 148 event.obj 5 543 958 event_log_backend.obj 2 749 488 exceptions.obj 5 136 624 format_parser.obj 1 646 009 global_logger_storage.obj 1 315 975 light_rw_mutex.obj 988 729 named_scope.obj 5 128 769 named_scope_format_parser.obj 1 713 509 once_block.obj 555 737 process_id.obj 751 919 process_name.obj 1 593 922 record_ostream.obj 1 273 079 severity_level.obj 180 simple_event_log_res.obj 1 969 074 spirit_encoding.obj 3 039 412 syslog_backend.obj 15 313 056 text_file_backend.obj 1 182 865 text_ostream_backend.obj 575 528 threadsafe_queue.obj 1 244 833 thread_id.obj 556 962 thread_specific.obj 764 713 timer.obj 57 159 timestamp.obj 1 207 578 trivial.obj 34 667 unhandled_exception_count.obj libboost_log_setup-vc110-mt-gd-1_55.lib: 84 880 092 default_filter_factory.obj 78 733 860 filter_parser.obj 92 323 500 formatter_parser.obj 39 735 808 init_from_settings.obj 2 109 440 init_from_stream.obj 777 225 parser_utils.obj 54 887 842 settings_parser.obj The components you listed are in once_block.obj, threadsafe_queue.obj, thread_specific.obj. Still think that these are the culprit? I suggest you get slightly more informed next time before you start pointing fingers. BTW, if anyone's interested, I've described the reasoning for implementing some of these components here: https://svn.boost.org/trac/boost/ticket/8730#comment:9 * Non-stripped Boost.Log bloats binary installer *much* more than any other
Boost library.
Although I don't aim to minimize the binary size, that's something I'd like to address, if possible.