- Boost - lists.boost.org

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