is there any function in ice to save properties?

xiehua

we can use "properties->load("config");" to load properties from file.
but is there any function in ice to save properties into file?

marc

No, no such functions exists. However, you could write one yourself by getting a list of all properties and then saving them.

Kruppy

Saving Properties

Mark, could you please provide a sample code how one can save the list of props from config file in C++ and then reuse them? Is the storage in that case the config file or just txt?

Thanks
Yuri

marc

Sorry, but providing custom sample code is beyond the scope of support we can give here on these forums. Please contact us for commercial support and consulting services at [email protected].

(Please also update your signature, as explained in this thread: http://www.zeroc.com/vbulletin/showthread.php?t=1697)

n2503v

xiehua,

you may want to look at getCommandLineOptions() functions.

see sec. 27.8.3 in the manual. It returns a StringSeq in the form "key=value". These are easy to save into a format from which you can load again later.

alex

acbell

Here's some code

Here is some code that writes our properties. It uses a property to define
which properties get written to the file.

void ConfLog::Server::store(const Ice::Current& cur)
{
  const int MAXLEN = 1000;
  char buf[MAXLEN] = {0};
  int result;
  time_t now;
  struct tm *locTime;
  string newname = _propFilename;
  string prefixes;
  string prefix;
  Ice::PropertiesPtr props;
  Ice::PropertyDict pDict;
  Ice::PropertyDict::iterator i;
//
// Rename exisiting file with current time appended.
//
  now = time(NULL);
  locTime = localtime(&now);
  if (! strftime(buf, MAXLEN, "-%d-%b-%Y:%T", locTime))
    buf[MAXLEN - 1] = '\0';
  newname += buf;
  Cssm::Util::fileRename(_propFilename, newname);
  ofstream out(_propFilename.c_str());
//
// Loop through properties and write those that are of interest to the file.
//
  props = communicator()->getProperties();
  prefixes = props->getProperty("ConfLog.Prefixes");
  istringstream prefixStream(prefixes);
  while (prefixStream) {
    prefixStream >> prefix;
    prefix += ".";
    pDict = props->getPropertiesForPrefix(prefix);
    for (i = pDict.begin(); i != pDict.end(); i++)
      out << i->first << "=" << i->second << "\n";
  }
}

matthew

I recommend this code check the return value of strftime. Don't want a nasty buffer overflow

acbell

Return value from strftime

Hi,

Thanks for pointing this out. I did change the code above to initialize the buffer to zero. I think this should take care of any problem, since the buffer won't overflow (limited by the maxsize argument), but it could be undefined (strftime returns zero).

Really, I can't think of any cases which would cause strftime to fill the buffer with anything other than the number of bytes specified by the format string.

Cheers,

matthew

Its not clear from the manual page on my system what occurs if maxsize is exceeded. Is the character array unchanged? Is maxsize characters put in the array? Is maxsize-1 characters put in the array and the then null terminated? I think to be paranoid I think I'd probably pass N-1 as the max, and NULL terminate the Nth character.

acbell

More strftime

I agree, and have fixed the code accordingly. You don't have to pass maxlen - 1. At least my man page says that maxlen takes the terminating NULL byte into account.

Still, this is pretty much a nit. If strftime returns more characters than are specified by the format string, then it is broken, and you can't do much to protect against broken code. A buffer sized sufficiently large should really make this a non-issue.

Thanks again,

matthew

Ok, as the code stands above now there is no problem.

That being said, not to beat the horse too much, but the problem is that since parts of the strftime format string are locale dependent you don't really know ahead of time (as this code tries to do) how long to make the buffer. For example, perhaps in Hawaiian the month name is some obscenely long thing.

acbell

Locale and strftime

Of course, you are correct. Locale is one of those things that I don't think about much because I know the environment in which my code will run. On the other hand, I'm sure that you guys at ZeroC have to take that kind of thing into account all the time, since you could might be run by anyone, anywhere.

Thanks for all the good feedback.