August 2004 - Boost - lists.preview.boost.org

Nightly CVS docs broken?
by Vladimir Prus 30 Aug '04

30 Aug '04

The link to nightly CVS documentation on boost.org appears to be broken: it leads to http://www.boost.org/regression-logs/cs-win32_metacomm/doc/html/libraries.h… which generates an error. Is it possible to fix somehow? Thanks, Volodya

2 2

Re:Re: [boost] another bjam question
by Robert Ramey 30 Aug '04

30 Aug '04

John Maddock >> This indicates that the Microsoft native include is specified BEFORE the >> STLPort one. This would explain why the config_info doesn't reflect the >> STLPort usage. >> >> Can someone tell me what I should be doing differently? I don't know, but the dmc toolset is broken for the same reason. Actually this seems to me to be a bad design decision: why would the compilers include directory be present on the command line at all? If my compilers environment has been modified to place some other directory first (for example in vcvars32.bat) then why would bjam subvert that? I traced this to changes made at the beginning of august by Rene Rivera to factor out commonalities of stlport toolset. Basically not a bad idea but it ended up with this error. Rene is the best person to fix it if he's around. I sent him a private email but go no response. So I'm a little bit in holding pattern on this. Apparently there are some loose ends with the stlport/serialization library combination that I would like to resolve. Robert Ramey

2 1

Re:[boost] Review of Daryle Walker's "More IO" library begins today, August 21, 2004.
by Robert Ramey 30 Aug '04

30 Aug '04

Some general comments: First of all, let me say that I am a fan of Daryle's state-saver library. I have found it to be very useful. The documentation sections use the word "Rationale" where I think they should be using the word "Motivation". I see Motivation as the explanation why the library is useful in the first place. I see Rationale (plural) as a list of justifications for design choices. This is one library submission. However, it is really several almost disjoint or orthogonal parts. a) new io manipulators b) facilities for wrapping streambuf c) a couple of new kinds of streams These should be considered separately. Manipulators ============ Here is the first part of the documentation: Rationale There are several I/O manipulators that can be useful to a general audience besides the ones given in the Standard library. This header supplies some of them. Form-based Manipulator Header The header boost/io/iomanip_form.hpp contains a class template for multiple manipulations. Form-based Manipulator Objects from a boost::io::basic_ios_form template class represent manipulators that determine what and how to affect the standard I/O attributes via repeated calls to its member functions, then can change how a single insertion or extraction call happens for an streamable object. Said manipulators can be temporarily created (in-line, without a name) or created conventionally in advance for multiple insertions/extractions. On getting this far, I have no idea what these manipulators are supposed to do, what problem they are meant solve. Or when I would use them. I believe that this part of the manual should contain: Motivating example. Problem solved by form-based manipulators. A sort of Tutorial section. The line-skipping an repeated-char seem a little more understandable- if only because of their names. Repeated_char_narrow - I would think that the "narrowing" of characters might be something more commonly handled by codecvt facet. I would prefer that the html files be broken in smaller sections. Array Based Streams =================== Its not clear to me how this is functionally different from strstream Stream buffer implementations ============================= Stream buffer with variable size buffer Stream buffer which discards output Stream buffer which returns a constant value These I find understandable though I'm not sure what I would use them for - but that's not a criticism. The streams based on these buffers are small facilitators when don't have much code. OK. Stream buffer wrapper ===================== I gather this is to factor out common code for making new stream buffers. Actually, since I haven't made a streambuffer myself I don't know all of what's involved. I'll take your word that its useful. Overlap ======= I've also taken a forward look at Jon Turkanis coming offering. I see significant overlap. Jonathon's library is more ambitious in that it in that it addresses composition of stream buffer adaptors. I suspect it would include the above as subset. So - I'm going to recommend that the review manager for this library reserve judgment pending the upcoming review of the Jonathon's library. Ideally the two managers involved would coordinate their reviews so that functionality doesn't get duplicated. >What is your evaluation of the design? The design is a natural extension of standard C++ library and in principle I see no problems here. >What is your evaluation of the implementation? I didn't run the code, but it seems to follow standard convention - a good thing for a library like this. >What is your evaluation of the documentation? The documentation is pretty clear - as far as it goes. It needs more background, motivation, and tutorial like examples. >What is your evaluation of the potential usefulness of the library? >Did you try to use the library? With what compiler? Did you have any >problems? I didn't use the library. >How much effort did you put into your evaluation? A glance? A quick >reading? In-depth study? Just about 1-2 hours reviewing the documentation. >Are you knowledgeable about the problem domain? Fairly knowledgable >And finally, every review should answer this question: >Do you think the library should be accepted as a Boost library? Be sure to >say this explicitly so that your other comments don't obscure your overall >opinion. a) manipulators are probably OK - but they need more documentation to explain what they are to be used for. With these changes, I would expect to see them added to the io library. b) streambuffers. I believe that it premature to include these in Boost. I think this will be more clear after the upcoming review of Jon Turkanis library which has overlapping functionality. Robert Ramey

