- Boost - lists.boost.org

[Boost-bugs] [ boost-Bugs-937606 ] filesystem::directory_iterator returns incorrect listing
by SourceForge.net 19 Apr '04

19 Apr '04

Bugs item #937606, was opened at 2004-04-19 14:04 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=937606&group_i… Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jonathan Roewen (s-a-t-a-n) Assigned to: Nobody/Anonymous (nobody) Summary: filesystem::directory_iterator returns incorrect listing Initial Comment: directory_iterator doesn't work correctly under debian linux (sarge/testing). Returns an invalid iterator value, which can cause a segmentation-fault, and drops the last item from the resulting listing. path dir = "my_dir"; if ( exists(dir) || !is_directory(dir) ) return; directory_iterator itr(dir), end; while ( itr != end ) { const path &p = *itr++; //-- do something with it } When I had a directory with only one file, no actual filenames were returned. When calling methods such as leaf() on const path &p, it would cause a seg-fault. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=937606&group_i… ------------------------------------------------------- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

Re: [boost] Re: [indexed_set] revised naming proposal
by JOAQUIN LOPEZ MU?Z 19 Apr '04

19 Apr '04

----- Mensaje original ----- De: Jeremy Maitin-Shepard <jbms(a)attbi.com> Fecha: Jueves, Abril 15, 2004 7:50 pm Asunto: Re: [boost] Re: [indexed_set] revised naming proposal > How about just allowing any MPL sequence to specify the indices? mpl_index_list does precisely this. Check the MPL part in the advanced topics section of the docs. > > Also, it would be a nice syntactic convenience to allow the main > container template to accept a "variable" number of parameters, > and then > allow the indices to be specified as parameters directly to the main > container template. > Pardon? Do you mean something like multi_index_container < employee, ordered_unique<...>, unordered_unique<...> > without the index_list<> nesting? This cannot be done, as multi_index_container accepts an additional argument, the allocator class. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

6 7

Re:[boost] Serialization compile errors on CW9
by Robert Ramey 18 Apr '04

18 Apr '04

Miro Jurisic wrote: > I am trying to play with Serialization #18 on CodeWarrior 9, and I ran > into the following problems: > mbstate_t is not in the global namespace when using CW9 and MW STL > (I didn't test with gcc STL). This caused compile errors in > archive/codecvt_null.hpp. I altered the workaround already present for > Borland, but I believe this is the wrong answer, because it puts a using > declaration in a header file. We're open to suggestions. > That leaves me with the following two errors in compiling > text_oarchive.cpp... I am not sure what to do about these two errors, > but I am too tired to stare at them right now, so I am posting them here > in hope that someone can make sense out of them... the second error in > particular makes no sense to me at all. meeroh My formatting: > Error : illegal explicit conversion from > 'boost::iterator_facade< > boost::archive::iterators::insert_linebreaks< > boost::archive::iterators::base64_from_binary< > boost::archive::iterators::transform_width< > const char *, 6, 8, char > >, > Char > >, > 72, > Char > >, > char, > boost::single_pass_traversal_tag, > char, > char > >' > to 'const char *' ... I recently cleaned up and streamlined the implementation of the "dataflow iterators" in my local copy. I don't know if this will make the above disappear. I sort of doubt it. I'm suspicious of the transition from char to const char. I'll look at this. > Error : object > 'boost::archive::text_oarchive_impl<boost::archive::text_oarchive> > ::text_oarchive_impl `base constructor'(std::basic_ostream<char, > std::char_traits<char>> &, unsigned int)' redefined This looks like a compiler issue in getting bool/int confused. Try Changing basic_text_oprimitive<std::ostream>( os, 0 != (flags & no_codecvt) ) At around line 63 in file text_oarchive.hpp to basic_text_oprimitive<std::ostream>( os, static_cast<bool>(0 != (flags & no_codecvt)) ) Robert Ramey

3 2

Serialization compile errors on CW9
by Miro Jurisic 18 Apr '04

18 Apr '04

