- Boost - lists.preview.boost.org

Improving Boostbook's Output
by John Maddock 04 Dec '08

04 Dec '08

Currently the Boostbook XSL stylesheets generate a lot of verbose output when run: to put this in perspective a complete build of the docs under boost-root/doc/ generates 3.1 Mb of messages, quite a large proportion of which are from Boostbook. Consequently at present it's impossible to figure out what represents a real issue, and what's just "chaff". So I'm proposing changing the Boostbook stylesheets as follows: * Add a new xsl:param "boostbook.verbose" which defaults to 0. * For each occurrence of xsl:message in the style sheets, we will either: * Terminate with an error if the message looks like it's a possible genuine error. * Otherwise emit a warning *only* if boostbook.verbose=1 I'm prepared to invest some time to make this work, but any comments or possible issues anyone foresees from this change? Cheers, John.

1 0

Mailing list configuration
by Vladimir Prus 04 Dec '08

04 Dec '08

Hi, it seems that the way most Boost mailing list are configure is fairly inconvenient, especially for newcomers. Here's a typical chain of events: 1. Somebody reads Boost mailing list via Gmane and wants to post. 2. He posts. 3. Gmane responds, asking the user to prove that he exists. Somewhere in the body of the message, Gmane suggest that user subscribes to the mailing list, but it's very easy to miss, and furthermore, those instructions do no work for Boost mailing lists. 4. User replies, and Gmane forwards the message to the list. 5. The list is configured to reject email messages from non-subscribers. When using Gmane, this results in *no notification at all*. 6. User posts directly, and gets bound message saying, literally: allowed to post to this mailing list, and your message has been automatically rejected. If you think that your messages are being rejected in error, contact the mailing list owner at boost-docs-owner(a)lists.boost.org and [email address] This message does not even hint that the user has to subscribe. 7. User subscribes. His post in the held for moderation. I have personally was fairly confused by (6) -- where my messages disappear silently, and by (7) -- where the message seem to say my messages are specifically rejected. I suspect many users might not make it to the point (7) at all. Can we configure all mailing list to not reject posts from non-subscribes, instead holding them for moderation. This will also require talking to mailing list admins to enable at least some spam filtering -- presently, messages written in the languages I don't understand seem to freely hit boost-build mailing list moderation queue, and for boost-devel this will be impossible to handle. Comments? - Volodya

2 1

Re: [boost] [Boost-users] [review][constrained_value] Review of ConstrainedValue Library begins today
by raindog＠macrohmasheen.com 04 Dec '08

04 Dec '08

Another example: 6 represents june. 6 + 3 is then 3 months after june, otherwise september. 6 + 12 is the next june. ------Original Message------ From: Edward Diener Sender: boost-users-bounces(a)lists.boost.org To: boost-users(a)lists.boost.org Cc: boost(a)lists.boost.org ReplyTo: boost-users(a)lists.boost.org Sent: Dec 3, 2008 8:03 PM Subject: Re: [Boost-users] [review][constrained_value] Review of ConstrainedValue Library begins today Deane Yang wrote: > Edward Diener wrote: >> Deane Yang wrote: >>> >>> I have an even more extreme view on this. I don't believe any >>> arithmetic operations should be permitted for constrained numbers. >>> They just don't make sense (would you ever want to add two different >>> days of a month?). >> >> You have chosen a particular type for which arithmetic operations >> sometimes make little sense. In many other situations this is not the >> case. > > > Could you give an example? An example of what ? Of a constraint where arithmetic operations make sense ? If we take a constraint representing a percentage between 0 and 100, I think it is perfectly valid to add a percent to what is already there. That is just one of innumerable cases where arithmetic operations of contraints seem perfectly valid to me. Why would you even want to consider limiting constraints by removing arithmetic operations if the underlying type supports such operations ? _______________________________________________ Boost-users mailing list Boost-users(a)lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users Sent from my Verizon Wireless BlackBerry

2 1

regression in math
by frederic.bron＠alcan.com 04 Dec '08

04 Dec '08

