- Boost - lists.boost.org

help with including boost.log into the current trunk
by Bernd Prager 10 Apr '11

10 Apr '11

I would appreciate some help in including the logging libs into the boost compilation process. I am using the recent SVN trunks, Cygwin 1.7.9 and g++ (GCC) 4.3.4. Unfortunately there is nor README or INSTALL docs as I am used to in a GNU automake environment. So I tried my best based on what I found google-ing it: I downloaded the current boost SVN trunk and the current boost-log SVN trunk. Then I linked the log directories into the boost trunk: $ ln -s boost-log/trunk/boost-log/libs/log/ boost-trunk/libs/ $ ln -s boost-log/trunk/boost-log/boost/log/ boost-trunk/boost/ Compiling boost with normal ./bjam does not recognise the log components at all: ... Component configuration: - chrono : building - date_time : building - exception : building - filesystem : building - graph : building - graph_parallel : building - iostreams : building - math : building - mpi : building - program_options : building - python : building - random : building - regex : building - serialization : building - signals : building - system : building - test : building - thread : building - wave : building ...patience... Explicitly including it gets me an error message: $ ./bjam.exe target-os=cygwin --with-log error: wrong library name 'log' in the --with-<library> option. What am I missing? Is there an easier way to do it? Thanks a lot for any help. -- Bernd

3 2

Proposed Library Boost.Algorithm
by Marshall Clow 09 Apr '11

09 Apr '11

(Finally) I have uploaded to the vault <http://www.boostpro.com/vault/index.php?action=downloadfile&filename=Boost.…> a proposal for the Boost.Algorithm library. This has been a matter of interest and discussion for a long, long time. Some of this code was written during the "Library in a week" session at BoostCon 2008. More was written last summer after this year's BoostCon. There is no way that I can write and submit all the algorithms that people want/need/are interested in, so I am proposing to set up a system by which people can submit algorithms to be included in the library, and have them reviewed, much like how new libraries are reviewed for acceptance into boost. The difference will be that a new algorithm is generally a much smaller piece of code than a new library, so hopefully we can lower the barrier to getting small pieces of code into Boost. So, what's in this proposal? 1) Three search algorithms: Boyer-Moore, Boyer-Moore-Horspool and Knuth-Morris-Pratt. (search.hpp) 2) A set of predicates for determining if a sequence is ordered (by some criteria) (ordered.hpp) Originally written by Grant Erickson during the "Library in a week" session at Boostcon 2008, and reworked somewhat by myself. 3) A set of predicates for determining other properties of a sequence, based on some suggestions for C++0x. (all.hpp) 4) An algorithm for restricting a value between two endpoints (clamp.hpp) And, of course, test cases and documentation. -- Marshall

6 13

Re: [boost] [lexical-cast] version of lexical_cast in 1.46.1 is quite older than in trunk
by Antony Polukhin 09 Apr '11

09 Apr '11

