> 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 >>> 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.