- Boost - lists.preview.boost.org

[spirit2] Documentation?
by Carlos Rafael Giani 31 Dec '08

31 Dec '08

Hello, I have been trying to find the Spirit2 documentation, but all I can find is the Spirit 1.8.5 one. The documentation in boost, too, is the 1.8.5 one. I cannot find it in the spirit svn. Is it in the boost svn? If not, where is it?

3 2

Re: [boost] Futures - Reviews Needed (January 5, 2009)
by Jason Wagner 31 Dec '08

31 Dec '08

Tom Brinkman wrote: > Futures > > Join the review and discussion starting January 5, 2009. > > I need commitments for reviews from threading experts on the two > Futures library candidates. > > Braddock Gaskill - http://braddock.com/~braddock/future > Anthony Williams - http://www.justsoftwaresolutions.co.uk/files/n2561_future.hpp > > Early comments are welcome. Will you be accepting uncommitted reviews? I have an interest in the futures library, but can't promise that I'll have a chance to fully evaluate it. --- Jason Wagner jason(a)nialscorva.net

1 0

Re: [boost] [logging] Interest check on logging library.
by Jason Wagner 31 Dec '08

31 Dec '08

The last email was sent instead of saved as draft. The last line should have been: log << severity::warn() << "Packet was larger than the buffer that contains it!" << auditing::full() << set("User", user) << set("connection",connection) << " Packet source= " << connection << ", account = " << user << "\n" << dump_hex(packet); I'll finish it up after lunch. --- Jason Wagner jason(a)nialscorva.net

1 0

Re: [boost] signals2 release schedule
by Frank Mori Hess 31 Dec '08

31 Dec '08

Frank On Mon Dec 29 19:47 , 'James C. Sutherland' <James.Sutherland(a)utah.edu> sent: >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... It's still in the sandbox: https://svn.boost.org/svn/boost/sandbox/thread_safe_signals/trunk The plan is to make a RFC here once I've made the documentation, etc. improvements requested during the review, in order to give the reviewers a chance to look over the changes before it's moved onto the trunk.

1 0

Novice Problem
by master master 31 Dec '08

31 Dec '08

This code is running in codepad http://boost.codepad.org/ybbmMUEc (available ony for 24 hrs) But when I run this at my side it gives error 1>------ Build started: Project: stringmanipulation, Configuration: Debug Win32 ------ 1>Compiling... 1>stringcases.cpp 1>c:\documents and settings\administrator\my documents\visual studio 2008\projects\formattesting\stringmanipulation\stringcases.cpp(115) : error C2275: 'std::string' : illegal use of this type as an expression 1>c:\documents and settings\administrator\my documents\visual studio 2008\projects\formattesting\stringmanipulation\stringcases.cpp(115) : error C2146: syntax error : missing ')' before identifier 'elem' 1>c:\documents and settings\administrator\my documents\visual studio 2008\projects\formattesting\stringmanipulation\stringcases.cpp(115) : error C2059: syntax error : ')' 1>c:\documents and settings\administrator\my documents\visual studio 2008\projects\formattesting\stringmanipulation\stringcases.cpp(116) : error C2143: syntax error : missing ';' before '{' 1>c:\documents and settings\administrator\my documents\visual studio 2008\projects\formattesting\stringmanipulation\stringcases.cpp(117) : error C2065: 'elem' : undeclared identifier 1>c:\documents and settings\administrator\my documents\visual studio 2008\projects\formattesting\stringmanipulation\stringcases.cpp(115) : error C3861: 'BOOST_FOREACH': identifier not found 1>Build log was saved at "file://c:\Documents and Settings\Administrator\My Documents\Visual Studio 2008\Projects\FormatTesting\stringmanipulation\Debug\BuildLog.htm" 1>stringmanipulation - 6 error(s), 0 warning(s) ========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ========== If I comment BOOST_FOREACH loop every thing runs fine. Where is the problem??? I am using VC 9.0 (Visual Studio 2008) and boost_1_36_0. If this issue is already solved in boost 1.37 then which lib I need to download from trunk. Give me url like this http://cgs.hpi.uni-potsdam.de/trac/vrs/browser/trunk/3rd-party/boost-1.36.0… 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. Unlimited freedom, unlimited storage. Get it now, on http://help.yahoo.com/l/in/yahoo/mail/yahoomail/tools/tools-08.html/

