- Boost - lists.boost.org

GSOC - Boost.XML
by Shrinidhi Hudli 26 Mar '10

26 Mar '10

Hello, I am interested to send a proposal to work on Boost.XML for GSOC 2010. I have a couple of questions: 1. Would it make sense to provide C++ binding for XML using XSD? This would make it much more convenient that using parsers explicitly. 2. Is the project mostly to develop an abstraction for the backend parsers so that different parsers can be "plugged-in"? Thanks for the clarification. -- Shrinidhi Hudli

2 1

Re: [boost] [lexical_cast] A non-throwing lexical cast? [Was: 5Observations - My experience with the boost libraries]
by pete＠pcbartlett.com 26 Mar '10

26 Mar '10

On Fri 26/03/10 01:25 , Gennadiy Rozental <rogeeff(a)gmail.com> wrote: > Rene Rivera writes: > > > > Tom Brinkman wrote: > > > boost::lexical_cast_no_throw() > > > > Or.. > > > > template > > T lexical_cast(const S & arg, const T & error_default_value); > > > I've implemented later in my own version of lexical cast. In 99% of > the time > this is exactly what I need: either convert string to number or take > this > default value. Another good consequence is that I do not need > template parameter > anymore. > Gennadiy Looking at the various threads it seems like three different behaviours in the event of conversion failure have been requested. - Default Value - boost::system::error_code - throw custom exception. So this would suggest an interface like template< typename T , typename S, typename FailureHandler > lexical_cast(S const& arg , FailureHandler fh) with specializations if FailureHandler = T or FailureHandler = boost::system::error_code&. You do lose your "good consequence" with this formulation though. As I said in another message, the original author of lexical_cast has said several times over the years that doing something like this is too far from the spirit of a *_cast, though, so if it gets into Boost I think it will have to be in the StringConvert library.

1 0

[lexical_cast] A non-throwing lexical cast? [Was: 5 Observations - My experience with the boost libraries]
by pete＠pcbartlett.com 26 Mar '10

26 Mar '10

On Wed 24/03/10 03:40 , Jonathan Franklin <franklin.jonathan(a)gmail.com> wrote: > On Tue, Mar 23, 2010 at 9:31 PM, Tom Brinkman wrote: > > ... All I'm saying is that in the real world, most > > projects are mixed C/C++ and that the needs of both communities > need > > to be addressed if boost is going to remain relevent. > For the sake of not arguing, let's assume that your assertion is > true. > Let's hear your *actionable* proposal for improving boost. E.g. > show > us the better interface for <insert Boost library here> Taking an example from way back at the start othis thread, in my personal experience a non-throwing version of lexical_cast<> would be very nice. If I look at the cases where I pass user data through my libraries into boost libraries without some pre-validation, there are very few, and naturally these are the cases where the validation would as difficult as the "parse": - boost::spirit::phrase_parse - Just returns a true/false, and I build a nice context-driven error message myself if necessary. - boost::lexical_cast - throws. Almost always needs to be caught and re-thrown.

7 10

Re: [boost] [lexical_cast] A non-throwing lexical cast? [Was: 5 Observations - My experience with the boost libraries]
by Pete Bartlett 25 Mar '10

25 Mar '10

Kim Barrett wrote: > On Mar 24, 2010, at 5:20 PM, Bruno Santos wrote: >>boost::bad_lexical_cast is not derived from >>my_project::invalid_user_input o or whatever. This happens a lot with >>boost::lexical_cast. >> >If the user data is data that comes from a file or user interface, I >agree in your assertion. > >However, if it's from someone using your library, it's an obvious >programming error, doing exception translation in this case is >pointless. Agreed, but the source of data in a text format that should be a numeric format is much more likely to be end-user systems and inputs rather than that created within a client application, IME. >Anyway, in my opinion, passing a boost::system::error_code as the second >parameter for a non throwing version would be the best solution. As Jeff points out, others have been here before us, and it looks like the proposed Boost.StringConvert is the result of prior discussions. Perhaps our energies would be best spent making sure that library meets our needs by being reviewers or even the review manager [one is still needed, according to the schedule]. Pete

