- Boost - lists.preview.boost.org

[boost] my 2 cents x 10 - Documentation, moreIO, iostreams, move_ptr, fsm, & boost
by Thomas Xkey 04 Sep '04

04 Sep '04

my 2 cents x 10 - Documentation, moreIO, iostreams, move_ptr, fsm, boost -------------------- Review Periods I would prefer to see a review period of 10-12 days [i like 12 days from a sunday thru the following weeks friday perspective.] The present period is just to short. Most of us are overworked, underpaid, and dont always care to look at works in progress of others until things are a bit more "finalized" and "stable" so to speak. Hence we may not peek early enough at a library to provide good guiding input but we can toss our 2 cents in during the final review melee lol :) ---------------------- Documentation !!! Please utilize & include more diagrams & examples in your library documentation!!!! Compare & contrast with existing implementations that are lacking, State why they are lacking, what they are lacking, with what the proposed library implementation presents to fill the missing pieces, how it is better in some respects to anything it "replaces", and why it replaces some typical library code currently in widespread use or fills a gaping hole. --------------------- moreIO & IOstreams Daryls rationales and motivations are completely lacking in depth and sharpness. The summarys are so general and non-delineated that they are no help to me in discerning the clarity of what he proposes as benefits and properties of his library. an example :: this snippet is from the wrapping streams rationale "The Standard stream base class templates are designed to use stream buffers with an independent lifetime, and include functionality for switching what stream buffer is used." Yes, but are you just reiterating something everyone already knew, do you feel that is a bad thing or a good thing? There are no "supporting" remarks no remarks of impact laden with design criteria or shortcomings. Not coming from a circle where I/O is the most important aspect of my development I am not an "expert" on streams. So reading the documentation which purports to support and sing the praises of this libary was completely useless to me. I had better luck just looking at the code. When i think rationale and motivation i think objectivity must be forefront. Even a simple outline or summary of design criteria clearly delineated and put forth makes it easier to read an overall document of this nature. Project managers and others working on a project need to see clarity of thought, clear cut guidelines, inputs, outputs, and the design that goes in the middle. I am sure as most have laid out the design of their libraries they have ad-hoc flowcharts, points pro & against certain features. You may wish to bring some of those out and flesh them into the documentation so that others can understand the motivations behind your design. It would surely make life easier for anyone reviewing the code to speak to the issues addressed and/or generated by the code. It would elevate the efficiency of the process. Now that isnt to say some fluff isnt nice *grin* null_stream yes. something missing that is necessary. would prefer though to see it constructed using the concept of sinks & sources from the turkanis IO library up for review. streambuf_wrapping I would vote no on this until it is cleaned up and a better rationale presented to me. array_stream maybe. you would have to convince me this buys something appreciable in an efficiency concern over the way the standard streams presently operate. perhaps give me 2 examples a non-I/O expert such as myself could "grasp" concretely. pointer_stream no. the concept would be better implemented again using turkanis IO lib up for review. value_stream no. this specialized stream doesnt seem all that beneficial to stuff it in to a library. if the appl programmer wishes to he can easily fabricate his own. [u have a value_stream for just a char, what about for just a user_type, for just a "string" etc why not a "pair_stream" that would return a pair of values etc ad nauseum] now that isnt to say such a stream cannot be useful on rare occasion but again it would be fairly easy to implement using an appropiate set of "sources/sinks" that could be implemented in turkanis IO lib. -------- Now having said that it may seem like i'm being a pita and trying to tear your hard work into pieces, but i think you have some good "ideas" but perhaps the implementation should come off differently. I think if you perhaps had looked into the other IO lib that jason was developing at the time you 2 coudl have had a meeting of the minds and come up with some great ideas and both done some things differently. This library is a software community and with scales ever growing great ideas shouldnt necessarily be pondered on by lone rocket scientists squirreled away with their code and not picking their heads up to look around and talk (though we all do accept input i'm sure, and even act upon some of it, it seems more often than not we do not communicate as much as we should in the "early stages" and leave it all for the end-game) Perhaps you 2 should get together and collaborate. [now there's a concept] --------- Now my rationale : We all agree a layered/tiered approach to complex software is the best way to go. It allows more degrees of freedom, greater re-user, greater specialization as well, and greater replacement of parts. It does push or mutate the complexity more from a particular piece of complex code into the complexity of "simpler components" with more complex entanglement, more complex communication and cooperation at times. This is why i would much prefer with some efficiency clean-ups & improvements that the turkanis library be used as a basis(implementation-wise) for any of the moreIO features accepted. I like the small raw nature & flexibility of the simpler "building pieces" at the bottom of this IO pyramid I can then compose my complex streams on these "sinks & sources" As to the turkanis library, I have not had as much time to examine it. I am not sure the merit of Carlo Woods remarks but from a 1st perusing I think i agree with him. I also partly agree with Daryl about some efficiency concerns and bloat concerns but i think with everyones assistance those can be hammered out or down in size. ---------------- 2 cents on names for manipulators & readability These comments are due to the disagreement some seem to have over things like newl versus newlines and proliferation of manipulators and whether some should be placed in the library and others left to appl developers to produce on their own. A) Do not have both a singular and plural version instead just opt for the plural version - the singular use could be the default and is typically understood as much by viewing code as well. that is to say dont have a skipline & skiplines instead just opt for skiplines skiplines(x) would skip x lines [thus for one line x==1] B) The use of underscores to break up and make names more readable for classes, vars & funcs is a good thing. Someone tried to bring up the point that the standard streams library was such n such a way well that doesnt just mean it was the best way in terms of its naming schema C) I prefer slightly longer more meaningful names getting away from obfuscation so when it comes to newl or nl i'd really prefer newline. i think most of us can type sufficiently fast and we are thinking "newline" in our heads we can type it with barely any speed difference nor loss in efficiency but it makes for a lot better readability than "nl" (my cognitive web sees "nl" as netherlands these days lol) now that isnt to say this should be taken to the maximum in the opposite direction!! macros/functions like "min" & "max" are plenty self-explanatory. Ok, so that was more like 3 cents on this topic :) ---------------- fsm This library seems & acts more like a "simulator" than an "efficient finite state machine". There is a very high level functionality tied into (possibly) a bare-bones base... not properly tiered or layered approach. Functionality is wrapped into one library rather than separated into add-on libraries with additional functionality. It doesn't seem to scale well even according to the author(s)? (most fsms a computer scientist would deal with encompass 100s to 1000s of states with as many different transitions possible) I would strongly urge something more efficient and bare bones along the lines of http://www.research.att.com/sw/tools/fsm/ take on the mantle of an "fsm" library in boost upon which coarse-grained objects can be simulated from above. would prefer this 'currently proposed' fsm to take on its true stance perhaps attaching the nomenclature of "hlfsm" --> "high level fsm". Due to its greater abstractions, fluffy aggregations and bulk in nature it isnt "efficient". If a library isnt efficient for its purpose or intended purposes then it will be under-utilized. I could never use this one as it is evolving away from an efficient fsm into more of a large coarse simulator. [now if i had need of that it would be great] This library seems more intended for simulation at a higher level than at a more simplistic state/event transition approach. Yes i am biased coming from an algorithms and mathematical background; I am more of a computer scientist who practices softare engineering than most application programmers who just want a product out the door and efficiency goes out the window. Can we adjust this library conceptually into a cleaner bare-bones fsm at one layer and then interject the higher level simulation aspects along with the ability to automatically produce code etc. [Canned automatically generated code is usually not so hot. In fact it rather bites. Any decent programmer can still out-optimize todays compilers based on intimate knowledge of their code & algorithms even on todays complex processors. Given that compilers have thousands of man-years of code & know-how how does one expect this fsm library to generate decent code or is it intended for someone who cannot program?] ------------------ On the subject of move_ptr How about self_consistent_ptr invar_postmove_ptr I must be a freak because "selfish_ptr" grows on me it instantly says "mine mine all mine i can move through proustian circles but it is still my object" moveptr is something i've seen in untold reams of computational code along with leftptr, rightptr, and currptr & variants thereof; so i'm really hoping someone comes up with better nomenclature to settle on :) -------------------- Lastly an area where I dont want to get into because no one manages software well lol The topic of boost - releases, the GABB (gawd almighty boost book), documentation & structure 1) is it possible to go with both a long-term more flexible scheme for release-dates along with a more rigid short-term window as we slide forward into the future? Note the famous M$ vaporware long-term software & release info is not the approach i'm talking about lmao more like "tentative" long range plans [the reiser boys(release 4 is out now) have done a good job with their long term feature & release targets] but sticking to your guns short term with branches rather than how it has been this "special circumstance" time I think most are of the opinion from the app & devel point of view that more "dot" releases are better rather than fewer. (of course within reason!) Presently it seems haphazard with cvs patch check-ins and outs and then fudging jam files, regression test failures and ... seems like by waiting so long between "dot" releases is NOT buying you any more efficiency or salvation from bug issues any more than having more frequent releases would but some of the libs within would be able to rev and get feedback faster. The compilation (syntax) issues are one thing but seems like some of the libs would benefit from hitting the streets when the developers have stomped most of their bugs. It becomes time the hapless consumer of the lib can play their guinea pig role and dive into their playground with much zeal. So i dont see any "good solid" argument as to why releases are so far apart rather than a bit more "reasonably timely" [ok well integration testing when a MAJOR lib-wide wholescale change occurs is one reason why a particular release would take forever :)] NOW if it was an end-user , we all know how psychologically important keeping the release #s down and only coming out with a major rev every few millenia(hic sarcasm hic) is great for business [hmm IE 6 hmmm how many years b4 IE 7? lolol] We devels are made of more sterner stuff though :) 2) Is the flippin book going to be available as ps or pdf since I dont feel the need to kill more trees just to have another book about programming yada yada yada collecting dust on my bookshelves? most programming books are so light on substance and full of wasted verbiage they could do without it isnt funny. [my fave c++ book was the annotated reference can ya tell? lol] If not, would at least the chapter summaries along with toc, glossary, and appendices be available for d/l? I much prefer cutting to the chase to get to information 3) Can someone get the documentation into a more consistent format along with the information at boost.org /boost-consulting site? as someone else pointed out the review information at boost.org was shall we say "slightly dated" 4) Structure ... oh forget it i've rambled enough on this random walk C++ya, xkey

