On 2020/04/24 13:15:10, dak wrote: > mailto:hanw...@gmail.com writes: > > > Here is how I have experienced this discussion: > > > > DAK: this is micro-optimization that causes memory fragmentation. > > > > HW: No, it's not; here is a benchmark that shows decreased memory use as > > well. > > > > DAK: We could use even different data structures in the future. > > > > HW: This seems very philosophical to me. > > It is interesting that you call it "philosophical" to want to change > data structures while getting a patch of yours reviewed that wants to > change data structures. In particular after I indicated that I even > have code. > > Why is it "philosophical" when someone other than you does it? > > > Maybe I misunderstood, because the hardcoding of a specific STL > > container type predates this patch. > > Changing the used container type would be a reasonable point of time for > changing the hardcoding, particularly since it facilitates comparisons. > Also C++11 makes this considerably less awkward than previously, and > code written with lists in mind tends to require less adaptation to use > via vectors than the other way round, anyway.
At any rate, this is not "philosophical" really. The kind of action done here is also provided by C++' container adaptor std::queue which can be based off std::list as well as std::deque where the latter is a compromise in storage use and locality between vectors and lists and would well worth be checking out as well. Hard-coding to one particular container type makes this a lot more expensive and does not allow revisiting the decision for later versions of compiler/library or actually entirely different compilers. https://codereview.appspot.com/583750043/
