Re: CMap - can it do this?
"Doug Harrison [MVP]" <dsh@mvps.org> wrote in message
news:ie4p44t376bs2nn4l6ut0rh50s211hmjkt@4ax.com...
Presumably, a container is inherently thread-safe for read-only access.
(It's de facto standard for the C++ Standard Library.) For example, you
might want to populate a map, create some threads, and have those threads
perform lookups without using synchronization. If caching the last key and
value means copying them, there is obviously a problem with thread safety
for read-only access.
Yes, I had not known that collections were by convention thread-safe for
read-only access.
The solution is for CMap to use an internal mutex
around operations on these cached objects, which I think you'd agree is
undesirable.
I would think a critical section (more lightweight than mutex) would be
enough, since only one process is involved. Or caching would need to be
done on a per thread basis, say in TLS; both of which are probably more than
it's worth.
Also, there would be coherency problems between the cached and
actual values due to the user modifying the actual value, and that's true
even in the absence of multithreading.
This could be fixed by invalidating the cache when the collection is written
to.
Large key and/or value objects could
grow the map object considerably. A straightforward implementation would
impose a default constructor requirement for both key and value classes.
If
you mean to cache pointers to the key and value, then that's not much
different than caching a POSITION.
I don't exactly know what a POSITION is, except a handle to a key/value
pair. How much computation it takes to convert that to an actual key/value
pair is hidden, so it might be a lot, and might not be.
I explained why I don't think that would
be worth doing in my last message and how providing the right
functionality
makes it superfluous.
I think you limited your comments to RemoveKey(POSITION), and I was trying
to expand to remove RemoveKey() from the equation, since that's not the only
thing you might want to do with a POSITION.
Anyway, the inherent thread safety for read only access probably is why
caching is not done. I suppose I'll have to use the returned value in the
iteration to save some cycles, if that's important, rather than writing
cleaner code to lookup the iterated key.
Thanks,
David