- Boost - lists.boost.org

invalid null pointer error in serialization with MSVC2008
by h yh 16 Mar '10

16 Mar '10

Hi, I am getting a very strange runtime error using boost serialization library with MSVC2008. I called the following template in my program. template <class T> void loadData(std::string fileName, T &t) { std::ifstream ifs(fileName.c_str()); boost::archive::text_iarchive ia(ifs); t.clear(); ia >> t; ifs.close(); } it gets an assertion failed when running into boost::archive::text_iarchive ia(ifs); Debug Assertion failed: invalid null pointer Here is the stack frame: msvcr90d.dll!memcpy_s(void * dst=0x00000000, unsigned int sizeInBytes=4294967295, const void * src=0x07953f63, unsigned int count=22) Line 55 + 0x2f bytes msvcp90d.dll!std::char_traits<char>::_Copy_s(char * _First1=0x00000000, unsigned int _Size_in_bytes=4294967295, const char * _First2=0x07953f63, unsigned int _Count=22) Line 582 + 0x16 bytes msvcp90d.dll!std::_Traits_helper::copy_s<std::char_traits<char> >(char * _First1=0x00000000, unsigned int _Size=4294967295, const char * _First2=0x07953f63, unsigned int _Count=22, std::_Secure_char_traits_tag __formal={...}) Line 714 + 0x15 bytes msvcp90d.dll!std::_Traits_helper::copy_s<std::char_traits<char> >(char * _First1=0x00000000, unsigned int _Size=4294967295, const char * _First2=0x07953f63, unsigned int _Count=22) Line 706 + 0x22 bytes msvcp90d.dll!std::basic_streambuf<char,std::char_traits<char> >::_Xsgetn_s(char * _Ptr=0x00000000, unsigned int _Ptr_size=4294967295, int _Count=22) Line 342 + 0x1a bytes msvcp90d.dll!std::basic_streambuf<unsigned short,std::char_traits<unsigned short> >::_Sgetn_s(unsigned short * _Ptr=0x00000000, unsigned int _Ptr_size=4294967295, int _Count=22) Line 118 msvcp90d.dll!std::basic_istream<char,std::char_traits<char> >::_Read_s(char * _Str=0x00000000, unsigned int _Str_size=4294967295, int _Count=22) Line 698 + 0x27 bytes msvcp90d.dll!std::basic_istream<char,std::char_traits<char> >::read(char * _Str=0x00000000, int _Count=22) Line 712 MyProject.exe!boost::archive::text_iarchive_impl<boost::archive::text_iarchive>::load() + 0xad bytes MyProject.exe!loadData<std::set<GamingNote,GamingNote,std::allocator<GamingNote> > >(std::basic_string<char,std::char_traits<char>,std::allocator<char> > fileName="nocturne.gnt", std::set<GamingNote,GamingNote,std::allocator<GamingNote> > & t=[0]()) Line 14 + 0x14 bytes It happens when the text_iarchive class constructs, so I am sure it's nothing to do with the serialize function of T, but something between boost and std::ifstream. The wierd thing is I didn't come across this program at the first time. It appears suddenly during development. If I separate the serialization code to a single cpp file, it doesn't have any problem at all. By the way, I am intergrating Qt and Ogre with boost by the way, but that seems not to be quite helpful to identify this problem. Any ideas about that? Yuheng Huang

1 0

boost::log review (printf style api)
by Tom Brinkman 16 Mar '10

16 Mar '10

>> It is actually more relevant than a "flame war." We are discussing how a log API should look to be most useful >> (in terms of depth and width), and that discussion pertains to all (new) libraries of Boost: do we want them >> to be used by the larger C populace? How much are we ready to sacrifice in expressivity (or succinctness) in >> order to widen our target? Should we have C wrappers for the most "utilitarian" libraries, such as a log library? >> My point is that Boost is a C++ library and should not care at all about the impact on C developers, or people >> who happen to be used to that "glue language," even for their C++ development. I still think it is a valid >> discussion to have. Well said. Good summary, although as noted, I disagree with your conclusion. The larger question is -- what has gone wrong with boost? Why do so many libraries languish in the review queue. Why has the the C++ standard taken so long to get enough momentum to pass through committee. In my view, C++ is tired. Boost is an experiment of a particular style of development, that being functional, generic, orthogonal and "non-hieararchical". Boost through its heavily template ladden libraries offered this style of development, and it had great appeal to those who had grown tired of object oriented style of development. The experience of those of us that have developed with this style over the years has been mixed. Like anything, somethings are nice, somethings are more trouble than there worth. Fortunately, for those of us that have an appreciation for functional programming will still be highly relevent in the future. The reason has primarily has to do with parralel programming which lends its self very nicely to functional programming, which is what boost is all about. The way I explain it, functional programming is just a variation of procedural programming with a different way of passing around state. Unfortunately, this advanced programming style is often abused in hideous ways. Particularly, when they are used in small utilty libraries which should be simple and general purpose, and not push a particular style of development. I've already made this point, but I'll make it again. Utility libraries should be agnositic and usable across the widest variety of programming styles, that being procedural, objected orienteated or functional. This boost::log library should not be approved without a simple "C" friendly api. That being a printf style api. Failure to include a "printf" style api will only continue to marginalize boost further to small subset of c++ developers. Most develpers will look at the api without a printf and go, HUH?

