Problem with std::stable_sor t on a std::vector<gcr oot<T> >

[Gerhard Menzl]

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::operato r& is private.

--
Gerhard Menzl

#dogma int main ()

Humans may reply by replacing the obviously faked part of my e-mail
address with "kapsch".

[Bo Persson]

"Gerhard Menzl" <ge***********@ spambucket.net> skrev i meddelandet
news:41******** @news.kapsch.co .at...

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::operato r& is private.

An object stored in a standard container must be CopyConstructib le,
which includes having a public operator& returning the address of the
object.
Bo Persson

[Vladimir Nesterovsky]

> 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::operato r& 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::Allo c" -
registration of managed pointer handler. The better way is to have gcroot in
some object which is not moved around.
--
Vladimir Nesterovsky
e-mail: vl******@nester ovsky-bros.com
home: http://www.nesterovsky-bros.com

[Gerhard Menzl]

Vladimir Nesterovsky wrote:

Although you can easely avoid this restriction I should point out that
gcroot isn't as light as pointers. Its copy involves "GCHandle::Allo c" -
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.

--
Gerhard Menzl

#dogma int main ()

Humans may reply by replacing the obviously faked part of my e-mail
address with "kapsch".

[Gerhard Menzl]

Bo Persson wrote:

An object stored in a standard container must be CopyConstructib le,
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/managedcp...asp?print=true, for example.

--
Gerhard Menzl

#dogma int main ()

Humans may reply by replacing the obviously faked part of my e-mail
address with "kapsch".

[Bo Persson]

"Gerhard Menzl" <ge***********@ spambucket.net> skrev i meddelandet
news:41******** @news.kapsch.co .at...

Bo Persson wrote:

An object stored in a standard container must be CopyConstructib le,
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/managedcp...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