4 ms·
> It's four goddamn bytes. Or eight if you really want more than 4 billion elements. As long as you don't have millions of lists with a few elements each -- yo
by apaprocki 13y ago
> It's four goddamn bytes. Or eight if you really want more than 4 billion elements.
As long as you don't have millions of lists with a few elements each -- you can't presume that they are only used one way :)
- angersock 13y agoNo, really, it's quite a safe assumption. Hell, you probably lose that much to padding somewhere anyways.
- Someone 13y agoAccording to http://www.cplusplus.com/reference/list/list/size/ http://www.cplusplus.com/reference/list/list/size/, list::size must be constant time in C++11. That may make 'splice' slower. See http://home.roadrunner.com/~hinnant/On_list_size.html http://home.roadrunner.com/~hinnant/On_list_size.html (I think that could be solved by having list iterators carry a field pointing to their container, but haven't given it much thought. Corrections welcome)
- deleted 13y ago[deleted]
- TwistedWave 13y agoHaving list iterators carry a field pointing to their container wouldn't help you determine the number of objects between two iterators when you splice, which is what you need in order to maintain the object count. Storing an index in the iterator would not be a solution either. That would mean updating the index in all the existing iterators when you insert an object in the list.
- Someone 13y agoOf course. Thanks.
- sharth 13y agoIt changes the ABI of std::list, which is a serious concern.
- snogglethorpe 13y ago... and figuring out how to deal with that is the reason that libstdc++ is moving slowly on this. libc++ has the luxury of assuming c++11.
- vinkelhake 13y agoThen you might be better off with a std::forward_list which is typically the size of a pointer.