- Boost - lists.boost.org

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