Andrei Alexandrescu wrote:
>> I agree that vector (or vector-like substitutes) are preferred over
>> smart_ptr<T[]> in most circumstances. But there are times when
>> ownership of the array needs to be transferred or shared. In those
>> instances, vector is not a good fit. smart_ptr<vector<T> > is a
>> possibility, but this is typically inferior both in performance, and
>> in client level syntax (e.g. (*p)[i] instead of p[i]).
>
> When designing an amenity, it is important to figure out how the
> alternatives work for its target audience. For the limited audience
> that (1) needs a smart pointer to an array and (2) is unhappy with
> vector's performance, I'd say it's ok to just advice using a SmartPtr
> configured
> with an array deleter and have them write get_impl(sp)[45] instead of
> sp[45]. The super-performance-critical code portions of an app are
> not that large and much uglier for different reasons anyway :o).
If an implicit conversion to the pointed-to type is provided, there is no need
to overload the subscript operator:
#include <iostream>
struct sample {
inline operator const char*() const {
return "01234";
}
};
int main() {
sample var;
std::cout << var[0] << var[1] << &std::endl;
return 0;
}
The same applies to the standing problem of operator->*().
2c.
Paul Mensonides
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
