October 2004 - Boost - lists.preview.boost.org

Trial history file; CSS problem
by Daryle Walker 17 Oct '04

17 Oct '04

[I sent something like this on Saturday, but no one responded. So I'm resending in case it got rejected.] Instead of a mail attachment, the file is now in the Sandbox. Look under its "BOOST_ROOT/more/version_history.html" and pretend it's at the same relative spot in the main CVS. I'm surprised that a full-blown version history file wasn't added a long time ago. I raided the CVS history of the main "index.htm" file for the details. Any ancient-timers know the history of 1.11.0 and earlier? The header looks funny; I was wondering how to replicate the current look by mutating what's given with CSS. (I was thinking of the headers seen at <http://www.mozilla.org>.) I processed what I wrote through HTML-Tidy, adding indentation and line wrap. I kept getting weird spacing with the function descriptions at the Spirit section of 1.30.1 and the Lambda block-quote at 1.28.0. I worked-around the problem by undoing the line-breaks Tidy added at those points. After being bewildered for a long while about the weird spacing, I saw the problem when looking in the CSS file: CODE { FONT-FAMILY: Courier; white-space: pre; } This last (non-brace) line says that multiple white-space characters are _not_ collapsed into a single space. This lets CODE acts as an in-line variant of PRE, but it violates what CODE usually does! I need the default space-collapsing behavior of CODE. If no one can give me a justification for that attribute, I'm going to erase it. Even if you can justify it, do this instead: CODE.my_special { FONT-FAMILY: Courier; white-space: pre; } Then call it like so: <p>Blah blah, please <code class="my_special">keep all of my spaces</code> blah blah.</p> That way people who need the default space-collapsing attribute of CODE don't get screwed. (Right now it's optimizing the [IMO] <1% wacky case and forcing extra work to get the usual semantics [that should take 99+% of the cases].) -- Daryle Walker Mac, Internet, and Video Game Junkie darylew AT hotmail DOT com

2 3

Re: [boost] Re: [tuple] attempt to fix a BCB regression, and a plea for help
by JOAQUIN LOPEZ MU?Z 17 Oct '04

17 Oct '04

----- Mensaje original ----- De: Tobias Schwinger <tschwinger(a)neoscientists.org> Fecha: Domingo, Octubre 17, 2004 1:01 pm Asunto: [boost] Re: [tuple] attempt to fix a BCB regression,and a plea for help > JOAQUIN LOPEZ MU?Z wrote: > > Umm... This got me thinking, maybe the whole BCB-specific > > patch is just overkill, and it only takes to avoid > > the add_const<> construct. > > The attached file does just this, i.e. it relies on > > the default implementation for element<>, using > > plain const-qualifying instead of add_const<> for > > BCB. Would you be so kind to give it a try? Thanks in > > advance. > > > > This new version compiles fine with BCC 5.6.4 but does not compile > with > BCC 5.5.1 (and versions below this, according to Boost.Config). > > The patch is the difference from the file attached to the post I > reply > to (and not the first file you sent) and makes it work again. > > It uses the previous workaround in case > BOOST_NO_CV_SPECIALIZATIONS is set. > Another check for BCB within this block could be made in order to > use > 'add_const' for compilers where it works fine (I omitted it, for now). > > > Here's my (still fuzzy) problem analysis: > > 1. The "BCC <= 5.5.1 - problem" is that for these versions of BCC > cv-specializations don't work. > > 2. The "add_const - problem" could have something todo with the > fact > that for BCC 'type const' and 'const type' can be different types. > [ see the note regarding the '__BORLANDC__' - block in > 'is_const.hpp' ] As I understand it, the comment you refer to has to do with cv-qualifying references --not our problem now, I think. > I am not sure if and how this affects template argument > substitution, > but I changed > > typename T::head_type const > > to > > const typename T::head_type > > , just in case... > My only objection to your patch is that the problem with add_const is attributed to BOOST_BCB_PARTIAL_SPECIALIZATION_BUG Do you have any reason to think so? I'd prefer to have that part guarded by a simple __BORLANDC__ workaround, given our current (lack of) knowledge about what's causing the problem. If no one complains, I'll commit this stuff to the CVS tomorrow. Thanks everyboydy for your help. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