1 0

GSOC 2010 Boost-Graph
by Chinmaya Poswalia 25 Mar '10

25 Mar '10

Hi Myself Chinmaya Poswalia Computer Science an Engineering B.Tech, Indian Institute of Technology, Guwahati I am finding all the graph topic(my favorite topic to work on) very interesting that's why i asked a lot of questions regarding all in one mail. - i want to work on semantic graph - how about maintaining an adjacency list, denote V as nodes and E as edges, so the space complexity will be O(V+E). - Also we can employ pointers of type void* to point to edges/vertices of different types so as to maintain the graph of different edge and vertex types. - rather than employing a vector in each node and edge either we should allocate space during insertion or we maintain the size of vector array by ourself. - Through generic programming, all the operations being implemented on graph up till now will be made applicable on these new members of the library. - various functions that can be induced on these graphs are 1. Distribution of node degree 2. finding clustering co-efficient of semantic graph 3. relevance of a link and node 4. scale on semantic graph 5. disparity of connected types/dispersion co-efficient. - Semantic graph are generating huge level of importance in networking (network semantics on web), video screening, statistical analysis of data,etc so it will be a great thing to work on it. Can you suggest some more links to read on for these I am working on my proposal about the graph and your help is crucial for me. With regards Chinmaya

2 1

[log] Boost.Log formal review result
by Vladimir Prus 25 Mar '10

25 Mar '10

First of all, I would like to thank Andrey for this submission and the active discussion during the review. I also would like to thank everybody who participated in the review. The comments on the library were generally positive. Several reviewers have tried it in practical projects already, and found it superior to other libraries. It clearly will benefit the users of Boost right away. Therefore, the library is accepted. Congratulations, Andrey! On the other hand, some concerns about the ease of use and performance and implementation details were raised. Of those, some can be easily addressed as part of normal maintenance, while some seem to require significant rework and may change the library quite consirably. Therefore, the library is accepted subject to several conditions -- listed below under "Critical issues". Because the changes can be large, I think a mini-require is required when those issues are addressed. To avoid delays, it's probably not necessary to formally schedule and conduct a mini-review -- just posting a email asking for discussion will be sufficient. Statistics ========== There were roughly 300 emails during formal review (I have a mbox archive if anybody needs it). The following persons submitted a review with a vote. Some of votes are "provisional", this is not reflected below, but affects the list of critical issues below. - Boris Schaeling (yes) - Roland Bock (yes) - Ralf Globisch (yes) - Sean Chittenden (yes) - Darryl Green (no) - Tom Brinkman (no) - Barend (yes) - Sam Gundry (yes) - Vicente Botet (yes) - Robert Stewart (yes) - Alexander Arhipenko (yes) - "M-Square" (yes) Critical issues =============== These issues must be addressed, and be passed through informal mini-review, before the library can be added to SVN. - It appears that the 'trivial' logging is not sufficiently good to just take and use. The library should provide an out-of-the-box mechanism that: - supports channel/severity attributes, without creating new logger for each severity. It also should be possible to filter out specific channel by essentially poking at some "map", and without manually composing a new filter that checks for a set of allowed channels sequentally. I believe that at least Christian, Roland, Robert and myself requested this. - has no observable effect on compile time. One second (or more) that trivial.hpp imposes is not acceptable. - outputs to console by default, but permits changing that - outputs only component/severity/message by default, but probably permits changing that. - By default, the library should try hard to continue working no matter what errors happen during processign a log record -- including things like invalid attribute names or types, or other exceptions. - The library should not reinvent wheels. In particular, custom implementations of TSS and RW mutex seems like a very bad idea. Use of a custom lambda implementation was pointed by many as not great -- we already have a couple, so let's not add more to the mix. - Library interface is too geared towards lambda. In particular, implementing formatters/filters as free-standing functions appears to require considerably more code. In particular, it should be possible to access an attribute using a single function call. Also, logging::extract taking a lambda for callback complicates matters, it's desirable to have a more direct variant. Important issues ================ These issues are important enough to be mentioned here, but can be addressed as convenient. - The reported run-time performance can be improved. In particular the performance with date attributes seems scary and 2x slowdown relative to some other library in the 'most records are filtered out' case is also concerning. - I don't think it was satisfactory explained why 'attr' exists in two namespaces, as opposed to being a single type that is used for both formatting and filtering. Other notes =========== These issues seem important and should be considered, but might not even be fixable within the current design. - Several reviewers said the library is "too flexible" and this makes it harder to understand. Probably nothing can be done about that at this point, but interesting data point notwithstanding. - It was suggested that the library include an API that another Boost log may use in a way that permits plugging another logging library should end user of a Boost so desire. This seems a good idea, but I think it's up to Andrey to implement such API or not. - Alternative design approaches were proposed, in particular (i) permitting user log records and templating/basing other components on a user-defined record type and (ii) using compile-time indexing to access attributes. Also, it was proposed that named parameters not be necessary to use the library, and a more conventional interface be available. It does not seem that implementing those suggestions is fully possible without writing a different library from scratch, so it's up to Andrey to consider those proposals. - It was suggested to use newer Spirit to address poor compile times for the library itself. Thanks, Volodya