3 3

[newbie] using non "header-only" boost libraries, but not linking the ".lib"
by Enrique Nieloud 31 Dec '08

31 Dec '08

I'm using filesystem library. I'm using it under vs2005 on windows, and g++ on mac. Instead of linking the .lib I'd like to include the source files of the fs library in my project. I tried to include all the ".cpp" under the filesystem/src directory in the vs2005 project. But the linker still ask for the lib. As far as know I didn't mention the .lib in the project. Why is that? The project files are created using cmake.

3 2

[MultiIndex] STL algorithm support for multi_index_containers
by Arno Schödl 31 Dec '08

31 Dec '08

Hello, we have added support for using multi_index ordered index iterators in lieu of random access iterators in standard algorithms that require sorted ranges, e.g. lower_bound, upper_bound, equal_range, and binary_search. This is useful when using these iterators in generic algorithms that internally call lower_bound/upper_bound/etc. Our implementation is attached. We are currently overloading std::lower_bound/... which is illegal. I propose introducing a boost::lower_bound/..., where we can ignore the C++ standard restriction, and where the standard implementation forwards to std::lower_bound. Runtime is O(log N), where N is the total number of elements in the container, rather than, as it would be optimal, the number of elements within the (sub)range on which the algorithm is called. The problem is that the red-black tree nodes do not store the tree level number, so we cannot find the parent node that encompasses the whole subrange in linear time. I am not sure this is practically relevant. In any case, using the sortedness of the tree rather than treating the iterators as arbitrary bidirectional iterators is a step forward. Any opinions? Regards, Arno -- Dr. Arno Schoedl · aschoedl(a)think-cell.com Technical Director think-cell Software GmbH · Invalidenstr. 34 · 10115 Berlin, Germany http://www.think-cell.com · phone +49-30-666473-10 · toll-free (US) +1-800-891-8091 Directors: Dr. Markus Hannebauer, Dr. Arno Schoedl · Amtsgericht Charlottenburg, HRB 85229

7 50

GSM Programming
by master master 31 Dec '08

31 Dec '08

I want to program GSM mobile. GSM mobile will be connected to a PC via a serial port or usb cable or bluetooth etc. I will send commands from my PC and that command will operate the mobile like sending sms, calling numbers, etc. For this type of programming what libraries should I refer ??? Currently I am referring Asio for socket and threading. What else I need to refer ? Currently I am in analysis stage. 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. Share files, take polls, and make new friends - all under one roof. Go to http://in.promos.yahoo.com/groups/

2 2

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

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

[logging] Interest check on logging library.
by Jason Wagner 27 Dec '08

27 Dec '08