3 2

[preliminary submission] Is there any interest in an algebraic vector class?
by Debian User 17 Oct '04

17 Oct '04

Hi @, I've uploaded the initial version of the algebraic vector class as proposed in comp.lang.c++.moderated. It has been renamed to Euclidean vector class as a result of the discussions so far. Is there any interest here? Comments are welcome. The library is not yet in the boost name space and not yet under the boost licence. That's of course going to change if it eventually should be accepted. Andreas

2 1

Re: [boost] Re: [tuple] attempt to fix a BCB regression, and a plea for help
by JOAQUIN LOPEZ MU?Z 17 Oct '04

17 Oct '04

Hi Tobias, ----- Mensaje original ----- De: Tobias Schwinger <tschwinger(a)neoscientists.org> Fecha: Sábado, Octubre 16, 2004 10:24 pm Asunto: [boost] Re: [tuple] attempt to fix a BCB regression,and a plea for help > > Hi, > > the patch makes tupe_test_bench.cpp compile successfully on BCB > 5.5.1 > and 5.6.4. This is great news! Thanks for investigating. > > I have to add the disclaimer that it is an intuitive guess and may > not > be a real solution. I gave it a try, that's all ;+). > The code looked good before I touched it and I have honestly no > idea why > my adjustments make BCB behave again (for both changes)... > Umm... This got me thinking, maybe the whole BCB-specific patch is just overkill, and it only takes to avoid the add_const<> construct. The attached file does just this, i.e. it relies on the default implementation for element<>, using plain const-qualifying instead of add_const<> for BCB. Would you be so kind to give it a try? Thanks in advance. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

2 1

[boost] [tuple] attempt to fix a BCB regression, and a plea for help
by JOAQUIN LOPEZ MU?Z 17 Oct '04

17 Oct '04

Hello, A couple of days ago I prompted about the status of a supposed regression on tuple_test_bench (http://tinyurl.com/62plc) The attached file (to be replacing boost/tuple/detail/tuple_basic.hpp) is an (unsuccesful) attempt to fix the problem, which is related to the inability of BCB to cope with element<N,T> being specialized for T a const tuple type. AFAICS, the attached file should work (I've checked the workaround with other compilers), but BCB still doesn't like. Lacking the necessary BCB skills and tools, I'd appreciate if someone can take a look at it and, hopefully, turn it into a valid workaround for Borland. The relevant part is guarded by a "#if defined(__BORLANDC__)" directive. There are 14 regressions left in the main trunk, and if we all pull a little together, the long awaited Boost 1.32 release could be make real very soon. Thanks for the help. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

4 4

[Graph] New algorithms on graph_devel_1_33_0 branch
by Doug Gregor 16 Oct '04

16 Oct '04

I've just checked in some new graph algorithms that have been contributed to the BGL. They're on the branch graph_devel_1_33_0 until we've branched off the 1.32.0 release, at which point they will go into the trunk. The interesting algorithms are: - A* search, from Kristopher Beevers and Jufeng Peng - Floyd-Warshall all-pairs shortest paths, from Lauren Foutz and Scott Hill - Fruchterman-Reingold force-directed layout, from Doug Gregor The first two algorithms came out of David Musser's Generic Programming class at RPI. Consider that a challenge for any one else teaching courses in Generic Programming now or in the future: you know who you are :) I'll also be moving (sequential) code from the Parallel BGL project into CVS as soon as it becomes ready, and will batch up messages to list announcing the additions. All of the code has been written or reviewed by me, so you know where to direct comments and complaints :) Doug

2 2

Re: [boost] StringAlgo - (was: boost::tokenizer )
by Dirk Gregorius 16 Oct '04

16 Oct '04

