December 2008 - Boost - lists.preview.boost.org

boost::date_time and gcc-4.3 with enabled optimization.
by Dmitry V. Krivenok 30 Dec '08

30 Dec '08

Hello! Please look at this simple example: krivenok@develop2 11:51:44 /tmp/date $ cat date.cpp #include <string> #include <boost/date_time.hpp> const std::string Date(boost::posix_time::ptime posix_time) { return boost::gregorian::to_iso_extended_string(posix_time.date()); } krivenok@develop2 11:51:54 /tmp/date $ I have two compilers (gcc-4.1.2 and gcc-4.3.2) and boost-1.37.0 installed on my linux host. I wrote simple test to demonstrate the problem: krivenok@develop2 11:51:54 /tmp/date $ export CC=g++-4.1.2 krivenok@develop2 11:52:32 /tmp/date $ for((i=0;i<4;i++)) do echo "Optimization level $i" ; $CC -O$i -Wall -I/usr/local/dev/boost/include/ date.cpp -c ; done Optimization level 0 Optimization level 1 Optimization level 2 Optimization level 3 krivenok@develop2 11:52:40 /tmp/date $ export CC=g++-4.3.2 krivenok@develop2 11:52:44 /tmp/date $ for((i=0;i<4;i++)) do echo "Optimization level $i" ; $CC -O$i -Wall -I/usr/local/dev/boost/include/ date.cpp -c ; done Optimization level 0 Optimization level 1 /usr/local/dev/boost/include/boost/date_time/constrained_value.hpp: In function 'const std::string Date(boost::posix_time::ptime)': /usr/local/dev/boost/include/boost/date_time/constrained_value.hpp:68: warning: 'year.boost::gregorian::greg_year::<anonymous>.boost::CV::constrained_value<boost::CV::simple_exception_policy<short unsigned int, 1400u, 10000u, boost::gregorian::bad_year> >::value_' may be used uninitialized in this function /usr/local/dev/boost/include/boost/date_time/gregorian_calendar.ipp:122: note: 'year.boost::gregorian::greg_year::<anonymous>.boost::CV::constrained_value<boost::CV::simple_exception_policy<short unsigned int, 1400u, 10000u, boost::gregorian::bad_year> >::value_' was declared here /usr/local/dev/boost/include/boost/date_time/constrained_value.hpp:64: warning: 'year.boost::gregorian::greg_year::<anonymous>.boost::CV::constrained_value<boost::CV::simple_exception_policy<short unsigned int, 1400u, 10000u, boost::gregorian::bad_year> >::value_' may be used uninitialized in this function /usr/local/dev/boost/include/boost/date_time/gregorian_calendar.ipp:122: note: 'year.boost::gregorian::greg_year::<anonymous>.boost::CV::constrained_value<boost::CV::simple_exception_policy<short unsigned int, 1400u, 10000u, boost::gregorian::bad_year> >::value_' was declared here Optimization level 2 /usr/local/dev/boost/include/boost/date_time/constrained_value.hpp: In function 'const std::string Date(boost::posix_time::ptime)': /usr/local/dev/boost/include/boost/date_time/constrained_value.hpp:68: warning: 'year.boost::gregorian::greg_year::<anonymous>.boost::CV::constrained_value<boost::CV::simple_exception_policy<short unsigned int, 1400u, 10000u, boost::gregorian::bad_year> >::value_' may be used uninitialized in this function /usr/local/dev/boost/include/boost/date_time/gregorian_calendar.ipp:122: note: 'year.boost::gregorian::greg_year::<anonymous>.boost::CV::constrained_value<boost::CV::simple_exception_policy<short unsigned int, 1400u, 10000u, boost::gregorian::bad_year> >::value_' was declared here /usr/local/dev/boost/include/boost/date_time/constrained_value.hpp:64: warning: 'year.boost::gregorian::greg_year::<anonymous>.boost::CV::constrained_value<boost::CV::simple_exception_policy<short unsigned int, 1400u, 10000u, boost::gregorian::bad_year> >::value_' may be used uninitialized in this function /usr/local/dev/boost/include/boost/date_time/gregorian_calendar.ipp:122: note: 'year.boost::gregorian::greg_year::<anonymous>.boost::CV::constrained_value<boost::CV::simple_exception_policy<short unsigned int, 1400u, 10000u, boost::gregorian::bad_year> >::value_' was declared here Optimization level 3 /usr/local/dev/boost/include/boost/date_time/constrained_value.hpp: In function 'const std::string Date(boost::posix_time::ptime)': /usr/local/dev/boost/include/boost/date_time/constrained_value.hpp:68: warning: 'year.boost::gregorian::greg_year::<anonymous>.boost::CV::constrained_value<boost::CV::simple_exception_policy<short unsigned int, 1400u, 10000u, boost::gregorian::bad_year> >::value_' may be used uninitialized in this function /usr/local/dev/boost/include/boost/date_time/gregorian_calendar.ipp:122: note: 'year.boost::gregorian::greg_year::<anonymous>.boost::CV::constrained_value<boost::CV::simple_exception_policy<short unsigned int, 1400u, 10000u, boost::gregorian::bad_year> >::value_' was declared here /usr/local/dev/boost/include/boost/date_time/constrained_value.hpp:64: warning: 'year.boost::gregorian::greg_year::<anonymous>.boost::CV::constrained_value<boost::CV::simple_exception_policy<short unsigned int, 1400u, 10000u, boost::gregorian::bad_year> >::value_' may be used uninitialized in this function /usr/local/dev/boost/include/boost/date_time/gregorian_calendar.ipp:122: note: 'year.boost::gregorian::greg_year::<anonymous>.boost::CV::constrained_value<boost::CV::simple_exception_policy<short unsigned int, 1400u, 10000u, boost::gregorian::bad_year> >::value_' was declared here krivenok@develop2 11:52:50 /tmp/date $ As you can see the example compiled using gcc-4.1.2 compiles without any warnings regardless of optimization level. However, gcc-4.3.2 produces a lot of strange warnings if optimization is enabled. I don't really know is it gcc or boost issue. Is it safe to use boost::date_time with gcc-4.3.2 and -O3 optimization level? Thank you beforehand! -- Sincerely yours, Dmitry V. Krivenok Orange System Company Saint-Petersburg, Russia work phone: +7 812 332-32-40 cellular phone: +7 921 576-70-91 e-mail: krivenok(a)orangesystem.ru web: http://www.orangesystem.ru skype: krivenok_dmitry jabber: krivenok_dmitry(a)jabber.ru icq: 242-526-443