4 3

C++ Random Container
by Joel Young 04 Sep '04

04 Sep '04

I would be very interested in such a container. Even more, I would be interested in a priority queue which allows one to specify a distribution based on either the order statistic or the priority. The head/front/pop operator would then select based on the distribution. Joel

2 3

Re:[boost] Re: IOStreams review
by Robert Ramey 04 Sep '04

04 Sep '04

>"Dietmar Kuehl" <dietmar_kuehl(a)yahoo.com> wrote in message >news:200409031908.13053.dietmar_kuehl@yahoo.com... >|On the ACCU 2003 conference JC (I can figure out the full name if >|necessary...) presented the idea for creating filters which I really >|liked. It looked something like this: >|filter_stream out(tee(std::cout) | encode | gzip | file("some file")); >|This would create a stream which writes everything to 'std::cout' >|and also encodes the stuff before sending it on to compress it and >|finally write it to the file. I like this notation... >I second that FWIW - I do NOT like this idea. I concede its mostly a matter of taste but I think it adds another layer of syntax. I think the original .. push, etc is ok. But my preference would be for filter_stream out( tee( std::out, encode( gzip( file("somefile") ) ) ) ) I'm sure people are going to love this idea. Robert Ramey

3 2

Checking if RTTI is available.
by Jurko Gospodneti� 03 Sep '04

