- Boost - lists.boost.org

Re: immutable string
by Igor Kholodov 27 Sep '04

27 Sep '04

>reverse_iterator and reverse_const_iterator actually >refer the same type: > > typedef char_type const* iterator; > typedef char_type const* const_iterator; > typedef std::reverse_iterator<iterator> >reverse_iterator; > typedef std::reverse_iterator<const_iterator> >reverse_const_iterator; Agree, but which name should we used - "reverse_const_iterator" or "const_reverse_iterator"? I thought it was the latter. Igor Kholodov cttl(a)users.sourceforge.net http://cttl.sourceforge.net/

2 1

Re:[boost] Re:[serialization] scoped_ptr.hpp broken
by Robert Ramey 27 Sep '04

27 Sep '04

Vladimir wrote: >I think the docs are a bit unclear: Well, I guess that's no surprise as the whole question is still not totally clear to me. >What's the meaning of 'dependent' type? Do you mean 'dependent in context >of 'serialize'? Then, if I write: > template<class Archive> > inline void serialize( > Archive & ar, > my_class & t, > const unsigned long int file_version) {} >then the type to be serialized is never dependent type. Or do you refer to >a case where 'serialize' is templated on saved type? I'd suggest that you >write that explicitly, as "dependent type" is a bit vague. >From Vandervoorde and Josuttis book "C++ Templates - A Complete Guide" page 119 I quote: "A name is a dependent name if it depends in some way on a template parameter. For example, std::vector<T>::iterator is a dependent name if T is a template parameter but it is a nondependent name if T is a known typedef (for example, of int)." That is the definition I'm using for "dependant type" >> Before this change, there is a problem with compilers which implement >> two-phase lookup. Overrides for templates have to be defined before their >> usage in another template. >It would be great if you could put the explanation to the docs. I'll try to expand on this a little. >BTW, I start >to wonder if two-phase lookup does any good, for all additional portability >problems that it has. I've "wondered" about that as well. I brought this up before and the rationale was explained to me but I was left unsatisfied. I have to say this is the kind of thing that raises doubts in my mind about the applicability of C++ for programming jobs assigned to people who can't justify the rigorous parsing of the standard and extremely subtle compiler variations. That is - the rest of us. >> This conflicted with the implementation of >> BOOST_CLASS_EXPORT. To support these compilers, I had to either put >> non-intrusive serialization functions in the same namespace as the type >> being serialized or re-organize export. The latter is non-trivial and >> couldn't be guaranteed to be ready in time for release (at least at the >> time the issue came up). >Is the issue really with BOOST_CLASS_EXPORT? It seems that on compilers >with two-phase lookup, if 'save' overloads are in boost::serialization, >they must be seen before any code which uses 'save'. And this requirement >is not specific to BOOST_CLASS_EXPORT. And also, btw, the table says >boost::serialization is suitable for 'save' overload if compiler supports >ADL, two-phase lookup and type is dependent. Why is it so? Damn - now I have to figure it out all over again. I honestly don't remember. I believe I concluded that the problem could be addressed by requiring all the serialization headers be specified before all the archive headers, but that THAT conflicted with the implementation of export which required the opposite. It turned out invoking serialization without namespace qualification delayed lookup until instantiation and that resolved the solution. My current thinking is that I should re-implement export so that all serializations can be required to be before inclusion of all archive headers. Then serializations could be in any of the following namespace (on conforming compilers: Boost::serialization The namespace of T The namespace of Archive And that section of the manual could be eliminated. Robert Ramey

1 0

FORMAL review of "Output Formatters" - votes needed
by John Torjo 27 Sep '04

27 Sep '04

Dear boosters, There's been quite a hot debate about "Output Formatters" library. Reece has provided some input facilies in this library as well. This has drawn people to either sides: some don't want these input facilities, while others do. To conclude, I would like to ask you to vote: - "Yes" - in favor of Input facilities - "No" - don't want Input facilities. My personal vote is "No". Please share your own. Best, John Review Manager -- John Torjo -- john(a)torjo.com Contributing editor, C/C++ Users Journal -- "Win32 GUI Generics" -- generics & GUI do mix, after all -- http://www.torjo.com/win32gui/ -- v1.4 - save_dlg - true binding of your data to UI controls! + easily add validation rules (win32gui/examples/smart_dlg)

8 12

cvs wedged?
by Neal D. Becker 27 Sep '04

27 Sep '04

Been saying this for a while now: cvs update: [15:53:19] waiting for david_abrahams's lock in /cvsroot/boost/boost/libs/numeric/ublas/test4

2 1

Re: [Test] Current failures
by Gennadiy Rozental 27 Sep '04

27 Sep '04

"Jonathan Wakely" <cow(a)compsoc.man.ac.uk> wrote in message news:20040923120115.GA88617@compsoc.man.ac.uk... > On Thu, Sep 23, 2004 at 06:22:58AM -0500, Aleksey Gurtovoy wrote: > > > Gennadiy, > > > > Could you please take a look at/comment on the current Boost.Test > > failures as per http://tinyurl.com/5wojs? > > Attached patch fixes the failures. > > jon Thanx, Jonathan. I forgot about this one. Will fix today. Regards, Gennadiy.

2 2

Re: [boost] [multi_index + mpl + bind] Regression?
by JOAQUIN LOPEZ MU?Z 27 Sep '04

27 Sep '04

Hi again Volodya, after thinking this over I'm not so sure the mpl::deref thing has anything to do with your problem --still, it'd be good to know whether it has some impact, if you can do the test locally. I'm afraid we're in Alexsey's hands to solve this out. BTW, boost/bind/arg.hpp is deceivingly simple I can't figure out how its inclusion can make a difference. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo ----- Mensaje original ----- De: JOAQUIN LOPEZ MU?Z <joaquin(a)tid.es> Fecha: Sábado, Septiembre 25, 2004 3:56 pm Asunto: Re: [boost] [multi_index + mpl + bind] Regression? > Vladimir, I don't have my compiler handy right > now, but I think this is due to an overlook when > doing the adaptation to the new MPL. In particular, > the line 50 in boost/multi_index/detail/node_type.hpp: > > typedef typename IndexSpecifierIterator::type index_specifier; > > should be changed to > > typedef typename mpl::deref<IndexSpecifierIterator>::type > index_specifier; > > (also, the corresponginf #include <boost/mp/defer.hpp> > must be inserted) > Could you please try this locally and report the results? > If the problem is solved, I'll commit something along this > line next Monday. > > I don't know the rationale for having to use deref, since > I thought these two expressions are equivalent, but there > must be some difference, for Alexsey changed some of the > code in multi_index to do that when mergien the new MPL. > > Joaquín M López Muñoz > Telefónica, Investigación y Desarrollo > > > ----- Mensaje original ----- > De: Vladimir Prus <ghost(a)cs.msu.su> > Fecha: Sábado, Septiembre 25, 2004 2:41 pm > Asunto: [boost] [multi_index + mpl + bind] Regression? > > > > > The attached code, which use the multi_index library, produces > > screens of > > errors from mpl. The STLfilted log is attached too. > > > > Commenting out #include <boost/bind/arg.hpp> makes the error go > > away, as well > > as including it after multi_index. > > > > This happens with: > > gcc version 3.3.4 (Debian 1:3.3.4-6sarge1) > > gcc version 3.4.1 (Debian 3.4.1-4sarge1) > > > > The code used to work some time ago, but I can't give the exact > date.> > > I've tried too look at the problem, but got lost in MPL internals. > > > > - Volodya > > > _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

4 8

[Test or Build?] How to add dummy files and dirs to a test?
by Angus Leeming 27 Sep '04

27 Sep '04

Dear all, I'm putting the finishing touches to a Posix-conformant boost::glob function that I'd like to submit to Boost (assuming there's some interest). However, before I do so, I'd like to get the regression tests running smoothly. Currently my 'test' directory contains: $ ls .oo* foo* foo1bar foo bar foo!bar foo]bar foo*bar foocbar foo.hpp fooabar foo-bar foo?bar foo{bar foo\bar foo.cpp .oobar foo^bar foo,bar foo[bar foo}bar foobbar foo.cxx All 20 of these files have zero size; the idea is to test boost::glob's ability to find matches. However, I'd rather not have them as part of the library. How do I get the test framework to create them for me before running a test? Regards, Angus

4 7

[serialization] documentation for xml archive usage
by Christoph Ludwig 27 Sep '04

27 Sep '04

Hi, I am using the Boost Serialization library with the text archive implementation in my project and it works quite well. Robert did a very good job - thanks! For some reason I am considering switching to the xml archive implementation. However, this triggers a BOOST_STATIC_ASSERT in basic_xml_oarchive<Archive>::save_override<T>(const T&, BOOST_PFTO int). The implementation insists that all serialized types be wrapped in a nvp<T>. I think I understand more or less why this is necessary - the xml archive implementation generates the xml name tags from the information stored in the nvp wrapper. But I couldn't find an explanation in the docs what special steps a user is supposed to take if the data shall be serialized into an xml archive. (The only hint that xml archives need special care that I found was the description of the header file nvp.hpp libs/serialization/doc/headers.html: "To associate a name tag with a serializable object. This is necessary to properly render an xml archive which includes the object name." BTW, this webpage claims nvp.hpp is in boost/archive, but in fact it is in boost/serialization.) Do I need to write ar & nvp<MyMemberType>("my_member_tag", this->my_member); in my serialization functions for every variable I want to (de-)serialize? Can I choose an arbitrary tag for each variable or is it supposed to be consistent for all variables of a specific type? Am I correct to assume that the code will still work if I serialize into a "normal" text archive and the nvp will essentially be ignored? I guess I could find my answers by some trial and error and digging through the test cases. But since I probably won't be the only user looking for this information may I suggest that a section explaining the issues with xml archives be added to the docs before the 1.32 release? Thanks Christoph -- http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/cludwig.html LiDIA: http://www.informatik.tu-darmstadt.de/TI/LiDIA/Welcome.html

2 2

[program_options] cw9.3 failures
by Vladimir Prus 27 Sep '04

27 Sep '04

The current regression test results show two similar failures of program_options on cw9.3 http://tinyurl.com/6ay5m The situation is the following: parsers.hpp contain: template<class charT> basic_parsed_options<charT> parse_config_file(std::basic_istream<charT>&, const options_description&); parsers.cpp contain: template<class charT> basic_parsed_options<charT> parse_config_file(std::basic_istream<charT>& is, const options_description& desc) { ........ } template BOOST_PROGRAM_OPTIONS_DECL basic_parsed_options<char> parse_config_file(std::basic_istream<char>& is, const options_description& desc); And the linker can't find the explicitly instantinated function. This happens only in _dll tests, so I'd suspect a bug in the compiler/linker. Can anybody sched the light on this? Thanks, Volodya

2 4

Any interest in a boost::glob() function?
by Angus Leeming 27 Sep '04

27 Sep '04

Dear all, I've taken Richard Johnson's glob_iterator that he posted to the list back in January and re-written it completely, using Boost.Spirit to transform the input 'glob' into an equivalent regex. The result is a 'boost::glob' function that I believe is fully POSIX-conformant. Example usage: fs::path const starting_directory("."); std::list<fs::path> const matches = boost::glob("../te?t/foo*bar", starting_directory); The docs can be browsed online at http://www.devel.lyx.org/~leeming/globbing/index.html The library can be found at http://www.devel.lyx.org/~leeming/globbing.zip It should unzip to give: boost/glob.hpp boost/detail/glob.hpp libs/glob + ensuing sub directories and files. The code has been tested on Linux (g++ 3.3.2) and on Windows using MinGW/MinSys. There are still some "issues" that I don't know how to resolve. Any pointers would be most welcome: REGEX ===== A single test "foo[[:alpha:]]bar" is failing under Windows. It succeeds under Linux. Is there anything about Boost.Regex with MinGW/MinSys that I should be aware of? DOCS ==== * It would be nice to insert a table inside an itemized list item, but quickbook doesn't like doing that. Instead I must add the table in a separate paragraph which messes up the look a little. * boostbook/doxygen fails to document the glob_flags enum. * I generate a BOOST_LIB_NAME.html page and would like to supress it. * The bottom of the first page has this "Last revised: September 13, 2004 at 04:56:20 GMT" I don't know where it comes from, but it's just not true ;-) BUILD ===== I have a couple of targets, lib/glob/example/real_glob.cpp and lib/glob/test/test_real_glob.cpp that I'd like to build only on POSIX machines. (They're wrappers for the system glob function.) Any pointers on how to instruct bjam to do that? Regards, Angus

1 0