- Boost - lists.boost.org

[ublas] scalar_vector documentation
by Chris Weed 17 Apr '06

17 Apr '06

The scalar_vector documentation shows as example with a constructor taking only one argument; however, the constructor does not exist in the documentation just below. I suspect the example must be wrong. The web page is here: http://www.boost.org/libs/numeric/ublas/doc/vector.htm Chris

1 0

Re: [boost] Report from Berlin C++ Standards Committee meeting
by Reece Dunn 17 Apr '06

17 Apr '06

Steve Hutton wrote: > The idea is that to select all rows, you fetch within a loop. The > vector gets resized to contain the number of rows returned. > > const int BATCH_SIZE = 30; > std::vector<int> valsOut(BATCH_SIZE); > Statement st = (sql.prepare << "select value from numbers", > into(valsOut)); > st.execute(); > while (st.fetch()) > { > std::vector<int>::iterator pos; > for(; pos != valsOut.end(); ++pos) > { > cout << *pos << '\n'; > } > } > > http://soci.sourceforge.net/doc/statements.html How abouit something like: sql::statement query; query << "select value from numbers"; sql::rowset< int > rows(query); cout << "found = " << rows.size() << endl; std::vector< int > values; std::copy( rows.begin(), rows.end(), values ); Multi-item row searches could use tuple: sql::rowset< int, std::wstring, int > rows( query ); std::tr1::tuple< int, std::wstring, int > value = rows.begin(); - Reece _________________________________________________________________ Express yourself instantly with MSN Messenger! Download today it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/

9 14

[iterator] Test patch for BCB2006
by Nicola Musatti 17 Apr '06

17 Apr '06

Hallo, libs/iterator/test/iterator_traits_test.cpp should be updated for the latest Borland compiler. Patch attached. Cheers, Nicola Musatti ******Index: iterator_traits_test.cpp =================================================================== RCS file: /cvsroot/boost/boost/libs/iterator/test/iterator_traits_test.cpp,v retrieving revision 1.4 diff -d -u -r1.4 iterator_traits_test.cpp --- iterator_traits_test.cpp 20 Feb 2006 15:45:08 -0000 1.4 +++ iterator_traits_test.cpp 12 Apr 2006 07:34:10 -0000 @@ -153,7 +153,7 @@ input_iterator_test<std::istream_iterator<int>, int, std::ptrdiff_t, int*, int&, std::input_iterator_tag> istream_iterator_test; -#if defined(__BORLANDC__) && !defined(__SGI_STL_PORT) +#if BOOST_WORKAROUND(__BORLANDC__, <= 0x564) && !defined(__SGI_STL_PORT) typedef ::std::char_traits<char>::off_type distance; non_pointer_test<std::ostream_iterator<int>,int, distance,int*,int&,std::output_iterator_tag> ostream_iterator_test;

2 2

[Boost-bugs] [ boost-Support Requests-1471723 ] support new 2007 DST rules for timezone db
by SourceForge.net 17 Apr '06

17 Apr '06

Support Requests item #1471723, was opened at 2006-04-17 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=207586&aid=1471723&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: support new 2007 DST rules for timezone db Initial Comment: The boost time library supports processing of the timezone database file as a .csv, with one entry per time zone, such as "America/New_York". However, in 2007, the daylight savings time rules will change. The contents of the csv need to change, to incorporate a range of effective years. Since DST is a spring and fall event (in both north and south hemispheres) only a year need be recorded. I suggest adding two values at the beginning of the line, (as one field in the form nnnn-nnnn) for the low effective-year and high effective-year, as 4-digit values. Let 0000 be used for "all previous years" and 9999 be used for all subsequent years. [If the '-' separator is a problem, ':' could be used instead.] Then, the change in 2007 can be recorded as two lines: "2007-9999","America/New_York", ... "0000-2006","America/New_York", ... Lines unaffected by the change would have "0000-9999" as the first field. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=207586&aid=1471723&group_… ------------------------------------------------------- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

Re: [boost] [type_traits] is_convertible<noncopyable,To> crashes
by JOAQUIN LOPEZ MU?Z 17 Apr '06

17 Apr '06