Hi there, > I'm not very good at explaining the things in short, but I'll try. thanks for the explanation. I think I got it and it was not as bad as you maybe think. To come back to the initial problem of string tokenizing. I am trying to implement the finder in terms of ForwardIteratorT. Here is what I think I am expecting to do - also actually I am not very sure about it. I justed started to read M. Austern's book and I am quite new to concepts, requirements and so on. So here is what I did so far: struct comment_finder { template<typename ForwardIteratorT> boost::iterator_range<ForwardIteratorT> operator()( ForwardIteratorT Begin, ForwardIteratorT End ) { ForwardIteratorT first, last; while ( Begin != End ) { first = Begin; if ( *Begin++ == '/' && *Begin == '/' ) { last = first; while ( *last++ != '\n' ) { // FAILURE: Return an empty range if ( last == End ) return boost::make_range( ??, ?? ); // return an empty range - HOW? } // SUCCESS: Return the range return boost::make_range( first, last + 1 ); } } return boost::make_range( ??, ?? ); // return an empty range - HOW? } }; Is this the way I have to implement the finder or can it be implemented using some facilities in your library? This implementation is quite low-level, so I am wondering if this is correct. Secondly, for the case this is correct, how should I return an empty range or what shall I return if didn't find a matching range? What are the following steps? Do I have to split two time times or how do I erase the comments out of the string? Will the final token iterator be only of ForwardIteratorT or will be of the type of the conatiner that is holding the tokens. ( e.g. for a vector it would be a randow access iterator? ) Sorry for the inconvinience and thanks for the help so far. -Dirk

2 1

RE: [boost] Library Proposal: database (boost::db)
by Brian Braatz 16 Oct '04

16 Oct '04

> -----Original Message----- > On Behalf Of Jonathan Wakely > On Fri, Oct 15, 2004 at 10:56:58AM -0600, Brian Braatz wrote: > > > As a user I would like to see something along the lines of DTL \ Mysql++ > > > > http://dev.mysql.com/doc/plusplus/en/index.html > > As a user, maybe - but as a developer I wouldn't touch MySQL++ with > a ten foot pole. > > I'm the current maintainer of mysqlcppapi, which was forked from MySQL++ > to fix the most glaring errors, but I'd even hesitate to recommend > that! It is a vast improvement, but is still far from the quality I'd > expect from a Boost library. > > jon > [Brian Braatz] Please allow me to clarify; I am referring to the INTERFACE presented to the programmer. I had pretty good success taking people from a MS ADO world and using MYSql++. >From your web page: " Here are the major changes: All objects are classes with constructors and destructors, so all data is initialized. Reference-counting is used to allow sharing of the various object instances and underlying connections, avoiding segfaults or complicated memory management. All classes are in the mysqlcppapi namespace There is now no public member data. Many methods have been un-inlined, allowing a much clearer file structure. The 'custom' and stored query interfaces have been removed because they made excessive use of preprocessor macros and perl-generated code. Exceptions are no longer optional - they are part of the design. The fields classes have been completely replaced. " http://mysqlcppapi.sourceforge.net/ Excellent. The work you have done, I would agree with. What I am talking about is the basic interface of being able to do: (from the mysql examples) #include <iostream> #include <iomanip> #include <sqlplus.hh> int main() { Connection con("mysql_cpp_data"); // The full format for the Connection constructor is // Connection(cchar *db, cchar *host="", // cchar *user="", cchar *passwd="") // You may need to specify some of them if the database is not on // the local machine or you database username is not the same as your // login name, etc.. Query query = con.query(); // This creates a query object that is bound to con. query << "select * from stock"; // You can write to the query object like you would any other ostrem Result res = query.store(); // Query::store() executes the query and returns the results cout << "Query: " << query.preview() << endl; // Query::preview() simply returns a string with the current query // string in it. cout << "Records Found: " << res.size() << endl << endl; Row row; cout.setf(ios::left); cout << setw(17) << "Item" << setw(4) << "Num" << setw(7) << "Weight" << setw(7) << "Price" << "Date" << endl << endl; Result::iterator i; // The Result class has a read-only Random Access Iterator for (i = res.begin(); i != res.end(); i++) { row = *i; cout << setw(17) << row[0] << setw(4) << row[1] << setw(7) << row["weight"] // you can use either the index number or column name when // retrieving the colume data as demonstrated above. << setw(7) << row[3] << row[4] << endl; } return 0; } I like the fact that I have a table\recordset style structure (Result) I like the fact that it is iterator friendly I like the fact that the code above would be understandable from a person coming from an MS ADO world (which would lead to more adoption of the library)