3 2

Java style GUI in C++
by Reece Dunn 29 Aug '04

29 Aug '04

I am currently designing a GUI framework in C++ (initially targeting the Windows platform) that uses a model similar to that which Java uses in it's AWT and Swing libraries. Specifically: [1] Being able to use constructors to create the windows/components. This means there is no need to explicitly call a Create method like in the MFC framework. [2] The use of layout managers. I like the various layout managers in Java and how easy it is to construct complex GUI interfaces. [3] The support for events via "listeners". This will most likely be geared towards key/mouse events and "action" events (e.g. when the user presses on a button). [4] Support for windowed and windowless components. Windowed components will use the native controls where possible, allowing a natural look and feel. Windowless controls will be lightweight components that do not use a native component (a Window handle on the Windows platform); these will be useful for writing the layout managers. At the moment, I have a basic working version that allows you to write the following: int PASCAL WinMain( HINSTANCE, HINSTANCE, LPSTR, int sw ) { swing::JFrame frame( L"Swing JFrame!" ); frame.setPane( new swing::JPanel()); frame.setSize( 500, 500 ); frame.show( sw ); MessageLoop msg; return( msg.Execute()); } This creates two windows: the main frame and a panel that is a child of that frame. The JFrame is created in the constructor, but is not displayed until show is called. Likewise, the JPanel is created inside its constructor and the JFrame.setPane method makes that window a child of the frame. I would appreciate comments and ideas as to what people would like out of a GUI framework, especially one that will be multi-platform. Regards, Reece _________________________________________________________________ It's fast, it's easy and it's free. Get MSN Messenger today! http://www.msn.co.uk/messenger

12 27

Copyright and License in XML documentation
by Jeff Garland 29 Aug '04

29 Aug '04

