- Boost - lists.boost.org

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