2 1

file modes in boost cvs
by Neal Becker 16 Oct '04

16 Oct '04

I noticed that in boost cvs files seem to have random modes. Many sources show up as executable when checked out of cvs onto my Linux box. Hopefully this will be fixed before release.

4 3

boost::tokenizer
by Dirk Gregorius 16 Oct '04

16 Oct '04

Hi, I like to break a file into tokens for processing. The file contains comments which are introduced by "//", "#" and ";". Can I setup the tokenizer directly such that the comments are skipped? If no, what would you suggest to erase the comments from my string before processing? Here is what I do right now: // CODE ifstream is( "file.txt" ); string file, line; file.reserve( 2 * 1024 * 1024 ); while ( getline( is, line ) ) { TrimHead( line ); if ( line[0] != '/' && line[1] != '/' ) file.append( line + "\n" ); // Need to append "\n" again to get the right tokens - not very nice } typedef tokenizer<char_separator<char> > Tokenizer; char_separator<char> sep(" \t\n"); Tokenizer tokens( file, sep ); // END CODE Another idea was to the following: // CODE ifstream is( "file.txt" ); string line( ( istreambuf_iterator<char>( is ) ), istreambuf_iterator<char>() ); EraseComments( line ); // END CODE Any help is appreciated. -Dirk

3 2

Re:Re: [boost] Proposal for cleanup of INT64 macros
by Robert Ramey 16 Oct '04

16 Oct '04

> There seems to be a lot of confusion about these macros, so let me try and > give you the full lowdown: > BOOST_NO_INT64 > Indicates that boost::int64_t and boost_uint64_t do not exist in > boost/cstdint.hpp. It's a defect macro because these types are documented > as existing; it doesn't indicate a defect in the compiler, although if > we're being picky, neither these types nor *any* of the exact width types > in boost/cstdint.hpp are required to be supported by C99. If you need a > 64-bit integer type then this macro is the one to check (and then use > [u]int64_t). > Note these macros should only be used when overloading/specialising > for all intrinsic types, such usage should probably be infequent IMO. This is exactly my problem with polymorphic_(i/o)archive.hpp. Its an interface class that redirects save/load for all intrinsic types to the implementation in a derived class. Among the intrinsic types considered is long and int64 (long long is not considered - the name suggested a compiler dependent kludge). Currently I use BOOST_NO_INT64 but now I see that this fails on at least one machine where apparently int64 is a typedef or macro for long. In this environment I get a compile error because a rather than a function overload I get a compiler error with function redefinition. Before, I had a homemade BOOST_NO_INTRINSIC_INT64_T which seemed to work. What is the best thing to do in this situation? > The macros BOOST_NO_INTRINSIC_INT64_T and BOOST_NO_INTRINSIC_UINT64_T > appear to have been removed, so no cleanup necessary :-) :-( It seems that this is just what I need. I didn't realize it existed as I just depended on the information in the documentation and didn't look at the config.hpp file. Robert Ramey

2 1

Proposal for cleanup of INT64 macros
by Markus Schöpflin 16 Oct '04

16 Oct '04

Hello, currently we have a number of macros in boost which deal with whether INT64 support is available of not and in what form it is available. To my knowledge these are (in no particular order): - BOOST_NO_INTRINSIC_INT64_T, - BOOST_NO_INTRINSIC_UINT64_T, - BOOST_NO_INT64, - BOOST_HAS_MS_INT64, and - BOOST_NO_INTEGRAL_INT64_T. I propose to change these as follows. - BOOST_HAS_INT64_T - BOOST_HAS_INTEGRAL_INT64_T - BOOST_HAS_INTRINSIC_INT_64_T - BOOST_HAS_MS_INT64_T Where the following would hold: BOOST_HAS_INTRINSIC_INT_64_T => BOOST_HAS_INTEGRAL_INT64_T => BOOST_HAS_INT64_T. (I don't know where BOOST_HAS_MS_INT64_T would fit in above but I'm sure some MS expert will know.) The reasons for this proposal are: 1. I think the BOOST_NO_.. macros are misnamed. They don't describe a defect (INT64 support isn't mandated by the standard) but rather an extension. Therefore they should be named BOOST_HAS_... 2. Most uses of the above macros are #ifndef(BOOST_NO_INT64) or #ifndef(BOOST_NO_INTEGRAL_INT64_T) or the like. This double negation makes the use harder to understand than neccessary. 3. I think it is safe to assume that when an intrinsic INT64 type is available, the UINT64 type will be intrinsic, too. 4. If one currently wants to know wheter an integral INT64 type is available, the correct way to check is #if !(defined(BOOST_NO_INT64)) && !(defined(BOOST_NO_INTEGRAL_INT64_T)). This would be facilitated to #ifdef BOOST_HAS_INTEGRAL_INT64_T . Is there any interest in this proposal? Any comments and thoughts are welcome. Markus