Very strange: nearly all regression tests failed on my linux platform with g++: http://www.boost.org/development/tests/trunk/developer/math.html (look at linux_x86_64, bronf) The reason is the always the same but is strange to me: "g++" -ftemplate-depth-128 -O0 -fno-inline -Wall -g -mfpmath=sse -mieee-fp -march=nocona -fPIC -Wno-missing-braces -DBOOST_ALL_NO_LIB=1 -DBOOST_REGEX_DYN_LINK=1 -DBOOST_UBLAS_UNSUPPORTED_COMPILER=0 -I".." -c -o "/soft/bal/usr/builds/boost_test/results/boost/bin.v2/libs/math/test/dist_bernoulli_incl_test.test/gcc-3.4.6/debug/dist_bernoulli_incl_test.o" "../libs/math/test/compile_test/dist_bernoulli_incl_test.cpp" In file included from ../boost/math/distributions/detail/common_error_handling.hpp:13, from ../boost/math/distributions/bernoulli.hpp:33, from ../libs/math/test/compile_test/dist_bernoulli_incl_test.cpp:9: ../boost/math/special_functions/fpclassify.hpp:170: error: expected unqualified-id before '&&' token This line has been modified recently and seems not to work now with g++: Index: boost/math/special_functions/fpclassify.hpp =================================================================== --- boost/math/special_functions/fpclassify.hpp (revision 50010) +++ boost/math/special_functions/fpclassify.hpp (working copy) @@ -165,7 +165,9 @@ { return BOOST_FPCLASSIFY_PREFIX fpclassify(t); } -#if !defined(__CYGWIN__) && !defined(__HP_aCC) && !defined(BOOST_INTEL) && !defined(BOOST_NO_NATIVE_LONG_DOUBLE_FP_CLASSIFY) +#if !defined(__CYGWIN__) && !defined(__HP_aCC) && !defined(BOOST_INTEL) \ + && !defined(BOOST_NO_NATIVE_LONG_DOUBLE_FP_CLASSIFY) \ + && !(defined(__GNUC__) && !defined(BOOST_MATH_USE_C99)) // The native fpclassify broken for long doubles with aCC // use portable one instead.... F. Bron ___________________________________ Frédéric Bron (frederic.bron(a)alcan.com) Unité ALT, Alcan CRV, BP 27, 38341 Voreppe +33 4 76 57 81 72, +33 6 07 48 56 67 Avis : Ce message et toute pièce jointe sont la propriété d'Alcan et sont destinés seulement aux personnes ou à l'entité à qui le message est adressé. Si vous avez reçu ce message par erreur, veuillez le détruire et en aviser l'expéditeur par courriel. Si vous n'êtes pas le destinataire du message, vous n'êtes pas autorisé à utiliser, à copier ou à divulguer le contenu du message ou ses pièces jointes en tout ou en partie. Notice: This message and any attachments are the property of Alcan and are intended solely for the named recipients or entity to whom this message is addressed. If you have received this message in error please inform the sender via e-mail and destroy the message. If you are not the intended recipient you are not allowed to use, copy or disclose the contents or attachments in whole or in part.

2 1

[config] BOOST_NO_INITIALIZER_LISTS patch
by Daniel James 04 Dec '08

04 Dec '08

Hi John, I've attached a patch for adding BOOST_NO_INITIALIZER_LISTS to config. Is it okay to commit? thanks, Daniel

2 1

[shared_ptr] make_shared and enable_shared_from_this with boost 1.36
by Michael Marcin 04 Dec '08

04 Dec '08

The following code throws boost::bad_weak_ptr using boost 1.36. #include <boost/shared_ptr.hpp> #include <boost/enable_shared_from_this.hpp> #include <boost/make_shared.hpp> class Test : public boost::enable_shared_from_this<Test> {}; int main() { boost::shared_ptr<Test> test = boost::make_shared<Test>(); test->shared_from_this(); } -- Michael Marcin

2 1

Re: [boost] [Boost-users] [review][constrained_value] Review of ConstrainedValue Library begins today
by raindog＠macrohmasheen.com 04 Dec '08

04 Dec '08

I totally agree. Pre contstraining a value for assignment to constrained_value seems to defeat the purpose of the library all together. ------Original Message------ From: Edward Diener Sender: boost-users-bounces(a)lists.boost.org To: boost-users(a)lists.boost.org Cc: boost(a)lists.boost.org ReplyTo: boost-users(a)lists.boost.org Sent: Dec 3, 2008 7:58 PM Subject: Re: [Boost-users] [review][constrained_value] Review of ConstrainedValue Library begins today Mathias Gaunard wrote: > Edward Diener wrote: > >> I disagree with your analysis. The '26' value could be a run-time >> calculation and not just a compile-time constant. In which case you >> are saying that the assignment of a run-time calculation should assert >> only when run in debug mode and otherwise should be ignored. I can not >> agree with that idea. > > I say it is up to the programmer to ensure valid values are provided. > If the value is only known at runtime, there should be explicit checking > in the code prior to assignment. Suppose the value is provided by the end user of the program. Do you still feel such a value, when used in a constraint, should assert only in debug mode rather than throw an exception ? A large part of the constrained value concept is that the constraint provides the necessary checking, in the form of a policy, which alleviates specific pre-checking by the programmer. I like that, else the constraint library serves less purpose than it could. _______________________________________________ Boost-users mailing list Boost-users(a)lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users Sent from my Verizon Wireless BlackBerry

