March 2009 - Boost - lists.preview.boost.org

BGL question about districting
by Barend Gehrels 06 Mar '09

06 Mar '09

Hi, We're about an automated districting tool. We want to create Y districts from X polygons, all having a specific value (e.g. area or inhabitants), where the total value of each district is as similar as possible and each district is also as similar as possible. Let's call the value the "potential". Of course this problem is NP-hard so we're glad with the first solution or e.g. the first ten solutions. We thought to implement this by the Boost Graph Library. First we detect neighbour relations with our own Geometry Library (using the still-to-build "touches" relationship). We've a graph then and can divide the graph into subgraphs, each having connected nodes and an (nearly) equal "potential". I've some experience with BGL, having used the "connected_components". But I cannot find an appropriate algorithm for this problem, if it is available. Actually it even could be a "network flow" algorithm dividing the total potential by Y, and starting at some point flowing the potential through the graph. But all network flow algorithms seem to be on directed graphs. This is an undirected graph. It it is not possible with a standard BGL algorithm I think we can still solve it using BGL and e.g. breadth-sort-first, but just want to verify if it is possible or maybe by an unexpected workaround. Thanks, Barend

4 5

Blocking Queue implementation in C++
by Filip Klasson 06 Mar '09

06 Mar '09

Hi, I need to create a Blocking queue implementation in *C++* with the help of Boost libraries and i am looking for some advise. What i need is a queue with linked nodes. The queue needs to be ordered as FIFO (first-in-first-out). I need the following functionality (Functionality from BlockingQueue implementation in Java) INSERT: Insert new items into the queue and if there is no space the queue needs to wait until space is available. RETRIEVE: Retrieve and removes the element that has waited the longest. If there is no elements in the queue it waits until an element becomes available. SIZE: Return the number of elements in the queue. POLL: The same as retrieve but only waits for a specified time for items to become available. I found a messageQueue that looks something like what i need (found here: http://www.boost.org/doc/libs/1_36_0/boost/interprocess/ipc/message_queue.h…) is that correct? /Filip

1 0

[itl] Preview 4 of the Interval Template Library
by Joachim Faulhaber 05 Mar '09

05 Mar '09

Dear list, I am happy to announce that the Interval Template Library (Boost.Itl) converges to a state, that conforms the standards of the boost libraries. It now contains substantial test suites and almost complete quickbook documentation. I hope it will soon be mature for a formal review after a last round of feedback and subsequent improvements. Since the last progress report in November last year the following work has been done. + Interoperability of interval_containers: Addition, subtraction, intersection and symmetric difference are now interoperable for all combinations of interval containers that make sense: You may for instance intersect a split_interval_map with an interval_map, an interval_set an interval or an element. + Added symmetric difference and renamed operators in accordance to other set class templates like e.g. boost::dynamic_bitset. + Introduced infix operators as itl::namespace global functions that are interoperable between interval_maps, sets, intervals and elements, so far as the combinations make sense. + Operators are now +=, +, |=, | : Set union / Map union with aggregation -=, - : Set difference / Map union with aggregation &=, & : Set intersection / Map intersection with aggregation ^=, ^ : Set symmetric difference / Map symmetric difference with aggregation. + Extended the test suite, specifically for the new operators and their overloadings. + Wrote quickbook documentation for the library. Please note that the original ITL as presented in May 2008 has been split into 3 parts and only the *first* part is prepared for boost now: itl : Core library, interval containers, PREPARED FOR BOOST itl_xt : Extensions like histories and generalized crosstables validate: The law based test automaton (LaBatea). A validation tool using laws aka axioms. So please focus on the core part (itl). Download the current version 'preview 4' from the boost vault's containers section: itl.zip http://www.boostpro.com/vault/index.php?action=downloadfile&filename=itl.zi… If you are interested in extended parts or LaBatea you may download all parts as itl_plus.zip http://www.boostpro.com/vault/index.php?action=downloadfile&filename=itl_pl… The quickbook generated documentation is included in the zip files and is also availabe online at http://herold-faulhaber.de/boost_itl/doc/libs/itl/doc/html/index.html Sources are also available form the sandbox: https://svn.boost.org/svn/boost/sandbox/itl/ The documentation has a focus on tree aspects (1) A short introduction, that wants to be easy to understand and to provide good and use case related examples: http://herold-faulhaber.de/boost_itl/doc/libs/itl/doc/html/index.html#boost… http://herold-faulhaber.de/boost_itl/doc/libs/itl/doc/html/boost_itl/exampl… (2) Synoptical representations that allows to see the complete 'picture' of the library. For instance the function matrix http://herold-faulhaber.de/boost_itl/doc/libs/itl/doc/html/boost_itl/interf… is supposed to give a complete overview over the most important functions across all itl containers. (3) A description of the semantics which is characterized by sets of laws that apply for the different interval containers. The semantical analysis, based on sets of laws, was a quite interesting work, where software development sometimes transformed into software discovery guided by the validation tool LaBatea ;) My main finding out of that process was, that the semantics of the aggregating itl::Maps is determined by the semantics of their data or codomain parameter U, so that if U is model of concept C then itl::Map<T,U> is model of C which is stated in section concept induction: http://herold-faulhaber.de/boost_itl/doc/libs/itl/doc/html/boost_itl/semant… All your feedback is welcome. Cheers Joachim

3 4

[time series] What happened to this library?
by Christian Henning 05 Mar '09

05 Mar '09

Hi there, as far as I can tell this lib has been approved but it doesn't show up in boost. Why is it not in there? Thanks, Christian

11 21

Trunk Inspection Report fixed + other reminders
by Beman Dawes 05 Mar '09

05 Mar '09

The trunk Inspection Report is now cycling daily, with a new URL. See http://boost.cowic.de/rc/inspect-trunk.html The release branch Inspection Report also cycles daily. See http://boost.cowic.de/rc/inspect-release.html The links to these and other useful "State of Boost" links are found at http://www.boost.org/development/testing.html --Beman

2 1

Submission of a new application to 'Who's Using Boost'
by Carlo Medas 05 Mar '09

05 Mar '09

Dears, this is a submission of a brand new free application which is using boost. It is also a chance to say thanks to you all. Boost is amazing and thanks to your excellent work we've been able not only to speed up the development but also to make the new app available on several platforms, without a huge effort. Application name: fing Company/team name: overlook App description: Fing is the ultimate command line tool for network and service discovery; born from the ashes of Look@LAN, it takes advantage of a brand new cross-platform network engine and reaches an impressive discovery sharpness and speed. Its network discovery reaches 100% hit in any ethernet-based network. Supported operating systems: Linux, Mac OS, Windows. Boost parts used: thread, system, filesystem, asio, multi-index containers, smart pointers, program options URL: http://www.over-look.com Thank you all once more for your great work, Overlook team Carlo Medas, Daniele Galdi, Marco De Angelis

2 1

Re: [boost] [math] Does any one interesting in calculating derivative for a expression automatically?
by Dongfei Yin 05 Mar '09

05 Mar '09

Hi Bruno, thank you for your interesting, I will try to use proto, I never use it before. yes, It's technically feasible. but the type of all the symbol in the expression can not be the build-in type. and gamma function should be a special version. integral is more difficult than derivative, else, to calculate the volume will be more easier. to simplify the expression is a interesting work. especially in compile time. BTW: I do not know how to upload source to this system, do you know how to do that? Dongfei. > >From my point of view, the main interest would be to compute > expressions containing some compile-time values provided by the user. > For example I want to calculate the volume of a hypersphere which is: > (pi^(N/2)*r^N) / gamma(N/2 + 1), with dimension N known at > compile-time. If the user happens to work only with N=2, that is > circles, I want the resulting expression to be as effective as a > hand-written pi*r^2 (the volume of a hypersphere<2> is the area of a > circle). It's technically feasible. > > Bruno > >

3 2

BoostCon '09 Sessions
by David Abrahams 05 Mar '09

05 Mar '09

Hartmut Kaiser and the BoostCon Program committee have done a stellar job assembling a list of sessions for this year's BoostCon, including everything from C++ compiler developer presentations, to hands-on C++0x development, to talks on eexperimental metaprogramming enhancements, to expression templates for running code on GPUs. I can honestly say I want to go to almost every session. It's going to be hard to choose. Please see the session list at: http://www.boostcon.com/program/sessions and then, of course, head on over to http://www.boostcon.com/registration to register for the conference. Best regards to all. See you there! -- Dave Abrahams BoostPro Computing http://www.boostpro.com

1 0

[serialization] string serialization
by Nikolay Mladenov 04 Mar '09

04 Mar '09

Hi, I the basic_binary_iprimitive.ipp (and I suppose other files) the size of the strings is serialized as std::size_t and not as serialization::collection_size_type. Is that intentional? Thanks, Nikolay Mladenov

4 11

Design conventions; passing functors
by Joachim Faulhaber 04 Mar '09

04 Mar '09

Hi, I am pondering about functor passing. Functors occur in my library (ITL) e.g. for the aggregation of associated values on insertion in interval_maps (aggregation on overlap): template<class Domain, class Codomain, ...> class interval_map{ ... //(1) My current implementation is this: // Combinator is the aggregating functor template, // instantiated at compiletime template<template<class>class Combinator> interval_map& add(const value_type& value_pair) { /*Combinator template passed or instantiated somewhere*/ } ... } //I like this definition, because it's abstract: // The functor has to be a matching template e.g. inplace_max interval_map<int,int> m; m.add<inplace_max>(some); //(1) template<class Domain, class Codomain, ...> class interval_map{ //(2) The more traditional definition template<class Combinator> interval_map& add(const value_type& value_pair) { /*Combinator type passed or called somewhere*/ } ... m.add<inplace_max<int> >(some); //(2) I prefer (1) but both definitions (1) and (2) are purely static denotations. To have adaptable functors or functors that can have states, like in ... m.add(some, max_under(42)); ... I am afraid I have to say sayonara to definition (1) and use this instead: template<class Domain, class Codomain, ...> class interval_map{ //(3) Adaptable functor template<template<class>class Combinator> interval_map& add(const value_type& value_pair, const Combinator<Codomain>& combine) { /*combine functor passed or called somewhere*/ } Now, there seems to be a convention from the STL that functors shall be passed BY VALUE. template<template<class>class Combinator> interval_map& add(const value_type& value_pair, Combinator<Codomain> combine); This is stated in [Sutter & Alexandrecu 2005, C++ Coding Standards] item 89: "Function objects are modeled on function pointers. Like function pointers, the convention is to pass them by value. All of the standard algorithms pass objects by value, and your algorithms should too." I do not really understand this convention and feel some resistance to follow it. In addition the call by value implementation can (and will) lead to heavy inefficiency by unaware usage of fat functors. So I browsed through some boost libraries and found that functors are passed by reference there (e.g. accumulators, fusion). Final question: What is the boost standard on passing functors, that I can adapt to? Cheers Joachim

6 20

[serialization] problems implementing free-standing functions
by Thorsten Ottosen 04 Mar '09

04 Mar '09

Hi, I'm having some annoying problems when implementing serialization for the attached class. Basically I define boost::serialization::load()/save(). I do just like done in e.g. boost.ptr_container, so I'm really confused about what's going on here. From the error message it looks like the free-standing functions are not found. Any help will be greatly appreciated. Thanks -Thorsten

3 12

[serialization] automation of class version sanity checking
by troy d. straszheim 04 Mar '09

04 Mar '09

Hey (Robert), Use case. It is possible (and does happen) that a user tries to deserialize version N+1 of a class C with software that only understands versions up to N. What typically happens is that C appears to deserialize OK, but it has eaten too many (or few) bytes from the archive. This means that the next class that gets loaded from the archive will fail in some unpredictable way. To deal with this we've started adding the following to all of our classes: struct C { double x; // this was present in version 0 double y; // this arrived with version 1 template <typename Archive> void serialize(Archive& ar, const unsigned int version); }; BOOST_CLASS_VERSION(C, 1); template <typename Archive> void C::serialize(Archive& ar, const unsigned int version) { if (version > 1) throw unsupported_version(version, 1); if (version == 0) ar & x; if (version == 1) ar & y; } ( Note the two arguments to unsupported_version ). This has the pleasant side effect of often catching errors in *other* classes. Eg if I'm trying to deserialize C and that exception is thrown, you can generate a message "trying to read version 3243856293 of class C, but I only know about version 0-1". Now I know that something has gone quite wrong, for instance someone has removed a member from my enclosing class without correctly incrementing and handling the version there, and what I've been given as 'version' is garbage. If the message is instead "trying to read version 4 of class C but I only know about versions 0-3", it looks like I simply need to update my software, nothing more sinister. This greatly simplifies these situations, which otherwise could spiral into a long, painful back-and-forth over a segfault in a serialization routine involving questions about what software the user has, where the data came from, what software was used to write it, etc. So: 1. I can't think of a situation where having file_version greater than BOOST_CLASS_VERSION isn't a catastrophic error. 1a. It'd be nice to configurably auto-check for this kind of versioning error. 2. As far as I can tell, these checks could be done cleanly inside the library, in serialize_adl() (?). 3. We don't actually use that unsupported_version exception, which takes no arguments and is thrown from serialization of variant (I wrote that and now find it confusing). I think the variant error should be specific to variant (or just totally generic), and unsupported_version should be used for the case currently under consideration... and to enable the 'pleasant side effect' above, I think the exception should carry the greatest version known to the code and the attempted-to-read version. Sanity check please, say so if you want me to try implementing... -t

2 2

Re: [boost] [optional_io] InputStreamable refinement
by Andrew Troschinetz 04 Mar '09

04 Mar '09

Just heard back from Robert, I figure it's ok to forward this information: On Feb 26, 2009, at 10:00 AM, Robert Ramey wrote: > The serialization library does no depend up optional or it's > implementation. If you > change the implemenation of optional, just make the changes > are consistent with the requirements of the serialization library. > > The fact that the serialization of optional is implemented and tested > as part of the serialization library is an anomoly. In fact, this > code and test should be moved into the optional library. I checked the optional test in the serializable library and it doesn't seem to even include optional_io.hpp. And given Robert's comments, it seems like it would be ok to make changes to optional_io.hpp. With respect to the change I suggested for operator>>() (I think in my last post I typoed and wrote operator<<(), I always get those silly things backwards!): In the case where we fail to extract optional<T>::value_type, I'm not sure what would be the best thing to do with respect to the position of the get pointer or other state bits. I had suggested this: if (in.fail () && !in.eof ()) { in.clear (); in.get (); } The intent of calling get() there is to enable this use case: stringstream sin ("one 2 three 4 five 6"); optional<int> i; while (sin >> i) { if (i) cout << "found int: " << i << endl; } // which finds 2, 4, and 6 But why move the get pointer up by one? Why one? Does this make sense? I can't provide a reasoning as to why it does, if it does. So another possibility is this: if (in.fail () && !in.eof ()) { in.clear (); in.setstate (std::ios::eofbit); } This has the added benefit of of making the following possible w/o any code change to lexical_cast: // doesn't throw, returns 0 lexical_cast<optional<unsigned> > ("-1").get_value_or (0); And if it's well documented that extracting an uninitialized optional<T> sets the eofbit on the istream, then a prudent user could (if they really wanted to) reformulate the first use case as: stringstream sin ("one 2 three 4 five 6"); optional<int> i; while (sin >> i) { if (i) cout << "found int: " << i << endl; else { sin.clear (); sin.get (); } } This leaves the why of moving the get pointer up to the user, where I think it really belongs. Because I can image some use cases where you'd want to do something other than just call get(). For example, maybe you'd want to call getline() and ignore an entire line before trying to extract another optional<T>. Or maybe you'd want to read until you found some delimiter before trying again. -- Andrew Troschinetz Applied Research Laboratories

4 9

boost versioned namespace ?
by Roland Schwarz 04 Mar '09

04 Mar '09

I am seeking advice on how I could package some of boosts libraries as part of a library I am writing. Given: "libboost_1_35" a boost lib at ver. 1_35 which is used by my "libmy". I need to be able to ship binary versions of "libmy" and "libboost_1_35". A customer writing an application "app" and using "libmy" and "libboost_1_39". The problem: libboost_1_39 and libboost_1_35 likely will have common symbols, which either prevents the customer to use 1_39 or forces me to also upgrade to 1_39 (altough everything is fine with 1_35). The questions: What would boosters recommend? Is there a way to use kind of a versioned boost namespace? Regards, speedsnail

3 4

Re: [boost] An extension to boost::variant
by Catalytic 04 Mar '09

04 Mar '09

Chris Hamilton-3 wrote: > > While boost::variant is very capable at what it does, there is one thing > it doesn't do .. > > ..My question is this: why can't boost::variant be clever about reference > data types.. > > The reason I want this, is to have a nice String variant, that > encapsulates the various forms a string can take in a current project: > std::strings, char*'s, and std::string* and > boost::shared_ptr<std::string>. I want functions to be able to handle > all of these types transparently by using variants as the argument > types. Allowing "const std::string&" as a variant type allows this to > be done while not requiring a wasteful string copy. > .. > (I have a small custom variant class implementing this, and it appears > to work well. It's not as 'full fledged' as the boost::variant class, > but the approach I've taken could surely be grafted on to boost::variant.) > > An example will be better than a lengthy explanation, please have a look at the test-cases in the boost distribution: libs/variant/test/: specially variant_reference_test.cpp IMHO, it will answer all your queries. -Cat -- View this message in context: http://www.nabble.com/An-extension-to-boost%3A%3Avariant-tp21881442p2189668… Sent from the Boost - Dev mailing list archive at Nabble.com.

5 13

Re: [boost] [math] Does any one interesting in calculating derivative for a expression automatically?
by Dongfei Yin 04 Mar '09

04 Mar '09

Hi John, 1. I have tried that if you write d(d(d(d(x*x*x*x, x), x), x), x), it will take a long compile time without optimized. I have do something to optimized it. I need to write a lot of specialized template class for most of the operators. 2. Because of the C++ grammar, I think it can just accept expression like C++ style. think about operator^, the priority is lower in C++ than in math. 3. As I said, high derivative will cost lots of compile time without "simplify", so you are right, the expression should be simplified. but at compile time, it is a little difficult to do it, but I'll do my best to optimized it. Dongfei. > Good idea, and this is all very neat, but I see a couple of issues: > > 1) Compile times for a compile time derivative is likely to be slow? > 2) Isn't it easier to just calculate the derivative within a symbolic math > package and then cut and paste the result into your code (Yacas is free for > example)? > 3) What happens for very complex expressions? Can the compile time code > simplify the resulting derivative so that it is optimally evaluated? Most > symbolic math packages will have a "simplify" function that does just that, > without it, code might be very inefficient to evaluate, with it, compile > times might be way too long :-( > > Regards, John. >

2 1

Re: [boost] [math] Does any one interesting in calculating derivative for a expression automatically?
by Dongfei Yin 04 Mar '09

04 Mar '09

Hi Mukkul, I have implement the trigonometric terms. only sin and cos. it can add new operator into it easily. this expression d(cos(_x * _x) , _x) will return a functor, at last, the computation is done by std::sin : ) Dongfei. > HI Dongfei, > > I am interested in it. But what the plan is exactly ? How you are going to do it > for say expressions involving trigonometric terms ? For polynomial expressions > things are manageable, how you are going to parse other complex expressions ? > > BTW how you are going to take care of algebra at many places ? > > With Regards, > Reetesh Mukul >

1 0

Re: [boost] [math] Does any one interesting in calculating derivative for a expression automatically?
by Dongfei Yin 04 Mar '09

04 Mar '09

Hi Kasra, I am very glad that you are interesting in it. Now, it can just calculate polynomial, and sin, cos. what should I do to upload the source? I am not so familiar with this system. Dongfei. > I think the function are rather interesting in fact I really like differential calculations with the way you have implemented it. > > If you give more information about your implementation maybe we could work something out. > > > -- Kasra >

1 0

[math] Does any one interesting in calculating derivative for a expression automatically?
by Dongfei Yin 04 Mar '09

04 Mar '09

Hi, Recently, I am working on some mathematical issues, most of my working time, I am calculating the derivative of function manually, it is such a tedious work that I write a piece of code to do it for me. now I want to share it with others. Let me show it for you. it it something like lambda expression, I mean boost::lambda. but the main purpose is to calculate derivative. As lambda do, I defined some variables like _x, _y in advance. A function named "d" can calculate derivative. then we can use it like this. d(_x * _x , _x)(1.0); // f(x)=x*x, f '(x) = 2x. so the result will be f '(1.0) = 2.0. d(d(_x * _x, _x), _x)(4.0); // f(x)=x*x, f ''(x) = 2, so the result will be f ''(4.0) = 2.0; this argument is just used to determine the return type. of cause it can work with more than one variables, such as, d(_x * _y, _x)(2.0, 1.0); // f(x,y)=x*y, f 'x(x,y)=y, so the result will be f 'x(x,y)=1.0; // the first argument will be ignored. d(d(_x * _y, _x), _y)(1.0); // f(x,y)=x*y, f ''xy(x,y)=0, so here one or two argument are all OK. and it can calculate derivative for some complicated expressions. theoretically, it can calculate high derivative for a expression as high as you want until the expression become zero. I want to share it with others, but it is not so perfect now. I need some suggestion to make it better. by the way, I am a new face, and English is not my native language, so if I did not explain some thing clearly, please do ask me. I will do my best to clarify.

5 4

[convert] Default Syntax Idea
by Stewart, Robert 04 Mar '09

04 Mar '09

I was thinking a bit about syntax for the default value for the notional boost::convert() and kin. How about the following: int const i(3); string const s("something"); int const j(convert<int>(s) | 5); convert<DestType,SourceType>(SourceType) can return a type which throws on failure in operator DestType(), but has an operator |(SourceType) which returns a second type constructed with the SourceType value. The second type provides its own operator |(SourceType) which returns that value in its operator DestType() on failure. Returning a default value in lieu of an exception is a special case; it ought not be treated like formatting. Thus, while Boost.Parameter might be appropriate to package the extra information desired for formatting, I don't like the idea of writing "default_ = 5" in the call, and I don't think ", 5" in the argument list is as clear as it could be. The syntax above is obvious and concise while being distinct from whatever may be done for formatting. _____ Rob Stewart robert.stewart(a)sig.com Software Engineer, Core Software using std::disclaimer; Susquehanna International Group, LLP http://www.sig.com IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.

9 32

[thread] thread-safe static local
by Oliver Kowalke 04 Mar '09

04 Mar '09

Hi, I need a function 'get_default_X()' returning a reference to a singleton in a multithreaded env. I choosed Scott Meyers singleton pattern (static local) together with boost::call_once(). My this be a reasonable, threadsafe implementation? regards, Oliver -- Computer Bild Tarifsieger! GMX FreeDSL - Telefonanschluss + DSL für nur 17,95 ¿/mtl.!* http://dsl.gmx.de/?ac=OM.AD.PD003K11308T4569a

5 5

Boost.Test: documenting a little Mac OS X usage nit
by Owen Smith 03 Mar '09

03 Mar '09

Greetings! I'd like to present a little tiny puzzle that took me an embarrassingly long time to solve--a year, to be specific. (OK, maybe a day poking around, followed by a year being buried in the bug queue. :-) ) With this comes a couple of requests for the Boost.Test documentation. If i understand correctly, the Boost.Test library boost_unit_test_framework is a little bit odd in that the static version of the library carries a main() routine (which I intend to take advantage of) whereas the dynamically linked version does not. In Mac OS X, with the standard MacPorts installation of boost, this poses a problem because both static and dynamic libraries are built and installed to the same location. When linking with gcc using my usual -L and -l options, given the choice, the linker will always select the dynamic library, and I will be missing my main(). (I should point out this would be a non-issue if the main() routine were in a different library that you could choose to include or not include as you wish, but I'm assuming this battle has long since been fought and resolved.) First, I know the main() issue has been mentioned many times on the list before, but I couldn't find any documentation of it in the 1.38.0 manual. This seems like a significant issue to document--am I just missing it somewhere? Second, the best workaround we found for this problem was to explicitly select the static library by foregoing the -L and -l options and directly specifying <full-path>/libboost_unit_test_framework-mt.a as one of the linker arguments. And this is what I'd like to see documented--either as a footnote to "Unit Test Framework > User's guide > Usage variants > Static library", or maybe as part of the topic "Unit Test Framework > Usage recommendations > Generic". I'm happy to prepare documentation patches if desired. Thanks! -- O

