View Single Post
  #1 (permalink)  
Old 07-21-2003
sylvain sylvain is offline
Registered User
 
Name: Sylvain Fasel
Organization: university of Geneva
Project: quantum cryptographic systems
 
Join Date: Feb 2003
Location: Geneva (Switzerland)
Posts: 42
about Freeze::Map::iterator

Hi!

I am beginning to write an academic application using Freeze and I find that Ice in general is absolutely amazing.

But I have one more question anyway about Freeze::Map.

Suppose I have for eg. string for key and StringSeq for value (with a lot of String in the StringSeq). If I want to read a particular key-value pair in the db, add a string in the StringSeq then write it back, I have to do the following:

MyMap::iterator p=mymap.find("this one");

if(p != mymap.end())
{
StringSeq ss = p->second; //at lot of copy occure here
ss.push_back("one more string");
p.set(ss);
}

That is the best I can do, right? My problem is that,
at "ss=p->second" the whole StringSeq will be copied from the internal value of the iterator to my "ss", and this can be very "long".

As I suppose you have a very good reason to use this scheme where the iterator type return a pair of const object, I would like to understand why you didn't choose for example the following approach:
- a iterator type that return a non-const reference to the "value" of the internal key-value pair object.
- a function like "validate_changes()" instead of the "set" that in fact internaly call set() with the internal value as parameter.

This way the above code should be:

MyMap::iterator p=mymap.find("this one");

if(p != mymap.end())
{
p->second.push_back("one more string");
p.validate_changes(); //the internal modified value is flushed to database
}

Of course, the state of the internal value object is changed before its db counterpart, so there is a lack of synchronisation before the call to validate_changes(), and if there is an exception somewhere during the modifying process the iterator will be left in a "dirty" non-synchronized state. Is that the reason for your choice? It seems to me that is some cases this would be less problematic than a lot of copies (for example in a case where the exception is caught a little bit outside the scope where the iterator is constructed, it will be destroyed anyway, so its value is of no relevance).

In fact I can make the changes in the source for my personal use, but I would like to know what you think about it, because I am pretty sure that there is some problems that I didn't think about.

Thanks a lot for your answer (and for the others you already gave to me).
Reply With Quote