March 2005 - Boost - lists.boost.org

Classpath to C++ conversion
by Tushar 01 Apr '05

01 Apr '05

Hi all, I am thinking of converting GNU Classpath used for GCJ to C++. I have following reasons about why to do this. 1. C++ requires a Good OOPs library with well defined api. Java has that . While C++ also have many of them, most do not look truly object oriented. As all of us know, Java is really a subset of C++ from pure language point of view. C++ has every thin that JAVA has except GC. But still programming in JAVA is more easy because they have a well define API to work with. I thinks, we should have some thing similar in C++ also. 2.C++ has much of the libs using STL. The only problem is STL is not a object oriented.(See STL Tutorial and reference) This really makes it difficult to think in OO and implement in STL. Particularly in STL, T a,b T a=b means a is separate entity and same for b. This make problem in many case where one wants just pointer e.g File handling and manipulation of large buffer. 3.There are other "standard" API to work with things like thread and networking. I know many libs are there on this boost and some other good site, but there is no uniform framework to work with in C++,one like one JAVA provides. These was some reasons why C++ libs are required. My idea is that API specification is already defined for java. And it seems much complete.I mean to say more complete then if start deciding from scratch -:). Why not to use java then? 1.JAVA is not free neither under GPL. 2.GC makes problem for many programs. 3.Compilation of java to binary using GCJ or something similar gives performance problem 4.After all, many C++ programmer like me do not want to change language but I do want a good uniform library. Difference bet proposed C++ and Java 1.Everything is a pointer other them simple atomic data types.(Same) 2.There is no GC. Its here large change will be required. (Diff) 3.Arrays - I do not know. Should it be made object like in java or let it be as it is in C++. Later seems good and one can use some class like Array to have similar effects.(?) 4.Every thing is subclass of Object(Same). 5.Sync support in Object (i.e to every object) using wait and signal - I am not sure. This makes it easy but may also bring some performace problem (?) Ok, enough thinking. Now implementation. Here I am thinking of converting entire GNU Classpath to C++. One major change will be lack of GC. For others, I will have to dig deeper. For GNU Classpath people, it will be review of their code. Regards, Tushar

10 24

[format] conversion to string
by Vladimir Prus 01 Apr '05

01 Apr '05

Hello! While it's generally considered a bad practice to provide implicit conversions, I think it would be good to provide such a conversion for the boost::format class. Currently, I can't write: string s; s = format("%1%") % 10; and need to write s = (format("%1%") % 10).str(); Maybe it's specifics of my code, but I can count 10 such conversions in a single source file. I think that: 1. Calling .str() is rather inconvenient. 2. The 'format' class most often used inside expressions. It's not likely to be passed around to functions and so the dangers of implicit conversions are not critical. Thoughts? - Volodya

4 7

Re: Asynchronous I/O
by Don G 31 Mar '05

31 Mar '05

Hi Robert, Thanks for contributing to these discussions! I hope that with you and the others involved we can get this long overdue library off the ground. Anyway, to respond to your question: --- Robert Ramey wrote: > The question here is: > > Is aio.h interface not sufficient in some way? If not, what > facility is it missing? If it is sufficient, then just > depend on the available implementation or re-implement the > interface in the most convenient way. > > Robert Ramey IMHO, the "io" part of "aio" is the primary thing what makes it insufficient. Unless I misread the man pages, I cannot post custom events or messages with aio; it is all about I/O on file descriptors. Which brings me to the other problem. At least on Windows, a file != socket != pipe != etc (regardless of the quasi-polymorphic WaitForXXX functions). If we constrain the discussion only to sockets, then this approach could be used. Sadly, pipes are a totally different ball game. If memory serves, the CygWin folks "mapped" all such types of objects to fd's, but doing so was very heavy handed. There was no other solution to their particular problem, but that is not the case here since we can invent the interface. The first issue is what spawned to Asynchronicity thread: given a general async mechanism, I/O could be easily adapted to it. The interface could be portable, even given the diverse ways and means necessary to achieve the goal. If we are to adopt an existing interface, I believe that it should be general enough for non-I/O uses. It should also be something that could be implemented on all platforms without undue inefficiency (something a select-style interface could not do, IMO, because of the poor performance of populating fd_set's or their moral equivalent). In a previous post I showed that the async technique I am proposing could be (fairly<g>) easily used to shield the application from library worker thread issues. With a little more work (and coupling), the use of channel.async_call could be encapsulated/automated to simplify the user experience. Best, Don __________________________________ Do you Yahoo!? Make Yahoo! your home page http://www.yahoo.com/r/hs