1 0

[review][constrained_value] Bounded value
by Edward Diener 04 Dec '08

04 Dec '08

This is not a full review of the constrained_value library but rather a comment on one of the concepts of the library. I hope to give a full review by December 10 if I have the time. I believe the bounded objects are actually a subset of a larger concept, which is the set of valid values for an object. Ideally what one could have is a set of bounded values which define the valid values. Each member of the set could be a pair ( or two-element tuple ) defining a lower and upper value inclusive, and of course a single value in the set would have its lower and upper value be the same. In this way one could define, as an example, a constrained object whose integer value could be between 0 and 20 and between 50 and 70. Currently the bounded object concept only allows one "bounds". With the larger concept I mention, a bounded object can have any number of bounds. While the single bounds bounded object can still be supported, I would like to see the constrained value library implement a multi-bound concept, in which case the current bounded object concept is just a subset of the multi-bound with a single bound.

2 4

[vault] trojan in vault?
by Eric Niebler 03 Dec '08

03 Dec '08

Looks like someone uploaded a trojan or something to the boost file vault. Can someone with permissions please delete shell.php4 here: http://www.boostpro.com/vault/index.php?&direction=0&order=&directory=eric_… Thanks, -- Eric Niebler BoostPro Computing http://www.boostpro.com

1 0

Re: [boost] [unicode] Interest Check / Proof of
by Graham 03 Dec '08

03 Dec '08

Hi, I have taken a different approach and distilled the Unicode character rules down into a library as the rules are too complex to be defined algorithmically. This library gives full Unicode support for iterators for the full Unicode set of characters. It just needs the string wrapper round it. Please see the Unicode character library at: http://www.boostpro.com/vault/ Unicode_lib.zip. Good Luck. Yours, Graham

1 0

[Function] Problem using target() with boost::mem_fn and boost::bind
by Pengcheng Song 03 Dec '08

03 Dec '08

Hi, I have encountered a crash trying to use the target() function to retrieve a function pointer from a boost.function initialized with a member function (using boost.bind). See the code below. // =========================================== #include <iostream> #include <boost/bind.hpp> #include <boost/function.hpp> typedef double(*FunctionType) (double); double Square( FunctionType f, double x ) { return f(x) * f(x) ; } class A { private: double x_; double y_; public: A() : x_(1.0), y_(1.0) {} double Area(double x, double y) { x_ = x; y_ = y; return x_ * y_; } }; int main() { A a1; boost::function<double(double)> f1 = boost::bind( boost::mem_fn(&A::Area), &a1, _1, 2.5 ); double s1 = f1(2.0); // this works FunctionType f2 = *f1.target<FunctionType>() ; // Error: this would crash s1 = Square( f2, 2.0 ); return 0; } // ====================================================== After debugging the code, I found out that the crashed happened inside target() function in file function_base.hpp: template<typename Functor> Functor* target() { if (!vtable) return 0; detail::function::function_buffer type_result; type_result.const_obj_ptr = &typeid(Functor); vtable->manager(functor, type_result, detail::function::check_functor_type_tag); return static_cast<Functor*>(type_result.obj_ptr); } After vtable->manager() call, type_result became null, and this caused static_cast to fail. I was using boost_1_36_0 precompiled by BoostPro with Visual Studio 2008. Is this an expected behavior? Your feedback would be greatly appreciated. Pengcheng Song -- View this message in context: http://www.nabble.com/-Function--Problem-using-target%28%29-with-boost%3A%3… Sent from the Boost - Dev mailing list archive at Nabble.com.

2 1

[python] Bug during build process?
by Robert Dailey 03 Dec '08

03 Dec '08

Hi, I execute the following command to build the entire boost 1.37 library with python debugging ON: *bjam --toolset=msvc --layout=system link=shared threading=multi variant=debug python-debugging=on stage* I then use dependency walker <http://www.dependencywalker.com/> to load the file *boost_python-mt-gyd.dll* and I see that both python25.dll and python25_d.dll are being loaded side by side. This obviously shouldn't be happening and only python25_d.dll should be loaded. Is there a bug in the build script for boost python, or am I doing something wrong?

