July 2007 - Boost-users - lists.boost.org

Question about from_time_t implementation
by Gerardo Lamastra 18 Jul '07

18 Jul '07

Hello everybody, I've seen that boost::posix_time supports a conversion function time_t from_time_t(ptime t) I've also seen on the mailing list, that something related to this issue has already been discussed. However, I've not found enough information (browsing ML and bug support) to understand if this issue is considered closed, or if anyone has never run into similar problems: We're using this function, and a counterpart ptime to_time_t(time_t) function because our application interacts with a MySQL db where date information is stored as unix timestamp. While processing the data, we run in a problem (I won't say 'bug') because MySQL and boost give different meaning to unix timestamp. For example, timestamp 1184795149 is 2007-Jul-18 23:45:49 (local time) for MySQL and it is 2007-Jul-18 21:45:49 (local time) for boost. The correct value is the first one. My current timezone offset is 2 hours, so you can see that we are missing UTC here. Checking the code, I've seen that the function basically converts by adding the number of second to 1/1/1970 0:0:0; however, it should be 1/1/1970 0:0:0 UTC, which is not. Jeff Garland touches this issue in this post: http://aspn.activestate.com/ASPN/Mail/Message/1758411 where he encourages C++ developer to move away from the time_t interface; however, often, for legacy reason, this may not be possible (as in our application). In order to comply with other implementation, we suggest to modify the function as follows: // The Boost Actual Implementation ptime boost_from_time_t(std::time_t t) { ptime start(boost::gregorian::date(1970,1,1)); return start + seconds(static_cast<long>(t)); } // Our 'old' function, written to match the previous one time_t boost_to_time_t(ptime t) { static const ptime THE_EPOCH(boost::gregorian::date(1970,1,1)); return time_period(THE_EPOCH, t).length().total_seconds(); } // The implementations that takes into account UTC ptime my_from_time_t(std::time_t t) { static const time_duration OFFSET = second_clock::local_time() - second_clock::universal_time(); static const ptime THE_EPOCH(boost::gregorian::date(1970,1,1), OFFSET); return THE_EPOCH + seconds(static_cast<long>(t)); } time_t my_to_time_t(ptime t) { static const time_duration OFFSET = second_clock::local_time() - second_clock::universal_time(); static const ptime THE_EPOCH(boost::gregorian::date(1970,1,1), OFFSET); return time_period(THE_EPOCH, t).length().total_seconds(); } That's all. Thanks a lot for any response. -Gerardo -------------------------------------------------------------------- CONFIDENTIALITY NOTICE This message and its attachments are addressed solely to the persons above and may contain confidential information. If you have received the message in error, be informed that any use of the content hereof is prohibited. Please return it immediately to the sender and delete the message. Should you have any questions, please contact us by replying to webmaster(a)telecomitalia.it. Thank you www.telecomitalia.it --------------------------------------------------------------------

1 0

Question about from_time_t implementation
by Gerardo Lamastra 18 Jul '07

18 Jul '07

Hello everybody, I've seen that boost::posix_time supports a conversion function time_t from_time_t(ptime t) I've also seen on the mailing list, that something related to this issue has already been discussed. However, I've not found enough information (browsing ML and bug support) to understand if this issue is considered closed, or if anyone has never run into similar problems: We're using this function, and a counterpart ptime to_time_t(time_t) function because our application interacts with a MySQL db where date information is stored as unix timestamp. While processing the data, we run in a problem (I won't say 'bug') because MySQL and boost give different meaning to unix timestamp. For example, timestamp 1184795149 is 2007-Jul-18 23:45:49 (local time) for MySQL and it is 2007-Jul-18 21:45:49 (local time) for boost. The correct value is the first one. My current timezone offset is 2 hours, so you can see that we are missing UTC here. Checking the code, I've seen that the function basically converts by adding the number of second to 1/1/1970 0:0:0; however, it should be 1/1/1970 0:0:0 UTC, which is not. Jeff Garland touches this issue in this post: http://aspn.activestate.com/ASPN/Mail/Message/1758411 where he encourages C++ developer to move away from the time_t interface; however, often, for legacy reason, this may not be possible (as in our application). In order to comply with other implementation, we suggest to modify the function as follows: // The Boost Actual Implementation ptime boost_from_time_t(std::time_t t) { ptime start(boost::gregorian::date(1970,1,1)); return start + seconds(static_cast<long>(t)); } // Our 'old' function, written to match the previous one time_t boost_to_time_t(ptime t) { static const ptime THE_EPOCH(boost::gregorian::date(1970,1,1)); return time_period(THE_EPOCH, t).length().total_seconds(); } // The implementations that takes into account UTC ptime my_from_time_t(std::time_t t) { static const time_duration OFFSET = second_clock::local_time() - second_clock::universal_time(); static const ptime THE_EPOCH(boost::gregorian::date(1970,1,1), OFFSET); return THE_EPOCH + seconds(static_cast<long>(t)); } time_t my_to_time_t(ptime t) { static const time_duration OFFSET = second_clock::local_time() - second_clock::universal_time(); static const ptime THE_EPOCH(boost::gregorian::date(1970,1,1), OFFSET); return time_period(THE_EPOCH, t).length().total_seconds(); } That's all. Thanks a lot for any response. -Gerardo -------------------------------------------------------------------- CONFIDENTIALITY NOTICE This message and its attachments are addressed solely to the persons above and may contain confidential information. If you have received the message in error, be informed that any use of the content hereof is prohibited. Please return it immediately to the sender and delete the message. Should you have any questions, please contact us by replying to webmaster(a)telecomitalia.it. Thank you www.telecomitalia.it --------------------------------------------------------------------

1 0

[multi_index][ann][rfc] Preview of Boost.MultiIndex 1.35 release
by Joaquín Mª López Muñoz 18 Jul '07

18 Jul '07

Hello, I've uploaded a preview version of Boost.MultiIndex as planned for shipping with Boost 1.35 --I don't think there'll be time to include more major features. Download at the Vault: http://www.boost-consulting.com/vault/index.php?&direction=0&order=&directo… (file multi_index.zip) You can try the preview with Boost 1.34.x; if you want to test the newly added interoperability with Boost.Interprocess, you'll have to use a snapshot of Boost CVS, where this library currently lies. The new important features: * New global_fun predefined key extractor. * Added iterator_to facility. * Included support for non-standard allocators such as those of Boost.Interprocess, which makes multi_index_containers placeable in shared memory. Don't miss example #12 at the examples section, which fully exercises this new capacity. * New versions of modify and modify_key with rollback, as described in the tutorial. * Indices provide the new cbegin, cend and, when applicable, crbegin and crend member functions, in accordance with the latest drafts of the next revision of the C++ standard. A longer list of changes can be consulted at the release notes page. I'd be extremely grateful if you can try this preview version and report any problems you find. As we're still in time to discuss the new features, do not hesitate to comment on these and bring forward your proposals for improvement. Thank you very much for your interest in Boost.MultiIndex, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

1 0

Problem linking Boost Signals 1.34.0
by Craig Sanders 18 Jul '07

18 Jul '07

3 2

BGL: filtering (newbee)
by Line B. Reinhardt 18 Jul '07

18 Jul '07

Hi I have a question about graph filtering. My problem is that I would like to filter all edges from a graph g with weight less than 0.01 and all vertices which only has out edges with a weight less than 0.01 The filtering of the edges is show in the documentation. However I have problems with filtering the vertices. Can anyone help? Thanks Line

2 1

Is CountDown avaliable in Boost thread library.
by soi＠swordfish.com.au 18 Jul '07

18 Jul '07

Hi, This is my first time to use thread's boost library. I am looking for a CountDown or similar class which allows a caller to wait until all calling threads are completed. Are there similar feature in Boost's thread library. Many Thanks, Soi

2 1

Why intrusive_ptr destructor can throw exceptions?
by Pavel Syomin 18 Jul '07

18 Jul '07

Hello! I found another difference between shared_ptr and intrusive_ptr behavior: * shared_ptr destructor never throw exceptions; * intrusive_ptr destructor can throw exceptions. In my opinion, ~intrusive_ptr() should not throw exceptions too, because current behavior is much complicated and fraught with memory leak bugs.

2 1

[program_options]: Unicode option name and description
by Niko Vuokko 18 Jul '07

18 Jul '07

I understand how to make option values unicode, but don't know how to make something like generic->add_options() (L"ärrä,ä", L"ä option") ; work correctly. Looking at the headers it looks like this is impossible, because operator() is not a template<charT> class as many others. Another thing: How can I make the default argument not to show in the options_description printing and change the "arg" argument placeholder? Right now ("dir,d", po::value<string>()->default_value("."), "dirDesc") prints out cout << *opts; -> ... -d [--dir] arg(=.) dirDesc ... I would like to just write -d [--dir] path dirDesc The module tutorial tells (Multiple sources example) of the possibility to get --optimization n : optimization level -I [ --include-path ] path : include path where path is written instead of arg, n instead of arg, and the default value 10 is not printed, but compiling the code and testing it gives out --optimization arg (=10) optimization level -I [ --include-path ] arg include path What's wrong? I have boost-1.34.0. niko

1 0

problem porting code using spirit parser to v1.34.0
by Pearson, Andrew 18 Jul '07

18 Jul '07

Hi, I'm having trouble porting some code to use v1.34.0 of boost. We are using the spirit parser and have found that strings containing trailing white space are not parsed as before. The following code is a simple example of the problem. This code works with boost 1.33.1 but not 1.34.0. Can anyone help explain why the code no longer works and what we should do to fix the problem? Regards, Andy #include <string> #include <iostream> #include <boost/spirit/core.hpp> using namespace std; using namespace boost::spirit; bool parseStr(const string& str) { return parse(str.c_str(), real_p >> *(',' >> real_p), space_p).full; } int main(int argc, _TCHAR* argv[]) { string s1 = "1,2,3,4,5"; string s2 = "1,2,3,4,5 "; cout << "parsing: '" << s1 << "' : " << (parseStr(s1) ? "OK" : "ERROR") << endl; cout << "parsing: '" << s2 << "' : " << (parseStr(s2) ? "OK" : "ERROR") << endl; return 0; }

2 1

Problems with Cygwin/g++ and boost::spirit
by Patrick Gräbel 18 Jul '07

18 Jul '07

I am using Cygwin's g++ 3.4.4 and the official Cygwin Boost package version 1.33.1. This minimal programm using namespace boost::spirit; rule< > r; r = real_p; bool b = parse(inp.c_str(),r,space_p).full; produces the following error: g++ -c -o objs/src/Main.o -D__cygwin__ -O -Isrc -Ilibutil/include -Ilibrsrc/include src/Main.cpp /usr/include/boost/spirit/core/scanner/impl/skipper.ipp:173: instantiated from `boost::spirit::parse_info<const CharT*> boost::spirit::parse(const CharT*, const boost::spirit::parser<DerivedT>&, const boost::spirit::parser<SkipT>&) [with CharT = char, ParserT = boost::spirit::rule<boost::spirit::nil_t, boost::spirit::nil_t, boost::spirit::nil_t>, SkipT = boost::spirit::space_parser]' src/Main.cpp:16: instantiated from here /usr/include/boost/spirit/core/non_terminal/impl/rule.ipp:189: error: no matching function for call to `boost::spirit::impl::abstract_parser<boost::spirit::scanner<const char*, boost::spirit::scanner_policies<boost::spirit::iteration_policy, boost::spirit::match_policy, boost::spirit::action_policy> >, boost::spirit::nil_t>::do_parse_virtual(const boost::spirit::scanner<const char*, boost::spirit::scanner_policies_t>&)' Using the parser expression directly works without problems: bool b = parse(inp.c_str(),real_p,space_p).full; What am I doing wrong? Thanks, Patrick.

4 3