----- Mensaje original ----- De: John Maddock <john(a)johnmaddock.co.uk> Fecha: Viernes, Abril 14, 2006 12:19 pm Asunto: Re: [boost] [type_traits] is_convertible<noncopyable,To> crashes > > In a post from yesterday (see http://tinyurl.com/hzk5w) > > Alexei Alexandrov found a rather serious problem with > > is_convertible in at least MSVC 7.1 and Intel 9.0, namely > > that is_convertible<From,To> fails to compile when > >> From is non-copyable, emitting an error message like this: > > Wait a second, I've just looked at the original error messages, > and the test > case is very specific, it fails for: > > is_convertible<const noncopyable, const noncopyable> > > That is known not to work, *and will never work*, there is no way > we can > define a trait that detects whether a type is copy-constructable > or not. In > other words the From and To parameters must be different types. OK, I've carefully read the standard and I understand now that convertiblity between X and itself is tantamount to X being copy constructible (my naive understanding was that X is always convertible to X by definition.) For the purposes of my code, I can then replace the calls of the form is_convertible<X,Y> with calls to template<typename From,typename From> struct is_same_or_convertible: mpl::or_< is_same<From,To> is_convertible<From,To> > {}; and thus avoid executing is_convertible<From,To> whith From=To. [On a side note, if From must be different to To, why is this is not stated in the docs? There's even a case whith From=To in is_convertible_test.cpp: BOOST_CHECK_INTEGRAL_CONSTANT( (::tt::is_convertible<Base,Base>::value), true); end of side note.] So, if we exclude the case where From=To, is is_convertible supposed to work for the call pattern is_convertible<const X,Y> where X is non-copyable and Y!=X? From Alexei tests seems like this could be failing too, and does not fall under the forbidden From=To case. I don't have any compiler handy right now, will try to check out by myself in a few days. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

3 2

fixed_point math request
by Yashin Evgeny 17 Apr '06

17 Apr '06

Hello. Fixed point computation appears too often on an embedded systems, but it seems that implement bug free class too complex (i found a lots of implementations in internet but all of them have 2 issues - either they have an computations bugs and precision loss either they not template). That's why it will be good if in Boost appear standart fixed point library. I assume, that interface should look like these: template< typename T, int N > class fixed_point { .. }; where T - set for us bitness of the variable, and signed/unsigned flag, and N - a number of bits for fractional part of number. of course, for T - best to use types like: uint32, int32 and so on.. or change interface on something like: template< bool signed, int number_all_bits, int number_fract_bits > class fixed_point { .. };

1 0

new library class offer
by Yashin Evgeny 17 Apr '06

17 Apr '06

First of all, if this is a not correct mailing list, please forward the letter to a correct. Thank you. Well.. Consider this code: struct LibraryClass { Object* create_object(); void push_in_stack_object(Object* ); }; In this case library user meets with ambiguity, should him destroy this pointers after using these methods, or not. I just thought out some very simple and small wrapper class, and name it intact_ptr<> which the only way to say library user, that this pointer user should not delete after using (in case of create_object method) or library will not own the pointer (in push_in_stack_object method). It seems that sometimes it's useful. Also this class can decide another pointer related problems, like unwantable increment/decrement operations, pointers equality comparing and so on.

1 0

Re: [boost] Report from Berlin C++ Standards Committee meeting
by Reece Dunn 16 Apr '06

16 Apr '06

Robert Ramey wrote: > On the other hand - I don't see the motivation for including concepts > in the core language. Haven't we been able to implement concept > checking with the current facilities of the library? It seems to me that > the main problem these days with the C++ language these days is that > its too hard to write a correct compiler for it. Making the core > language fancier will only make this problem worse. Concepts in the language allow things that aren't currently possible with C++98. For example, standard algorithms of the form: fn( Iterator first, Iterator last ) fn( Iterator first, Iterator last, Functor f ) cannot have overloads (in C++98) taking containers/ranges: fn( Iterator first, Iterator last ) fn( Iterator first, Iterator last, Functor f ) fn( Range rng ) fn( Range rng, Functor f ) as the last overload is ambiguous. Concepts will allow this to be resolved as a Functor will not match the Iterator requirements :). > While, the commitee is at it - how about re-visiting two-phase lookup. > Apparently there are enough implementers skeptical about it that > they've declined to implement it. (for good reason in my opinion). > I believe this is related to the "export" feature - which has also > failed to gain traction. export is way too complicated to implement, including changes to the output the compiler generates and how the linker works. Two-phase lookup has been implemented by a growing number of compiler vendors. The reason why some vendors choose not to implement this is that it will break (a lot of?) existing code. > So its seems to me that there are a number of issues more > important/urgent than the ones currently being focused on. I, for one, like concepts. They also help simplify the implementation of functions like std::distance as they remove the need to use iterator_traits and the iterator categories that clutter implementations and make them harder to read. - Reece _________________________________________________________________ Express yourself instantly with MSN Messenger! Download today it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/

5 8

Re: [boost] string_to/to_string (was: Re: Report from Berlin C++ Standards Committee meeting)
by Reece Dunn 16 Apr '06

16 Apr '06

Olaf van der Spek wrote: > On 4/15/06, Reece Dunn <msclrhd(a)hotmail.com> wrote: > > What about converting to different string types, mainly std::string or std::wstring? > > > > I am also working on implementing to_string and string_to :). Maybe we could combine our efforts and get to_string/string_to into Boost. > > > > At the moment, my versions don't have locale support and string_to isn't returning optional<T>, although I am working on it. They can be used like this: > > > > print( boost::to_string< char >( 10 )); // returns std::string > > The template parameter doesn't look nice (IMO). > What about to_basic_string<T> and to_string as alias for > to_basic_string<char> and to_wstring as alias for > to_basic_string<wchat_t>? What about when you want to have a different character traits or allocator type for the string you are converting to? > But then you're still limited to basic_string. Can't you make one that > can use other containers? Interesting. However, I would say define it as "to_string< StringT >( x ) will convert the object x into a string of type StringT, provided that char_type< StringT >::type returns the underlying string type of StringT and StringT can be constructed from a pointer to that type." This would then allow you to define one for ATL::CStringT< CharT >, QtString or whatever other string type you want to use. You could then use it to do things like: list.AddItem( to_string< ATL::CString >( data.string )); // std::string --> ATL::CString qtlist.AddItem( to_string< QtString >( 10 )); // int --> QtString Without the template, it is difficult to do this. - Reece _________________________________________________________________ Express yourself instantly with MSN Messenger! Download today it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/

2 1

Mixing a dll boost library with a static runtime is a really bad idea..."
by Saurabh Ramya 16 Apr '06

16 Apr '06

I am getting error "fatal error C1189: #error : "Mixing a dll boost library with a static runtime is a really bad idea..." I am building a application which uses boost threads and mutexs using vc6. My runtime library is "Debug MultiThreaded". please help to solve this issue? --------------------------------- Blab-away for as little as 1¢/min. Make PC-to-Phone Calls using Yahoo! Messenger with Voice.

3 3