7 10

Collection of Jamfiles for 3rd-parties?
by Mateusz Loskot 15 Mar '10

15 Mar '10

Hi, I'm wondering if would it make sense to have a directory in Sandbox or close where Jamfiles for various third-party programs and libraries could be maintained. I imagine it could make it easier to integrate various dependencies with Boost and Boost Sandbox libraries. For example, GIL makes use of libpng, libjpeg, libtiff, libz, gzip/bzip2 are used by others too. I found that HAIKU OS maintains collection of Boost Build enabled libraries: http://dev.haiku-os.org/browser/haiku/trunk/src/libs I'm not suggesting to do the same, but perhaps it would make sense to maintain Jamfiles only, so users can download them and refer to such libraries using symbolic targets. I'm curious of your comments? Best regards, -- Mateusz Loskot, http://mateusz.loskot.net Charter Member of OSGeo, http://osgeo.org

2 1

base class for boost::array
by Peter Myerscough-Jackopson 15 Mar '10

15 Mar '10

Dear all, In using boost::array I have felt the need to pass around boost::array's of an unknown size (unknown to the function receiving the array). I have therefore created an abstract base class for boost::array so that I can create a pointer to a common base class for arrays of different sizes. Essentially std::vector's of different sizes can be passed into a function with a fixed prototype, but because boost::array constructs a different type for each array size, a single fixed prototype cannot be described such that it can be called with different sizes of boost::array. In code I can write (toy functions) : double sumTotal(const std::vector<double>* values) { double result = 0 ; BOOST_FOREACH(double v, values) { result += v; } return result; } But I can't write: double sumTotal(const boost::array<double>* values) { double result = 0 ; BOOST_FOREACH(double v, values) { result += v; } return result; } Without the second function being a template function, i.e. I cannot provide a library that takes a boost::array<double>. With the attached base class, I could define a function that takes a boost::array_base<double>. Since, I think, the ability to allow boost::array to be used in this way is that it requires the use of virtual functions, I have written it so that the inheritance is optional. It is enabled with a #define before including array.hpp . Is this useful? (I am aware that I maybe could use a boost::range) Thanks for your time, Peter Ps. On my current compiler, swap and operator= could not be uncommented in the array_base class. PPs. This is my first post to boost dev, please be kind... J Dr Peter Myerscough-Jackopson - Senior Engineer Tel: +44 (0)23 8076 7808 Fax: +44 (0)23 8076 0602 Web: http://www.macltd.com/ <BLOCKED::http://www.macltd.com/> Email: peter.myerscough-jackopson(a)macltd.com <mailto:peter.myerscough-jackopson@macltd.com> MULTIPLE ACCESS COMMUNICATIONS LIMITED is a company registered in England at Delta House, The University of Southampton Science Park, Southampton, SO16 7NS, United Kingdom with Company Number 1979185 and VAT Number GB 411942866

5 4

[Boost.Locale] New Release
by Artyom 15 Mar '10

15 Mar '10