03 Sep '04

Hi all. I was wondering if boost has any portable way for detecting whether RTTI is enabled? (For instance a macro expanding to _CPPRTTI in Visual Studio). If there is, I have not been able to find it. Best regards, Jurko

6 7

[range] Collection Concept
by David Abrahams 03 Sep '04

03 Sep '04

Are the authors of range libraries aware of http://boost/libs/utility/Collection.html? Just wanted to make sure. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com

2 15

Building Boost with PathScale compiler
by Richard Hadsell 03 Sep '04

03 Sep '04

I am trying to build the Boost 1.31.0 libraries on an AMD Opteron platform using PathScale C++ 1.2. There is no toolset for this compiler, which looks something like a MipsPro compiler and something like a g++ compiler. Has anyone created a toolset for it? If not, how do I build a new toolset, or is there an easier way to build and install the libraries? -- Dick Hadsell 914-259-6320 Fax: 914-259-6499 Reply-to: hadsell(a)blueskystudios.com Blue Sky Studios http://www.blueskystudios.com 44 South Broadway, White Plains, NY 10601

2 5

Boost serialization: release configuration linker errors
by Andrew Favell 03 Sep '04

03 Sep '04

Ive been using Boosts serialization library with MSVC 7.1 (the first time that Ive used it). For most of my project I put the load / save function declaration in the class header (the .h file) and the definitions in the .cpp file VC 7.1 allows this for templated functions, unlike some older compilers. In debug mode this compiled and linked fine except for abstract base classes through trial and error I found that for abstract classes the functions had to be defined in the .h file to avoid linker errors. My project built fine in Debug mode and I then tried to compile / link it in Release mode this threw up quite a few LNK2001 errors relating to just a few of the serialization load / save functions in just some of the classes most of the classes that declared the load / save functions evidently linked fine (as they all did in Debug mode). After much double checking of the compile / link project configurations I tried the following: 1. I removed the BOOST_CLASS_EXPORT(etc) declaration at the bottom of the .h files in which the load / save functions were not linking. On recompiling / linking most of the linker errors were gone, but a few remained. 2. For the remaining classes that were not still not linking, I moved the load / save functions from the .cpp file into the .h file (these were not abstract classes). This fixed the remaining linker errors and my application compiled / linked / ran fine. I can't see why this occurred. I havent checked yet (its very time consuming to rebuild this application) but possibly option (2) would have worked for all the affected classes. For most of this project, the load / save functions remain defined in the .cpp file and clearly link fine in both debug and release configurations. Before someone asks, I did complete clean / rebuilds for both configurations anybody any ideas? andy :-) -- ___________________________________________________________ Sign-up for Ads Free at Mail.com http://promo.mail.com/adsfreejump.htm

