- Boost - lists.preview.boost.org

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