- Boost - lists.boost.org

Interest in a Boost.JSON library?
by Kirit Sælensminde 31 Dec '08

31 Dec '08

As part of our web application framework (currently being ported from Windows to Linux) we have a JSON parser and library that might be of interest to a wider community as part of the Boost libraries. It uses a Spirit parser that deals correctly with embedded UTF-16 inside strings. The JSON blobs themselves are built on Boost.Variant and can store null, booleans, strings, int64_t, doubles and arrays & objects. The strings are our Unicode string implementation -- how this should be dealt with in Boost is an open question maybe only cleanly soluble when Boost has it's own proper Unicode string handling. A templated adapter layer could be used I think for both the string and the numeric types. There is also the internal implementation of the array and objects which could be moved to a policy based design. At the moment we use std::vector and std::map with boost::shared_ptr< json > as the value type. The JSON objects are immutable and use a thread safe CoW implementation when changes are required (handled through a separate jcursor object). One thing that is missing is a good EDSL for creating JSON blobs within C++ source code. The latest implementations is where we are using it to create an ACID JSON database and is here: http://svn.felspar.com/public/fost-base/branches/dbschema/Cpp/include/fost/… The parser itself is here: http://svn.felspar.com/public/fost-base/branches/dbschema/Cpp/include/fost/… There's a lot of room for improvement, but hopefully it's a good start. K

7 18

[TR1] can't compile with Boost installed in /usr/include (and with Boost.Test)
by Ling Li 30 Dec '08

30 Dec '08

Fedora rawhide recently bumped the boost version from 1.34 to 1.37 so I gave it a try. I can't compile the code below: [ling@fedora-vm test]$ cat t.cpp #include <boost/test/unit_test.hpp> #include <memory> BOOST_AUTO_TEST_SUITE(dummy) BOOST_AUTO_TEST_CASE(foo) { std::tr1::shared_ptr<int> bar; } BOOST_AUTO_TEST_SUITE_END() [ling@fedora-vm test]$ g++ -I /usr/include/boost/tr1/tr1 -I /usr/include -c t.cpp In file included from /usr/include/boost/tr1/tr1/utility:19, from /usr/include/boost/config/no_tr1/utility.hpp:21, from /usr/include/boost/config/select_stdlib_config.hpp:20, from /usr/include/boost/config.hpp:40, from /usr/include/boost/test/detail/config.hpp:19, from /usr/include/boost/test/utils/class_properties.hpp:20, from /usr/include/boost/test/predicate_result.hpp:19, from /usr/include/boost/test/test_tools.hpp:19, from /usr/include/boost/test/unit_test.hpp:19, from t.cpp:1: /usr/include/boost/tr1/detail/config_all.hpp:117:26: error: no include path in which to search for utility In file included from /usr/include/boost/tr1/detail/config_all.hpp:130, from /usr/include/boost/tr1/tr1/utility:19, from /usr/include/boost/config/no_tr1/utility.hpp:21, from /usr/include/boost/config/select_stdlib_config.hpp:20, from /usr/include/boost/config.hpp:40, from /usr/include/boost/test/detail/config.hpp:19, from /usr/include/boost/test/utils/class_properties.hpp:20, from /usr/include/boost/test/predicate_result.hpp:19, from /usr/include/boost/test/test_tools.hpp:19, from /usr/include/boost/test/unit_test.hpp:19, from t.cpp:1: /usr/include/boost/tr1/detail/config.hpp:25:29: error: no include path in which to search for utility Defining BOOST_TR1_DISABLE_INCLUDE_NEXT helps to reduce the two errors to one, [ling@fedora-vm test]$ g++ -DBOOST_TR1_DISABLE_INCLUDE_NEXT -I /usr/include/boost/tr1/tr1 -I /usr/include -c t.cpp In file included from /usr/include/boost/tr1/detail/config_all.hpp:130, from /usr/include/boost/tr1/tr1/utility:19, from /usr/include/boost/config/no_tr1/utility.hpp:21, from /usr/include/boost/config/select_stdlib_config.hpp:20, from /usr/include/boost/config.hpp:40, from /usr/include/boost/test/detail/config.hpp:19, from /usr/include/boost/test/utils/class_properties.hpp:20, from /usr/include/boost/test/predicate_result.hpp:19, from /usr/include/boost/test/test_tools.hpp:19, from /usr/include/boost/test/unit_test.hpp:19, from t.cpp:1: /usr/include/boost/tr1/detail/config.hpp:25:29: error: no include path in which to search for utility I also have a local copy of Boost 1.37 at ~/include/boost, and I have no problems with that: [ling@fedora-vm test]$ g++ -I ~/include/boost/boost/tr1/tr1 -I ~/include/boost -c t.cpp Do you know what I am missing here? Thanks in advance for any tips.

2 2

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