- Boost - lists.boost.org

[threads] Compilation problems on CW and others...
by Rene Rivera 20 Jul '04

20 Jul '04

Michael, I believe one of the last remaining problems with the compilation of threads in Win32 platforms, maybe others, is that the line-endings on the files are totally incorrect. When I look at the files I see double spaced lines with line-endings of the CR-CR-LF variety. This causes all kinds of problems when the CW preprocessor tries to parse multi-line macros as it only parses the first line and error on the rest, for example: ### mwcc Compiler: # File: ..\src\exceptions.cpp # ------------------------------ # 49: || defined(__CYGWIN__) # Error: ^^ # declaration syntax error Which is the second line of: # if defined(_WIN32) || defined(__WIN32__) || defined(WIN32) \ || defined(__CYGWIN__) It will likely be easier for me to fix this directly than have you try and get the line endings just right, as the editor I use has functionality to fix those problems. Would it be OK for me to fix those at this time? I don't want to collide with anything you might be changing. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com - 102708583/icq

6 35

RE: [boost] This afternoon's test run
by Victor A. Wagner Jr. 20 Jul '04

20 Jul '04

At Monday 2004-07-19 12:47, you wrote: > > ../libs/test/test/ifstream_line_iterator_test.cpp(28): error in > > "test_default_delimeter": test it != utf::ifstream_line_iterator() failed > >I do not understand something in Boost.Build system. This test should pass. >Are you sure you did update -d ? cvs -z9 update -dPA >> update.log and it ran at 0300 -0700 (PDT) >Gennadiy. >_______________________________________________ >Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost Victor A. Wagner Jr. http://rudbek.com The five most dangerous words in the English language: "There oughta be a law"

2 1

dynamic_bitset question & compiler warning
by Terence Wilson 20 Jul '04

20 Jul '04

I have an unsigned char array which I would like to represent as an array of bits in order to perform bit shift operations. My code is as follows: // rotate bits as one large bitset typedef unsigned char octet; void Normalize(boost::shared_array<octet> RawHash, int RawHashLength) { int ShiftLength=7; boost::dynamic_bitset<octet> HashBits; for (int i=0; i<RawHashLength; ++i) { HashBits.append(RawHash[i]); } boost::dynamic_bitset<octet> ShiftedBits=HashBits << ShiftLength; } A couple of issues: 1) How do I get bits out as unsigned chars after the shift operation? 2) I get a compiler warning, it doesn't seem to like me using unsigned char. I am using Visual Studio 2003- c:\PROJECTS\vcpp\Libs\Boost\boost_1_31_0\boost\dynamic_bitset.hpp(655) : warning C4267: 'initializing' : conversion from 'size_t' to 'const boost::dynamic_bitset<Block>::block_type', possible loss of data with [ Block=octet ] c:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\include\xmemory(115) : while compiling class-template member function 'boost::dynamic_bitset<Block> &boost::dynamic_bitset<Block>::operator <<=(boost::dynamic_bitset<Block>::size_type)' with [ Block=octet ] c:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\include\xmemory(156) : while compiling class-template member function 'boost::dynamic_bitset<Block>::dynamic_bitset(const Allocator &)' with [ Block=octet, Allocator=std::allocator<octet> ] c:\PROJECTS\vcpp\PasswordGenerator\Normalizer.cpp(46) : see reference to class template instantiation 'boost::dynamic_bitset<Block>' being compiled with [ Block=octet ] c:\PROJECTS\vcpp\Libs\Boost\boost_1_31_0\boost\dynamic_bitset.hpp(658) : warning C4267: '=' : conversion from 'size_t' to 'octet', possible loss of data c:\PROJECTS\vcpp\Libs\Boost\boost_1_31_0\boost\dynamic_bitset.hpp(660) : warning C4267: '=' : conversion from 'size_t' to 'octet', possible loss of data c:\PROJECTS\vcpp\Libs\Boost\boost_1_31_0\boost\detail\dynamic_bitset.hpp(88) : warning C4267: 'return' : conversion from 'size_t' to 'octet', possible loss of data c:\PROJECTS\vcpp\Libs\Boost\boost_1_31_0\boost\detail\dynamic_bitset.hpp(88) : while compiling class-template member function 'octet boost::detail::dynamic_bitset_base<Block,Allocator>::mask1(boost::detail::dy namic_bitset_base<Block,Allocator>::size_type)' with [ Block=octet, Allocator=std::allocator<octet> ] c:\PROJECTS\vcpp\Libs\Boost\boost_1_31_0\boost\dynamic_bitset.hpp(76) : see reference to class template instantiation 'boost::detail::dynamic_bitset_base<Block,Allocator>' being compiled with [ Block=octet, Allocator=std::allocator<octet> ]

