Hi
So David and Stephan recommended that I make the accessor methods to
o3tl::sorted_vector const in order to prevent clients from invalidating
the sorted-ness of it.
This works out fine when I'm storing pointers to something in the
sorted_vector like this:
struct SomeStruct {
int xxx;
}
o3tl::sorted_vector<SomeStruct*> var1;
var1[0]->xxx = 12;
Which is because thanks to C++'s typing rules, const-ness does not
propogate with a pointer.
However, if I do this:
o3tl::sorted_vector<SomeStruct> var1;
var1[0].xxx = 12; // <--- error! reference is const!!!
And, in fact, if I store any value class directly into
o3tl::sorted_vector, it becomes pretty much useless, because I can't get
anything out of it afterwards without casting away the const-ness.
What is the "correct C++ idiom" here?
Should I create a separate container types here?
And if so, what would be a good names to distinguish between the "sorted
vector for pointers to values" and the "sorted vector for values" ?
I don't want to use sorted_ptr_vector, because that sounds too much like
a boost::ptr_vector, and might confuse people as to the ownership
semantics of this thing.
Thanks, Noel Grandin
Disclaimer: http://www.peralex.com/disclaimer.html
Context
- sorted_vector, constness, pointers, and structs · Noel Grandin
Privacy Policy |
Impressum (Legal Info) |
Copyright information: Unless otherwise specified, all text and images
on this website are licensed under the
Creative Commons Attribution-Share Alike 3.0 License.
This does not include the source code of LibreOffice, which is
licensed under the Mozilla Public License (
MPLv2).
"LibreOffice" and "The Document Foundation" are
registered trademarks of their corresponding registered owners or are
in actual use as trademarks in one or more countries. Their respective
logos and icons are also subject to international copyright laws. Use
thereof is explained in our
trademark policy.