2 2

[inteprocess] maximum length for names of mutexes, memory segments etc.
by JOAQUIN M. LOPEZ MUÑOZ 03 Dec '08

03 Dec '08

Boost.Flyweight uses long names for some internal mutexes and memory segments inside the intermodule_holder component, with the purpose of guaranteeing name unicity. For instance, this is a typical name for such an internal mutex, with length 87: boost_flyweight_intermodule_holder_mutex_5660_601342046_2913549788_3054690985_591945496 However, on some platforms line NetBSD 87 chars is too much:

1 0

[future N2561] Implementation comments
by vicente.botet 03 Dec '08

03 Dec '08

Hi, on the current Future (N2561) library proposal the promise protect the value setting/getting from multiple threads using a lock, but the lock do not protect the future initialization (lazy_init()). void set_value(typename detail::future_traits<R>::source_reference_type r) { lazy_init(); boost::lock_guard<boost::mutex> lock(future->mutex); if(future->done) { throw promise_already_satisfied(); } future->mark_finished_with_result_internal(r); } I'm wondering if we don't need to extend the protection or avoid the lazy initialization? I'm missing something? BTW, Is it safe to take the address of a promise? If not, why not delete the operator&()? Best, Vicente

2 6

[xpressive] regex_token_iterator - bug, feature, misunderstanding query?
by Michael Goldshteyn 03 Dec '08

03 Dec '08

OK, so I want to use the sregex_token_iterator functionality to split a data string. The data string contains: /a/b//c/ The delimiter is the forward slash and I do want empty strings. I expect to get: {}{a}{b}{}{c}{} What I actually get is: {}{a}{b}{}{c} The empty string after {c}, which I expect because the data string ended in a forward slash, is missing. What do I have to do to get the empty string after {c} if the data string ends in a forward slash? The code is as follows: --- #include <iostream> #include <string> #include <boost/xpressive/xpressive.hpp> #include <boost/xpressive/regex_token_iterator.hpp> int main(int argc, char *argv[]) { // Split the path using namespace boost::xpressive; // For simplicity sregex levelSplitter(as_xpr('/')); std::string nodePath("/a/b//c/"); sregex_token_iterator begin(nodePath.begin(),nodePath.end(),levelSplitter,-1); sregex_token_iterator end; for (sregex_token_iterator iCur=begin;iCur!=end;++iCur) std::cout << '{' << *iCur << '}'; std::cout << std::endl; return 0; } --- Thanks, Michael Goldshteyn

2 2

Re: [boost] [Boost-users] [review][constrained_value] Review of Constrained Value Library begins today
by Mika Heiskanen 03 Dec '08

03 Dec '08

Mathias Gaunard wrote: > I say it is up to the programmer to ensure valid values are provided. > If the value is only known at runtime, there should be explicit checking > in the code prior to assignment. If the value must be checked beforehand, why bother using a constrained type at all? Where's the benefit if all assignments are already guaranteed to be valid by external tests? Might just as well use a test+POD combination. --> Mika Heiskanen

1 0

How to access the Boost wiki?
by vicente.botet 03 Dec '08

03 Dec '08

Hi, In order to access the Boost wiki I do COMMUNITY > Requesting a New Feature > " ticket system," > Wiki. Is there a shorter way? If not can we add it on COMMUNITY? Best, Vicente

1 0

Which Future library will be reviewed?
by vicente.botet 03 Dec '08

03 Dec '08