Hello Boost List! ================= I'm glad to introduce updated version of Boost.Locale library: This library was designed for Boost and created because of needs CppCMS framework. I'm looking forward to formal review and general inputs from Boost.Community. Documentation: http://cppcms.sourceforge.net/boost_locale/html/index.html Download: From: https://sourceforge.net/projects/cppcms/files/ File: https://sourceforge.net/projects/cppcms/files/boost_locale/boost_locale.zip… Boost.Locale is a library that brings high quality localization facilities in C++ way. It provides the natural glue between C++ locales framework, iostreams and powerful ICU library giving: * Correct case conversion, case folding and normalization * Collation including support of 4 Unicode collation levels. * Date, time, timezone and calendar manipulations, formatting and parsing including transparent support of calendars other then Gregorian. * Boundary analysis for characters, words, sentences and line-breaks. * Number formatting, spelling and parsing. * Monetary formatting and parsing. * Powerful message formatting including support plural forms, using GNU catalogs. * Character set conversion. * Transparent support of 8-bit character sets like Latin1. * Support of char, wchar_t and C++0x char16_t, char32_t strings and streams. New in this version: ==================== a. Fully redesigned break iterator interface b. Added date_time and calendar support that allow manipulating with dates over non-Gregorian calendars c. Implemented full set of unit-tests d. Added support of many platforms and compilers. e. Lots of bug fixes. f. Complete reference with Doxygen g. Many tutorial updates, thanks to Markus Raab inputs Tested compilers and platforms: =============================== - Compilers: - GCC 3.4, 4.1, 4.2, 4.3, 4.4 - Intel Compiler 11.0 - SunStudio 12 with STLPort - MSVC 2008 - Operating Systems: - Linux - FreeBSD - OpenSolaris - Windows XP - Windowns XP/Cygwin - ICU Versions: 3.6, 3.8, 4.2 Full list of tests: =================== - Linux: - Debian GNU/Linux 2.6.18, x86, GCC 4.1.2, ICU 3.6.1 - Debian GNU/Linux 2.6.26, x86_64, GCC 4.3.2, ICU 3.8.1 - Debian GNU/Linux 2.6.26, x86_64, GCC 4.4 -std=c++0x, ICU 3.8.1 (Some faults on char16_t/char32_t support) - Debian GNU/Linux 2.6.26, x86_64, Intel Compiler 11.0, ICU 3.8.1 - FreeBSD - FreeBSD 8.0, i386, GCC 4.2.1, ICU 3.8.1 - OpenSolaris: - SunOS OpenSolaris 5.11, i386; Sun Studio 12, with STLPort, ICU 4.2 - SunOS OpenSolaris 5.11, i386; GCC 3.4.3, ICU 4.2 - Windows XP/SP2 - Cygwin 1.5, GCC 3.4, ICU 3.8 - Cygwin 1.5, GCC 4.3, ICU 4.2 - Windows XP/SP2, Mingw/GCC 4.4, ICU 4.2 (Static build only) - Windows XP/SP2, MSVC9 (2008)

10 19

[iterator] Help needed understanding output_iterator requirements
by Thomas Klimpel 15 Mar '10

15 Mar '10

Dear iterator experts, Jesse Perla recently reported that boost::multi_array fails compilation for many basic tasks on MSVC 2010. I investigated the failures, because I had already investigated other failures on MSVC 2010 reported by Jesse Perla for boost::ublas. While I'm quite familiar with boost::ublas, I'm a complete novice with respect to boost::multi_array and boost::iterator. I could track the failures to a specific (intentional?) behavior of iterator_facade from Boost.Iterator (more specifically of facade_iterator_category.hpp): http://lists.boost.org/Archives/boost/2010/03/163039.php Thomas Klimpel wrote: > What effectively happens it that the iterator gets the category > "input_iterator", but std::copy wants to have an "output_iterator". I > think I understand why the iterator doesn't satisfies the requirement > of a "forward_iterator", but it's unclear to me why it didn't qualify > as an "output_iterator". There is an "input_output_iterator_tag" in > "boost/iterator/detail/facade_iterator_category.hpp", so it would have > been possible for the iterator to be both "input_iterator" and > "output_iterator". However, it seems to me that > "input_output_iterator_tag" is never used in the Boost.Iterator > library. I would have to read more about "output_iterator" to > understand whether Boost.Iterator is correct here. With my current > understanding of "output_iterator", I would say it's a bug in > "boost/iterator/detail/facade_iterator_category.hpp". > > Perhaps somebody with more knowledge about "output_iterator" and > Boost.Iterator can explain to me why an iterator using the > "boost::random_access_traversal_tag" for the "CategoryOrTraversal" > template parameter of "iterator_facade" will never get the category > "output_iterator" (or "input_output_iterator_tag"). Of course I could go on and read more about "output_iterator", or find out whether the Boost.Iterator documentation has to say something about this issue, but since I only came to this problem because I wanted to help Jesse Perla on a problem with boost::multi_array, I would much prefer if an "iterator expert" could "take over". Regards, Thomas

2 2

[log] Boost.Log formal review
by Vladimir Prus 15 Mar '10

15 Mar '10

Boosters, the formal review of the Boost.Log library, written by Andrey Semashev, starts now and will run through March 17, 2010. The documentation for the current version is available at: http://boost-log.sourceforge.net The downloads are at: http://sourceforge.net/projects/boost-log Here are the important points: 1. All comments are appreciated. Even if you don't have the time for in-depth study of everything, comments on parts of the library are welcome. In particular, if you are already using logging in your applications and have specialized requirements, you might want to directly check how the proposed library handles them. 2. The reviews and all comments should be submitted to the developers list, boost(a)lists.boost.org and the email should have "[log]" prefix in the subject to make sure it's not missed. The deadline for reviews is 23:59, March 17, PST = 2:59, March 18, EST = 7:59 March 18, GMT = 10:59, March 18 MSK 3. Please explicitly state in your review whether the library should be accepted. 4. The general review checklist is provided below: - What is your evaluation of the design? - What is your evaluation of the implementation? - What is your evaluation of the documentation? - 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? - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? - Are you knowledgeable about the problem domain? Thanks, Volodya