1 0

IOStreams review
by Dietmar Kuehl 03 Sep '04

03 Sep '04

Hi, let's start with the obvious formal requirement for review, i.e. the answer to the question: Should this library be included into Boost? I don't know. I have no strong feelings either way. Maybe I'm too used to writing stream buffers without help from any library but to me it is unclear whether this really makes things simpler. The number of different concepts is, at least to me, quite confusing. The library does, however, avoid a small fraction of boilerplate code (mainly for buffer maintenance). Unfortunately it does not at all address the really problematic area in stream buffers, namely seeking: the interface of stream buffers is retained. This is interface is, in my opinion, really hard to use. Typically, I don't bother implementing it unless some specification requires me to do so. On the other hand, I'm not using seeking with streams anyway. The documentation should make clear that the filters are not usable as temporary add-ons: I have some uses where I have an underlying stream buffer which is used directly until a portion of the stream needs special processing. At this point, a filter is used to process the portio and normal processing is continued afterwards. For example, when parsing a mail, a mime-decode filter is used to handle embedded binary data. This assumes, however, that the filter synchronizes with the underlying stream buffer. On the ACCU 2003 conference JC (I can figure out the full name if necessary...) presented the idea for creating filters which I really liked. It looked something like this: filter_stream out(tee(std::cout) | encode | gzip | file("some file")); This would create a stream which writes everything to 'std::cout' and also encodes the stuff before sending it on to compress it and finally write it to the file. I like this notation... Finally, here are some issues I stumbled over in the documentation: - The description for "boost::io::read()" seems wrong to me: "returning a value less than n indicates end-of-sequence". At least on POSIX systems, return less than the number of requested bytes indicates that *currently* no more characters are available. The next call may return more characters. This behavior could be useful e.g. when filtering: get a buffer from the underlying stream and pass on what is left from this buffer after filtering. - On the "Filter" concept page, "OutputFilter" is not found (but it is reachable from the "InoutFilter" page). - On the "SeekableFilter" concept page, I think the preconditions for "f.put()" and "f.write()" should be "output" rather than "input". At least, I would consider it confusing if "input" were right... -- <mailto:dietmar_kuehl@yahoo.com> <http://www.dietmar-kuehl.de/> <http://www.contendix.com> - Software Development & Consulting