Hello all, I know there are two proposed logging libraries out there for Boost, already, but I had a different itch to scratch on a project. I think I saw that Andrey Semashev was going to submit his far more mature version soon, but I thought I'd throw my technique out there for an interest check and hopefully commentary. This is very much a prototype-- there's a lot of work yet to be done but the basic outline and functionality is implemented. Getting the code ---------------- http://www.nialscorva.net/boost_logging-0_1.tar.bz2 File is also attached, since it's small. Just unzip, put on path, and include. It's header only for now. Tested against 1.36 and 1.37 on gcc 4+ and msvc 8+. Elevator Conversation Rundown ----------------------------- My logging library involves no macros, it relies on using template metaprogramming and the compiler optimizer to mostly eliminate logging statements that cannot be logged. It also supports conditional output within the context of a single statement, complex filter evaluation and chaining, lazy function evaluation, and support for standard ostream operators. All features are easily extensible without macros or hidden code. Requirements ------------ I had several wants/needs that weren't elegantly handled by existing log libraries. - Tagging mentality for enabling logs with in-line conditions. I'm writing a client/server program. I want to be able to write: logger << severity::error() << "An error has occurred!" << severity::debug() << " packet= " << hex_dump(packet); When debug is disabled, the packet contents are not logged. Tags should be easy to add and define. There is common code between the client and server and I want slightly different output on each: // action, ip, and context are local vars that are defined for operator<<(ostream&,T&) logger << "Action failed to occur: " << action << target::server() << " from ip address " << ip << " with context= " << context; When the code is compiled for the server, the ip and context are logged. When compiled on the client, it is removed from completely. The code is compiled every time, so there's no risk of stale code hidden by macros. The optimizer removes the strings and dead code later. - Sink selection based upon filter evaluation. For example, sending severity::warning and above to a console and everything to a file: filter_split_action f(severity() >= severity::warning()); f.on_success(my_console_log); f.always(my_log_file); logger.set_action(f); - Chaining filter evaluation. The client sends certain log events back to the server, but also to local sources: filter_split_action f(severity() >= severity::warning()); f.on_success(my_console_log); f.always(my_log_file); logger.set_action(f); // build the server reporter filter_split_action to_server(target() == target::client() && send_to_server() == send_to_server::yes()); to_server.on_success(my_server_sink); // chain the server reporter off of the original filter f.always(to_server); Chaining to on_success and on_failure works as well. - Lazy evaluation of expensive functions. Only invoke them if they are going to be logged. The library accepts any boost::function that returns an ostream compatible type and takes no arguments. The "lazy()" convenience functions create a boost::bind wrapped in a boost::function for this purpose. int nth_digit_of_pi(int place); logger << lazy(nth_digit_of_pi,500000); - Reconfigurable on the fly (excluding compile-time conditions). Not yet implemented but the groundwork is laid and will be implemented in the core via facades that act as handles. - Hierarchical variable sets. When looking up a variable for filtering or for formatting, climb a chain of parents from record->logger->channel->thread->global. Example ------- namespace bl=boost::logging; // defined in logger.hpp typedef boost::mpl::vector< bl::condition::greater_equal<bl::severity::warning>, bl::condition::in<bl::build_type::release> > optimized_conditions; typedef boost::mpl::vector<bl::build_type::release,bl::severity::info> optimized_tags; // end defined in logger.hpp bl::logger<optimized_conditions, optimized_tags> log(sink); log << "severity::info-- not printed\n" << bl::severity::debug() << "debug is not printed\n" << bl::severity::warning() << "warning is printed\n" << bl::severity::error() << "and so is error\n" << bl::build_type::debug() << "but build_type::debug fails the condition\n" << bl::end_record(); Other samples can be found in lib/logging/examples. Other ----- There are still a lot of things in the TODO list. The best look at usage is found in the lib/logging/examples directory. I've been using speed.cpp to take simple timing information to watch performance. Mostly they are one-off snippets I've been using while prototyping this. There's an excel spreadsheet with numbers in it, but generally it takes 3+-0.5 times as long to write to a logger as to cout, depending upon sinks, conditions, etc. A lot of this time is spent in variable_set, which is an easy target for optimization. Whole messages rejected by filters take about 1/2 as long as writing to cout, while rejection at compile time take 1% to 2% of the time to write to cout. Currently, there is no multithreading support. The places that need guarding are localized and will be implemented as facades on variable_set, filter_action, and sink. Core will be a registry and factory for populating variable_set parents and filter_actions on loggers, as well as properly putting multithreading and reconfiguration facades on things that need them. I'm not planning on implementing i19n, scoped variables, functor variables, or some of the other requirements in the boost logging list unless there's interest. There's more, I'm sure, but I can't write the whole project's documentation in an introduction email. -- Jason Wagner jason(a)nialscorva.net

2 1

which implementation for move semantics?
by k-oli＠gmx.de 27 Dec '08

27 Dec '08

Hello, I saw that some boost libraries (for instance boost::thread) implement their own move semantics. I'd like to know which would be the prefered implementation I should choose.

1 0

[Test] reopened trac issues floating comaparison
by Juergen Hunold 26 Dec '08

26 Dec '08

Hi Gennadyi ! Nice to see you back ! Could you please take a look at issue #2390 again ? https://svn.boost.org/trac/boost/ticket/2390 There are currently two patches missing: - attached patch to make operator() of check_is_small and check_is_close "const". This is needed because Boost.Test now stores "const&" due those two objects due to the previous applied ODR-patch. - gcc-4.3 warnings "../boost/test/floating_point_comparison.hpp:88: warning: suggest parentheses around && within ||" which are rather annyoing. Yours, Jürgen -- * Dipl.-Math. Jürgen Hunold ! Ingenieurgesellschaft für * voice: ++49 511 262926 57 ! Verkehrs- und Eisenbahnwesen mbH * fax : ++49 511 262926 99 ! Lister Straße 15 * juergen.hunold(a)ivembh.de ! www.ivembh.de * * Geschäftsführer: ! Sitz des Unternehmens: Hannover * Prof. Dr.-Ing. Thomas Siefer ! Amtsgericht Hannover, HRB 56965 * PD Dr.-Ing. Alfons Radtke !