Hi Anthony, your current Boost.Future(http://www.justsoftwaresolutions.co.uk/files/n2561_future.hpp + http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2561.html) library is closer to the C++0x standard than the Boost.Future from Braddock. This let me think that yours is a better candidate for Boost, but the current state of your library interface has some differences, restrictions and extensions respect to the standard http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2627.html and http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2709.html I know that you have implemented a prototype for an earlier version of n2676 available at http://www.justsoftwaresolutions.co.uk/threading/updated-implementation-of-…. I would like to know which one will be reviewed? Do you plan to review your current Boost proposal and adapt it to the current C++0x proposal before the review. IMO, if you do that the review will be much more efficient. The current documentation includes often the C++0x interface and not the C++98 emulation. Do you plan to add it? before the review? In addition to the current reference, do you plan to add more documentation such as tutotial, examples, design rationale, implementation notes? before the review? I think restrictions/extensions to the standard should be stated explicitly. A comparaison of your implementation and the standard seems mandatory. * How move semantics is emulated (restrictions) * How the default constructed deleted functions are emulated (note that these are part of the interface) Next follows some differences that need attention (from http://www.justsoftwaresolutions.co.uk/files/n2561_future.hpp) ===== private: unique_future& operator=(unique_future& rhs);// = delete; versus public: unique_future& operator=(const unique_future& rhs) = delete; ===== wait_for, wait_until versus timed_wait, timed_wait_until ===== shared_future & operator=(const shared_future& rhs) = delete; versus shared_future& operator=(shared_future const& other); === shared_future(const shared_future& rhs); shared_future(unique_future<R>); shared_future(); shared_future & operator=(const shared_future& rhs) = delete; Versus shared_future(); ~shared_future(); // copy support shared_future(shared_future const& other); shared_future& operator=(shared_future const& other); ===== template<class> class packaged_task; // undefined template<class R, class... ArgTypes> class packaged_task<R(ArgTypes...)> { public: typedef R result_type; versus template<typename R> class packaged_task { HTH for the review, Vicente

1 0

[announce][flyweight] Boost.Flyweight added to the trunk
by JOAQUIN M. LOPEZ MUÑOZ 02 Dec '08

02 Dec '08

Hello, I'm happy to announce that Boost.Flyweight has been just commited to the SVN trunk, far too many months later than initially planned (but better later than never). The goal is to have the lib included in Boost 1.38, if its stability and the release manager permit. If you're interested in the Boost.Flyweight please update your SVN copy, play with the lib and report your comments/complaints. Thank you, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

1 0

Re: [boost] [Review] UUID library (mini-)review starts today, November 23rd
by Vladimir.Batov＠wrsa.com.au 02 Dec '08

02 Dec '08

Andy, >> ... > > The first thing that comes to mind is size. A uuid class that holds the > data at text ... > As a much more minor note, ... I thought you might jump on my mikki-mouse string-based UUID... and in fact it was a trap of a sort. :-) I had a strong impression that the discussion in this thread revolved too much about actual implementation (MAC retrieval springs to mind) and too little about the interface. Yes, the implementation is important but it is the interface that makes it or breaks it as far as user's acceptance is concerned. That (acceptance) buys you time to improve the implementation hidden behind the interface. My concern with the proposal is that IMHO the interface has not been given enough consideration from the user perspectives. > I agree that many users do not care about the algorithm used. If they > really don't care, is it an issue to use the > boost::uuids::uuid_generator > since they don't really care what it does anyway? I feel that "do not care" is an oversimplification. The user does care -- he wants the "best available" without getting bogged down investigating what that "best available" exactly is. That is what Linux uuid_generate() gives the user right out of the box. To be successful boost::uuid just has to match that offer. > I believe they would > just use this function and assume all is well. I have to disagree. As a user I do not want to *assume*. I want to *know* that my application uses the available infrastructure to the fullest. That way if/when something goes wrong, it'll the OS to blame and not my application. > Those who care will look > at what boost::uuids::uuid_generator does and decide for themselves. Unfortunately, the reality begs for correction. I do care. However, with dead-lines approaching and the boss breathing down my neck I simply have no resources to look at every damn thing to decide for myself. In fact, I do not want to as I expect much-smarter-than-me people to have taken care of that for me. Exactly as I do not try reinventing std::map (even though I am aware of other than red-black-tree algorithms available). > They will likely be happy as long as there are the options that they > want. Giving options is merely part of the deal -- people often hate choice/options as they have to stop/think/evaluate/decide -- that process in time-consuming and draining, it distracts people from their main task. The only option pretty much guaranteed to succeed IMHO is the "best available" option. > I do want boost::uuid to provide algorithms to create uuids. I don't > want platforms that don't provide an algorithm to not be able to easily > create a uuid. Thus I don't want boost::uuid to be just a wrapper > around > OS functionality. I do not think I said I wanted to see boost::uuid to be just a wrapper. In a nut-shell I'd like to see boost::uuid providing the user with the "best available" option. If that means Linux uuid_generate() or your own algorithm under the hood, then it's fine by me. > > Does boost::uuid provide superior support and a upgrade path? >> ... > > I would agree, that boost::uuid will never have the support of > industrial/commercial scale. I now think that boost::uuid should > provide > a windows_uuid_generator (that uses UuidCreate), a linux_uuid_generator > (that uses uuid_generate), plus possibility others platform specific > ones, > plus some of it's own. Then a boost::uuids::uuid_generator could use > one of these if available and if not, use it's own generator. This > would > give users the support and upgrade paths that you are talking about. Makes a lot of sense to me. Saying to the user -- Dear user, I've done the hard yards for you and I've come up with the best option available on your platform -- is a lot. I believe the overwhelming majority will be very happy. The curious ones (or with too much time :-) on their hands) will still be able to play with explicit uuid generators via "uuid id(some-generator);" > ... > I do believe that a null uuid is a valid uuid, but regardless, if the > common use case really is as you say, then sure lets have the default > constructor call a function to generate a unique uuid. And still > provide a way to create a null uuid. Please do not take my word for it. Just look around at your own usage pattern of the default constructor beyond the UUID domain. > My work also heavily relies on uuids, but we almost never create one > ourselves in code. We get almost all our uuids from the database > that our program uses. Understood. Our usage is pretty much the same. Still, if my component does not create UUIDs, then IMHO it has to state that with Foo() : uuid_(boost::uuid::null()) // initially invalid {} That way the other poor soul coming after me won't be getting any wrong ideas/interpretations what the code is actually doing. > I would be surprised if there aren't many > others that use uuids in the same way, they receive them, they don't > generate them. Understood. I do not believe you should be providing the default constructor for that usage pattern -- it feels like the copy constructor is in order here. All in all my impression of the *current* situation with the proposal is that at *present* we have many useful and promising bits and pieces lying around. I see good ideas. I see good suggestions. I fail to see the product. It surely is a good start but to me we have not reached the destination yet. I'd be more comfortable after I see those bits and pieces taking shape. For me that shape primarily would be the interface and the documentation -- the initial pieces of the contract between the user and the implementor. Once both parties are happy with the contract, you'll beaver away providing the content/implementation. Thanks, Vladimir.