3 4

Problem running the official boost regression tests on Vista x86
by Neil Groves 30 Dec '08

30 Dec '08

Hi, I am having trouble following the instructions for running the regression tests on the trunk as described here: http://www.boost.org/development/running_regression_tests.html Compiler: MSVC9 Express OS: Vista Ultimate x86 Python: python 2.5 I am attempting to use the command line: python.exe run.py --toolset=msvc After many hours of execution I get this error: # Executing SVN command "svn --non-interactive info --xml "C:\Users\neil\source\ boost-trunk\boost" >"C:\Users\neil\source\boost-trunk\boost\svn_info.txt"" # Collecting test logs into "C:\Users\neil\source\boost-trunk\results\None.xml". .. Traceback (most recent call last): File "run.py", line 60, in <module> runner(root) File "C:\Users\neil\source\boost-trunk\tools_regression_src\regression.py", line 193, in __init__ self.main() File "C:\Users\neil\source\boost-trunk\tools_regression_src\regression.py", line 551, in main getattr(self,action_m)() File "C:\Users\neil\source\boost-trunk\tools_regression_src\regression.py", line 517, in command_regression self.command_collect_logs() File "C:\Users\neil\source\boost-trunk\tools_regression_src\regression.py", line 424, in command_collect_logs revision ) File "C:\Users\neil\source\boost-trunk\tools_regression_src\collect_and_upload_logs.py", line 309, in collect_logs, 'revision': revision File "c:\python25\lib\xml\sax\saxutils.py", line 132, in startElement self._write(' %s=%s' % (name, quoteattr(value))) File "c:\python25\lib\xml\sax\saxutils.py", line 73, in quoteattr data = escape(data, entities) File "c:\python25\lib\xml\sax\saxutils.py", line 39, in escape data = data.replace("&", "&") AttributeError: 'NoneType' object has no attribute 'replace' Has anyone seen this issue before, or know how to fix it? Thanks in anticipation, Neil Groves

