$include_dir="/home/hyper-archives/boost/include"; include("$include_dir/msg-header.inc") ?>
Subject: Re: [boost] c++03 library survey
From: Robert Ramey (ramey_at_[hidden])
Date: 2018-08-28 20:07:12
On 8/28/18 10:21 AM, degski via Boost wrote:
> On Tue, 28 Aug 2018 at 19:06, Robert Ramey via Boost <boost_at_[hidden]>
> wrote:
> 
>> Actually, I think the the impact of move semantics on performance of
>> well written existing code is minimal.  On new code which uses more
>> types as values it's helpful.
>>
> 
> I don't think it has anything to do with whether the code is well written,
> copying a pointer f.e. is not the same as copying a whole array of data,
> because that could [should be] be the difference between move assignment
> and copy assignment.
right.  One who is thinking about what he's doing is not going to copy a 
whole array of data if he's using C++03.  But since C++11 makes it 
efficient, he may.  So compiling C++03 code with a C++11 compiler isn't 
going to make a difference.
> 
> Of course if the library were written today, it would all the new stuff.
>>    I don't think it would be faster (unless it were made header only) but
>> it would likely have have half the number of lines of code (or less).
>>
> 
> Header only is of no interest, whatsoever, in terms of performance, that's
> not how things work (inlining could be affected, but that's about it, I
> would say)
LOL - inlining IS the essential difference with a header only library. 
It would eliminate one move in the serialization libary.  And that would 
double the speed.  This is why a C++11 serialization library (cereal) is 
twice as fast as boost serialization and other libraries.
>> But the years long slog to address corner cases, workarounds for
>> compiler bugs and standard library bugs, etc. And there would be design
>> changes which would also create a bunch of ripple effects. So it would
>> really end up as a whole re-write.
>>
> 
> Yes, it's a major job, hence all the resentment.
It's not just resentment - there's just no benefit to it.
> 
> degski
>