2 1

Re: [boost] Boost CMake status?
by raindog＠macrohmasheen.com 02 Dec '08

02 Dec '08

There is a separate mailing list for the cmake effort that should answer your question. ------Original Message------ From: JOAQUIN M. LOPEZ MUÑOZ Sender: boost-bounces(a)lists.boost.org To: boost(a)lists.boost.org ReplyTo: boost(a)lists.boost.org Sent: Dec 2, 2008 11:50 AM Subject: [boost] Boost CMake status? Hi, I've discovered that the libs at the trunk are populated by files by the name CMakeLists.txt and module.cmake and I assume these belong to the once annonced effort to create a build infrastructure for Boost with CMake. I'd have several questions in this regard: 1. Is this effort active and supported? 2. If so, is it the responsibility of authors to update the existing CMake-related files and/or create them when commiting a new lib? 3. If so, are there any guidelines to do this? Thank you! Joaquín M López Muñoz Telefónica, Investigación y Desarrollo _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost Sent from my Verizon Wireless BlackBerry

1 0

Boost CMake status?
by JOAQUIN M. LOPEZ MUÑOZ 02 Dec '08

02 Dec '08

Hi, I've discovered that the libs at the trunk are populated by files by the name CMakeLists.txt and module.cmake and I assume these belong to the once annonced effort to create a build infrastructure for Boost with CMake. I'd have several questions in this regard: 1. Is this effort active and supported? 2. If so, is it the responsibility of authors to update the existing CMake-related files and/or create them when commiting a new lib? 3. If so, are there any guidelines to do this? Thank you! Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

1 0

[interprocess] map of vectors
by Jan Stetka 02 Dec '08

02 Dec '08

Hi, Is something like this likely to work? typedef interprocess::vector<int, ShmemAllocator> MyVector typedef std::pair<const long, MyVector> ValueType; typedef allocator<ValueType, managed_shared_memory::segment_manager> ShmemAllocator; typedef interprocess::map<long, MyVector, std::less<long>, ShmemAllocator> MyMap;

3 6

boost 1.37.0 and intel-linux-10.0
by frederic.bron＠alcan.com 02 Dec '08

02 Dec '08