2 2

Format library
by master master 30 Dec '08

30 Dec '08

I am just understanding format library, I came across an example. cout << boost::format("writing %1%, x=%2% : %3%-th step") % "toto" % 40.23 % 50; it prints "writing toto, x=40.230 : 50-th step" and another expression cout << format("writing %s, x=%s : %d-th step \n") % "toto" % 40.23 % 50; it prints "writing toto, x=40.23 : 50-th step " Both expression are printing same result. But these below two expressions give error cout << boost::format("writing %s, x=%2% : %3%-th step") % "toto" % 40.23 % 50; cout << format("writing %1%, x=%s : %d-th step \n") % "toto" % 40.23 % 50; If I am not wrong then this is because " format specifications can not be the combination of ordered types(%1%, %2%, ...) and unodered types(%s, %d, etc) " If this is true then this is the limitation of Format library in Boost or may be I am wrong. So what is the solution if I want to use combination of both types. This is just my requirement, it is not must to do in this way. Rahul To create something exceptional ________________________________ -Master4Master "Confidentiality Warning: This message and any attachments are intended only for the use of the intended recipient(s), are confidential, and may be privileged. If you are not the intended recipient, you are hereby notified that any review, re-transmission, conversion to hard copy, copying, circulation or other use of this message and any attachments is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return email, and delete this message and any attachments from your system. Virus Warning: Although I have taken reasonable precautions to ensure no viruses are present in this email, I cannot accept responsibility for any loss or damage arising from the use of this email or attachment." Speak out for justice and peace, even if your voice trembles. Add more friends to your messenger and enjoy! Go to http://messenger.yahoo.com/invite/

2 1

[test] unit tests succeed on abort?
by Dean Michael Berris 30 Dec '08

30 Dec '08

I'm using Boost 1.35 and I notice that when a unit test aborts due to asserts in the code, it doesn't count as a failure -- the end report says "*** No errors detected" when in fact a call to abort() was made due to a failed assert. I'm thinking this would be a bug, but I'd like to ask first whether this is intended behavior before thinking it's a bug with Boost.Test. Have a good day! -- Dean Michael C. Berris Software Engineer, Friendster, Inc.

3 5

signals2 release schedule
by James C. Sutherland 30 Dec '08

30 Dec '08

Does anyone know the anticipated release date for signals2 (thread- safe signals)? Where can I download the current version? I tried the svn development trunk http://svn.boost.org/svn/boost/trunk/ and couldn't see it there... Thanks, James

1 0

[test] Some more warning suppression
by John Maddock 30 Dec '08

30 Dec '08

It's not just gcc that's emitting a bunch of warnings from the new Boost.Test code: MSVC does as well, the attached patch fixes these, OK to commit? Cheers, John.

2 1

Re: [boost] [uuid] Interface
by Vladimir Batov 29 Dec '08

29 Dec '08