> On Wed, 2011-03-30 at 18:16 +0300, Matthew Chambers wrote: >> Does that mean lexical_cast is orphaned? I'd like to see lexical_cast have optimized conversions for >> string->number and number->string (template specializations using strtol/strtod; or optionally using >> the spirit-based construe_cast). Being able to pass ios flags to control the format (i.e. boolalpha) >> would be nice too [...] >> Which reminds me - lexical_cast error messages are not very >> informative[...] > >Agreed. This should be added as well[...] > >-Matt Added some optimizations for casts to integral types ( you can see them in tickets #5417 and #5350). Did not used strtol/strtod (it will be hard to implement tags/ios flags if we`ll use them, hard to detect overflows), did not used spirit library (it`s too big, includes too many files, and looks like it`s API changes often). Alexander Nasonov wrote: >Stewart, Robert wrote: >> Not true. You and others will benefit from the patches. First, they can be applied manually to local Boost installations, even if they aren't part of a Boost release. Second, others, with commit permission, can apply the patches even without an active maintainer if they are sufficiently comfortable with doing so (and there's enough noise to get their attention). Besides, you could volunteer to be the maintainer! > >No objections from me (the current maintaier). I don't have time for >this any more. > >Alex If there will be no active maintainer, I`d like to have at least commit permissions to lexical_cast library (if nobody has objections). I`ve got some ideas on implementing tags/ios flags and there are some more possible optimizations for float types and locales usage. So, is there any volunteers to be the maintainer? - Antony

5 10

Re: [boost] [range] for_each and std::map of std::list
by Jeremy Maitin-Shepard 09 Apr '11

09 Apr '11

On 04/07/2011 04:39 AM, Mathias Gaunard wrote: > On 07/04/2011 12:56, Thorsten Ottosen wrote: > >> Well, that is only a problem if you want to avoid manually applying the >> adaptor twice (or more), right? >> >> If so, I think that is a limitation we can live with. A simple solution >> covers most cases IMO. > > Oh, the adaptor I wrote flattens recursively. > > I guess just flattening the top level could be fairly easy. You could also require that the user specify the number of levels of recursion explicitly, as in many cases the final value_type you want to iterate over may be a range itself. Consider, for instance, that a string is itself a range of characters, but in many cases the user would not want to flatten a range of strings into a range of characters.

4 3

GSoC 2011,Graph library
by Sultana Rashid 09 Apr '11

09 Apr '11

I am Mariya Zaman.I am in the 6th semester in Bangladesh University of Engineering and Technology.My subject is CSE. I study a lot about your libraries.I saw ideas on graph in 2010 GSoC.I had studied graph theory,algorithm engineering.One of my interests is planar graph. I have found that some features may be added in your graph library.As: 1. For max flow and min cut Ford-Fulkerson and Dinitz Blocking Flow algorithms. 2. Fow min cut, the library has only Stoer Wagner algo.There are several randomized algo with high success rate as Krager's contraction or Recursive Contraction algo.These can be added. 3. Check if a graph have an Euler tour and find one and/or all possible Euler tours. 4.There are nine algorithms implemented on Planar Graph.We can implement some more algorithms as there exists a lot of algorithms on it. I have details plan on every topic.So I am just curious if you are interested in these types of algorithms.I thought you might be interested.So if you express interest on any topic,please let me know.I am eager to send you details. Thanking You, Mariya

3 2

[network] cpp-netlib v0.9-beta out now!
by Dean Michael Berris 09 Apr '11

09 Apr '11

Hi Everyone, Apologies for the cross-post, but I just want to announce that after a couple months delay because of some outstanding bugs and TODO items that needed to get dealt with, I am now ready to package a 0.9 release and with that in mind I've just uploaded the 0.9-beta release of cpp-netlib. When the beta period (1 week) is over and all outstanding bugs are addressed, the 0.9 release will be the basis for submission for review to the Boost C++ Library. You can get the beta from: https://github.com/cpp-netlib/cpp-netlib/downloads What's New in 0.9 (taken from the documentation): - IMPORTANT BREAKING CHANGE: By default all compile-time heavy parser implementations are now compiled to external static libraries. In order to use cpp-netlib in header-only mode, users must define the preprocessor macro BOOST_NETWORK_NO_LIB before including any cpp-netlib header. This breaks code that relied on the version 0.8.x line where the library is strictly header-only. - More consistent message API for client and server messages (request and response objects). - Refactoring of internal implementations to allow better separation of concerns and more manageable coding/documentation. - Client and Server constructors that support Boost.Parameter named parameters. - Client and Server cosntructors now take in an optional reference to a Boost.Asio io_service to use internally. - Documentation updates to reflect new APIs. This Beta has been tested mainly on Linux (GCC 4.4, 4.5) and Mac OS X (10.6.7, Xcode 3.2.x w/ GCC 4.2.1) builds against Boost trunk and Boost 1.45. Note that cpp-netlib does NOT work with Boost 1.46.1 because of some breaking changes in the Boost.Spirit customization points have caused cpp-netlib to cease to play well with it. That said, the issues have been addressed in Boost trunk and should be fixed in Boost.147. Thanks to everyone who contributed to making this Beta possible, namely Emre Turkay, Oleg Malashenko, and other users that filed issues on the Github issue tracker. Have a good day everyone and I do look forward to feedback! -- Dean Michael Berris http://about.me/deanberris

2 4

[context] missing part
by Oliver Kowalke 09 Apr '11

09 Apr '11

Hi, my previous message was incomplete - sorry: The modifications requested by the reviewers are incorporated into boost.context - available at git://git.gitorious.org/boost-dev/boost-dev.git (branch context-dev) @Vicente: I've send you several emails without response - possibly your ISP filters my emails (SPAM)? regards, Oliver - context: - stack unwinding: bool context::finished() const indicating that the called function has finished -> stack already unwinded void context::unwind_stack() jump back into context and throw a special exception -> stack will be unwinded (requires that no try/catch(...) was used) - context is now moveable - is not a template == the stack type is only passed/known in the templated ctor - the function to be called by the context is not saved on top of the stack - exceptions replaced by assertions / exceptions.hpp removed - fcontext_t used as default implementation; ucontext_t only fallback for platforms not supported by fcontext_t - on Windows Win Fiber API is used as default - protected stack: - keyword explicit added to ctor - public static members min_stacksize, max_stacksize, default_stacksize - fcontext_t renamed to boost_fcontext_t, boost_fcontext_get(), boost_fcontext_set(), boost_fcontext_jump(), boost_fcontext_make() -> move into global namespace - i386 ASM preserves SSE2 control/status word - x86 ASM uses indirect jump for boost_fcontext_set() and boost_fcontext_jump()

1 0

[phoenix] typo in doc
by Thomas Klimpel 09 Apr '11

09 Apr '11

In Table 1.7. Iteration Algorithms on <http://www.boost.org/doc/libs/1_46_1/libs/spirit/phoenix/doc/html/phoenix/a…> This first line of the table reads: for_each(r, c) for_each(begin(r), end(r), f) but I guess it should be: for_each(r, f) for_each(begin(r), end(r), f) Regards, Thomas

2 1

[QNX] Which macro to identify QNX operating system?
by Beman Dawes 08 Apr '11

08 Apr '11

Does anyone with QNX experience know if __QNX__ or __QNXNTO__ is preferred? Both are used in Boost code. Does it matter? Are the impacts the same for both GCC and Intel compilers? Are any other compilers used on that platform? For example, Watcom? --Beman

1 1

Re: [boost] [Boost][GSoC] Checks and hashes proposal
by Pierre Talbot 08 Apr '11

08 Apr '11

Well, I just modify the "specifics" because I don't have time to re-structured all the proposal. Thank you for those precisions. I join the skeleton library I coded few days ago. EDIT : I couldn't join it because the message exceed 75KB, so I uploaded it, please download the file with the following link : http://www.mediafire.com/file/0odobkg11p2uvda/checks_hashes_project.zip 2011/4/8 Pierre Talbot <pierre.talbot.6114(a)herslibramont.be> > Well, I just modify the "specifics" because I don't have time to > re-structured all the proposal. > > Thank you for those precisions. > > I join the skeleton library I coded few days ago. > > > 2011/4/8 Scott McMurray <me22.ca+boost(a)gmail.com> > >> On Fri, Apr 8, 2011 at 07:19, Pierre Talbot >> <pierre.talbot.6114(a)herslibramont.be> wrote: >> > >> > I wrote my proposal and posted it on the GSoC website, any feedbacks or >> > comments are welcomed. >> > >> >> You mix four distinct things in one: ISBN/EAN/VISA/etc, for catching >> human-entry errors; hash functions as in hash tables, which only care >> about distribution; checksums like CRC32, for catching data >> transmission errors; and cryptographic hash functions, the only ones >> useful against malicious adversaries. >> >> The summer is short, and the boost process is long. I'd encourage you >> to look only at the first category. As you mention, it's the one with >> the fewest alternative libraries, so you won't have to prove >> competitive performance and such, and there are no real security >> issues to deal with. >> >> Also, I'd like to see some sketches of interfaces. What do you expect >> user code to look like? >> >> A few specifics: >> >> "This kind of drama situation can be avoided by storing encrypted >> passwords." >> Encrypted means cyphers, not hashes. You want digests or MACs of >> passwords, not something reversible. >> >> "Write, test and document the hash functions MD5 and SHA-1 256 bits." >> There's no such thing as 256-bit SHA-1. Do you mean SHA-256, from >> "SHA-2"? >> >> Also, MD5, SHA-1, and SHA-2 are implemented in my hash library: >> <http://svn.boost.org/svn/boost/sandbox/hash/boost/hash/md5.hpp> >> <http://svn.boost.org/svn/boost/sandbox/hash/boost/hash/sha1.hpp> >> <http://svn.boost.org/svn/boost/sandbox/hash/boost/hash/sha2.hpp> >> >> ~ Scott >> _______________________________________________ >> Unsubscribe & other changes: >> http://lists.boost.org/mailman/listinfo.cgi/boost >> > >

1 0