- Boost - lists.boost.org

1.31.0 Win32 Graph/graph failures?
by Beman Dawes 02 Feb '04

02 Feb '04

Damn! Win32 Graph/graph has been failing for Intel and Microsoft since sometime Friday! That's a showstopper. Quick response would be greatly appreciated. --Beman The VC++7.1 error message begins: D:\boost-snapshot\boost\graph\detail\adjacency_list.hpp(1325) : error C2440: 'initializing' : cannot convert from 'std::_Tree<_Traits>::const_iterator' to 'std::_Tree<_Traits>::iterator' with [ _Traits=std::_Tset_traits<boost::detail::adj_list_gen<boost::adjacency_list<boost::setS,boost::setS,boost::undirectedS,boost::property<vertex_id_t,size_t>,boost::property<edge_id_t,size_t>>,boost::setS,boost::setS,boost::undirectedS,boost::property<vertex_id_t,size_t>,boost::property<edge_id_t,size_t>,boost::no_property,boost::listS>::config::StoredEdge,std::less<boost::detail::adj_list_gen<boost::adjacency_list<boost::setS,boost::setS,boost::undirectedS,boost::property<vertex_id_t,size_t>,boost::property<edge_id_t,size_t>>,boost::setS,boost::setS,boost::undirectedS,boost::property<vertex_id_t,size_t>,boost::property<edge_id_t,size_t>,boost::no_property,boost::listS>::config::StoredEdge>,std::allocator<boost::detail::adj_list_gen<boost::adjacency_list<boost::setS,boost::setS,boost::undirectedS,boost::property<vertex_id_t,size_t>,boost::property<edge_id_t,size_t>>,boost::setS,boost::setS,boost::undirectedS,boost::property<vertex_id_t,size_t>,boost::property<edge_id_t,size_t>,! boost: : no_property,boost::listS>::config::StoredEdge>,false> ] and [ _Traits=std::_Tset_traits<boost::detail::adj_list_gen<boost::adjacency_list<boost::setS,boost::setS,boost::undirectedS,boost::property<vertex_id_t,size_t>,boost::property<edge_id_t,size_t>>,boost::setS,boost::setS,boost::undirectedS,boost::property<vertex_id_t,size_t>,boost::property<edge_id_t,size_t>,boost::no_property,boost::listS>::config::StoredEdge,std::less<boost::detail::adj_list_gen<boost::adjacency_list<boost::setS,boost::setS,boost::undirectedS,boost::property<vertex_id_t,size_t>,boost::property<edge_id_t,size_t>>,boost::setS,boost::setS,boost::undirectedS,boost::property<vertex_id_t,size_t>,boost::property<edge_id_t,size_t>,boost::no_property,boost::listS>::config::StoredEdge>,std::allocator<boost::detail::adj_list_gen<boost::adjacency_list<boost::setS,boost::setS,boost::undirectedS,boost::property<vertex_id_t,size_t>,boost::property<edge_id_t,size_t>>,boost::setS,boost::setS,boost::undirectedS,boost::property<vertex_id_t,size_t>,boost::property<edge_id_t,size_t>,! boost: : no_property,boost::listS>::config::StoredEdge>,false> ] No constructor could take the source type, or constructor overload resolution was ambiguous

3 5

[filesystem] adding path equality and path equivalence
by Beman Dawes 02 Feb '04

02 Feb '04

