Archived

This forum has been archived. Please start a new discussion on GitHub.

is there any function in ice to save properties?

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

Comments

  • No, no such functions exists. However, you could write one yourself by getting a list of all properties and then saving them.
  • 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
  • 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 info@zeroc.com.

    (Please also update your signature, as explained in this thread: http://www.zeroc.com/vbulletin/showthread.php?t=1697)
  • 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
  • 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
    matthew NL, Canada
    I recommend this code check the return value of strftime. Don't want a nasty buffer overflow :)
  • 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
    matthew NL, Canada
    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.
  • 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
    matthew NL, Canada
    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.
  • 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.