3 3

Boost policy on relying on std library implementation defined behaviour
by Jonathan Turkanis 31 Mar '05

31 Mar '05

Hi All, Is there a reason to avoid providing a uniform interface to implementation-defined standard library features? One of the most often heard complaints about the standard iostreams library is that there is no portable way to seek within a file stream using large (64-bit) offsets. Simplifying a bit, the standard library provides functions for seeking within a stream using - an offset of type streamoff, which may be 64-bits but is sometimes smaller, or - a position indicator of type streampos (usually fpos<mbstate_t>), a non-integral implementation defined type, with implicit conversions to and from streamoff. (streampos also stores a code conversion state, but I'm ignoring this) There are platforms where streamoff is inadequate to express an arbitrary seek offset, and where streampos is adequate, but only if implementation defined functionality is used. (There might be cases where neither type is adequate, but I'm ignoring this) I would like to implement functions which provide conversions between a large integral type and streampos. This will allow most uses of streampos to be hidden, with library users specifying integral types most of the time. The alternative would be: 1. provide additional concepts which require user defined filters and devices to implement functions involving streampos, AND 2. force users to deal with streampos directly, relying whatever guarantees are provided by their standard libraries. Point 1. requires complicating the iostreams library interface. Point 2. forces users to implement functions which could instead have been implemented just once by the iostreams library. What do people think? Jonathan

6 11

Re: [boost] Addition for shared_ptr
by Peter Dimov 31 Mar '05

31 Mar '05

Michael Rutman wrote: > At 1:40 PM +0300 9/20/04, Peter Dimov wrote: >> Michael Rutman wrote: >>> I'd like to propose adding a template function to shared_ptr to >>> allow the automatic testing of a shared_ptr to its raw ptr. >>> >>> The template is as simple as >>> >>> template <class T> >>> bool operator==(boost::shared_ptr<T> const & a, T * const & b) >>> { >>> return a.get() == b; >>> } >>> >>> >>> Here is the case where I need it. >>> >>> I have a vector<Foo> myFoo. >>> >>> In a method of Foo I need to see if this instance is in the vector. >>> I want to do this >>> >>> vector<Foo>::iterator iter = find( myFoo.begin(), myFoo.end(), this >>> ); >> >> This is a reasonable suggestion. It turns out that std::find _is_ >> specified in a way that allows heterogeneous comparisons, although >> this may be an oversight on the part of the committee and not a >> design decision. ;-) > > Any chance this can go in for the next release? <tilts head and ponders for a moment> Probably not, but not because it's necessarily a bad idea. I only add extensions to components already in TR1 if I'm reasonably sure that I want to (formally) propose this extension for a later version of the component (TR2, or C++next). Which in this case I'm not (yet).

1 0

Detecting static member constants on GCC
by David Abrahams 31 Mar '05

31 Mar '05

It seems GCC 3.3.3 doesn't like to do SFINAE based on the validity of T::value: int f(...); template <class T> int f(T, int(*)[T::value] = 0); int x = f(1); // error: `int' is not an aggregate type The same applies when eliminating partial specializations via SFINAE. Has anyone got an alternative approach? -- Dave Abrahams Boost Consulting www.boost-consulting.com

1 0

[assign] MinGW list_of() set<string> problem
by Daniel Schlyder 31 Mar '05

31 Mar '05