3 9

Re:[boost] Re: Proposal for cleanup of INT64 macros
by Robert Ramey 15 Oct '04

15 Oct '04

>Tobias Schwinger wrote: >> Markus Schvpflin wrote: >> >>> currently we have a number of macros in boost which deal with whether >>> INT64 support is available of not and in what form it is available. >>> >>> To my knowledge these are (in no particular order): >>> >>> - BOOST_NO_INTRINSIC_INT64_T, >>> - BOOST_NO_INTRINSIC_UINT64_T, >>> - BOOST_NO_INT64, >>> - BOOST_HAS_MS_INT64, and >>> - BOOST_NO_INTEGRAL_INT64_T. >> >> What version of boost are you referring to ?? >> >> <snip> >> $ find /cvs/boost/boost/config -type f |xargs grep INTRINSIC |grep 64 >> $ # whoops - no 'INTRINSIC' and '64' at the same line in any config >> file $ # current state of the Boost main-CVS (head revision) <snap> >> >> Wishful thinking ? Well, I would like it, too ;+). >It was used in "boost/archive/polymorphic_[io]archive.hpp" but was removed >yesterday. Honestly. :-) LOL - I removed it yesterday. The cited file needs to know if int64 is an intrinsic type or a synonym for some other type - e.g. long on a 64 bit machine or ?. If it is, it will generate a compile error when the cited file is compiled. I would like to avoid this. For my purposes, if it were defined as a synonym for long long it would be ok so the above macros don't quite give me what I need in this instance. I'm still undecided what to do about this. I suppose the above proposal would work for me. I would use #if ! defined(BOOST_NO_INT64) && ! defined(BOOST_NO_INTRINSIC_INT64_T) virtual void load(int64_t & t) = 0; #endif >> I propose to change these as follows. >> >> - BOOST_HAS_INT64_T >> - BOOST_HAS_INTEGRAL_INT64_T >> - BOOST_HAS_INTRINSIC_INT_64_T >> - BOOST_HAS_MS_INT64_T >> I prefer sticking to the BOOST_NO... syntax. Yes it implies double negatives in some cases - but it means I don't have to remember which is negative and which is positive logic. (Foolish) consistency is a virtue Here. Robert Ramey

2 1

StringAlgo - (was: boost::tokenizer )
by Dirk Gregorius 15 Oct '04

15 Oct '04

> Boost.Tokenizer is currently not the only option for this > kind of job. There is also splitting facility incorporated > in the StringAlgo library. Thanks for the hint. This is something I really was looking for. When do you think will this code be in the official release ( I will download it now anyway )? > Note, that you will need to load whole file into a string before > processing, since all these facilities need at lease a forward > iterator, so streambuf_iterator is not sufficient. This is exactly what I do. ifstream is( "file.txt" ); string file_string( ( istreambuf_iterator<char>( is ) ), istreambuf_iterator<char>() ); This reads in the whole file into file_string in one step. A question regarding your design of this library. In your help file I read: "The library interface functions and classes are defined in namespace boost::algorithm, and they are lifted into namespace boost via using declaration" I try to use also more namespaces in my code. boost makes heavy use of namespaces as far as I can say this. Is it common style to have the implementation "deeper" in nested namespaces and "lift up" the interface again to the first level? How is this done? So you must use using declarations in the header files if I understand that correctly - which is a "NoNo" in a lot of books. I once used nested namespaces in my code, but found it very inconvinient to use, so I rewrote it, although it was logical very well grouped together. Can you give any design considerations / hints if I want to do the same? I found it very hard to find any discussions/papers regarding the proper use of namespaces. For me it seems as if namespace are only understood as facility to avoid nameclashes. In my opinion they also make the code more understandable and also allow some kind of abstraction by grouping logical dependent entities together. Best regards, -Dirk