I am trying to play with Serialization #18 on CodeWarrior 9, and I ran into the following problems: mbstate_t is not in the global namespace when using CW9 and MW STL (I didn't test with gcc STL). This caused compile errors in archive/codecvt_null.hpp. I altered the workaround already present for Borland, but I believe this is the wrong answer, because it puts a using declaration in a header file. Inside iterator_facade, I had to change: Derived const& derived() const { return static_cast<Derived const&>(*this); } to Derived const& derived() const { return *static_cast<Derived const*>(this); } Without that change, CW gives a warning saying that the function returns a reference to an automatic variable. I am pretty sure the warning is wrong, but this change silenced it, and I don't have the time to read over the spec to find out if the warning is correct or not. That leaves me with the following two errors in compiling text_oarchive.cpp... I am not sure what to do about these two errors, but I am too tired to stare at them right now, so I am posting them here in hope that someone can make sense out of them... the second error in particular makes no sense to me at all. meeroh Error : illegal explicit conversion from 'boost::iterator_facade<boost::archive::iterators::insert_linebreaks<boost::archi ve::iterators::base64_from_binary<boost::archive::iterators::transform_width<cons t char *, 6, 8, char>, char>, 72, char>, char, boost::single_pass_traversal_tag, char, char>' to 'const char *' (instantiating: 'boost::archive::basic_text_oprimitive<std::basic_ostream<char, std::char_traits<char>>>::save_binary(const void *, unsigned long)') (instantiating: 'std::copy<boost::archive::iterators::insert_linebreaks<boost::archive::iterators ::base64_from_binary<boost::archive::iterators::transform_width<const char *, 6, 8, char>, char>, 72, char>, boost::archive::iterators::ostream_iterator<char>>(boost::archive::iterators::ins ert_linebreaks<boost::archive::iterators::base64_from_binary<boost::archive::iter ators::transform_width<const char *, 6, 8, char>, char>, 72, char>, boost::archive::iterators::insert_linebreaks<boost::archive::iterators::base64_fr om_binary<boost::archive::iterators::transform_width<const char *, 6, 8, char>, char>, 72, char>, boost::archive::iterators::ostream_iterator<char>)') (instantiating: 'boost::operator!=<boost::archive::iterators::insert_linebreaks<boost::archive::i terators::base64_from_binary<boost::archive::iterators::transform_width<const char *, 6, 8, char>, char>, 72, char>, char, boost::single_pass_traversal_tag, char, char, boost::archive::iterators::insert_linebreaks<boost::archive::iterators::base64_fr om_binary<boost::archive::iterators::transform_width<const char *, 6, 8, char>, char>, 72, char>, char, boost::single_pass_traversal_tag, char, char>(const boost::iterator_facade<boost::archive::iterators::insert_linebreaks<boost::archiv e::iterators::base64_from_binary<boost::archive::iterators::transform_width<const char *, 6, 8, char>, char>, 72, char>, char, boost::single_pass_traversal_tag, char, char> &, const boost::iterator_facade<boost::archive::iterators::insert_linebreaks<boost::archiv e::iterators::base64_from_binary<boost::archive::iterators::transform_width<const char *, 6, 8, char>, char>, 72, char>, char, boost::single_pass_traversal_tag, char, char> &)') (instantiating: 'boost::archive::iterators::insert_linebreaks<boost::archive::iterators::base64_f rom_binary<boost::archive::iterators::transform_width<const char *, 6, 8, char>, char>, 72, char>::insert_linebreaks<boost::iterator_facade<boost::archive::iterators::insert _linebreaks<boost::archive::iterators::base64_from_binary<boost::archive::iterato rs::transform_width<const char *, 6, 8, char>, char>, 72, char>, char, boost::single_pass_traversal_tag, char, char>>(boost::iterator_facade<boost::archive::iterators::insert_linebreaks<boost: :archive::iterators::base64_from_binary<boost::archive::iterators::transform_widt h<const char *, 6, 8, char>, char>, 72, char>, char, boost::single_pass_traversal_tag, char, char>)') (instantiating: 'boost::archive::iterators::base64_from_binary<boost::archive::iterators::transfo rm_width<const char *, 6, 8, char>, char>::base64_from_binary<boost::iterator_facade<boost::archive::iterators::inser t_linebreaks<boost::archive::iterators::base64_from_binary<boost::archive::iterat ors::transform_width<const char *, 6, 8, char>, char>, 72, char>, char, boost::single_pass_traversal_tag, char, char>>(boost::iterator_facade<boost::archive::iterators::insert_linebreaks<boost: :archive::iterators::base64_from_binary<boost::archive::iterators::transform_widt h<const char *, 6, 8, char>, char>, 72, char>, char, boost::single_pass_traversal_tag, char, char>)') (instantiating: 'boost::archive::iterators::transform_width<const char *, 6, 8, char>::transform_width<boost::iterator_facade<boost::archive::iterators::insert_l inebreaks<boost::archive::iterators::base64_from_binary<boost::archive::iterators ::transform_width<const char *, 6, 8, char>, char>, 72, char>, char, boost::single_pass_traversal_tag, char, char>>(boost::iterator_facade<boost::archive::iterators::insert_linebreaks<boost: :archive::iterators::base64_from_binary<boost::archive::iterators::transform_widt h<const char *, 6, 8, char>, char>, 72, char>, char, boost::single_pass_traversal_tag, char, char>)') transform_width.hpp line 105 super_t(Base(BOOST_MAKE_PFTO_WRAPPER(static_cast<T>(start)))), Error : object 'boost::archive::text_oarchive_impl<boost::archive::text_oarchive>::text_oarchive _impl `base constructor'(std::basic_ostream<char, std::char_traits<char>> &, unsigned int)' redefined (instantiating: 'boost::archive::text_oarchive_impl<boost::archive::text_oarchive>::text_oarchive _impl `base constructor'(std::basic_ostream<char, std::char_traits<char>> &, unsigned int)') text_oarchive.hpp line 61 text_oarchive_impl(std::ostream & os, unsigned int flags = 0) : -- If this message helped you, consider buying an item from my wish list: <http://web.meeroh.org/wishlist>