3 6

[test] Runtime parameter handling subsystem updated
by Gennadiy Rozental 26 Dec '08

26 Dec '08

Hi, I've checked in an update to the runtime parameters handling subsystem. It's not completely up to my liking yet, but should fare better than old one. From usage prospective you will see major differences in features supported by command line argument parser (don't worry - everything is backward compatible). New command line arguments parser allows: a) double identification for parameters (is not used for all parameters, but most). For example: "--log_level=<value>" and "-l <value>" for log level b) name guessing for long names. For example "--log_l=<value>" and "--log_le=<value>" will work fine Note though that --log_=<value> will produce an error message complaining about ambiguity, since there are two parameters - --log_level and --log_format that may fit. c) boolean parameters does not require the value. For example "--catch_system_errors" will work fine Parameter --random can be used without any value as well. d) New parameter --help,-? is supported that produces help message with usage information. Note that usage information is being printed also in case there was error parsing command line. Any comments and suggestions appreciated, Gennadiy

2 2

[python] bogus backward-compatibility code
by Ulrich Eckhardt 26 Dec '08

26 Dec '08

Hi! I'm looking at versions up to at least 1.37, and in python/detail/config.hpp, I find found some code that is currently in my way, because I'm not sure what it should do. I'm talking about the following few lines: // backwards compatibility: #ifdef BOOST_PYTHON_STATIC_LIB # define BOOST_PYTHON_STATIC_LINK # elif !defined(BOOST_PYTHON_DYNAMIC_LIB) # define BOOST_PYTHON_DYNAMIC_LIB #endif Notes here: 1. The first macro, BOOST_PYTHON_STATIC_LIB, is undocumented and probably (I'm guessing) an old spelling of BOOST_PYTHON_STATIC_LINK. It is used in some Jamfile.v2s, probably to link with or build a static library. On first view, it's odd that the build system depends on backward code. 2. On second look, you see that BOOST_PYTHON_STATIC_LINK is completely unused and similarly undocumented, in any case defining it is not necessary for Boost itself. 3. The macro BOOST_PYTHON_DYNAMIC_LIB is also of questionable use. It is used in that file to setup auto linking and symbol visibility for a dynamic library, but otherwise it is unused. Actually, compare that to config/user.hpp, which says that you should use either of BOOST_{PYTHON,ALL}_DYN_LINK to get dynamic linking. 4. Speaking about config/user.hpp, there is no documented way to specify static linking. I think some libraries use e.g. the _DLL macro on MS' compiler to default to dynamic linking and otherwise assume static linking. Boost.Python instead assumes dynamic linking when nothing is specified and the only way to get static linking is by defining an otherwise undocumented macro. Suggested resolution: 1. Remove above quoted lines. They have been there since 2002 (SVN revisions 12083, 12146, 13462), and any code relying on undocumented backward compat code for such a long time is broken anyway (yes, sadly, that includes Boost itself sadly). 2. Replace checks for BOOST_PYTHON_DYNAMIC_LIB with checks for the macros documented in config/user.hpp. 3. Document BOOST_{ALL,foo}_STATIC_LINK as guaranteed way to get statically linked libraries in config/user.hpp. 4. Maybe introduce a header config/guess_linkage.hpp which will define BOOST_ALL_STATIC_LINK or BOOST_ALL_DYNAMIC_LINK based on heuristics like e.g. _DLL under win32, unless either of these two is already defined. I think that such heuristics already are in place in some libraries, but they should actually be central. I'd start off with 1-3 and then see what breaks. Step 4 will require that checks are changed so that they look like this: if (ALL_DYN_LINK|FOO_DYN_LINK) && !FOO_STATIC_LINK // use dynamic linking else // use static linking endif instead of just like this: if (ALL_DYN_LINK|FOO_DYN_LINK) // use dynamic linking else // use static linking endif so that the detected default does not override an explicitly set linkage. Comments anyone? Uli

1 0