April 2010 - Boost - lists.preview.boost.org

[GSoC]Bits and Ints
by shiyang yang 10 Apr '10

10 Apr '10

Hi I have been working on the proposal of this project, but still have some questions, could anyone please give me some help? For the bits part, what does the 'compressed' mean, what is the main difference between the array, vector and the normal ones? Is there any other existing integral special functions that mentioned in the second part? Where can I find them? Thanks a lot Shiyang Yang

3 2

Re: [boost] Boost.Botan final proposal
by Chad Seibert 10 Apr '10

10 Apr '10

Hi, Perhaps this link will work: http://socghop.appspot.com/gsoc/student_proposal/show/google/gsoc2010/chads… Thanks to all who gave advice, please ask if you have any questions! Chad Seibert _________________________________________________________________ The New Busy think 9 to 5 is a cute idea. Combine multiple calendars with Hotmail. http://www.windowslive.com/campaign/thenewbusy?tile=multicalendar&ocid=PID2…

3 2

Message Hashing Interface (SHA-1/256/384/512, MD4/5)
by Scott McMurray 10 Apr '10

10 Apr '10

I wrote up some SHA message hashers recently, which came out rather nicely using templates to handle the commonalities between SHA-1/256/384/512. The one issue that came up is how to handle retrieving the hash from the accumulator. When working with just the raw SHA compressor it's not a problem, but when hashing messages, getting the hash of the message requires appending padding and a length. That means that SHA and MD[45] hashing cannot use the same simple interface of Boost.CRC that, in essence, consists of calling process_byte() and inspecting the cheap, const member function hash() as needed. Here are a couple of options: 1) The hash() function is non-const, and it appends the passing and length, calculates the hash, and resets the accumulator to be ready for the next message. This is perhaps the most efficient interface. 2) The hash() function is const, and copies the accumulator, then pads and length-appends the copied version, getting the hash from there instead. That gives perhaps the nicest interface, but the extra copying would be somewhat expensive. That said, it's overhead per message, not dependant on the length of the message, so it may be acceptable. Also, the hash function would still be quite expensive, contrary to usual expectations for const member functions. 3) The hash() function is just a cheap const that returns the current state of the compressor. This would require an additional end_of_message() function that would apply the padding and probably things up such that the next process_byte function would start a new message by resetting the compressor. That would allow the hash() function to be cheaply called as many times as desired between calling end_of_message() and providing the data for the next message. One big problem with this one is that hash() can be called after providing data but before calling end_of_message(), at which point is return value is essentially useless. I think I like (1) best, because it allows the user to copy it and get (2) if they'd rather, and doesn't have the potential call sequencing problem of (3). Any opinions, suggestions, alternatives, or comments? ~ Scott McMurray P.S. Yes, the point here is to create Boost.MD and Boost.SHA libraries. The first client would be Boost.UUID to allow it to offer the MD5 name-based UUIDs it currently cannot. It needs a hashing concept so that it can parametrise name_generator similarly to how it currently parametrises basic_random_generator [1]. [1] http://www.boost.org/doc/libs/1_42_0/libs/uuid/uuid.html#Random%20Generator

5 13

Log/tropical semiring for boost math
by Alex Graves 10 Apr '10

10 Apr '10

Hi, I work in machine learning, and often need to do probability computations in the log scale to avoid underflows. A nice way to do this is to use a class where the add, divide etc. operators are overloaded by their log scale equivalents (e.g. log(a*b) = log(a) + log(b)). In other words a class implementing the log semiring <http://en.wikipedia.org/wiki/Semiring>. Also useful in this context is the tropical semiring, where adding is replaced by taking the maximum (or minimum) of the arguments. I looked for these in the boost math library, but couldn't find anything. So I wrote my own. Did I miss something? And if not, is anyone interested in adding my implementation to boost math? Alex

2 1

Phoenix.bind VS Lambda.bind
by Alexey Tkachenko 10 Apr '10

10 Apr '10