>>> The behavior of the default constructor that you'd like to see (apologies if I got it wrong) is to create an invalid uuid. I feel that is not the canonical use of the default constructor. Indeed, that usage of the default constructor *not* to actually create an object has become quite popular. It does not make it right though. I find it unfortunate and hackish. >>> >> >> I agree. I like things to either default construct with a full usable >> object, or to not be able to default construct it at all. >> > > What defines "fully usable"? All the member functions in a nil UUID > return reasonable, predictable results, and none throw exceptions. Surely "predictable results" do not make a thing usable. A broken-down car behaves predictably (does not start). It even might be considered "usable" (as scrap metal or a frontyard "feature"). It is not usable from the *conventional* mainstream point of view as it fails to provide the service the car was *designed for* in the first place. My interpretation of "fully usable" is a "valid" object, that is an object that provides the *main* functionality the class's been designed/introduced for. For a pointer it'd be a pointer pointing somewhere, for an integer, double, std::string, std::map, etc. it'd be *any* integer, double, std::string, std::map as all their values are valid (those classes just have no an "invalid" concept), i.e. int() is valid, std::string is empty but is still valid. > Do you have some examples of other objects that do (or should) behave > similarly to your desire for uuid? int example = int(); double d = double(); std::string str; in fact probably all the classes with the value semantics. > In my view, a uuid is essentially > a pointer (though the dereference operation is context-dependant), so > it should be null/nil by default until you define what it should be > pointing to. To me uuid is a class with the *value* (rather than pointer) behavior/semantics. Value-semantics objects/classes *own* its underlying data. Pointer-semantics objects do *not*. Therefore, I feel that the conventional "language" interpretation of Ball ball; is "give me a ball" that satisfies the basic properties of a ball. Then, Ball ball(red); means the same (all the basic ball properties) plus the color. Asking for an unusable ripped into shreds ball is an anomaly, an exception. So, it needs to be treated as such Ball ball(Ball::broken()); so that the majority -- the mainstream users -- do not get confused or pay the penalty of saying "give me a ball, a real God-damn ball and not those shreds". With pointer-semantics objects the situation is starkly different as a pointer does not house any data. The pointer's *property* is to *point* to and *share* some data. That is its distinct characteristic for which pointers deployed. With that "pointing/sharing" characteristic comes in the twist of *not* pointing anywhere. The notion of a valid pointer pointing to some data is so obvious that it is widely understood that creating a pointer without pointing it anywhere makes it invalid. That is a *distinct* specific characteristic of a pointer. Unfortunately, that interpretation (of default-initialized) is making its way into value-semantics classes for which it is far from obvious/intuitive and in fact in general terms incorrect. Default-initialized is still *initialized*. There is nothing invalid about it. As for uuid I do not see how it can be treated as a pointer when the pointer's property is to *share* and the uuid's property is to be unique. Surely, we copy a uuid around (i.e. making several copies of the same). Surely, internally, those copies can even share the same implementation (via ref.-counting). Still, those are "technicalities". For all external purposes uuid is a value-semantics class (and the discussed class is implemented that way). Therefore, my interpretation is uuid id; // Give me the best you (OS/infrastructure) can come up with uuid id(some-gen); // I know better. Give me what I am asking for. uuid id(uuid::null()); // Do not want anything but have to have this placeholder I bet for portability purposes (and understandable unwillingness to go into every detail) the first will be used overwhelmingly. Some insist that #3 is to be used more often. I disagree as it goes against the C++ grain which states that objects are created when they are needed, i.e. *valid*. To me seeing the following int i; // Unusable. Initialized later int* p; // Unusable. Initialized later uuid id; // Unusable. Initialized later is equally worrisome regardless if an object is "uninitialized invalid" (as int) or "initialized invalid" (as uuid). > Take, for example, a map<string, uuid>. No default constructor means > that you can't use operator[], Of course an empty std::map is a valid map. And you certainly can use operator[] with it. :-) But I get your point -- operator[] on an empty std::vector will bomb. It does not make that vector invalid though as a good working car is not "invalidated" by one's attempts to run it on water. > and one that generates a random uuid > means you lose the convenient semantics of a non-existant element > being equivalent to the (trivially) invalid one. 1. Well, "generates a random uuid" is pretty much what I want from uuid. Therefore, I want this functionality in the most convenient form (apart from that long and boring talk about value- vs. pointer-semantics). 2. I do not see you losing anything as that non-existent is still available although in a more explicit form (which is good from the long-term maintenance point) -- uuid::null(). > (I say "trivially" > because afaik most uses of uuid do allow you to check whether a uuid > points to something or if it's garbage, though not terribly quickly or > conveniently.) You insist on "points". I insist on "has". > I'm also not the only person that thinks ... That does not make it right, right? George W. was not alone thinking he was the best candidate. :-) >> default-constructed instances should be equal. Well, I find that thought unreasonable and I bet you won't find it in the Standard. Take something as reasonable as > > vector<uuid> v; v.resize(10); I am not sure what it proves. You seem to extend the notion of the invalid uuid on to a vector of invalid uuids. I suspect "v.reserve(10)" is in order and then you'll put something meaningful into that vector when you have the data. IMHO trying to cater for incorrect usages as above enforces bad programming practices and wrong expectations. Best, V.

