On 2/20/04 7:39 AM, "Christian Engström" <christian.engstrom@glindra.org> wrote:
Is the following design valid, and if so, would it make a useful addition to the Boost library? I enclose a draft implementation, and look forward to any comments.
1. I think that someone else has already been working on something like this. (It should be in our YahooGroups files area.) 2. I think that person has done all the containers. (I'm not sure.) More importantly, the other submission is a _lot_ bigger, probably because s/he has thought through more of the issues (or maybe it's over-engineered). 3. I don't remember how the other guy did his/her implementation, but I have a hint anyway. If you're doing an indirect container that elements act like a smart-pointer, that doesn't actually mean that you should actually use a vector< smart_ptr<T> >. I think you should use something like a vector<T *> and handle the smartness yourself to save memory. 4. I know you have an issue with someone else on this list over your iterator/dereferencing policy, but I have an issue with it besides standard compliance. It's not consistent. The "->" gives the final object directly, but the "*" and "[]" only go one step and return a proxy. I don't like this mix. You claim that the directness is not needed for the latter two operators because proxy<T> takes assignments from T and converts to T. If so, then what is the point of using the proxy directly? Can I ever have an use for a "proxy<T>" object as itself? If not, then I don't need to be forced to deal with it and you should change "*" and "[]" to also return T& directly. (Your "proxy<T>" <-> T conversion policy could fail in some template contexts.) -- Daryle Walker Mac, Internet, and Video Game Junkie darylew AT hotmail DOT com