I built boost 1.37.0 with intel-linux-10.0. I obtained the following output : "icpc" -c -xc++ -O3 -Ob2 -w1 -mp -march=pentium4 -DBOOST_ALL_NO_LIB=1 -DNDEBUG -I"." -c -o "bin.v2/libs/math/build/has_long_double_support.test/intel-linux/release/address-model-64/link-static/threading-multi/has_long_double_support> icpc: command line remark #10010: option '-Ob' is deprecated and will be removed in a future release. See '-help deprecated' I have also seen this: libs/math/build/has_long_double_support.cpp(9): catastrophic error: #error directive: "long double support is not supported by Boost.Math on this Plaform: the long double version of the TR1 library will not be built." #error "long double support is not supported by Boost.Math on this Plaform: the long double version of the TR1 library will not be built." ^ compilation aborted for libs/math/build/has_long_double_support.cpp (code 4) ...failed intel-linux.compile.c++ bin.v2/libs/math/build/has_long_double_support.test/intel-linux/release/address-model-64/link-static/threading-multi/has_long_double_support.o... Any risks using boost 1.37.0 with intel 10.0? Regards, F. Bron Avis : Ce message et toute pièce jointe sont la propriété d'Alcan et sont destinés seulement aux personnes ou à l'entité à qui le message est adressé. Si vous avez reçu ce message par erreur, veuillez le détruire et en aviser l'expéditeur par courriel. Si vous n'êtes pas le destinataire du message, vous n'êtes pas autorisé à utiliser, à copier ou à divulguer le contenu du message ou ses pièces jointes en tout ou en partie. Notice: This message and any attachments are the property of Alcan and are intended solely for the named recipients or entity to whom this message is addressed. If you have received this message in error please inform the sender via e-mail and destroy the message. If you are not the intended recipient you are not allowed to use, copy or disclose the contents or attachments in whole or in part.

2 1

[graph] Bundled properties, listS, listS, write_graphml
by remi.chateauneu＠gmx.de 02 Dec '08

02 Dec '08