2 1

Re:[boost] Re: [serialization] CW problems...
by Robert Ramey 20 Jul '04

20 Jul '04

> Yes. But did anyone try other non intrusive approaches? Here are some > possibilities: Yesterday I studied this question carefully in light of the experience gained from testing with my own compilers and reviewing the test results. I altered the utf8_codecvt_facet.cpp to make it more correct and more obvious as to the issues it addresses with regard to each compiler. I tested on all the compilers I have (borland 5.51, borland 5.60, msvc 6.0, msvc-stlport, msvc 7.1 and gcc 3.3/cygwin and was satisfied with the results. I am awaiting test results for other compilers. I'm hopeful that this will achieve results satisfactory to all concerned. Vladimir's point is a interesting one: The is code module doesn't really belong to either package - the question arises as to where it should be placed. If I leave in the serialization package or Vladimir leaves it in the program options package its unsatisfactory as we either have to more or less identical packages or a non-sensical cross dependency. There is currently not neutral place for *.cpp code, docs and tests for unreviewed code of this nature. As to the particular case of this code module, there was an open invitation to review/scrutinize it and several people did comment it should be moved to boost directory/namespace, Vladimir found it sufficiently useful to copy it into the program options project. No one has found any major fault with its design, interface or implementation. The only problem has is that it depends upon libraries whose implementation is inconsistent in this area and this is being addressed and resolved by testing. My only regret is that Vladimir didn't communicate to me the changes he saw fit to make. I certainly would have been very happy to either incorporate the changes he included for CW (as I did the changes submitted by Pavel Vozenilek). Actually I would have been happy to hand this off to Vladimir or anyone else who would like to take responsibility for it as it's really peripheral to the serialization library in any case. Robert Ramey

2 1

Some SFINAE for vc6
by David Abrahams 20 Jul '04

20 Jul '04

Tip for those insane persons who are trying to nurse vc6 along: Some kinds of SFINAE are possible. Forming a pointer to a reference, for example, will remove a function signature from the overload set. Here's something I did in Boost.Python just now. In this case it was only needed for VC6, but it should work for any SFINAE-ish compiler: template <class T> explicit object( T const& x # if BOOST_WORKAROUND(BOOST_MSVC, == 1200) // use some SFINAE to un-confuse MSVC about its // copy-initialization ambiguity claim. , typename mpl::if_<is_proxy<T>,int&,int>::type* = 0 # endif ) Ron Garcia reminded me that I had done this for the multi_array library a while ago, and I realized I had forgotten all about it. I thought y'all should know. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com

1 0

Multiple or union range iterators
by Piccolboni, Antonio 20 Jul '04

20 Jul '04

Hi, I have n arrays of float and I need to take median of all the values. I have a nifty templatized implementation median(start stop) and I don't have the space to make a copy of all the arrays. Well I do most of the times but I like zero-copy implementations. So I was thinking that I could use an itarator that spans multiple ranges. Something like Vector<float a,b>; [fill them] Multiple_range_iterator<vector<float::iterator> start(a.end(),b.begin()), stop(start); start = a.begin(); stop = b.end(); cout << median(start, stop); Of course this needs to be extended to n ranges. The intended meaning is that incrementing start would apply the increment operator of the argument type until it reaches a.end(), where it would jump straight to b.begin(). You can imagine how random jumps and comparisons are defined. I guess < would bring trouble. Well, the question is: has anyone seen anything like this? Does it make sense? Should I start from iterator_adaptor? Any suggestions (no, "go get another job" is not admissible)? Thanks Antonio

2 1

Spirit grammar definition
by Nico Massi 20 Jul '04

20 Jul '04

Hi, I have a problem with a spirit parser. My grammar/skipgrammer and its definition are working, but only on the first spirit::parse() call. My function around parse() looks like this. void function() { string str; file.open(); file >> str; file.close(); vector<string> library; vector<Group> groups; MyGrammar g( library, groups ); MySkipGrammar s(); boost::spirit::parse( str, g, s ); // library and groups are now filled properly setLibrary( library ); setGroups( groups ); } This works fine, as long as i call function() only one time. The second time i call the function ( even if the parse data(str) is the same ), the parse() function failes with a memory error ( access to 0xcccccccc ( MSVCs default debug value ) ) I have tried to debug it and found the following. It seems that in the second call, the inner class(definition) of MyGrammer is still referencing the old data. And the first access in one rule actor to library or groups failes with memory access to 0xcccccccc. And even if a create MyGrammar on the heap ( MyGrammar* g = new... ) it seems that the inner definition class is not created the second time. I have set breakpoints to a self created actor, and the actor is only created once on the first function call. Every other function() call other than the first does not create the actors, so they are still hold the old object references. Any ideas where the error could be? And why are the actors only created once? P.S.: I`m using MSVC.net 2003

3 3

[inspect] Updated inspect checks show more line-ending problems...
by Rene Rivera 19 Jul '04

19 Jul '04

My newest run of the inspect tool shows a new set of invalid end-of-line problems, all in Boost.Spirit: http://www.boost.org/regression-logs/inspection_report.html#spirit Boost Inspection Report But overall the number of errors went down :-) From... 8021 files scanned 675 directories scanned 1572 problems reported problem counts: 1231 files missing copyrights 1 files with invalid line endings 0 bookmarks with invalid characters 1 invalid urls 91 broken links 45 unlinked files 51 file names too long 152 files with tabs To... 8043 files scanned 676 directories scanned 1477 problems reported problem counts: 1204 files missing copyrights 14 files with invalid line endings 0 bookmarks with invalid characters 1 invalid urls 80 broken links 44 unlinked files 51 file names too long 83 files with tabs -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com - 102708583/icq

2 1

Serialization and tmpnam
by Guillaume Melquiond 19 Jul '04

19 Jul '04

Hi, I see the serialization library uses "tmpnam" quite a lot. I don't know what the status of this function is on other operating system. But on GNU/Linux at least (and I suppose it is the same for any POSIX system), it is considered to be bad practice [1]. Such a bad practice that the linker ld is especially programed to complain whenever somebody uses this function. Moreover, I see that Borland and Microsoft compilers "have brain-dead tmpnam functions" [2] so a replacement was needed. So it may be a good idea to completely remove the function "tmpnam" from the Serialization library and use a saner replacement instead. This way, the library tests would compile without any complaint from the linker on Linux. Regards, Guillaume [1] As does the manpage say: "Never use this function". [2] Comment at the beginning of serialization/test/test_tools.hpp.

2 1

Re: Boost Software License Progress?
by Stephan T. Lavavej 19 Jul '04

19 Jul '04

[Doug Gregor] > This is a really good idea. Adding another mode to "inspect" > that outputs this web page would be the best way to start... Having such a page for each release of Boost would be good. > Looks like bind and smart pointers need the new license. Mlar! Can these be fixed before 1.32.0? Stephan T. Lavavej

1 0