- Boost - lists.boost.org

[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: 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

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

[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

Review Schedule (11-May-2005)
by Tom Brinkman 11 May '05

11 May '05

The singleton library review started on 5-May-2005. If you haven't done so already, download the library at http://tinyurl.com/6qvrd. You should submit a review by 15-May-2005. The Typeof Library review begins 20-May-2005. You can download this library at http://boost-sandbox.sourceforge.net/vault/ (typeof.zip) Contact Tom Brinkman at reportbase(a)gmail.com for updates to this schedule. Review Queue as of May 11, 2005 1) Singleton (Current) 5-May-2005; Ends: 15-May-2005 2) Typeof Starts: 20-May-2005; Ends: 30-May-2005 3) Function Types Starts: 5-June-2005; Ends: 15-June-2005 4) Logging To be confirmed: 20-June-2005; Ends: 30-June-2005 5) Policy Pointer To be confirmed: 5-July-2005; Ends: 15-June-2005 Other Libraries (no particular order): 6) Fixed Strings 7) Intrusive 8) TR1 9) Fusion 10) Factory 11) Interfaces 1) Singleton Author: Jason Hise chaos(a)ezequal.com Review Manager: Pavel Vozenilek pavel_vozenilek(a)hotmail.com Availabe At: http://tinyurl.com/6qvrd The singleton library provides multiple powerful methods of controlling the lifetimes of global resources. Client code can choose among the many provided methods of creation, or can easily write new creators for specialized initialization needs. Client code can additionally control precisely when a singleton instance is automatically created and destroyed, can create and destroy singleton instances explicitly any number of times, and can set up dependencies between singletons in an easy and natural way. 2) Typeof Author: Arkadiy Vertleyb Arkadiy Vertleyb, Peder Holt vertleyb(a)hotmail.com peder.holt(a)gmail.com Review Manager: Andy Little andy(a)servocomm.freeserve.co.uk Available: http://boost-sandbox.sourceforge.net/vault/ (typeof.zip) The proposed Typeof library implements the functionality of the non-standard typeof() operator. Depending on the compiler, it utilizes one of the following three methods: 1) Forwards to the non-standard typeof extension, usually called __typeof__, on the compilers where such extension is available; 2) Utilises a loophole, available on the Microsoft vc6.5, vc7.0, and vc7.1; 3) Emulates typeof by the means of template and preprocessor metaprogramming for the compilers that do not fall into above two categories, such as vc8.0 beta, etc. This method is rather portable, and can also be used on the compilers that implement the __typeof__ as a language extension, when compiling with language extensions switched off. The emulation mode is currently working with vc7.1, vc8.0 beta, and gcc 3.3/3.4; The MS-specific trick is working with vc6.5, 7.0, and 7.1. The __typeof__ extension forwarding is working with gcc 3.3/3.4 and Metrowerks. 3) Function Types Author: Tobias Schwinger tschwinger(a)neoscientists.org Review Manager: John Maddock john(a)johnmaddock.co.uk Available at: http://tinyurl.com/4oe7q This library provides a metaprogramming facility to classify, decompose and synthesize function-, function pointer-, function reference- and member function pointer types. For the purpose of this documentation, these types are collectively referred to as function types (this differs from the standard definition and redefines the term from a programmer's perspective to refer to the most common types that involve functions). The classes introduced by this library shall conform to the concepts of the Boost Metaprogramming library (MPL). The Function Types library enables the user to: * test an arbitrary type for being a function type of specified kind, * inspect properties of function types, * view and modify sub types of an encapsulated function type with MPL Sequence operations, and * synthesize function types. This library supports variadic functions and can be configured to support non-default calling conventions. 4) Logging Library Author: John Torjo john.lists(a)torjo.com Review Manaer: Hartmut Kaiser hartmut.kaiser(a)gmail.com Available at: http://torjo.com/code/logging-v132.zip The Boost Log Library is a small library, who: * makes it very easy to declare/define new logs * allows you very simple access to logs * allows for log hierarchies, and for modifying log hierarchies * allows for easy and efficient enabling/disabling of logs/log hierarchies * allows for easy manipulation of log behaviors (the log's destination(s) and/or adjusting the original message) * is thread-safe Using the library in code is easy and straightforward: int i = 1, j = 2, k = 3; BOOST_LOG(app) << "testing " << i << '-' << j << '-' << k << std::endl; BOOST_LOG(dbg) << "this is a debug message, i=" << i << std::endl; BOOST_LOG(info) << "I just wanted to tell you something...."; Additions to v1.3.2 - can be compiled as a static/dynamic runtime (works as a DLL as well) - removed dependency on boost_thread Note: I did not test this on Unix, but it should work. If anybody can take a look at detail/ts_posix.hpp, I'd appreciate it. - solved other small issues, based on feedback - slightly improved documentation 5) Policy Pointer Author: David B. Held dheld(a)codelogicconsulting.com Review Manager: Gennadiy gennadiy.rozental(a)thomson.com Available At: Boost Sandbox under policy_ptr Smart pointers are used to automate memory management by handling the deletion of dynamically allcoated objects (and other resources). They assist in ensuring program correctness, exception safety, and memory integrity. Policy Pointer is a policy-based smart pointer framework designed to accomodate the large number of smart pointer designs. Through the use of policy classes, virtually any smart pointer type can be constructed within this framework. This library is a Boostification of the original Loki::SmartPtr type with significant modifications. 6) Fixed Strings Author: Reece Dunn msclrhd(a)hotmail.com Review Manager: Beman Dawes bdawes(a)acm.org Available At: boosts-sandbox/boost/fixed_string The fixed string library provides buffer overrun protection for static sized strings (char s[ n ]). It provides a C-style string interface for compatibility with C code (for example, porting a C program to C++). There is also a std::string-style interface using a class based on flex_string by Andre Alexandrescu with a few limitations due to the non-resizable nature of the class. 7)Intrusive Author: Olaf Krzikalla krzikalla(a)gmx.de Review Manager: Needed Available At: http://people.freenet.de/turtle++/intrusive.zip Library presenting some intrusive containers to the world of C++. While intrusive containers were and are widely used in C, they became more and more forgotten in the C++-world due to the presence of the standard containers, which don't support intrusive techniques. Boost.Intrusive not only reintroduces this technique to C++, but also encapsulates the implementation in STL-like interfaces. Hence anyone familiar with standard containers can use intrusive containers with ease. 8) TR1 9) Fusion 10) Factory Author: Federico Stella f.stella(a)flashnet.it 11) Interfaces Author: Jonathan Turkanis <technews(a)kangaroologic.com> Review Manager: Needed Available: http://www.kangaroologic.com/interfaces "Boost.Interfaces provides a macro-based Interface Definition Language (IDL) which can be used to define C++ class types called interfaces. An interface is a lightweight value type associated with a set of named function signatures. An interface instance can be bound at runtime to any object which implements the interface, i.e., to any object of a type with accessible non-static member functions having the same name and signature as the set of functions associated with the interface. The functions of the bound object can then be invoked through the interface instance using the 'dot' operator. Binding is completely non-intrusive: the object's type need not declare any virtual functions or derive from any particluar base class. "Current applications of Boost.Interfaces include: * Non-intrusive dynamic polymorphism — interfaces can often be used in place of abstract base classes, and are sometimes much faster (see Performance). * Dynamic inheritance — allows function calls to be forwarded automatically to an object specified at runtime (see Delegation). * Smart Interface Pointers — smart pointers which can manage the lifetime of any object whose type implements a given interface. * Smart References — like smart interface pointers, but the managed object is accessed using the "dot" operator."

1 0