I found a few moments to work on cleaning up licensing issues and decided to go make sure all the date_time xml docs have licensing info. The problem is, how should the copyright be added to all the files? I hunted around in other libraries using boostbook and it looks like they all lack copyright and license info in all but the top level xml file. I notice that in the library main file we correctly notice the following construct in the inspection: <libraryinfo> <author> <firstname>Jeff</firstname> <surname>Garland</surname> </author> <copyright> <year>2001</year> <year>2002</year> <year>2003</year> <year>2004</year> <holder>CrystalClear Software, Inc</holder> </copyright> <legalnotice> <para>Subject to the Boost Software License, Version 1.0. (See accompanying file <filename>LICENSE_1_0.txt</filename> or copy at <ulink url="http://www.boost.org/LICENSE_1_0.txt">http://www.boost.org/LICENSE_1_0.txt</ulink>)</para> </legalnotice> <librarypurpose>A set of facilities to ease programming with dates and times. </librarypurpose> <librarycategory name="category:misc"/> </libraryinfo> So it seems one option would be to change the boostbook schema and allow copyright and legal notice elements in each file. The other possibility would be to add this as a comment:  Thoughts on how best to approach this? Jeff

1 0

is_abstract< A<int> > fails with gcc 3.4.1
by Christoph Ludwig 29 Aug '04

29 Aug '04

FYI: According to the regression tests, gcc 3.4.1 supports boost::is_abstract<T>. Unfortunately, that does not hold if T is a class template specialization, as exhibited by the following program: cludwig@lap200:~/C++/gcc3.4/tmp> cat ./is_abstract_test.cc #include <iostream> #include <iomanip> #include <boost/type_traits/is_abstract.hpp> template<typename T> class A { virtual void f() = 0; }; class B { virtual void f() = 0; }; int main() { std::cout << std::boolalpha; std::cout << "is_abstract< A<int> >::value == " << boost::is_abstract< A<int> >::value << '\n'; std::cout << "is_abstract< B >::value == " << boost::is_abstract< B >::value << '\n'; } cludwig@lap200:~/C++/gcc3.4/tmp> ./is_abstract_test is_abstract< A<int> >::value == false is_abstract< B >::value == true This causes problems, e.g., when using the serialization library with class templates. I entered the problem in the gcc bug database. It's PR#17232. Christoph -- http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/cludwig.html LiDIA: http://www.informatik.tu-darmstadt.de/TI/LiDIA/Welcome.html

1 0

problem with small width CRCs
by Bert Klaps 29 Aug '04

29 Aug '04

Hi, I ran into a problem using the CRC library for SDH LCAS control words (3-bit CRC) and SDH Trail Trace Identifier messages (7-bit CRC). For CRC widths smaller than character width the theoretical and optimized CRC computers produce different results for non-reflected input. Gcc produces this warning: /usr/local/boost/boost_1_31_0/boost/crc.hpp:581: warning: right shift count >= width of type The problem is that for the table based computer the msb of the remainder needs to be compared to the msb of the input byte. For most popular CRC parameters that's a right shift, but for CRC widths smaller than a character this should be a left shift... Reflected input requires comparing lsb's which doesn't involve any shifting. I've attached a patch that solved the problem for me. Regards, Bert Klaps /usr/local/boost/boost_1_31_0/boost/crc.hpp: In static member function `static unsigned char boost::detail::crc_helper<Bits, false>::index(typename boost::uint_t<Bits>::fast, unsigned char) [with unsigned int Bits = 3]': /usr/local/boost/boost_1_31_0/boost/crc.hpp:928: instantiated from `void boost::crc_optimal<Bits, TruncPoly, InitRem, FinalXor, ReflectIn, ReflectRem>::process_block(const void*, const void*) [with unsigned int Bits = 3, typename boost::uint_t<Bits>::fast TruncPoly = 3, typename boost::uint_t<Bits>::fast InitRem = 0, typename boost::uint_t<Bits>::fast FinalXor = 0, bool ReflectIn = false, bool ReflectRem = false]' /usr/local/boost/boost_1_31_0/boost/crc.hpp:947: instantiated from `void boost::crc_optimal<Bits, TruncPoly, InitRem, FinalXor, ReflectIn, ReflectRem>::process_bytes(const void*, unsigned int) [with unsigned int Bits = 3, typename boost::uint_t<Bits>::fast TruncPoly = 3, typename boost::uint_t<Bits>::fast InitRem = 0, typename boost::uint_t<Bits>::fast FinalXor = 0, bool ReflectIn = false, bool ReflectRem = false]' /usr/local/boost/boost_1_31_0/boost/crc.hpp:907: instantiated from `void boost::crc_optimal<Bits, TruncPoly, InitRem, FinalXor, ReflectIn, ReflectRem>::process_byte(unsigned char) [with unsigned int Bits = 3, typename boost::uint_t<Bits>::fast TruncPoly = 3, typename boost::uint_t<Bits>::fast InitRem = 0, typename boost::uint_t<Bits>::fast FinalXor = 0, bool ReflectIn = false, bool ReflectRem = false]' /usr/local/boost/boost_1_31_0/boost/crc.hpp:973: instantiated from `void boost::crc_optimal<Bits, TruncPoly, InitRem, FinalXor, ReflectIn, ReflectRem>::operator()(unsigned char) [with unsigned int Bits = 3, typename boost::uint_t<Bits>::fast TruncPoly = 3, typename boost::uint_t<Bits>::fast InitRem = 0, typename boost::uint_t<Bits>::fast FinalXor = 0, bool ReflectIn = false, bool ReflectRem = false]' /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.3/include/g++-v3/bits/stl_algo.h:157: instantiated from `_Function std::for_each(_InputIter, _InputIter, _Function) [with _InputIter = __gnu_cxx::__normal_iterator<unsigned char*, std::vector<unsigned char, std::allocator<unsigned char> > >, _Function = boost::crc_optimal<3, 3, 0, 0, false, false>]' lcas.cpp:44: instantiated from here /usr/local/boost/boost_1_31_0/boost/crc.hpp:581: warning: right shift count >= width of type *** crc.hpp.orig Tue Aug 10 14:10:34 2004 --- crc.hpp Tue Aug 10 14:57:06 2004 *************** *** 527,532 **** --- 527,556 ---- did_init = true; } + #ifndef BOOST_NO_TEMPLATE_PARTIAL_SPECIALIZATION + // Align the msb of the remainder to a byte + template < std::size_t Bits, bool RightShift > + class remainder + { + public: + typedef typename uint_t<Bits>::fast value_type; + + static unsigned char align_msb( value_type rem ) + { return rem >> (Bits - CHAR_BIT); } + }; + + // Specialization for the case that the remainder has less + // bits than a byte: align the remainder msb to the byte msb + template < std::size_t Bits > + class remainder< Bits, false > + { + public: + typedef typename uint_t<Bits>::fast value_type; + + static unsigned char align_msb( value_type rem ) + { return rem << (CHAR_BIT - Bits); } + }; + #endif // CRC helper routines template < std::size_t Bits, bool DoReflect > *************** *** 555,561 **** // Compare a byte to the remainder's highest byte static unsigned char index( value_type rem, unsigned char x ) ! { return x ^ ( rem >> (DoReflect ? 0u : Bits - CHAR_BIT) ); } // Shift out the remainder's highest byte static value_type shift( value_type rem ) --- 579,587 ---- // Compare a byte to the remainder's highest byte static unsigned char index( value_type rem, unsigned char x ) ! { return x ^ ( DoReflect ? rem : ! ((Bits>CHAR_BIT)?( rem >> (Bits - CHAR_BIT) ) : ! ( rem << (CHAR_BIT - Bits) ))); } // Shift out the remainder's highest byte static value_type shift( value_type rem ) *************** *** 578,584 **** // Compare a byte to the remainder's highest byte static unsigned char index( value_type rem, unsigned char x ) ! { return x ^ ( rem >> (Bits - CHAR_BIT) ); } // Shift out the remainder's highest byte static value_type shift( value_type rem ) --- 604,610 ---- // Compare a byte to the remainder's highest byte static unsigned char index( value_type rem, unsigned char x ) ! { return x ^ remainder<Bits,(Bits>CHAR_BIT)>::align_msb( rem ); } // Shift out the remainder's highest byte static value_type shift( value_type rem )

