Gennadiy Rozental wrote:
You've been touting multi_index here as well.
Not at all. If you follow my recent concern with multi_index design I actually believe it's lacking.
I read those and was sympathetic to the terminology arguments you made. L?pez Mu?oz believes it is too late to make those sort of changes. I disagree with him on that, but it isn't clear enough yet to me what would be better terminology. I didn't follow the other matter you raised in those posts. Please correct me if I'm wrong, but it seems B.MI's serialization forces you to receive a B.MI instance with the same number of indices as was sent. While on one level it is impressive that B.MI preserves the relative order of equal elements, it has a cost. If you have a B.MI with 3 indices in a server and only need one or two indices in a client, you have some work to do. In order to accomplish this I think you would have to receive a B.MI with the same indices as was sent and then write code that copies the contents of that B.MI to either a simpler B.MI or an STL container. Does the preservation of the relative order of elements matter more than this sort of flexibility? Brian www.webEbenezer.net