2 1

RE: [boost] Re: Library Proposal: database (boost::db)
by Brian Braatz 15 Oct '04

15 Oct '04

> > "Tito Villalobos" wrote: > > > I have been working on a library for database programming. It currently > > wraps only ODBC API,... > > > Can you compae it with Database Template Library > http://dtemplatelib.sourceforge.net/index.htm > ? Just an FYI here- I recently evaluated the DTL and it uses RTTI internally-

3 2

RE: [boost] Library Proposal: database (boost::db)
by Brian Braatz 15 Oct '04

15 Oct '04

> -----Original Message----- > From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] > On Behalf Of Jeff Garland > >...snip code... > > The one concern I have is that many db applications require runtime schema > discovery as well as data returns -- so I think the compile time approach > is > limited to a particular class of applications that can be fully specified > at > compile time. DTL has dynamic views and integrates well with STL > collections, > so at some level they are setting the standard on this currently. Another > interesting area of exploration for this would be integration with > boost.multi_index. > > > Would there be any interest in including this in boost? > > Yes, we really need a standard well thought out approach to accessing > databases in C++. > > Jeff I am currently going down this exact path and wanted to share what I ran into: 1- Boost does not have a 2dim "Table<>" - i.e. a Recordset 2- Boost.multi_index only works with concrete structures I would love it if I could use that to make a dynamic Table\ recordset 3- I have had to build my own Table<> by internally using boost.multiindex 4- Dtl is nice, however the thing that kicked me away from it is that it requires RTTI. This is a fact not clear in the documentation. It would be more than possible to do something along the lines of DRL and use boost.variant instead of having to resort to RTTI I believe boost is missing a "recordset" analolgy and I would hope that whatever is created is not "struct only" like boost.multi_index. (don't get me wrong I LOVE the multi_index - it just doesn't work dynamically) As a user I would like to see something along the lines of DTL \ Mysql++ http://dev.mysql.com/doc/plusplus/en/index.html It also sounds like you are thinking along the same lines (and we are working on similar things). I am more than happy to compare notes with you, either on this list or one -on-one if it is not-boost relevant, Thanks Brian Braatz

2 1

Re: [boost] Re: [multi_index] problem with gcc 3.4.2 for CompaqTru64UNIX
by JOAQUIN LOPEZ MU?Z 15 Oct '04

15 Oct '04

----- Mensaje original ----- De: Markus Schöpflin <markus.schoepflin(a)comsoft.de> Fecha: Viernes, Octubre 15, 2004 5:32 pm Asunto: [boost] Re: [multi_index] problem with gcc 3.4.2 for Compaq Tru64UNIX > Joaquín Mª López Muñoz wrote: > > > Markus Schöpflin ha escrito: > > >>The exact compiler switch removed was "-g". I will try to find > out whether > >>there is perhaps an updated assembler available which fixes the > problem. > > Please keep me informed if you make any progress. Thank you again. > > More on this... > > It's really not the fault of the system assembler that the file > cannot be > assembled by gcc in debug mode but the fault of mips-tfile which > is an > executable (first needed for MIPS, now only in use for Tru64, > hence the > name) which comes with gcc and is used to put the debug symbols > from the > assembler source into the object file _after_ the system assembler > has > created the object file. > > The length of the debug symbols mips-tfile can handle is limited > to 32768 > bytes. :-( There are some defines in the source code of mips- > tfile.c > (namely PAGE_SIZE and PAGE_USIZE) which look like they could be > used to > change that limitation but I'm not sure what else depends on these > constants. > I thought you might be interested in these findings. > They are very interesting indeed! Thank you for your efforts in clearing this out. Currently, this is what I wrote about the issue in the Boost.MultiIndex docs: http://tinyurl.com/43bfy I'll try to rewrite it according to your explanations. (If you feel like providing this paragraph to me, or even changing the doc in the CVS yourself, be my guest; I'm no Unix expert and much of this babble sounds like Greek to me.) As for the source code of mips-tfile.c, do you know if it is under control of the GCC folks? If so, maybe we can file a request that this issue be addressed in GCC 3.4.x. Best, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

