May 2005 - Boost - lists.boost.org

Formal Review Request -- Interfaces
by Jonathan Turkanis 11 May '05

11 May '05

Hi, I would like to propose the proposed Boost Interfaces library, which I introduced several months ago, for formal review. (Or maybe I should say: I'd like to nominate the candidate Boost Interfaces library.) See http://www.kangaroologic.com/interfaces/ for download and documentation. The version to be reviewed will include a number of changes from the above version; in particular, about half of the features described in "Future Directions" will be implemented. However, the above version is self-contained and suitable for review, so I would like to propose it now and work on integrating the changes while it is sitting in the review queue. Jonathan

8 13

[ptr_container] indirect_fun - do we still need it?
by Pavel Chikulaev 11 May '05

11 May '05

Thorsten, Now, when we got rid of ptr_iterators, we don't need indirect_fun, do we? At least as part of ptr_container library? P.S. About copyability: may be then provide some cloning mechanism like: ptr_vector<int> a; ptr_vector<int> b(a.clone()); b = a.clone(); Where ptr_vector<T>::clone doesn't create clone immeadiately, but returns some object that refers to this, and ptr_vector<T> has ctor and assignment operator taking that object. Thoughts? -- Pavel Chikulaev

3 7

Re: (Another) socket streams library
by Nathan Myers 11 May '05

11 May '05

I was directed to this thread after some work to make GNU libstdc++ expose POSIX pipe semantics at the istream::readsome() level, which probably will show up in release 4.0.1. (Cf. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21286 ) It started me thinking about how to make an iostream useful when attached to a non-blocking socket. Reading this thread, it seems to me you have stepped in the same trap as most other attempts. There are many, many libraries to make various sources and sinks, including sockets, look like iostreams, but without actually being iostreams. We don't seem to find ourselves using them. For nonblocking socket support to be widely useful, it must be possible to pass such a stream to a library that takes a regular istream& or ostream& argument. This has been characterized as impossible, because iostream semantics are not compatible with non-blocking I/O. While the latter is true, the former is not. The key to the paradox is the expression "out-of-band". The owner of the stream may know things about it, and its underlying socket, that the user of the istream or ostream does not, and can act accordingly. Most particularly, the owner may know that the amount of input or output to be done will not cause any system calls to return EWOULDBLOCK. The next question is, how do we know how much I/O we can do without blocking? It is common for select not to wake up a process for writing on a socket until there is more than (say) 4K of space in the output buffer. Therefore, any use of the socket that will not produce more than 4K of output is safe. An actual TCP "out-of-band" notification from the other end may help, indicating that the last written data have all arrived, proving that a full 64K of buffer space awaits. On input, we must ensure that our override of streambuf::underflow is satisfied by a short read, and that the user of the attached istream will be satisfied with what it actually finds, and won't loop trying to get more. These conditions seem awfully restrictive, but there remain a large class of problems for which they are not *too* restrictive. What remains is to identify and package up all the usable out-of-band notification mechanisms associated with sockets, and try to achieve some abstraction and perhaps even (who knows?) portability. Nathan Myers ncm(a)cantrip.org

5 15

parameters library and rvalue pitfall
by David Abrahams 11 May '05

11 May '05

I just added an index_result metafunction that was requested during the review, for getting the result of a named parameter lookup, possibly with a default or a lazy default. Whereas previously, you would write the following to implement your function with named parameters, template<class Params> void f_impl(const Params& p) { g( p[name] , p[value || boost::bind(&value_default) ] , p[index | 999 ] ); } now you have the option to write something like this: template<class Params> void f_impl(const Params& p) { typename boost::parameter::index_result< Params, struct name_>::type& n = p[name]; typename boost::parameter::index_result< Params, struct value_, double >::type const& v = p[value || boost::bind(&value_default) ]; typename boost::parameter::index_result< Params, struct index_, int >::type const& i = p[index | 999]; g(n,v,i); } The problem, which you may have noticed, is that in the latter case you may be creating dangling references to destroyed rvalues. In the case of the index parameter above, the rvalue 999 gets bound to a const reference that then *passes through* the operator[] and initializes i. Since p[index | 999] returns a const reference and not a value, i is bound directly to the original rvalue 999 which is destroyed at the end of the full expression. The question is, what should we do about this? It turns out to be surprisingly hard to write the declarations of these temporary variables so they work in all cases. For example, v had to be a const& because in one case index_result<...>::type turned out to be char const[4] and when the default is used, it's double with p[value || ...] returning a double rvalue (by value). Thoughts? -- Dave Abrahams Boost Consulting www.boost-consulting.com

2 10

[test] and bcc32 errors
by Russell Hind 11 May '05

11 May '05

Running the regression tests on boost.test with bcc32 leads to many errors like this (and also in other libs regression tests) basic_cstring_test.cpp: Error E2093 c:\Users\russell\Projects\boost-cvs\boost\boost/test/predicate_result.hpp 51: 'operator!' not implemented in type 'tt_detail::equal_impl_frwd' for arguments of the same type in function predicate_result::predicate_result(const tt_detail::equal_impl_frwd &) Any ideas what is going on? Thanks Russell

2 8

Re: [boost] Re: FOREACH / C++ "for" proposal
by brangdon＠cix.compulink.co.uk 11 May '05

11 May '05

In-Reply-To: <428133DD.20505(a)dcook.org> darren(a)dcook.org (Darren Cook) wrote (abridged): > Wouldn't someone wanting to do something "clever" like that fall back to > using a normal for() or while() loop? I thought for(i:vect){} is a > convenience function to save typing and make code clearer; can it do > something a while() loop cannot? I don't think it makes the code clearer, because it looks like a use of i rather than a declaration. I think it is very important for readability that names be declared explicitly. That is a general point. What you are proposing: for (i: vec) is especially misleading because it is inconsistent with: for (i = vec.begin(); i != vec.end(); ++i) I really don't think one should declare i and the other, not. What's wrong with: for (auto i: vec) ? -- Dave Harris, Nottingham, UK.

2 1

Re: [boost] Re: Re: Formal Review: FOREACH macro
by brangdon＠cix.compulink.co.uk 11 May '05

11 May '05

In-Reply-To: <00fb01c55599$e9fc23e0$6401a8c0@pdimov2> pdimov(a)mmltd.net (Peter Dimov) wrote (abridged): > I think that defining size( T[N] ) as N or N-1, depending on whether T > is a character type, will cause problems in generic code and preclude > the widespread use of the library. I agree. If we do support null-terminated character strings, can we support other kinds of terminators too? (Without undue loss of efficiency.) For example: int array[] = { 1, 2, 3, -1 }; int *pArray = array; for (int i, terminator_adaptor(pArray,-1)) cout << i; // Does not write -1. This can be useful if the size of the array is not visible to for(:). I use terminators fairly often, usually NULL for pointers, 0 or -1 for integral types, and "end" for enums. It's not something specific to characters. In fact, for me the need to enumerate character strings is rarer than for these other types. Usually strings are either wrapped in std::string or similar, or else passed to some other routine. By "Without undue loss of efficiency" I really mean without scanning the sequence an extra time to find the end. My impression is that BOOST_FOR_EACH had a fairly general termination mechanism which could cope with that. -- Dave Harris, Nottingham, UK.

1 0

Re: [boost] Re: FOREACH / C++ "for" proposal
by brangdon＠cix.compulink.co.uk 11 May '05

11 May '05

In-Reply-To: <d5qtbh$cpi$1(a)sea.gmane.org> nesotto(a)cs.auc.dk (Thorsten Ottosen) wrote (abridged): > which example are you referring to? The one using my_range_adapter, in section 4 of: http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2005/n1796.html > chances are that <vector> will include <iterator> anyway. I'd rather not have to take chances with my code. -- Dave Harris, Nottingham, UK.

1 0

[test] mingw (3.2.3) failure
by Gennadiy Rozental 11 May '05

11 May '05

Does anybody know what the deal here? Test output: mslater - test - basic_cstring_test / mingw Linker output [2005-05-10 22:57:32 UTC]: "g++" "-Wl,--enable-auto-image-base" -g -Wl,--allow-multiple-definition -mno-cygwin -o "C:\testing\boost\results\bin\boost\libs\test\test\basic_cstring_test.test\mingw\debug\basic_cstring_test.exe" -L"C:/testing/boost/results/bin/boost/libs/test/build/libboost_unit_test_framework.lib/mingw/debug" "C:\testing\boost\results\bin\boost\libs\test\test\basic_cstring_test.test\mingw\debug\basic_cstring_test.obj" "C:\testing\boost\results\bin\boost\libs\test\build\libboost_unit_test_framework.lib\mingw\debug\libboost_unit_test_framework.lib" "C:\testing\boost\results\bin\boost\libs\test\build\libboost_unit_test_framework.lib\mingw\debug\libboost_unit_test_framework.lib" C:\testing\boost\results\bin\boost\libs\test\test\basic_cstring_test.test\mingw\debug\basic_cstring_test.obj(.text$_Z19asignment_test_implIwEvPN5boost4typeIT_EE+0xef): In function `ZSt4setwi': c:/mingw/include/c++/3.2.3/iomanip: undefined reference to `std::char_traits<wchar_t>::compare(wchar_t const*, wchar_t const*, unsigned)' And a lot more like this. Why references to std::char_traits<wchar_t> symbols are undefined? Gennadiy

3 4

Re: [boost] Re: Formal Review: FOREACH macro
by Peter Dimov 11 May '05

11 May '05

Peter Dimov wrote: > Eric Niebler wrote: > >> Yes, but I was refering to native (C-style) strings, as in: >> BOOST_FOREACH(char ch, "hello world") > > This is a good opportunity to ask: what does this do? > > char const a[] = { 0, 1, 2 }; Or for extra fun, drop the 0. > BOOST_FOREACH( int x, a ) > { > std::cout << x << std::end; > }

6 20