4 4

[log] How to derive from a logger
by Andreas Huber 25 Mar '10

25 Mar '10

Hi Andrey As discussed earlier, we're kind of desperate to add functionality to a logger class provided by Boost.Log. Instead of duplicating severity_channel_logger_mt, I'm wondering whether it's a good idea to derive from it, as follows: class Logger : public ::boost::log::sources::severity_channel_logger_mt< Severity > { public: typedef ::boost::log::sources::severity_channel_logger_mt< Severity > logger_base; BOOST_LOG_FORWARD_LOGGER_CONSTRUCTORS(Tracer) void SetMinimumSeverity(Severity severity); Severity GetMinimumSeverity(); private: Severity minimumSeverity; }; Elsewhere we'd use this class as follows: BOOST_LOG_DECLARE_GLOBAL_LOGGER_INIT(Whatever, Logger) { // ... } It seems to work, but is this a good idea? Thanks & Regards, -- Andreas Huber When replying by private email, please remove the words spam and trap from the address shown in the header.

2 4

Re: [boost] GSOC 2010 Boost-Graph
by Chinmaya Poswalia 25 Mar '10

25 Mar '10

On Thu, Mar 25, 2010 at 3:21 AM, Chinmaya Poswalia < chinmaya.poswalia(a)gmail.com> wrote: > Hi Andrew, > I am finding all the graph topic(my favorite topic to work on) very > interesting that's why i asked a lot of questions regarding all in one mail. > > > - i want to work on semantic graph > > > - how about maintaining an adjacency list, denote V as nodes and E as > edges, so the space complexity will be O(V+E). > > > - Also we can employ pointers of type void* to point to edges/vertices > of different types so as to maintain the graph of different edge and vertex > types. > > > - rather than employing a vector in each node and edge either we should > allocate space during insertion or we maintain the size of vector array by > ourself. > > > - Through generic programming, all the operations being implemented on > graph up till now will be made applicable on these new members of the > library. > - various functions that can be induced on these graphs are > > > 1. Distribution of node degree > 2. finding clustering co-efficient of semantic graph > 3. relevance of a link and node > 4. scale on semantic graph > 5. disparity of connected types/dispersion co-efficient. > > > - Semantic graph are generating huge level of importance in networking > (network semantics on web), video screening, statistical analysis of > data,etc so it will be a great thing to work on it. > > Can you suggest some more links to read on for these > > > > I am working on my proposal about the graph and your help is crucial for > me. > With regards > Chinmaya >

1 0

GSOC Proposal for BIGINT - Long Mail
by swagat konchada 25 Mar '10

25 Mar '10

I had a look around in the Boost Sandbox and I found a BigInt implementation done by zeux during GSoC 07. I had a look at the code and I wanted to know its deficiencies. I'm interested in proposing some improvements in bigint and new bigdecimal implementation that is building on this code. There are 2 questions that I wanted to ask the list before moving further on this track: 1. Is there sufficient interest for a BigDecimal proposal on the lines of the Java implementation of BigDecimal (or has there been some prior work that can be used as a foundation?) 2. What are the deficiencies of bigint that have prevented its inclusion into the Boost distribution so as to address the same as part of my GSoC proposal. I did some homework and contrasted the bigint api in Boost and Java and found some interesting things that could be done. Boost.bigint was written by zeux and he used GMP bigint's features writing the Boost.bigint code around it. I think I could learn and analyse more after having a look at GMP bigint. After all, I think Boost.bigint should be more exhaustive. -------------------------------------------------------------------------------------------------------------------------------------------------------------- Feature Boost bigint Java BigInt -------------------------------------------------------------------------------------------------------------------------------------------------------------- Constructors from | int | byte[] #byte array with 2's complement representation of the BigInt. | unsigned int | int bitlen, int certainity #random BigInt with given bit length | int64_t | | uint64_t | | char *, int base | String | string& str, int base | String, radix -------------------------------------------------------------------------------------------------------------------------------------------------------------- *Conversion from string of digits to bigint is present. However conversion from/to byte-array(2's complement notation) to/from bigint isn't. Also the generation of a random arbitrary precision bigint should be done. int bitCount() #return the no of bits in 2's complement of the bigint; int bitLength() #no of bits excluding the sign bit double doubleValue() #casting bigint to double must be done. #even casts to int, uint and int64_t, char * must be done.* -------------------------------------------------------------------------------------------------------------------------------------------------------------- Arithmetic Operators += In Java, add, subtract, multiply, etc., | -= | *= | /= | %= | |= | &= | ^= #xor | <<= | >>= | ++ #postfix & prefix | -- #postfix & prefix -------------------------------------------------------------------------------------------------------------------------------------------------------------- Unary Operators + - BigInteger[] negate() ~ BigInteger[] not() ! #is zero < int compareTo(BigInteger val) <= BigInteger max,min(BigInteger val) > >= == != -------------------------------------------------------------------------------------------------------------------------------------------------------------- *These are some bit manipulators BigInteger clearBit(int n) #not in Boost.bigint #even setBit & toggleBit could be done, with a feature of changing the precision of the bigint. BigInteger[] testBit(int n) #also bit testers l* -------------------------------------------------------------------------------------------------------------------------------------------------------------- Binary Operators + BigInteger add(BigInteger val) - * BigInteger multiply(BigInteger val) {bigint lhs, int rhs} {int lhs, bigint rhs} / BigInteger divide(BigInteger val) % BigInteger mod(BigInteger val) , BigInteger modPower(BigInteger val) | BigInteger or(BigInteger val) & BigInteger and(BigInteger val) ^ BigInteger andNot(BigInteger val) << BigInteger shiftLeft(int n) >> BigInteger shiftRight(int n) -------------------------------------------------------------------------------------------------------------------------------------------------------------- Math function overloads abs(bigint_base) BigInteger abs(int exponent) pow(bigint_base, uint64_t) BigInteger pow(int exponent) div(bigint_base lhs, bigint_base rhs, bigint_base& remainder) BigInteger[] divideAndRemainder(BigInteger val) sqrt(bigint_base) ----------No Java version for BigInterger------------ -------------------------------------------------------------------------------------------------------------------------------------------------------------- *BigInteger gcd(BigInteger val) #GCD would be one of the most important requirements for bigint #Also the Java function of bool ProbablyPrime() is very interesting and would be challenging to implement.* -------------------------------------------------------------------------------------------------------------------------------------------------------------- -- Problem is a phenomenon indicating lack of thought. Swagat Konchada

3 2

Debugging Visualizers
by Alex Miller 25 Mar '10

25 Mar '10

quoted from the ongoing "5 Observations" thread: On Tue, Mar 23, 2010 at 4:36 PM, Steven Watanabe <watanabesj(a)gmail.com>wrote: > > Perhaps you would find this useful: > https://svn.boost.org/trac/boost/wiki/DebuggerVisualizers > > It is mentioned there that the same thing could be done for GDB,etc. However, I can't seem to find anything of the sort by googling (although it's very possible I'm just searching poorly). Could anyone point me towards where docs on how to do this could be found at?

2 2