2 1

Re: [boost] Re: [multi_index] problem with gcc 3.4.2 for Compaq Tru64UNIX
by JOAQUIN LOPEZ MU?Z 15 Oct '04

15 Oct '04

----- Mensaje original ----- De: Markus Schöpflin <markus.schoepflin(a)comsoft.de> Fecha: Viernes, Octubre 8, 2004 5:04 pm Asunto: [boost] Re: [multi_index] problem with gcc 3.4.2 for Compaq Tru64 UNIX > Markus Schöpflin wrote: > > > Joaquín Mª López Muñoz wrote: > > > >> mips-tfile, /tmp//cctFjnCI.s:10965 string too big (35326 bytes) > >> line:? #.stabs?"and_<boost::mpl::not_<boost::is_same<boost::mpl: > >> [very long expression] > > > > A quick google search indicates that this is a problem with gcc > on alpha > > when compiling with debug symbols. A possible workaround might > be to use > > -gstabs instead of -g, I'll try it ASAP. > > I did some experiments and the only way to compile these files it > to > disable debug symbols completely. I have done that on the toolset > for gcc > used for the regression runs, I hope it helps to clean up some of > the errors. > Hi Markus, I see that the failures are gone, thank you! Would you be so kind as to explain to me which compiler options you touched to make this work? I'd like to add that information on the "Compiler specifics" section of Boost.MultiIndex docs. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

3 3

[filesystem] file size
by Stefan Slapeta 15 Oct '04

15 Oct '04

Is there any rationale behind the lack of a function that returns the file size of a directory entry? (or do I miss something?) Stefan

2 1

[Boost-bugs] [ boost-Bugs-1047775 ] object_protocol.hpp - setitem: void func cant return a value
by SourceForge.net 15 Oct '04

15 Oct '04

Bugs item #1047775, was opened at 2004-10-15 06:20 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=1047775&group_… Category: Python Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: David Abrahams (david_abrahams) Summary: object_protocol.hpp - setitem: void func cant return a value Initial Comment: boost/python/object_protocol.hpp: template <class Key, class Value> void setitem(object const& target, Key const& key, Value const& value) { return setitem(target, object(key), object(value)); } won't compile on Tru64 Unix C++6.2 because of the return statement in a void function. Regards, Dario Cimafonte ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1047775&group_… ------------------------------------------------------- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

type_traits::is_polymorphic
by Richard Smith 15 Oct '04

15 Oct '04

Is there any chance that the virtual function boost::detail::is_polymorphic_imp1<T>::d2::foo defined in boost/type_traits/is_polymorphic.hpp could be renamed to have a name less likely to cause conflicts? I appreciate that the unique struct prevents this function from overriding any virtual functions in the base class, but it still has the potential to hide base class functions, which, at suitable warning levels in many compilers, causes a lengthy warning to be emitted. Although foo is unlikely to be a common function name in production code (well, good production code, anyway), it is the sort of name that is frequently found within unit tests and so forth. (For example, the name ``foo'' is used 2657 times in the gcc testsuite.) Cheers, Richard Smith

3 3

extending boost::io
by Israel Fdez. Cabrera 14 Oct '04

14 Oct '04

Hi, I'm working with the boost's IOStream library adding compression/decompression methods others than zip, gzip and bzip2. I'm working too adding support to OLE Compound Documents to the same library, I'd like to "extract" a containt OLE Document using boost::io stream interface. The problem is I'm not sure how to "return or extract" more than one document or compressed file from a stream. All boost examples boost::io::copy() a whole stream to another but not just part of it. I'll appreciate any help, best regards and thank you for such a helpful library Israel

3 7