1 0

[math] Does any one interesting in calculating derivative for a expression automatically?
by Kasra 03 Mar '09

03 Mar '09

Hi, I think the function are rather interesting in fact I really like differential calculations with the way you have implemented it. If you give more information about your implementation maybe we could work something out. -- Kasra

1 0

boost::bind, problem with result type deduction and calling conventions
by Ingo.Loehken＠boc-eu.com 03 Mar '09

03 Mar '09

hi, anybody able to explain, why the code for the result type, related to special calling conventions defines an void return type ? template< class R, class T > struct add_cref< R (T::*) (), 1 > { typedef void type; }; so that code like class A { public: int __stdcall x() { return 0; } void const y() {} explicit A() { typedef boost::function<int()> fun_t; fun_t const f(boost::bind(&A::x,this)); } }; ends up with an warning at bind 1>G:\boost\boost_1_37_0\boost/bind.hpp(1643) : warning C4180: qualifier applied to function type has no meaning; ignored 1> G:\boost\boost_1_37_0\boost/bind.hpp(1682) : see reference to class template instantiation 'boost::_bi::add_cref<Pm,I>' being compiled 1> with 1> [ 1> Pm=int (__stdcall Ado::A::* )(void), 1> I=1 1> ] 1> G:\dev\workspace\files\ado\ado_bind.hxx(36) : see reference to class template instantiation 'boost::_bi::dm_result<Pm,A1>' being compiled 1> with 1> [ 1> Pm=int (__stdcall Ado::A::* )(void), 1> A1=Ado::A * 1> ] because the proposed specialization is not choosen by the compiler. Adding an __stdcall to the function signature type in add_cref fixes that problem, but still i do no understand, why the defintion is not like template< class M, class T > struct add_cref< M (__stdcall T::*) (), 1 > { typedef M const& type; }; and of course that fix is only applicable for __stdcall, where specialzations for other calling conventions can easily be generated, like for mem_fn_cc in respect to requested support for calling conventions. Thanks for your help, ILo. compiler : msvc 8.0 library : boost 1.38

2 1

Headers erased after the first building in VC8 of boost 1.38
by Trimoldi, F. (Filippo) 03 Mar '09

03 Mar '09

I generated a Boost.sln solution for VC8 with the new system CMake. ( using this command: cmake -DCMAKE_IS_EXPERIMENTAL=YES_I_KNOW CMakeLists.txt in root directory of the boost ) When I try to build the entire solution all thinks goes good without problem. But only the first time. In fact, at the end of this first building all the headers are erased from the boost the directory. So I cannot make another building and I have to recover the headers file by other ways. Have you got the same problem? This e-mail and its contents are subject to the DISCLAIMER at http://www.tno.nl/disclaimer/email.html

2 1