- Boost - lists.boost.org

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