 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
.NET Forum / Languages / Managed C++ / November 2004Problem with std::stable_sort on a std::vector<gcroot<T> >
Has anyone ever tried to sort a Standard Library container of gcroots? I have run into the problem that somewhere deep in the Library logic (in line 338 of <memory>, to be precise) the destructor of a class _Temp_iterator tries to obtain the address of a gcroot, but fails because gcroot::operator& is private.  SignatureGerhard Menzl #dogma int main () Humans may reply by replacing the obviously faked part of my e-mail address with "kapsch". > Has anyone ever tried to sort a Standard Library container of gcroots? > I have run into the problem that somewhere deep in the Library logic > (in line 338 of <memory>, to be precise) the destructor of a class > _Temp_iterator tries to obtain the address of a gcroot, but fails > because gcroot::operator& is private. An object stored in a standard container must be CopyConstructible, which includes having a public operator& returning the address of the object. Bo Persson > An object stored in a standard container must be CopyConstructible, > which includes having a public operator& returning the address of the > object. Thanks for pointing this out. This seems like a major design flaw of gcroot to me. After all, gcroot is described as a way of storing managed objects in Standard Library containers. See http://www.codeproject.com/managedcpp/gcstl.asp?print=true, for example. SignatureGerhard Menzl #dogma int main () Humans may reply by replacing the obviously faked part of my e-mail address with "kapsch". >> An object stored in a standard container must be CopyConstructible, >> which includes having a public operator& returning the address of the [quoted text clipped - 5 lines] > http://www.codeproject.com/managedcpp/gcstl.asp?print=true, for > example. That's interesting. It's sort of a solution that almost works. :-) Guess that is the best you can do under the circumstances. Bo Persson > Has anyone ever tried to sort a Standard Library container of gcroots? I > have run into the problem that somewhere deep in the Library logic (in > line 338 of <memory>, to be precise) the destructor of a class > _Temp_iterator tries to obtain the address of a gcroot, but fails > because gcroot::operator& is private. Although you can easely avoid this restriction I should point out that gcroot isn't as light as pointers. Its copy involves "GCHandle::Alloc" - registration of managed pointer handler. The better way is to have gcroot in some object which is not moved around. -- Vladimir Nesterovsky e-mail: vladimir@nesterovsky-bros.com home: http://www.nesterovsky-bros.com > Although you can easely avoid this restriction I should point out that > gcroot isn't as light as pointers. Its copy involves "GCHandle::Alloc" - > registration of managed pointer handler. The better way is to have gcroot in > some object which is not moved around. I am well aware that there is a lot more going on behind the scenes when copying GCHandles than with pointers, and I don't have a performance problem with it. What I do have a problem with is having to add yet another wrapper whenever I want a Standard Library container of managed types. I also don't see how I could prevent such a wrapper object from being moved around: as soon as it is put into a standard container, it (and the GCHandle it wraps) *will* be copied. The only way to prevent this would be to not using standard containers of managed objects in the first place. Interestingly, std::sort does not exhibit the described problem. SignatureGerhard Menzl #dogma int main () Humans may reply by replacing the obviously faked part of my e-mail address with "kapsch".
Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.