3 2

Re: [boost] Using Serialization for binary marshalling
by Robert Ramey 17 Apr '04

17 Apr '04

Matthew Vogt wrote: > Is anyone else interested in using Robert Ramey's serialization library > for the purpose of marshalling data into pre-determined binary formats? Interest has been expressed for XDR in the past. Basically, I see this as a very positive thing and want to do everything I can to support your efforts. Your code supports save and load for two new formats (XDR and CDR). This is a valuable contribution. I'm also pleased that the serialization library has been deemed (at least by one person) to be worthy of investment of such an effort ( 1500 lines of code !). I took a little time to scan your attachments. My examination was cursory and feel free to correct any thing I didn't get right. Here are my comments. 1) I wonder why you derived ordered_oarchive from basic_binary_oprimitive<Archive, OStream> . It doesn't seem that any of the functionality basic_binary_oprimitive actually used. I presume the same goes for ordered_iarchive . 2) there's some stuff in boost that addresses alignment in a guaranteed? Portable manner that may relevant here. Sse #include <boost/aligned_storage.hpp> . BTW - the best way to make your code portable without cluttering up with #ifdef etc... is to use more boost stuff - let other people clutter up their code with #ifdef all over the place. 3) I'm curious about the override for the saving of vector. It seems to me equivalent to the one included with the system. And if vector requires special treatment, what about the list, et al. This doesn't seem necessary to me. Perhaps the fact that I did treat strings specially was misleading. I considered this a special case. I don't think vectors are in this context. 4) Missing license, authorship etc. Also add more comments and description and explanation of motivation for things that might not be obvious. This is a work of literature and art that will live for a long time - make it worthy. 5) I took great pains to organize code so that users of the library would not be including things that were strictly implementation. This is the origin of the *.ipp files. You might want to consider the same. Any template that does have a serializable type as a parameter (ie only archive) is a candidate for this treatment. In fact I would like to see a more "formal" separation of interface and implementation. 6) Get the bjam system running if you haven't already. It would be quite easy to add your archives to the set tested. Currenty, the test system runs about 30-40 tests on each archive type. It's a torture test ( and still I'm finding bugs). I think it would take you maybe an hour to tweak the bjam script and the code in serialization/test/test_tools.hpp to run all the tests on your own archive classes - ( maybe I should add information on doing this to the manual - it never occurred to me that someone would get to this point so soon) This is an absolute must if you want to have your addition seriously considered. 7) I'm just a little queasy about using the term marshalling. In fact any of the archive implementations could be used for marshalling - not just a binary one (XML is the favorite flavor of the month). So I think it's sort of misleading. I think it is very helpful that your naming scheme xdr_oarchive, cdr_oarchive, leverages on the existing one. 8) in my native binary archive, I used a template parameter for the stream class. As it stands, I don't test or use the corresponding archive for wide character streams because the WEOF would need special treatment. I haven't spent any time on this. Perhaps you've addressed this in some way. I didn't look in that much detail. I suspect that's enough to keep you motivated. Good luck and thanks for working on and with the library. Robert Ramey

2 1

[date-time] special value problem
by Pavol Droba 17 Apr '04

17 Apr '04

Hi, I have a problem with the date-time library. I have a code like this: namespace date=boost::gregorian; date::date dtMin(date::min_date_time); cout << dtMin << endl; Last line throws out-of-range exception. As far as I understand the meaning of min_date_time, this should not happen. If this is a standard behaviour, how can I get the minimal displayable date? Thanks, Pavol

2 2

heads up : free version of MSVC71 available!
by Bronek Kozicki 17 Apr '04

17 Apr '04

Just released: http://msdn.microsoft.com/visualc/vctoolkit2003/ It contains full version of *optimizing* compiler and linker, identical with ones present in Visual Studio .NET 2003 Professional. Included full implementation of standard C and C++ libraries, linked statically (sorry Boost.Thread) and few samples (plus support for .NET, as usual). Whole download is 32MB, Windows 2000/XP/2003 required to run. No IDE, no ATL, no MFC - just good C++ optimizing compiler run from command line and great implementation of C++ standard library, everything available for free under liberal license. B.

1 0

Re: [boost] Thoughts on Unicode and Strings
by Reece Dunn 17 Apr '04

17 Apr '04

Marshall Clow wrote: >>>"Reece Dunn" writes: >>> > RATIONALE: Why standardize on the UTF-32 view? Because UTF-8 and >>>UTF-16 are >>>> multi-character encodings of UTF-32 (not considering combining marks >>>>at this >>>> stage), whereas UTF-32 is a single character encoding. >I'm pretty sure that this is a bad assumption. Why is this a bad assumption? At the unicode_string level, we are talking about individual Unicode characters as specified by unicode.org. As an example, U+0x20 (space) can be represented simply on all encodings; U+0x2192 (left arrow) requires 2 bytes for UTF-8 encoding; U+0x1Dxxxx (I think these are the Fractur characters) require 3 UTF-8, 2 UTF-16 and 1 UTF-32. By treating a Unicode string as a virtual UTF-32 string (no matter what the underlying encoding is) makes it easier to use on a higher level, because you are dealing with the characters as they are represented on the Unicode tables. This makes it easier if there are mixed-width characters in the string: U+0x300A hello U+0x300B ==> [<<] hello [>>] >You can't just ignore combining characters. I am not ignoring combining characters. All I'm saying is that dealing with grapheme clusters at this stage makes processing Unicode strings too complex. They should be treated as a view *on top of the underlying unicode_string represtentation*. >I believe that Miro posted an example of how (even using UTF-32), you >may not have a single character <<-->> single "entry" mapping. I understand that now (see my other post), but dealing with it all at one level would make the interface too complex and would become too difficult to manage. You could have something like: struct grapheme_cluster: public std::pair< unicode_string::utf32_iterator, unicode_string::utf32_iterator > { inline grapheme_cluster( unicode_string & us ): std::pair< unicode_string::utf32_iterator, unicode_string::utf32_iterator > ( us.utf32_begin(), us.utf32_end()) { } ... inline bool is_single() const { return( first == second ); } inline unicode_string::utf32_t get_base() const { return( *first ); } bool advance(); // implementation defined; false iff end of string ... }; NOTE: if is_single() is true, then is_base() will be the value of the unicode character, otherwise it is the primary character with the combining characters removed. Regards, Reece _________________________________________________________________ Express yourself with cool emoticons - download MSN Messenger today! http://www.msn.co.uk/messenger

1 0

boost on HP-UX 11i
by DY, JERRY U (SBCSI) 17 Apr '04

17 Apr '04

Hi, I recently downloaded boost libraries to use the smart_ptr libraries. It appears to be working. But several other libraries, as shown by the compiler report is not. I also noticed that last run date is 9 months ago. Is anybody working on getting boost to work on aCC? I would be very surprised if nobody has tried before since HP is a top-tier vendor, but I couldn't find any useful information from the archives. If not, I would like to take a stab at getting it to work. I have contact with HP aCC techs to fix problems if it is a compiler problem. I'm particularly interested in getting the libraries regex and spirit (for now, more later) to work. I did a search on the boost archive and the last reference to this subject was written back in August 14, 2003: [boost] Re: Release of 1.30.2 imminent by David Abrahams other posts by this author Aug 14 2003 2:47PM messages near this date > On HP-UX: > aCC53800: http://boost.sourceforge.net/regression-logs/cs-HP-UX-links.html#optiona l_test-a cc > aCC33380: http://boost.sourceforge.net/regression-logs/cs-hpux-links.html#optional _test-ac c > > This is a compiler crash. aCC is definitely broken beyond repair. I'm not going ot worry about that Thanks! -Jerry

3 2

minute patch: boost/config/posix_features.hpp
by Ralf W. Grosse-Kunstleve 17 Apr '04

17 Apr '04

We experience compiler errors using MIPSpro C++ under IRIX. The problem goes away if we apply this patch: Index: boost/config/posix_features.hpp =================================================================== RCS file: /cvsroot/boost/boost/boost/config/posix_features.hpp,v retrieving revision 1.15 diff -r1.15 posix_features.hpp 79c79 < # if defined(_XOPEN_SOURCE) && (_XOPEN_SOURCE >= 500) --- > # if defined(_XOPEN_SOURCE) && (_XOPEN_SOURCE+0 >= 500) I can check this in, but I wanted to ask first if the "+0" was left off intentionally. It seems unlikely because "+0" is used consistently everywhere else, but just in case, is my patch OK? Thanks, Ralf __________________________________ Do you Yahoo!? Yahoo! Tax Center - File online by April 15th http://taxes.yahoo.com/filing.html

2 1