Equality -------- The path relational operators will be defined purely in terms of string comparison between the textual representation of the two paths. There are two ways to do this: (1) string comparison using std::string relational operators or (2) string comparison using std::lexicographical_compare. Given two paths, "foo.bar" and "foo/bar", (1) will order them: foo.bar foo/bar While (2) will order them: foo/bar foo.bar The primary use case I know of for operator<() is default ordering for paths used as keys in associative containers. I can't see that either approach is superior for this use, so unless someone comes up with a compelling argument, (1) will be used. Equivalence ----------- Two paths will be considered equivalent if they resolve to the same physical directory or file. Question 1: What is a use case that requires this function? Verifying that source and target files are different before some modifying operation is the only one I've come up with. I guess that is sufficient to justify adding the function. Question 2: What if neither exist? Only one exists? My initial thought is that these are likely to be errors, so treat them as such. It could be argued that if either or both don't exist, they can't be equivalent, so return false. Question 3: The implementation on Windows (see below) leaves a small hole in that duplicated media (such as two CD's) mounted on devices with the same device id on two different networked machines would be reported as equivalent. POSIX requires that such networked devices have different device id's, avoiding the problem. Is the fact that Windows and POSIX implementations would perform slightly differently on this corner case a showstopper? I think not. Windows logic for path equivalent: same device id AND same media volume serial number AND same physical location on disk AND same creation time. This works even in degenerate cases like camera formatted FAT flash memory cards or floppy disks with volume serial numbers incorrectly initialized to 0. POSIX logic: same device id AND same physical location on disk AND same modification time. The modification time is in theory redundant, but is an added protection in case the device id on networked devices failed to meet the POSIX specs. --Beman

6 16

value_initialized, deep const, and template instantiation
by Jim Apple 02 Feb '04

02 Feb '04

value_initialized has non-deep (shallow?) const semantics. const value_initialized<T> is supposed to be const. Unfortunately, due to compiler errors in VC++ and Borland, it has operator T &() const instead of operator T&() operator const T&() const which breaks const-correctness in a big way. I'd like for there to be a config macro that identifies this error. I would make one, as well as a test for it, myself, but I only have access to icc and gcc on linux, both of which pass the test, so it's hard trying to identify the extent of the overloading selection failure. After creating this macro, we could use it to make a const correct value_initialized class for users with more advanced compilers. For those compilers, I think there would be value to adding operator-> for the invocation of member functions, like boost::optional. As an alternative, deep-copy would break const expectations in generic functions that take a const T &, but it would preserve it elsewhere, so it may be worth some more thought. Finally, I have come up with a similar class (which I wrote with deep const sematics, although I am open to argument about shallow const) for solving the following problem: ---------------------------------------------------------------------- #include <iostream> template<typename T> struct wrap { static const T joe; }; template<typename T> const T wrap<T>::joe; struct call_out { int num; call_out() : num(77) {} }; template<typename T> struct check_call { check_call() { std::cout << wrap<T>::joe.num << std::endl; } }; check_call<call_out> x; int main(){} ----------------------------------------------------------------------- This outputs 0, not 77, on gcc 3.3.2, intel 8, and vc6. I don't know if that's correct, 14.7.1/1 says: "... in particular, the initialization (and any associated side effects) of a static data member does not occur unless the static data member is itself used in a way that requires the definition of the static data member to exist." If this is std-conforming behavior, or not, i have a workaround that allows: ------------------------------------------------------------------------ #include <iostream> #include "can_init.hpp" template<typename T> struct wrap { static can_init<const T> joe; }; template<typename T> can_init<const T> wrap<T>::joe; struct call_out { int num; call_out() : num(77) {} }; template<typename T> struct check_call { check_call() { wrap<T>::joe.ensure_init(); std::cout << wrap<T>::joe->num << std::endl; } }; check_call<call_out> x; int main(){} ----------------------------------------------------------------------- which obviously uses deep const. Is there any interest in including this in boost/utility/? Should it have shallow or deep const semantics? Jim

2 5

Output Formatters [update]
by Reece Dunn 02 Feb '04

02 Feb '04

There are now Jamfiles for the examples and test facility :) that has been tested on Boost.Build V2. I am currently working on developing a regression test facility that has been posted to the sandbox CVS (this is still experimental, but is quite stable). Feedback? When you run one of the test programs, they will produce a results.xml file, or add to it if the file already exists. To work as intended, the programs need to be moved to a directory that contains the view.xsl file then run seperately for each compiler/library configuration you are testing. I am looking at how to do this within the Jamfile :). Aside from that, I have been working on bugs and completing the read/input facilities. I have fixed it now so that sequential, set and associative containers are read properly. The only defect remaining (thus far) is reading string types: The string handling code has been dropped from basic_object as this intefered with wrapped_object, causing the serialization example to fail. I am currently working on getting strings properly supported and will upload it when it is working. Regards, Reece _________________________________________________________________ Express yourself with cool new emoticons http://www.msn.co.uk/specials/myemo

1 0

compile-time array count
by Gennaro Prota 02 Feb '04

02 Feb '04

Having a look to some old list messages I've seen there has been some discussion about discovering the number of elements of an array in compile-time. Sorry if I have simply misunderstood something here (I'm rapidly catching up with old threads), but isn't this enough? http://article.gmane.org/gmane.comp.lib.boost.devel/3216 That's for expressions, of course, not type-ids. Genny.

4 8

Re: [boost] Re: Boost Digest, Vol 622, Issue 5
by John Maddock 02 Feb '04

02 Feb '04

> How about using Boost.Thread's call_once function? I realize it requires > extra code, but something along these lines seems like it should both > avoid too much locking and still work: > Aha, good thinking, yes that's a good idea. John.

2 1

Liohyjdxevcm
by jewillco＠osl.iu.edu 02 Feb '04

02 Feb '04

The message cannot be represented in 7-bit ASCII encoding and has been sent as a binary attachment.

1 0

Re: problem with new iterators in 1.31 Release candidate # 2
by Robert Ramey 02 Feb '04

