Re: C++11 move semantics

[Hans Åberg]

> On 11 Mar 2018, at 18:29, Frank Heckenbach <address@hidden> wrote:
> 
> Hans Åberg wrote:
> 
>> In old computers, such a limit might have been seen as necessary.
> 
> I don't think so. I think I was due to the implementation in C where
> dynamic data structures are much more effort to write. Otherwise
> it's better to let the programs use as much memory as they can (by
> system limits, ulimit, etc.) and not impose arbitrary limits.

But the C parser has had dynamic allocations up to the limit as far as I 
recall, the 1990s. And there are POSIX specs for YACC.

>>>       vector  deque
>>> %left   7.7s    7.9s
>>> %right  8.9s    9.5s
>>> 
>>> So go ahead and use deque if you prefer, but now I'm even less
>>> convinced it's worth it. :)
>> 
>> It is a good chance it varies with the application.
> 
> Maybe if you use an unreasably large type for a semantic value, or a
> type that has an expensive copy constructor and no move constructor.
> Both are like "don't do that" kind of things, but if you really need
> to, as I said you'll be able to use deque.

It best is to time in the specific application , if one thinks it is critical.

>>> In fact that's interesting to me outside of Bison. In another
>>> program I wrote in a different language long time ago which doesn't
>>> use Bison, I had implemented a double indirect allocation much like
>>> deque.
>> 
>> Called handles. They may be required if objects pointed to need to move, as 
>> in a two space copy gc.
> 
> I know what handles are. Handle use double indirection, but not all
> double indirection means handles. Deque needs double indirection to
> go to the block, then to the item, whereas vector can go to the item
> directly.

It the past double indirection was considered slow, but today it is best to 
test the specific application.