4 4

Triple change to Base-from-member
by Daryle Walker 28 Aug '04

28 Aug '04

I applied three changes for this library to CVS. (Three separate commits were done.) 1. Implemented a scheme to use the Pre-processor library to generate the various constructor templates. This allows the maximum number of constructors to be set at compile-time. It's a macro constant, so other headers can copy the exact number of constructors too. Changed "base_from_member.hpp" and "base_from_member.html". Shouldn't cause any problems unless your header can't work with the Pre-processor library. 2. Moved the default of the second template argument of base_from_member to the primary header. This removes the last component of "utility_fwd.hpp". Changed "base_from_member.hpp" and "base_from_member.html", and removed "utility_fwd.hpp". Shouldn't cause any problems unless your header directly #included "utility_fwd.hpp", which my check didn't pick up. 3. Forgot to update the copyright year list of "base_from_member.hpp" to add 2004. Changed that. Shouldn't cause any (additional) problems. -- Daryle Walker Mac, Internet, and Video Game Junkie darylew AT hotmail DOT com

1 0

[type_traits] "member_function_pointer_traits" ?
by Tobias Schwinger 28 Aug '04

28 Aug '04

Dear Boosters, what is the reason for the absence of "member_function_pointer_traits" (or alike) in the type_traits library ? To be precise: is it a design decision or just something not yet implemented ? In the latter case I hereby volunteer for implementing it. I suggest an interface similar to the one of function_traits but with two additional constants for 'const' and 'volatile' qualification of the pointee method, because there is no member function type without the pointer thus making it impossible to use remove_pointer / is_[qualifier] or pass 'Class::member_function' (without the '&', that is) as an argument of parametrized type to a template function. Best regards, Tobias

5 7

RE: [boost] Re: [1.32 Plan] Stalled forever?
by Rozental, Gennadiy 28 Aug '04

28 Aug '04

> Gennadiy Rozental writes: > > I would like to second that. > > > > Two month ago I was told that I had to freeze any development yet > > another month ago. Now we still nowhere and I still couldn't move a > > finger. > > 1) Release or not, any major new development should happen on > the branch. I could do my own development anywhere, even keep files on my hard drive. How am I supposed to test it? > 2) At least please take care of the unmarked failures in > Boost.Test before > claiming that you've done your part for the release. Does it say anywhere that I am required to? All the failures either expected or too minor to jump to fixes now and disturb the release. I had enough unexpected headache with things I did decide to fix > > I understand that it may be caused by book preparation. But > should we > > necessarily need to use namely this release? > > Yes. We have to use a coherent set of sources that contains > the new version of the MPL, and this is what this release is > going to provide us with, in particular. We may've published this release month ago with MPL changes. And publish another one (may be patch release) month from now with new MPL. > > > > Let at least set a policy for open information: if for > whatever reason > > release needs to be postponed lets announce it and set a new date. > > There *was* announcement of the release delay. The new date is > going to be set as soon as MPL is in the main trunk. I don't believe "release postponed until further notice" is good enough. The same time new schedule needs to be proposed and agreed upon (or after discussion we may decide to go ahead with release on previously defined terms, ignoring issues causing release to postpone). Please, understand that I am not trying to find responsible. But I also don't find this uncertainty acceptable. Regards, Gennadiy.

3 2