Hi, Now I'm looking at Phoenix and Lambda libraries. Could somebody explain why Lambda allows to use the following expression: void foo(int) { ... } ... bind(foo, _1)(10); yet Phoenix does not. Phoenix requires to use helper variable: void foo(int) { ... } ... int i = 0; bind(foo, _1)(i); I've read document about "Forwarding Function Problem" (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2002/n1385.htm) I understand the core issue, but how does Lambda.bind solve it? Thank you, Alexey.

4 4

[serialization][1_42_0] basic_binary_oarchive - warning: comparison is always true due to limited range of data type
by Jeff Flinn 09 Apr '10

09 Apr '10

basic_binary_oarchive.hpp has this member: void save_override(const class_id_type & t, int){ // upto 32K classes assert(t.t <= boost::integer_traits<boost::int_least16_t>::const_max); const boost::int_least16_t x = static_cast<const boost::int_least16_t>(t.t); * this->This() << x; } It doesn't seem that there is a need for this runtime assert at all given the definition: BOOST_ARCHIVE_STRONG_TYPEDEF(int_least16_t, class_id_type) Can't the assert be removed to quiet the gcc warning? Jeff

3 4

[utility/value_init] boost::value_initialized<T> direct-initialized?
by Niels Dekker - address until 2010-10-10 09 Apr '10

09 Apr '10

Can anybody please have a look at the following feature request by Edward Diener? https://svn.boost.org/trac/boost/ticket/3472 He proposed to add an explicit constructor, value_initialized(T const&), to boost::value_initialized<T>. This constructor would copy the value of its argument to the object held by value_initialized<T>. When such a constructor would be added, an object held by value_initialized<T> might no longer be value-initialized. Instead it might be direct-initialized. Does anybody have any moral (?) objections against the idea that value_initialized<T> might hold a non-value-initialized object? Personally I think it would be useful to allow the wrapped object to be direct-initialized. But I do think there's a small risk that the new explicit constructor might cause ambiguities in legacy user code. Therefor I suggested adding an extra "tag" parameter to the new constructor, of a new type, boost::direct_initialized_t: struct direct_initialized_t { }; value_initialized(T const&, direct_initialized_t) Does anyone else also think that's a good idea? Or does anyone prefer the explicit value_initialized(T const&) constructor originally proposed by Edward? See also the thread starting at: "Re: [boost] Transfer of Maintenance Rights (utility/value_init)" http://lists.boost.org/Archives/boost/2010/03/164125.php Kind regards, Niels -- Niels Dekker http://www.xs4all.nl/~nd/dekkerware Scientific programmer at LKEB, Leiden University Medical Center

6 32

xml?
by Maarten L. Hekkelman 09 Apr '10

09 Apr '10

Hi, I saw there was some discussion on this list regarding an XML library. I wrote a C++ based XML library recently as part of the work I do on e.g. MRS, a full-text retrieval system for biological databanks. (See http://mrs.cmbi.ru.nl/ ) I extracted the XML and SOAP code from the MRS project and wrapped it into a new library. This library is called libzeep and I've put the code on Berlios (http://libzeep.berlios.de/) License is Boost. The library currently consists of: - a SAX parser with validation support based on DTD. - a simple XML library for nodes, elements, etc. - an XML writing utility/wrapper. - an xpath implementation And then the code contains a full high-performance SOAP server implementation. This code generated all SOAP related code and WSDL generator code based on the signature of exported server methods. No need to run a separate code generating tool. Network code is based on asio and I've implemented an optional pre-forked mode of operation. A previous version of libzeep is in production use for over a year now and I recently added the parser and xpath stuff to be able to drop libxml2 from the requirements for MRS. Code comes with quite a few test sets. Documentation is not updated yet for the parser and xpath but there is some for the SOAP part. I need to do a bit more testing before I can release a new version. My question now is, would this library be of interest to Boost? Perhaps it can be used, or parts of it can be recycled. And if there is interest, I'm sure there must be suggestions for improvement. You can browse the code at https://svn.cmbi.ru.nl/libzeep/trunk/ (There's also a copy at Berlios, but that may be out-of-date) The application zeep-test is a simple SOAP server, in ./tests/ you can find two simple test drivers, one for the parser and one for xpaths. Best regards, -maarten hekkelman

11 22

[GSoC] Students; Please note..
by Rene Rivera 09 Apr '10

09 Apr '10

GSoC students, Now that the GSoC submission deadline has passed it is vitally important that you pay attention to your proposals and the comments the mentors add to them. Please address questions and suggestions we put on the comments ASAP. As it will both make our lives easier, and hence more likely to make accurate assesments of proposals. And it will increase the chances that we consider your proposals serious enough to want to move forward, if we get our feedback resolved. Good luck to all :-) -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org (msn) - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim,yahoo,skype,efnet,gmail

1 0

[config] New defect macro: BOOST_NO_COMPLETE_VALUE_INITIALIZATION
by Niels Dekker - address until 2010-10-10 09 Apr '10

09 Apr '10

FYI, John Maddock has just added the tests to trunk/libs/config that I wrote for a new defect macro: BOOST_NO_COMPLETE_VALUE_INITIALIZATION https://svn.boost.org/trac/boost/changeset/61153 And some documentation: https://svn.boost.org/trac/boost/changeset/61154 A test failure indicates that the specific compiler doesn't have completely implemented value-initialization. In the coming few days, the test is likely to cause regression failures, because I still need to define the defect macro for those specific compilers (at boost/config/compiler). Although I already expect certain compilers to fail (MSVC <= 2010, CodeGear/Borland <= 2010, GCC < 4.4, and various versions of Sun) I chose not to define the defect macro /beforehand/, because the test output provides some extra information about the particular compiler issue. Moreover, once the defect macro is defined, the test framework no longer indicates whether the compiler defect is really there. I'll keep an eye on the regression page, http://www.boost.org/development/tests/trunk/developer/config_.html and fix them one by one, but please don't hesitate to remind me if there's a regression failure regarding the new defect macro that I overlooked. The defect macro will allow fixing ticket #3869, "Unconditional call to memset in value_initialized()", reported by Aleksey Gurtovoy: https://svn.boost.org/trac/boost/ticket/3869 by adding an #ifdef to utility/value_init.hpp: #ifdef BOOST_NO_COMPLETE_VALUE_INITIALIZATION std::memset(&x, 0, sizeof(x)); #endif Kind regards, Niels -- Niels Dekker http://www.xs4all.nl/~nd/dekkerware Scientific programmer at LKEB, Leiden University Medical Center

1 1

Re: [boost] [msm] new version available
by Christophe Henry 09 Apr '10

09 Apr '10

> The new package on Vault is missing boost/msm/back/default_compile_policy.hpp. > Everything seems to compile fine once I grabbed it from the sandbox, so I assume > the other files in the package are the proper versions. I found the problem. SVN refuses to correctly update the directory I used to build the zip. Even cleanup has no effect, so I will delete the whole stuff and checkout again. There are actually 2 important files missing, so I had no other choice than to upload the correct version again. For all who downloaded from the vault, sorry about it, you will need to download again (the sandbox is ok though). > Also, I very much dislike that metafunctions.hpp does 'namespace mpl = > boost::mpl;' in global scope. Isn't putting anything in global scope against the > boost guidelines? Even if not, I find it quite inappropriate to inject another > library's namespace into global scope. This line is not even needed as all mpl types are qualified inside the library with ::boost::mpl so I just removed the line. This problem is there since at least the 1.20 and went unnoticed. Sadly, some of the tutorials fail to fully qualify the mpl types, so I updated them too. Both versions, sandbox and vault should now be up to date and with these 2 problems solved. Thanks, Christophe

1 0

GSoC 2010: Heaps and Queues
by Dan Larkin 09 Apr '10

09 Apr '10

I'm another potential student throwing my hat in the ring for the heap project. I'll save most of my personal details for my proposal, but for right now I thought I'd try to get a bit of a dialogue going with the community to help me understand what it is you guys are looking for and what it is I can work towards. So I'll start with my current understanding of the situation. The way I see it, the current heap implementations in boost/pending are rather fractured. They just have simple push/pop interfaces with no mutability (well, there's mutable_heap.hpp, but that's separate and not fleshed out). All in all, what seems to be needed is a standardized heap concept/API along with a few fully-implemented models. Standard heap functionality begs the following functions: - findMin - deleteMin - insert - changeKey - merge These can all be implemented quite efficiently (either worst case or amortized O(logn) time or better) for any heap model. I would be looking to implement the d-ary, binomial, and Fibonacci heaps for sure, with relaxed and Brodal heaps as a possibility, should time allow it. These heap models would be built as extensions of a base Heap class, which could be easily wrapped in a PriorityQueue class which takes the heap-type as a construction parameter (and defaults to a d-ary heap for instance). I know that a stable priority queue was mentioned in earlier discussion, but I'm not sure what to do about that just yet. It'll take a little more thinking before I could say whether I think it'd fall under the scope of the summer project, or if it should be put on the back-burner for later addition to the library. I guess that's basically how I see the problem so far. Please let me know what you think, or what other sort of information/planning/etc. you would like to hear from me prior to my proposal/draft. Dan Larkin

7 34

Boost.Botan final proposal
by Chad Seibert 09 Apr '10

09 Apr '10

Hi, Pending any other revisions, here's my final proposal: http://socghop.appspot.com/gsoc/student_proposal/edit/google/gsoc2010/chads… Thanks to all who gave advice, please ask if you have any questions! Chad Seibert _________________________________________________________________ Hotmail is redefining busy with tools for the New Busy. Get more from your inbox. http://www.windowslive.com/campaign/thenewbusy?ocid=PID28326::T:WLMTAGL:ON:…

2 2

[GSoC] Bits & Ints proposal
by Murilo Adriano Vasconcelos 09 Apr '10

09 Apr '10

Here is my proposal for Bits & Ints idea: http://socghop.appspot.com/gsoc/student_proposal/show/google/gsoc2010/muril… Any comments? -- Murilo Adriano Vasconcelos

1 0

boost::interprocess
by Rohit Goel 09 Apr '10

09 Apr '10

Hi, How can I synchronize mutlipe read/single write on a file available on a shared folder ? The multiple read/write need to be synchronized b/w different processes running on different machine. -Rohit

2 1

[msm] new version available
by Christophe Henry 09 Apr '10

09 Apr '10

Hi all, I just finished the newest MSM version. Unfortunately, I'm afraid I'm a bit late to get it shipped with boost v1.43 but at least it will give us time to have a look at it. What is new: - the doc was rewritten almost from the ground up. - internal transitions: for all front-ends, and both ways: either in the transition table or inside state's internal transition tables - more row types (yes, even more) allowing actions to be defined in state machines or in states The last 2 points aim at making states more useful - some performance gain - new eUML syntax to get rid of parens and to better support attributes - policy for better compile-time at cost of dispatch speed. And a few minor improvements. It was not possible to implement every wish and excellent idea offered during the review at this point, but they are in no way forgotten and I do not intend to stop development now. I'm interested in any comments, especially about the doc, which, like everything new, probably is not perfect but I hope, still an improvement. You can find the new version, like always: - in the Vault (http://www.boostpro.com/vault/index.php?directory=Msm) - in the sandbox (http://svn.boost.org/svn/boost/sandbox/msm/) Regards, Christophe

5 4

GSoC Generic Sweep Algorithm
by Sweta Yamini 09 Apr '10

09 Apr '10

Hi, I am writing my proposal for GSoC and I'm interested in writing a generic sweep algorithm. I want to write a generic algorithm which takes in functions to determine the priority of the elements to be considered in the sweep line, and a function to perform necessary computations at each such point. And supplement it with inbuilt functions for line sweep, angular sweep about a point for 2 dimensions and plane sweep for 3 dimensions. Also, implement some algorithms like Voronoi diagrams, Delaunay triangulations, visibility problems using the generic sweep algorithm. I have looked through the documentation and could not find anything related to this. Is there something I have missed? Also, could I contact anyone to discuss? Sweta Yamini Fourth Year Student Department of Computer Science And Engineering Indian Institute of Technology, Kharagpur

3 5

[GSoC] Some new ideas for this year's GSoC
by Stefan 09 Apr '10

09 Apr '10

Hello, I am Stefan and this is my first year at GSoC as it's the first time I'm eligible to participate as a student. Since I have been using C++ and the Boost libraries for quite some time, I would be thrilled to be able to code for Boost. I have quite a few ideas, and I was wondering which ones you consider to benefit the most, therefore I'm awaiting for your feedback. Also, please let me know if any of these ideas are already implemented in any of the libraries. Here we go: * Selection algorithm (find the kth smallest element in a container, O(n) worst-case, very easy to implement) * Optimize Boost String Algorithm finders to use an efficient substring matching algorithm as opposed to the naive algorithm. Most likely because of the fact that boost has implemented the finders for strings as generic algorithms, they haven't used efficient algorithms such as KMP, Boyer-Moore, Rabin-Karp etc. \see boost/algorithm/string/detail/finder.hpp The idea is to implement efficient algorithms such as the ones mentioned above to replace the current naive implementation. Note: it may be difficult to find nth matching substring position using some of these algorithms. Difficulty: easy-medium * Implement a string algorithm for generating the suffix array. The suffix array, after being precomputed on a certain string, allows for very efficient substring searches in the future. This is useful when the string doesn't change too often but there are plenty of substring to search against. * Yet another efficient associative data structure, skip lists? * Space partitioning data structures? kd-trees? quadtrees? octtrees? collision detectors? closest neighbors? * A parser capable of evaluating mathematical expressions which contains operands,operators,function calls,variable names and constant names (also considering priority of operators): 1. a list of valid operators described by: a) number of operands (unary/binary/ternary?); b) allowed operand types; c) the precedence (priority of the operator) 2. a list of existent functions described by: a) function name; b) number of parameters; c) type of each parameter and return type; d) a callback (maybe just automatically deduce type based on the callback's type if possible) 3. a list of constants 4. a list of allowed variable names and types Here's a pseudo-C++ code sample on how it should look like: namespace m = boost::math_expressions_parser; m::parser p; p.add_operators() ('+', 1, ret<int32_t>(_1+_2)) // binary +, precedence 1 ('*', 2, ret<int32_t>(_1*_2)) // binary -, precedence 2 ('+', 3, ret<int32_t>(_1)) // unary +, precedence 3 ('-', 3, ret<int32_t>(-_1)); // unary - (also a funny face), precedence 3 p.add_functions() ("sin", ret<int32_t>(sin(_1))); p.add_constants() ("PI", 3); p.add_allowed_variables() (allowed_var<int32_t>("x")); m::expression E("1 + 3*sin(PI*x)", p); // evaluates mathematical expression E against parser p if (!E.valid()) { /* ... */ } else { std::cout << E.evaluate( ("x", 3) ); // evaluate this expression by letting x=3 E.let() ("x",4); std::cout << E.evaluate(); } //Maybe an optimization so only the parts that depend on the changed variable will be recalculated every time?. E.g.: for expression f(x)+y, f(x) is recomputed only when x is changed. This may cause problems for functions that do not always yield the same results for the same input. Maybe make this optimization optional, only if the user marks the function/operator as "volatile" or something Difficulty: hard-very hard * Someone suggested on this ml earlier that a crypto suite would be useful for boost. Maybe, but it would take a lot of time and dedication to implement. I believe that we should at least add some Cryptographic hash functions (such as md5, sha1, sha256 etc.). No one wants to install Crypto++ or something similar just to be able to compute the SHA1 sum of a file. It is a common necessity to want to compute a hash function of a string. Difficulty: very easy if you copy the implementation and just create a boost-ish interface * In-place radix sort? Radix sort is a very efficient algorithm which performs better than std::sort (my implementation) (also asymptotically better) for some particular types such as: uint8_t, uint16_t, uint32_t, unsigned char, unsigned char[2], unsigned char[4] etc. Radix sorting takes linear time, but unfortunately, linear memory. It is very useful for sorting very large amounts of numbers tho (or genetic codes and maybe some other stuff). I am able to implement some of these stuff and I'm waiting for your opinion in what would be most useful to be part of boost. Let me know if you believe that none will have any use. Yours sincerely, Stefan

8 15

[GSoC] - Graph.boost - Graph Connectives
by Davi Barbosa 09 Apr '10

09 Apr '10

Hi, I am interested in participation in GSoC 2010 in Boost.Graph. I liked the first two options, but between these two I am much more interested in the second (graph connectives) because it seems more useful and challenging. Unfortunately, I will be having classes until the end of June (some of them will end early), so I will have a restricted time at the beginning. Of course I am explaining this in my proposal and making the schedule work with this big restriction. Do you think this could be a big problem? I am having exams right now so I did not had the time to join the list, get in contact, etc. I already started writing a proposal, but I still have one exam in a 4 hours and only after that I will be able to really write it. After finishing a draft, I would like to know if I can send it in pvt to someone for a quick review. Is anyone able to do this big favor? I had some other questions, but I already asked them in the IRC channel (with the nick "recife"). Thanks for everyone who answered! Davi Barbosa.

2 1

[GSoC] Graph layout algorithms - proposal draft
by Milos Djuric 08 Apr '10

08 Apr '10

Hello everyone, I've put together a draft of my proposal for a GSoC project to work on graph layout algorithms. The proposal can be found here: http://socghop.appspot.com/gsoc/student_proposal/show/google/gsoc2010/djura… I'd really appreciate if I could get some feedback (especially from possible mentors, and maybe someone from the Parallel BGL ?). All suggestions are more than welcome. Thanks, Milos

4 4

Re: [boost] [GSoC] Heaps & Queues (draft proposal)
by iaml 08 Apr '10

08 Apr '10

First of all, thank you, Andrew for your appreciation and Jeremiah for your information. I do not notice there exists d-ary in the BGL since I just focus on boost/pending and libs/pri_queue these days. But after a quick glance on the code in boost/graph/detail/d_ary_heap.hpp, I think that the container is supposed to have push_back() and pop()_back() because they are used directly in push() and pop(), This is something like the alias for vector type, not the parameter. Is that right or I just misunderstand the code in boost/graph/detail/d_ary_heap.hpp? As someone says: APIs design is main contributor to the Boost (I have read it today in somewhere in boost.org, but I can find it now :-( ). And I am lack of experience in APIs design for library. So I want to focus on my APIs design again. I know I am a bit annoying, but I want to do my best since it is my first time to join in GSoC. Feedback are welcome. It will be nice of you to do that. ==== description here ==== In order to be extendible, I would like to add iterator to the base class, which is more frequently used in programming, especially generic programming, than pointer. In some libraries, such as the STL, iterator is a bridge for container and algorithm. Since one of the goals of this project is to redevelop a new library for advance data structures and adaptors, I consider iterator to be necessary component to the library. Maybe it’ll take a little bit more memory, but in modern PCs, I think it acceptable.(*am I wrong about the usage of the iterator?*) template <class RandomAccessIterator, // iterator of the container class TreeNode, // key type class Comp = std::less<TreeNode>> class heap{ public: class iterator{ // implement iterator so that this class can be use as container // for other adaptors and algorithms public: TreeNode const& operator* () const; TreeNode const* operator->() const; iterator& operator++(); iterator operator++(int); bool operator== (iterator const& it); bool operator!= (iterator const& it); }; public: /* param: new_inserted points to the bottom of the container * where the new value has been inserted but not heapify. */ void insert(RandomAccessIterator new_inserted); void delete(RandomAccessIterator delete_node); void update(RandomAccessIterator update_node, TreeNode& new_node); // make the heap mutable RandomAccessIterator merge(RandomAccessIterator other_root); RandomAccessIterator getRoot(); RandomAccessIterator find(TreeNode& node); bool empty() const; size_type size() const; iterator begin() const; iterator end() const; void print() const; private: void print_recur() const; protected: RandomAccessIterator _root; }; NOTICE: operations print and print_recur is optional. But I prefer to include them because it'll be helpful when debugging the programs using this library. The class mentioned above is the base class for all the heap structures in the new library. The classes such as Fibonacci heap, relaxed heap, binomial heap and d-ary heap should inherit from this abstract class and add additional operations if needed. As the adaptor of heaps, the priority queue API may like: template< class RandomAccessIterator, class TreeNode, class Comp = std::less<TreeNode> class Container = fibonacci_heap<RandomAccessIterator, TreeNode, Comp>> class priority_queue{ public: /* param: new_inserted points to the place * where the new value has been inserted */ void push(RandomAccessIterator new_inserted); void pop(); // get the first value without popping it const TreeNode& front() const; TreeNode& front() ; RandomAccessIterator front() const; RandomAccessIterator find(TreeNode& node); void update(RandomAccessIterator update_node, TreeNode& new_node); // make the priority queue mutable RandomAccessIterator merge(RandomAccessIterator other_head); bool empty() const; size_type size() const; void print() const; private: void print_recur() const; protected: RandomAccessIterator _head; }; Thank you for your time. Yours sincerely, Tao Lin

2 3

Re: [boost] New Boost.XInt Library, request preliminary review
by Anders Dalvander 08 Apr '10

08 Apr '10

Chad Nelson wrote: > > > This disables the copy-on-write optimization that the library uses by > > > default [...] > > > > > I'm not convinced that integers should be COW. What situations do you > > forsee where COW would be helpful but move semantics wouldn't suffice? > > > As described on the rationale page of the documentation, the primary > reason I'm using copy-on-write is that move semantics aren't widely > available yet. Portability is one of my primary goals, and while I've > seen references to a move-semantics-emulator in Boost, I've also seen > suggestions that it relies on the compiler to somehow recognize it. That > doesn't sound fully portable to me. > No offense, but I'm not confident that COW semantics for the integer class is a wise design choice. I assume you have tested the performance with and without COW semantics, as well tested the performance for thread safe operations with and without COW semantics, before making that decision. Care to disclose the numbers? I guess that you have read the COW string article (http://www.gotw.ca/gotw/045.htm) by Herb Sutter, and his conclusions. Optimizations on other parts should perhaps have been made before converting to COW semantics. Using COW semantics could also complicate the complexity requirements for most functions, as they may be "amortized O(something)" instead of just "O(something)". Another concern I have is that NaN is "signaling" as most operations on a NaN integer will throw an exception. I think it would be more sound if operations on NaN integers would result in NaN integers, compare with float NaN. Don't take these comments the wrong way, I'm very glad to see development of an arbitrary precision integer boost licensed library. Best regards, Anders Dalvander

18 136

Crypto Library - Draft Proposal
by Chad Seibert 08 Apr '10

08 Apr '10

Hello, Here's a draft of my proposal. If you have any suggestions, I'd greatly appreciate that. Also, we can discuss any potential issues or concerns you may have. I have enabled "public" mode so it should be visible to all of you. http://socghop.appspot.com/gsoc/student_proposal/show/google/gsoc2010/chads… Many thanks, Chad Seibert _________________________________________________________________ The New Busy is not the old busy. Search, chat and e-mail from your inbox. http://www.windowslive.com/campaign/thenewbusy?ocid=PID28326::T:WLMTAGL:ON:…

3 2

Crypto Library Abstract
by Chad Seibert 08 Apr '10

08 Apr '10

Hi, Here's my abstract for the crypto library proposal. Any feedback would be greatly appreciated! "This proposal describes the porting of the cryptography library Botan and its integration with ASIO. Botan is released under the BSD license and the author has already agreed to porting it. The major reason for having a crypto library integrated with Boost is threefold: ASIO has SSL support that should be extracted out, adding TLS support for ASIO requires supporting many other block cipher types, and adding support for cryptography will add reasonable upgrades to Boost.Random and Boost.CRC as well. This is projected to take about 3-4 months to complete." Thank you, Chad Seibert _________________________________________________________________ The New Busy is not the old busy. Search, chat and e-mail from your inbox. http://www.windowslive.com/campaign/thenewbusy?ocid=PID28326::T:WLMTAGL:ON:…

2 1

Status of Boost.Move(https://svn.boost.org/trac/boost/wiki/LibrariesUnderConstruction#Boost.Move)
by Anton Potapov 08 Apr '10

08 Apr '10

Hi, That is the status of boost.move library(https://svn.boost.org/trac/boost/wiki/LibrariesUnderConstruction#Bo… Regards

5 8