The following used to compile: std::set<std::string> const virtual_control::s_unbindables_permanent = boost::assign::list_of("Escape")("PrintScreen"); I'm not sure why, as Boost.Assign's docs seem to say I should have had to use the to_adapter function. Anyway, I recently started getting the following error: E:/libs/boost/boost/assign/list_of.hpp: In member function `boost::assign_detail::generic_list<char[7]>::operator set<string>() const' : E:\code\cpp\dasc\wc2\lib\alex\src\virtual_control.cpp:413: instantiated from here E:/libs/boost/boost/assign/list_of.hpp:334: error: call of overloaded `set( const boost::assign_detail::converter< boost::assign_detail::generic_list<const char *> > & )' is ambiguous After changing my code to std::set<std::string> const virtual_control::s_unbindables_permanent = boost::assign::list_of("Escape")("PrintScreen").to_adapter(); I now get the different error E:/libs/boost/boost/assign/list_of.hpp: In member function `set< string > boost::assign_detail::converter< boost::assign_detail::generic_list<const char *> >::convert_to_adapter(const set<string> *) const': E:/libs/boost/boost/assign/list_of.hpp:200: instantiated from `boost::assign_detail::converter< boost::assign_detail::generic_list<const char *> >::adapter_converter::operator set<string>() const' E:\code\cpp\dasc\wc2\lib\alex\src\virtual_control.cpp:413: instantiated from here E:/libs/boost/boost/assign/list_of.hpp:179: error: 'class set<string>' has no member named 'push' To me, this looks like an error in Boost.Assign. Am I doing something wrong? Thanks, -- Daniel Schlyder http://bitblaze.com/

2 9

[range] update on ADL hooks
by Thorsten Ottosen 31 Mar '05

31 Mar '05

Dear all, I'm going to change the ADL lookup hook of range functions. instead of the irritating void foo() { using namespace boost; begin(r); } we simply now say void foo() { boost::begin(r); } and get full ADL lookup. This changes the extension protocol to overiding these three functions: range_adl_begin() range_adl_end() range_adl_size() Any comments before I commit? -Thorsten -- Thorsten Ottosen ---------------------------- www.dezide.com www.cs.aau.dk/index2.php?content=Research/bss www.boost.org www.open-std.org/JTC1/SC22/WG21/

6 56

uBLAS tests moved to test subdirectory (confused regression results)
by Michael Stevens 31 Mar '05

31 Mar '05

A couple of weeks ago I moved the uBLAS tests into 'libs/numeric/ublas/test' for consistency with the rest of Boost. Since then the regression test results are filled with a lot of confussing results. I assume this results from the combing of stale result and the new configuration. I assume (and hope) that the next time testers do a 'clean build' things will clear up. This is a lot of work for many testers and there test machines however. Any ideas how to better make such changes in the future to avoid such confussion? Michael -- ___________________________________ Michael Stevens Systems Engineering Navigation Systems, Estimation and Bayesian Filtering http://bayesclasses.sf.net ___________________________________

2 1

Re: Serialization issuses under MS VC++ 7.1 ....
by Klaus Gütter 31 Mar '05

31 Mar '05

Hello Jason, I get the same error message when trying to deserialize this class (MSVC 7.1): class TestVector { private: std::vector<int> v; friend class boost::serialization::access; template<class Archive> void serialize(Archive& ar, const unsigned int version) { ar & BOOST_SERIALIZATION_NVP(v); } public: TestVector() { } }; Klaus "Jason Earl" <jason(a)hybd.net> schrieb im Newsbeitrag news:<004001c533fc$48724270$861aa8c0@system2600>... > If you have look at my original code, it does use > BOOST_SERIALIZATION_SPLIT_MEMBER() inside the class (sorry the code doesn't > intend with tabs nicely). > > I also have tried including both... > > #include <boost/serialization/split_member.hpp> > #include <boost/serialization/split_free.hpp> > > but neither work. I assume that the split free is obviously used by > the list > data type as it's not intrusive, and the member one is what I should include > and have been including. > > I'll look running the tests later when I get round to figuring out how > to > run them etc. I'll need to RTFM first though. From the regression thingy, it > said MSVC++7.1 worked OK though. > > I think this could be a little bug in the library (I won't speak too > loudly > here as I'm still a C++ beginner, and therefore there's a good chance I'm > still doing something very dumb), maybe someone else could confirm they get > the same problem as me when trying to serialize an class member varaible > that is a list of objects using load / save methods that are class members > under VS.NET 2003, like in my example.... > > anotherwords I have class A with separate load/save members, and then > I have > class B which has a member inside it that is of type std::list<A*>. > > Sorry in advance if I break the threaded reply structure on this list. > I > didn't have the list mail me replies. I'm new to all this mailing list > stuff. > > Jason > > _______________________________________________ > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost >

2 1