> On 11 Mar 2018, at 18:29, Frank Heckenbach <f.heckenb...@fh-soft.de> 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
>> 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
It the past double indirection was considered slow, but today it is best to
test the specific application.