[tuple] regression with borland-5_6_4
by Joaquín Mª López Muñoz 14 Oct '04

14 Oct '04

Hi, I've noted that tuple_test_bench is marked as a regression for BCB 564: http://tinyurl.com/62plc However, in the the following page listing Boost 1.31 issues, this test seems to appear as a failure: http://tinyurl.com/6j68r The problem seems to be related with BCB having a hard time with specializations on const types. So my questions are: 1. Is this really a regression or an expected failure as it seems to be present back in Boost 1.31? 2. Scanning the list, some folks claim that the problem goes away with BCB 5.6.4, yet what we have have does not indicate so. Anyone knows the status of this problem wrt to the version of the Borland compiler? 3. tuple already has an alternative implementation for those compilers without PTS, driven by BOOST_NO_TEMPLATE_PARTIAL_SPECIALIZATION (line 26 of boost/tuple/tuple.hpp). Could someone with local access to the Borland compiler try to apply the alternative implementation by replacing that line with the following? #if defined(BOOST_NO_TEMPLATE_PARTIAL_SPECIALIZATION)|| defined(BOOST_BCB_PARTIAL_SPECIALIZATION_BUG) (I don't know if BOOST_BCB_PARTIAL_SPECIALIZATION_BUG really relates to this particular problem, but its name fits perfectly well.) Thank you, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

2 1

BLL on a vector of tuples
by Brian Riis 14 Oct '04

14 Oct '04

Hi list, I have a situation where I need to find a tuple from a vector based on the value of one of the tuple's values. vector<tuple<string, int, int> > v; Basically I need the last int, and all I'm supplied is the first int. I thought of using lambda expressions for this, and dug into the documentation for that (so, this is my first real experience with BLL...and any lambda expressions for that matter). After some experimentation, I ended up with something akin to this. typedef boost::tuple<std::string, int, int> myTuple; std::vector<myTuple> v; ... using namespace boost::lambda; int id = <the value for the first int, that I need to find> std::vector<myTuple>::iterator iter = std::find_if(v.begin(), v.end(), (bind(&myTuple::get<1>, _1) == id)); My compiler (MinGW-3.4.2) gives me an error message on that last line: "error: cannot resolve overloaded function `get' based on conversion to type `SOCKET'" I'm sure it's trying to tell me where I've messed up, but I can really see it. (no doubt it's due to lack of experience with BLL, or lack of intelligence; quite possibly both :)) Am I totally out to sea here? If so, I'd be joyous if someone would light a beacon for me! :) TIA -- /Brian Riis

2 2

TR1 library extensions in libstdc++ - SmartPtr
by Jonathan Wakely 14 Oct '04

14 Oct '04

Hi, The libstdc++ developers are starting to implement the library extensions from TR1, including Boost-like smart ptrs, regex etc. http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1687.pdf I have volunteered to look into modifying the Boost smart pointers to match the TR1 specs and the libstdc++ coding standards. I realise I can modify the files and include them under the terms of the Boost licence, but the last Boost code to be used in libstdc++ (the concept checks) were licensed under the GPL. I believe that was something Jeremy Siek (as copyright holder) allowed specially: http://gcc.gnu.org/ml/libstdc++/2001-04/msg00050.html Would the SmartPtr authors (Peter, Greg, Beman, Daniel, Howard, Multi Media Ltd ...) consider allowing modified versions of shared_ptr.hpp, weak_ptr.hpp, shared_count.hpp and (maybe) checked_delete.hpp to be included in the GCC sources? It would probably require licensing them as GPL, which is where I imagine some people might have reservations. That wouldn't affect the copies in the Boost tree, of course. Allowing this would greatly speed up the process of adding TR1 features to libstdc++ and tracking the draft TR as it evolves. I am prepared to rewrite the smart pointers without using Boost code if necessary, but would obviously prefer not to, when the Boost implementations are the reference ones that were used for the TR1. I eagerly await responses, as whether I have to rewrite the classes or not will have quite an impact on my free time :-) jon -- "The following story is true. By which I mean false. It's all lies. But they're entertaining lies. And in the end, isn't that the real truth. The answer, is no." - Leonard Nimoy, in "The Simpsons"

9 23