5 27

[unordered] Buffered functions?
by David Abrahams 29 Dec '08

29 Dec '08

Hi all, Can someone please explain why the unordered containers store two copies of the hash and equality functions, and why they aren't using compressed_pair to take advantage of the EBO for these? Thanks, -- Dave Abrahams BoostPro Computing http://www.boostpro.com

6 21

Boost Sending Files over network Sockets
by master master 29 Dec '08

29 Dec '08

I want to send images over tcp network socket. I guess it will be sending images as binary data over socket stream but how to do that specially with Boost Library. I am using Visual Studio 8.0 so vc 9.0. Any example or source will be good. Thanks Rahul To create something exceptional ________________________________ -Master4Master "Confidentiality Warning: This message and any attachments are intended only for the use of the intended recipient(s), are confidential, and may be privileged. If you are not the intended recipient, you are hereby notified that any review, re-transmission, conversion to hard copy, copying, circulation or other use of this message and any attachments is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return email, and delete this message and any attachments from your system. Virus Warning: Although I have taken reasonable precautions to ensure no viruses are present in this email, I cannot accept responsibility for any loss or damage arising from the use of this email or attachment." Speak out for justice and peace, even if your voice trembles. Connect with friends all over the world. Get Yahoo! India Messenger at http://in.messenger.yahoo.com/?wm=n/

2 2

[UUID] PODness Revisited
by Scott McMurray 29 Dec '08

29 Dec '08

On IRC today, Dodheim made an excellent point: A uuid should be a POD, because that way it interacts better with Boost.MPI and Boost.Interprocess. MPI seems like an absolutely perfect situation in which to use UUIDs. However, going through serialization can more than 10 times slower than using using datatypes[1]. For something to be a datatype, it needs to be a POD[2], and thanks to the portable binary format, uuids can always use the BOOST_IS_BITWISE_SERIALIZABLE[3][4] trait since a UUID's bit format is independent of endianness and word size. [1] http://www.boost.org/doc/libs/1_37_0/doc/html/mpi/performance.html [2] http://www.boost.org/doc/libs/1_37_0/doc/html/boost/mpi/is_mpi_datatype.html [3] http://www.boost.org/doc/libs/1_37_0/doc/html/mpi/tutorial.html#mpi.homogen… [4] http://www.boost.org/doc/libs/1_37_0/libs/serialization/doc/traits.html#tem… Of course, you don't want to send UUIDs by themselves. This is even a bigger point, since if uuid isn't a POD, then sending composite types that include UUIDs pay the price of going through serialization too, even when they could have done the cheap way normally. Similarly, making uuid a POD allows it to be placed in Boost.Interprocess shared memory without the cost of going through serialization. For example, "A message queue just copies raw bytes between processes and does not send objects"[5], which requires a POD without member pointers to be safe. [5] http://www.boost.org/doc/libs/1_37_0/doc/html/interprocess/synchronization_… I think that these are two good examples that POD is the quintessential form for a value type, not something "clearly dragged in due to backward compatibility with C"[6]. In addition, note that even Boost.Proto, one of the fancier libraries in Boost, uses aggregates extensively[7]. [6] http://permalink.gmane.org/gmane.comp.lib.boost.devel/184223 [7] http://www.boost.org/doc/libs/1_37_0/doc/html/proto/appendices.html#boost_p… It's also trivial for someone to build a non-POD out of the pod should they desire: namespace vladimir { struct uuid : boost::uuid { uuid() : boost::uuid(boost::uuids::native_generator()()) {} uuid(boost::uuid id) : boost::uuid(id) {} }; } ~ Scott

4 14