Hi, I try to use boost::graph with two bundled properties, listS for vertices and edges, and serialize with write_graphml, and it does not compile: Boost 1.35 and 1.36, Windows Visual C++ 8.0 Here are the most important details of the code: class Host { int idx ; }; class SocketPair { int xxx ; }; typedef boost::adjacency_list< boost::listS, /// Needs stability of iterators. boost::listS, /// Needs stability of iterators. boost::directedS, Host, SocketPair > Graph; Graph gblGrf ; boost::dynamic_properties tmpDP ; boost::write_graphml( std::ofstream("xxx.xml"), boost::vertex_index_map( boost::get( &Host::idx,_gblGrf ) ), gblGrf, tmpDP ); Here is the beginning of the compile errors. Any idea, please ?? Thanks in advance 1>c:\program files\boost\boost_1_36_0\boost\graph\graph_traits.hpp(26) : error C2039: 'vertex_descriptor' : is not a member of 'boost::bgl_named_params<T,Tag,Base>' 1> with 1> [ 1> T=boost::bundle_property_map<boost::adjacency_list<boost::listS,boost::l istS,boost::directedS,Host,SocketPair>,void *,Host,int>, 1> Tag=boost::vertex_index_t, 1> Base=boost::no_property 1> ] 1> c:\program files\boost\boost_1_36_0\boost\graph\graphml.hpp(225) : see reference to class template instantiation 'boost::graph_traits<G>' being compiled 1> with 1> [ 1> G=boost::bgl_named_params<boost::bundle_property_map<boost::adjacency_li st<boost::listS,boost::listS,boost::directedS,Host,SocketPair>,void *,Host,int>,boost::vertex_index_t,boost::no_property> 1> ] 1> i:\remi\graph\graph\graph.cpp(435) : see reference to function template instantiation 'void boost::write_graphml<boost::bgl_named_params<T,Tag,Base>,Netstat::Graph> (std::ostream &,const Graph &,VertexIndexMap,const boost::dynamic_properties &,bool)' being compiled 1> with 1> [ 1> T=boost::bundle_property_map<boost::adjacency_list<boost::listS,boost::l istS,boost::directedS,Host,SocketPair>,void *,Host,int>, 1> Tag=boost::vertex_index_t, 1> Base=boost::no_property, 1> Graph=boost::bgl_named_params<boost::bundle_property_map<boost::adjacenc y_list<boost::listS,boost::listS,boost::directedS,Host,SocketPair>,void *,Host,int>,boost::vertex_index_t,boost::no_property>, 1> VertexIndexMap=Netstat::Graph 1> ] 1>c:\program files\boost\boost_1_36_0\boost\graph\graph_traits.hpp(26) : error C2146: syntax error : missing ';' before identifier 'vertex_descriptor' 1>c:\program files\boost\boost_1_36_0\boost\graph\graph_traits.hpp(26) : error C4430: missing type specifier - int assumed. Note: C++ does not support default-int 1>c:\program files\boost\boost_1_36_0\boost\graph\graph_traits.hpp(26) : error C2602: 'boost::graph_traits<G>::vertex_descriptor' is not a member of a base class of 'boost::graph_traits<G>' 1> with 1> [ 1> G=boost::bgl_named_params<boost::bundle_property_map<boost::adjacency_li st<boost::listS,boost::listS,boost::directedS,Host,SocketPair>,void *,Host,int>,boost::vertex_index_t,boost::no_property> 1> ] 1> c:\program files\boost\boost_1_36_0\boost\graph\graph_traits.hpp(26) : see declaration of 'boost::graph_traits<G>::vertex_descriptor' 1> with 1> [ 1> G=boost::bgl_named_params<boost::bundle_property_map<boost::adjacency_li st<boost::listS,boost::listS,boost::directedS,Host,SocketPair>,void *,Host,int>,boost::vertex_index_t,boost::no_property> 1> ] 1>c:\program files\boost\boost_1_36_0\boost\graph\graph_traits.hpp(26) : error C2868: 'boost::graph_traits<G>::vertex_descriptor' : illegal syntax for using-declaration; expected qualified-name 1> with 1> [ 1> G=boost::bgl_named_params<boost::bundle_property_map<boost::adjacency_li st<boost::listS,boost::listS,boost::directedS,Host,SocketPair>,void *,Host,int>,boost::vertex_index_t,boost::no_property> 1> ] 1>c:\program files\boost\boost_1_36_0\boost\graph\graph_traits.hpp(27) : error C2039: 'edge_descriptor' : is not a member of 'boost::bgl_named_params<T,Tag,Base>' 1> with 1> [ 1> T=boost::bundle_property_map<boost::adjacency_list<boost::listS,boost::l istS,boost::directedS,Host,SocketPair>,void *,Host,int>, 1> Tag=boost::vertex_index_t, 1> Base=boost::no_property 1> ] 1>c:\program files\boost\boost_1_36_0\boost\graph\graph_traits.hpp(27) : error C2146: syntax error : missing ';' before identifier 'edge_descriptor' 1>c:\program files\boost\boost_1_36_0\boost\graph\graph_traits.hpp(27) : error C4430: missing type specifier - int assumed. Note: C++ does not support default-int 1>c:\program files\boost\boost_1_36_0\boost\graph\graph_traits.hpp(27) : error C2602: 'boost::graph_traits<G>::edge_descriptor' is not a member of a base class of 'boost::graph_traits<G>' 1> with 1> [ 1> G=boost::bgl_named_params<boost::bundle_property_map<boost::adjacency_li st<boost::listS,boost::listS,boost::directedS,Host,SocketPair>,void *,Host,int>,boost::vertex_index_t,boost::no_property> 1> ] 1> c:\program files\boost\boost_1_36_0\boost\graph\graph_traits.hpp(27) : see declaration of 'boost::graph_traits<G>::edge_descriptor' 1> with 1> [ 1> G=boost::bgl_named_params<boost::bundle_property_map<boost::adjacency_li st<boost::listS,boost::listS,boost::directedS,Host,SocketPair>,void *,Host,int>,boost::vertex_index_t,boost::no_property> 1> ] 1>c:\program files\boost\boost_1_36_0\boost\graph\graph_traits.hpp(27) : error C2868: 'boost::graph_traits<G>::edge_descriptor' : illegal syntax for using-declaration; expected qualified-name 1> with 1> [ 1> G=boost::bgl_named_params<boost::bundle_property_map<boost::adjacency_li st<boost::listS,boost::listS,boost::directedS,Host,SocketPair>,void *,Host,int>,boost::vertex_index_t,boost::no_property> 1> ] 1>c:\program files\boost\boost_1_36_0\boost\graph\graph_traits.hpp(28) : error C2039: 'adjacency_iterator' : is not a member of 'boost::bgl_named_params<T,Tag,Base>' 1> with 1> [ 1> T=boost::bundle_property_map<boost::adjacency_list<boost::listS,boost::l istS,boost::directedS,Host,SocketPair>,void *,Host,int>, 1> Tag=boost::vertex_index_t, 1> Base=boost::no_property 1> ] 1>c:\program files\boost\boost_1_36_0\boost\graph\graph_traits.hpp(29) : error C2039: 'out_edge_iterator' : is not a member of 'boost::bgl_named_params<T,Tag,Base>' 1> with 1> [ 1> T=boost::bundle_property_map<boost::adjacency_list<boost::listS,boost::l istS,boost::directedS,Host,SocketPair>,void *,Host,int>, 1> Tag=boost::vertex_index_t, 1> Base=boost::no_property 1> ]

2 1