02 Feb '04

Dave Abrahams wrote: >Robert Ramey wrote: >> it seems to me that it is implemented for non - random access >> iterators by incrementing one iterator until it equals the other and >> return the number of times the increment occured. >Yeah, it's a mistake. It shouldn't use distance, but operator-. >That way neither one of your subtractions would compile. >From the documentation: counting_iterator requirements The Incrementable argument shall be Copy Constructible and Assignable. If iterator_category is convertible to forward_iterator_tag or forward_traversal_tag, the following must be well-formed: Incrementable i, j; ++i; // pre-increment i == j; // operator equal Suppose I had used a different iterator as a base - not an input iterartor but some kind of forward transveral iterator. Would that have been ok? Now if I understand correctly? the only difference between the single pass transveral and forward transversal is the ability to "rewind". As far as I can see the ability doesn't affect the requirement stated above. Are sure that the requirement isn't too strong. The fact that it "accidently" works seems to suggest this. from the nomenclature, example, other "counting iterators", and common sense, I would expect an example such as the one I presented to function as I expected. And in fact it did in the previous release candidate. That is, its natural to expect the following to function std::fstream is; std::input_iterator begin(is), end(); int filesize = end - begin; Can the design and implement (of off course document) be adjusted to permit this? If such a seemingly natural usage is not possible, it should be trapped at compile time (as you suggested) and the reason why it can't be supported described in the documentation. Robert Ramey

2 1

Re: problem with new iterators in 1.31 Release Candidate # 2 (repost)
by Robert Ramey 02 Feb '04

02 Feb '04

I didn't get the formating correct on this so I want to repost it so it makes more sense. >David Abrahams wrote: >>Robert Ramey <ramey(a)rrsd.com> writes: >> I have a problem with the latest version of the new iterators. >> This is illustrated in the following example. >> >> #include <strstream> >> #include <iterator> >> #include <boost/iterator/counting_iterator.hpp> >> >> main(){ >> std::istrstream is("abcdefg"); >> typedef boost::counting_iterator<std::istream_iterator<char> > ci; >> const ci end = std::istream_iterator<char>(); // note the const !!! >I don't see why the const should be relevant. >From looking at the code for counting iterator it seems to me that it is implemented for non - random access iterators by incrementing one iterator until it equals the other and return the number of times the increment occured. (I concede that I've had difficulty following the implementation so I could be wrong). So if one of the iterators is const - that one can't be the one that's incremented. >> ci begin = std::istream_iterator<char>(is); >Hmm, the implicit conversions from istream_iterator to the >counting_iterator above are troubling. I think those constructors >should be explicit. Hmmm - From looking at the documentation and the code, I get absolutly no indication that the counting iterator requires a random access iterator. In fact, looking at the code suggests that there is code especially included to handle any forward transversal iterators. And the first invocation below DOES work - I can't believe that's an accident. >> unsigned int size; >> >> // the following should fail at compilation ? >Why? OK, maybe it would be better to make it fail because the >iterator is not in fact a random-access iterator. > // in fact it compiles are returns a value of -7 !!! > size = begin - end; > > // the following should compile and return a value of 7 > // in fact, it compiles but goes into an infinite loop > size = end - begin; > } My mistake - I wrongly presumed that only the second iterator would be incremented and since its const it should fail. It looks like the code intends to select which iterator to increment depending on const. So this first case looks ok to me now. >I don't see why you think the first should compile but the second >should not. If they're not random-access iterators, it seems to me >that there's no reason you should be able to subtract them in any >order. If they were random-access iterators, it would be unreasonable >to expect the compiler to detect which one had an earlier position >and disallow one subtraction. So my position is that both compile (as they should). The first works as one would expect while the second results in an infinite loop. I'm sorry but I don't see how this can be correct. >> Note that this problem did not appear with the first release candidate. > >> Also, if one follows the links from the main documentation page, one >> is directed to the documentation of the old iterators. This is >> extremely confusing. This has been pointed out before. >That's a serious problem which I'll fix immediately. Robert Ramey

1 0

[config] BOOST_EXPLICIT_TEMPLATE_TYPE_SPEC
by Gennaro Prota 01 Feb '04

01 Feb '04

A while ago I pointed out that BOOST_EXPLICIT_TEMPLATE_TYPE_SPEC and its three variations (in config/suffix.hpp) are useless for VC6 (the only compiler, IIRC, for which the non-_SPEC versions were introduced). http://article.gmane.org/gmane.comp.lib.boost.devel/23486/ I thought they had been removed but I see that they are still there. There's one usage, in variant/detail/forced_return.hpp. Is it really needed? Why? Genny.

1 0