16 52

Fwd: Re: [log] review part 1
by Andrey Semashev 15 Mar '10

15 Mar '10

Due to technical reasons this reply went off-list. For sake of keeping the conversation public, I'm reposting it. -------- Original Message -------- Subject: Re: [boost] [log] review part 1 Date: Sat, 13 Mar 2010 16:08:14 +0300 From: Andrey Semashev <andrey.semashev(a)gmail.com> To: Steven Watanabe <watanabesj(a)gmail.com> On 03/12/2010 07:22 AM, Steven Watanabe wrote: > I mostly have documentation notes at this point. Andrey, since I have so > many, and they're mostly fairly minor, would it be better if I made > a patch for the documentation source? Yes, that would be great. I quickly reviewed your suggestions, and they all look reasonable (I always have a hard time with articles). Thanks! > I think newbies should probably be replace globally with new users, > since I kind of feel that the term newbie is somewhat derogatory. Ok. I didn't mean to offend anyone, of course. :) > http://boost-log.sourceforge.net/libs/log/doc/html/log/defs.html > ================================================================================ > > For Log record: > I don't like the expression "A single pack of information," although > I can't think of anything better off hand. A collection of data,...? > ================================================================================ > > Issues: > > Instead of compiling a narrow or wide library, why don't you use > libboost_log > and libboost_wlog? There are parts that would be the same in both these libraries. Most notably, singletons of file_collector repository and some constants. This might lead to linking problems if someone tries to use both versions of the library. > I agree with other comments that I saw about Attribute being > a poor choice for what it does. I would prefer that the term "Attribute" > should be used for what you call an "Attribute Value," and that > there should be a different term, like "Attribute Extractor" for > what you call an "Attribute." My understanding of the term "attribute" is that it's some kind of meta-information that defines the concrete values that will be attached to log records. I'm ready to agree that the word "attribute" doesn't bring my intention precisely, but the alternatives don't quite get closer. "Extractors" are reserved for another tool in the library.

5 6

static in_class constants
by Christian Henning 15 Mar '10

15 Mar '10

Hi there, I'm finishing up some linker problems I have with gcc. One area of problems seems to be static in_class constants that I have declared in my header file. MSVC doesn't have problem with it but gcc is complaining. I'm wondering how other libs in boost are dealing with these problems. For instance in my new gil::io lib I define some tags in pnm_tags.hpp as follows: /// Defines type for image type property. struct pnm_image_type : property_base< uint32_t > { BOOST_STATIC_CONSTANT( type, _mono_asc = 1 ); // Monochrome ASCII encoding BOOST_STATIC_CONSTANT( type, _gray_asc = 2 ); // Gray level ASCII encoding BOOST_STATIC_CONSTANT( type, _color_asc = 3 ); // sRGB color ASCII encoding BOOST_STATIC_CONSTANT( type, _mono_bin = 4 ); // Monochrome binary encoding BOOST_STATIC_CONSTANT( type, _gray_bin = 5 ); // Gray level binary encoding BOOST_STATIC_CONSTANT( type, _color_bin = 6 ); // sRGB color binary encoding }; Thanks, Christian

7 27

Review - boost::log
by Tom Brinkman 15 Mar '10

15 Mar '10

Should boost log be accepted into the boost library? My vote is no. This library will just reinforce boost's reputation as being a repository of needlessly complicated highly templatized libraries for relatively easy programming tasks. I don't mind this added complexity when it comes to genuinely difficult problem spaces. In my view, however, logging is not one of those problem spaces. Logging is one of those things that if it takes longer than 10 minutes to read the documentation and get up to speed, it will not get used. What is your evaluation of the design? Very much in the spirit of a typical boost library. However, it has very little attention to "C" interfaces and makes heavy use of templates. I suppose because this is boost, that that is acceptable. However, boost and the c++ community at large should start moving towards a more friendly attitude towards a "C" style api for utility libraries. Most non-boost c++ developers will dismiss this library out of hand, not because its a bad library, its not, it's just more of the same. Heavy handed use of templates. I guess I've spent too much time over the last 5 years ripping out poorly conceived heavily templated code. The thought of adding to this madness, with another utility library that is burdened by templates is hard to swallow. What is your evaluation of the documentation? Good What is your evaluation of the potential usefulness of the library? Logging is useful. Yes. Did you try to use the library? With what compiler? Did you have any problems? Yes. GCC++. No problems How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? 2 hours Are you knowledgeable about the problem domain? Yes. I was the review wizard for three years and have followed the progression of boost from the beginning, Tom Brinkman

10 23