5 6

[mpl] bug: has_xxx, default bool parameter
by Daniel Wallin 03 Sep '04

03 Sep '04

The traits generated with BOOST_MPL_HAS_XXX_TRAIT_DEF() doesn't work with lambda on VC7.1+. I think the problem is the default bool parameter: template< typename T, bool fallback_ = default_ > struct trait \ ^^^^^^^^^^^^^^^^^^^^^^^^^ This template will never match: template<template<typename ..> class F, class U1 .. UN> struct lambda<F<U1 .. UN> >; So lambda breaks. I guess the solution is to stop using a default bool parameter and use a class type instead. -- Daniel Wallin

2 1

[mpl] patch for config/has_xxx.hpp
by Jonathan Turkanis 03 Sep '04

03 Sep '04

Hi Aleksey, It looks like boost/mpl/aux_/config/has_xxx.hpp has an unnecesary include directive for boost/mpl/aux_/config/gcc.hpp. Jonathan begin 666 has_xxx.patch M26YD97@Z(&AA<U]X>'@N:'!P#0H]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T] M/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]#0I2 M0U,@9FEL93H@+V-V<W)O;W0O8F]O<W0O8F]O<W0O8F]O<W0O;7!L+V%U>%\O M8V]N9FEG+VAA<U]X>'@N:'!P+'8-"G)E=')I979I;F<@<F5V:7-I;VX@,2XR M#0ID:69F("UU("UR,2XR(&AA<U]X>'@N:'!P#0HM+2T@:&%S7WAX>"YH<' ) M,B!397 @,C P-" Q-3HT,#HT-2 M,# P, DQ+C(-"BLK*R!H87-?>'AX+FAP M< DR(%-E<" R,# T(#$X.C$P.C$X("TP,# P#0I 0" M,38L-R K,38L-B! M0 T*("\O("12979I<VEO;CH@,2XR("0-"B -"B C:6YC;'5D92 \8F]O<W0O M;7!L+V%U>%\O8V]N9FEG+V]V97)L;V%D7W)E<V]L=71I;VXN:'!P/@T*+2-I M;F-L=61E(#QB;V]S="]M<&PO875X7R]C;VYF:6<O9V-C+FAP<#X-"B C:6YC M;'5D92 \8F]O<W0O;7!L+V%U>%\O8V]N9FEG+W=O<FMA<F]U;F0N:'!P/@T* M( T*("\O(&%G=7)T+" Q,2]J86XO,#,Z('-I9VYA;',@82!S='5B+6]N;'D@ :)VAA<U]X>'@G(&EM<&QE;65N=&%T:6]N#0H` ` end

2 1