[boost] Someone wanted filtered/decorated streambufs?

For the past few weeks, some posters were talking about streambufs that can decorate another stream buffer. I wrote up a general class at . The non-virtual filter functions act as a pass-through (i.e. no change) filter/monitor at the

Re: [boost] Re: Draft of new Boost Software License

[2003-06-26] Beman Dawes wrote: >At 03:29 PM 6/26/2003, Rene Rivera wrote: > > >I would think that since the Library Proposal of the interface is a > >separate > >document than the Boost implementation+docs of that interface they would > >have different licenses. And therefore not present a proble

Re: [boost] Draft of new Boost Software License

On Thursday, June 26, 2003, at 07:51 PM, Beman Dawes wrote: A copyright, unlike a patent, just applies to the actual representation. So unless another implementation actually made a literal copy of the Boost code, the other implementation would not be a derived work of the Boost code and so wo

RE: [boost] vc6 + stlport + boost/unit_test.hpp

> Hello, > I neep help integrating STLport 4.5.3 with Microsoft Visual C++6.0 SP5 > and the unit test framework from boost(1.29). > Everything seems fine when I use vc6 with STLport alone but when I try > to use it in a test environment I get memory corruption. (It compiles > and links fine).

[boost] Using python/detail files in iterator_adaptor code

I downloaded the most recent iterator_adaptors code from the Sandbox CVS, and it required several files from the boost/python/detail directory. I found this slightly off-putting, since iterator_adaptors has no conceptual relation to Python, and we don't even use Python where I work. Would it be

[boost] Re: Draft of new Boost Software License

"Beman Dawes" <[EMAIL PROTECTED]> escribió en el mensaje news:[EMAIL PROTECTED] > Thanks to Dave Abrahams, Diane Cabell, Devin Smith, and Eva Chen, we now > have a pretty close to final draft of a new Boost Software License. > Congratulations! Excelent work!! > * Boosters for whom English isn't th

[boost] Re: tokenizer comments

More than a month ago I posted a correction to the tokenizer documentation to which no one replied: "The Tokenizer documentation for char_separator tokenizer function states that the default argument for the second template type is "char_traits". This is incorrect. The source code in token_functio

Re: [boost] Re: Draft of new Boost Software License

At 03:29 PM 6/26/2003, Rene Rivera wrote: >I would think that since the Library Proposal of the interface is a >separate >document than the Boost implementation+docs of that interface they would >have different licenses. And therefore not present a problem when the >Library Proposal is accepted as

Re: [boost] Re: Interest in FC++?

At 04:21 PM 6/26/2003, Brian McNamara wrote: >While some of these names are ones that I have made up, and thus can be >changed "on a whim" to lowercase versions, there are still two classes >of naming issues which I hesitate to change: > > Haskell names. Many functoids (like enumFromTo, takeWhi

RE: [boost] PP interest in facilities for variablelengthargumentlists

> -Original Message- > From: [EMAIL PROTECTED] > > it doesn't directly support variadics as a data structure. The > > reasons for this are simple: 1) Variadic data can contain > open commas > > and that interferes with parameter lists if you need to pass around > > more than one str

[boost] regex documentation bug

http://www.boost.org/libs/regex/template_class_ref.htm#partial_matches There are two examples given. Though the examples are different, in both cases, the "example" links to a complete implementation of the first example. This likely was a cut-and-paste error. Dave

[boost] vc6 + stlport + boost/unit_test.hpp

Hello, I neep help integrating STLport 4.5.3 with Microsoft Visual C++6.0 SP5 and the unit test framework from boost(1.29). Everything seems fine when I use vc6 with STLport alone but when I try to use it in a test environment I get memory corruption. (It compiles and links fine). I wish to use

Re: [boost] Draft of new Boost Software License

At 09:18 AM 6/26/2003, Howard Hinnant wrote: >Since boost is a spring board for standardization of a library, I'm >wondering if the boost license requires the copyright notice to follow >for other implementations which follow the interface of the boost >library, but independently develop the imple

Re: [boost] API Review request: XML API for C++, second round

On Thu, 2003-06-26 at 21:39, Stefan Seefeld wrote: > Hamish Mackenzie wrote: > > > dom::document doc; > > dom::document_ref doc2( doc.root().document() ); > > assert( &doc2 == &doc ); > > > > and... > > > > assert( doc2 == doc ); > > > > Can be implemented but ideally it would compare all the n

RE: [boost] Draft of new Boost Software License

At 07:35 AM 6/26/2003, Matt Hurd wrote: >"Is my work a derivate work?", I guess is the gist of the question. How >do you firewall it? Does a contract with a third party need to address >the boundary of boost code (which maybe modified and embedded or not) >and the proprietary code. Serious answer

RE: [boost] PP interest in facilities for variable lengthargumentlists

> It isn't that it isn't worthwhile to support them. Rather, it is > because there are already about three (on average) different > implementations of the pp-lib to work around various (sometimes > serious) compiler deficiencies. Supporting variadics and > placemarkers from C99 would add, at min

[boost] Re: Re: API Review request: XML API for C++, second round

"Stefan Seefeld" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > Hi Bohdan, > > even though you may think of a dom tree as 'just another tree', there is > really quite a bit of domain-specific semantics associated with it > that makes it impractical to use a general-purpose tree/grap

[boost] Re: Interest in FC++?

Brian McNamara wrote: Non-reusable: bind, mem_fn, compose, function, functional, lambda: (It looks like much of compose and functional is subsumed by bind/lambda anyway.) FC++ "indirect functoids" are similar to boost::function objects. fcpp::ptr_to_fun is similar to bind

RE: [boost] PP interest in facilities for variable lengthargumentlists

> > Not to the Boost library version. At least, not until > variadics and > > placemarkers are part of C++. > > But variadics are a part of C. Though this is a bit outside > of Boost's mission, the PP lib is arguably even more useful > to C programmers than it is to C++ programmers. I don't s

Re: [boost] asymmetry when converting a ptime to/from simple string

Yes, that helps. Of course, it would be nice to have the time_from_string use its internal month table to turn the month string into the correct integer. ;-) If/when I have time, I may look into how to do that. I think it would also be nice to be able to configure (at compile time and/or at run t

[boost] Re: PP interest in facilities for variable lengthargumentlists

Josh Dybnis wrote: >>> Is there interest in adding support for variable length >>> argument lists to the preprocessor library. >> >> Not to the Boost library version. At least, not until variadics and >> placemarkers are part of C++. > > But variadics are a part of C. Though this is a bit outside

RE: [boost] PP interest in facilities for variable lengthargumentlists

> Can you elaborate some more on this. Do you mean that when a > library macro calls some user-defined macro, which in turn > calls the same library macro, then it will fail to evaluate? Yes. Macros are not allowed to recurse. This means that something like this: #define true false #define f

Re: [boost] API Review request: XML API for C++, second round

Hamish Mackenzie wrote: dom::document doc; dom::document_ref doc2( doc.root().document() ); assert( &doc2 == &doc ); and... assert( doc2 == doc ); Can be implemented but ideally it would compare all the nodes in the document. well, that's different. Do you want to know whether both documents are

Re: [boost] API Review request: XML API for C++, second round

On Thu, 2003-06-26 at 21:00, Hamish Mackenzie wrote: > You might be worried about... > > dom::document dom; > assert( &dom.root().document() == &dom ); > > I think this can work be made to work with > > bool operator ==( document * p1, document_ref * p2 ) > { > return p1->raw_ == p2->raw_; > }

Re: [boost] Re: Interest in FC++?

On Thu, Jun 26, 2003 at 01:36:58PM +0200, Dirk Gerrits wrote: > Brian McNamara wrote: > > - Reuse: FC++ "reinvents" a number of Boost's libraries in its > > implementation, such as smart pointers and metaprogramming > > tricks. A Boost version of FC++ should reuse Boost libraries for > >

Re: [boost] API Review request: XML API for C++, second round

On Thu, 2003-06-26 at 19:51, Stefan Seefeld wrote: > Hamish Mackenzie wrote: > > And I don't use a 'document' class, as that is managed implicitely > by my dom::document_ptr: > > dom::document_ptr document; // create new document; > dom::document_ptr doc(document); // create s

Re: [boost] local copy of the date_time doxygen reference manual

On Thu, 26 Jun 2003 11:33:19 -0400, Philip Miller wrote > The date_time reference manual seems to be available only at > http://www.crystalclearsoftware.com/libraries/gdtl/gdtl_ref_guide/index.html. > Unfortunately, there are times when I need to look at the reference > manual without an internet

Re: [boost] asymmetry when converting a ptime to/from simple string

On Thu, 26 Jun 2003 14:35:26 -0400, Philip Miller wrote > I am trying out the boost 1.30.0 date_time library and am quite pleased > with it. I just came across a "feature" on which I would appreciate > some help. There is an asymmetry when converting a ptime to/from a > simple string. The to_sim

RE: [boost] PP interest in facilities for variable length argumentlists

> > Is there interest in adding support for variable length > > argument lists to the preprocessor library. > > Not to the Boost library version. At least, not until variadics and > placemarkers are part of C++. But variadics are a part of C. Though this is a bit outside of Boost's mission, th

Re: [boost] Re: Draft of new Boost Software License

[2003-06-26] Chris Little wrote: >on 6/26/03 1:24 PM, Alexander Terekhov at [EMAIL PROTECTED] wrote: > >> >> Howard Hinnant wrote: >>> >>> Since boost is a spring board for standardization of a library, I'm >>> wondering if the boost license requires the copyright notice to follow >>> for other

Re: [boost] Re: Draft of new Boost Software License

On Thursday, June 26, 2003, at 01:24 PM, Alexander Terekhov wrote: Howard Hinnant wrote: Since boost is a spring board for standardization of a library, I'm wondering if the boost license requires the copyright notice to follow for other implementations which follow the interface of the boost lib

Re: [boost] Re: Draft of new Boost Software License

on 6/26/03 1:24 PM, Alexander Terekhov at [EMAIL PROTECTED] wrote: > > Howard Hinnant wrote: >> >> Since boost is a spring board for standardization of a library, I'm >> wondering if the boost license requires the copyright notice to follow >> for other implementations which follow the interface

Re: [boost] API Review request: XML API for C++, second round

Hamish Mackenzie wrote: And I don't use a 'document' class, as that is managed implicitely by my dom::document_ptr: dom::document_ptr document; // create new document; dom::document_ptr doc(document); // create second reference to it dom::document_ptr doc2 = document.clone(); // clone it, i.e. mak

RE: [boost] PP interest in facilities for variable length argumentlists

Can you elaborate some more on this. Do you mean that when a library macro calls some user-defined macro, which in turn calls the same library macro, then it will fail to evaluate? I have to admit that I don't grok the magic BOOST_PP uses to make recursion work. Could the same technique be used h

Re: [boost] API Review request: XML API for C++, second round

On Thu, 2003-06-26 at 18:32, Stefan Seefeld wrote: > Hamish Mackenzie wrote: > > On Thu, 2003-06-26 at 16:04, Stefan Seefeld wrote: > > > >>I don't really understand why we need three different classes to > >>manage documents. In particular I don't understand why you provide > >>a 'document_ptr' t

[boost] asymmetry when converting a ptime to/from simple string

I am trying out the boost 1.30.0 date_time library and am quite pleased with it. I just came across a "feature" on which I would appreciate some help. There is an asymmetry when converting a ptime to/from a simple string. The to_simple_string(ptime) method will output 2002-Jan-01 10:00:01.123456

[boost] Re: Draft of new Boost Software License

Howard Hinnant wrote: > In other words, if we standardize a boost library, will the library's > copyright notice have to be in all implementations of that std::lib? > Will the copyright need to appear in the standard itself? The copyright holder can always choose to grant an alternative license t

Re: [boost] API Review request: XML API for C++, second round

Hamish Mackenzie wrote: On Thu, 2003-06-26 at 16:04, Stefan Seefeld wrote: I don't really understand why we need three different classes to manage documents. In particular I don't understand why you provide a 'document_ptr' that is a wrapper around document_ref. The document_ref and document_ptr

Re: [boost] API Review request: XML API for C++, second round

On Thu, 2003-06-26 at 16:18, Stefan Seefeld wrote: > Stefan Seefeld wrote: > > > And I don't use a 'document' class, as that is managed implicitely > > by my dom::document_ptr: > > > > dom::document_ptr document; // create new document; > > that should actually become > > dom::document_ptr docu

[boost] Re: Draft of new Boost Software License

Howard Hinnant wrote: > > Since boost is a spring board for standardization of a library, I'm > wondering if the boost license requires the copyright notice to follow > for other implementations which follow the interface of the boost > library, but independently develop the implementation? > >

[boost] Re: Draft of new Boost Software License

Beman Dawes wrote: [...] > You really need to talk to IBM's lawyers to get their views. I know they > have looked at the current Boost licenses, because they were kind enough to > report some ambiguous wording, but I have no idea what else they may be > concerned about. I'm pretty sure that IBM's

RE: [boost] PP interest in facilities for variable length argumentlists

> The nice thing about the implementation is that it is layered > on-top of the existing BOOST_PP _ macros like BOOST_PP_WHILE. > So it doesn't require modifications to the existing library, > and none of the definitions are more that a few lines long. > All the functions live in the namespace

RE: [boost] PP interest in facilities for variable length argumentlists

> Is there interest in adding support for variable length > argument lists to the preprocessor library. Not to the Boost library version. At least, not until variadics and placemarkers are part of C++. OTOH, the Chaos version of the library, which is nearly complete, has full support for varia

Re: [boost] API Review request: XML API for C++, second round

On Thu, 2003-06-26 at 16:04, Stefan Seefeld wrote: > I don't really understand why we need three different classes to > manage documents. In particular I don't understand why you provide > a 'document_ptr' that is a wrapper around document_ref. The document_ref and document_ptr would only be used

Re: [boost] Re: Draft of new Boost Software License

At 05:24 AM 6/26/2003, Alexander Terekhov wrote: > >Beman Dawes wrote: >> >> At 01:50 PM 6/25/2003, Alexander Terekhov wrote: >> > >> >Beman Dawes wrote: >> >[...] >> >> * Boosters (or their lawyers) from countries other than the US; do >they >> >> spot any issues missed by Boost's US-centric

[boost] PP interest in facilities for variable length argument lists

Is there interest in adding support for variable length argument lists to the preprocessor library. Variable length argument lists can be used in place of all the existing data structures (i.e lists, sequences, tuples, and arrays). I've put together a complete set of operations on variable length

[boost] local copy of the date_time doxygen reference manual

The date_time reference manual seems to be available only at http://www.crystalclearsoftware.com/libraries/gdtl/gdtl_ref_guide/index.html. Unfortunately, there are times when I need to look at the reference manual without an internet connection (usually from my laptop when I am on travel). Is ther

[boost] Re: compose_f_gxy_hxy

Aleksey Gurtovoy wrote: Daniel Frey wrote: Peter Dimov wrote: You've considered bind(f, bind(g, _1, _2), bind(h, _1, _2)) right? ;-) Sure. But still compose.hpp is in itself incomplete. And it completes the standard's parts on function objects so I think it might be desirable to supply compos

Re: [boost] API Review request: XML API for C++, second round

Stefan Seefeld wrote: And I don't use a 'document' class, as that is managed implicitely by my dom::document_ptr: dom::document_ptr document; // create new document; that should actually become dom::document_ptr document = dom::make_document("1.0"); or similar to indicate that a new document is

RE: [boost] Re: compose_f_gxy_hxy

Daniel Frey wrote: > Peter Dimov wrote: > > You've considered > > > > bind(f, bind(g, _1, _2), bind(h, _1, _2)) > > > > right? ;-) > > Sure. But still compose.hpp is in itself incomplete. And it completes > the standard's parts on function objects so I think it might be > desirable to supply c

Re: [boost] API Review request: XML API for C++, second round

Hamish Mackenzie wrote: Ok I think I understand the problem now. What does node->document() return and what does it point to??? it returns a dom::document_ptr, which behaves exactly the same way as the other _ptr types, i.e. it has reference semantics. Well I think as with the node->parent() it sh

RE: [boost] compose_f_gxy_hxy

Daniel Frey wrote: > To complete the implementation of combined_argument_type, it would > help if mpl::vector would have 16 instead of 10 arguments, Just do #include "boost/mpl/vector/vector20.hpp" and use 'vector16'. Aleksey ___ Unsubscribe & other

Re: [boost] API Review request: XML API for C++, second round

Ok I think I understand the problem now. What does node->document() return and what does it point to??? Well I think as with the node->parent() it should return a proxy object. Something like... // non owning reference class document_ref { public: // Define document related methods here prote

[boost] Re: Draft of new Boost Software License

Matt Hurd wrote: [...] > PS: does #include make you a derived work? I'd say that in the context of new boost license, "derivative work" is a work that includes some {transformed} copyrighted expressions of ideas such that the result would constitute an infringement if made without authorizat

[boost] Re: compose_f_gxy_hxy

Daniel Frey wrote: Sure. But still compose.hpp is in itself incomplete. And it completes the standard's parts on function objects so I think it might be desirable to supply compose_f_gxy_hxy. If we take bind into account here, we could just as well remove compose.hpp completly, couldn't we? Or

Re: [boost] Draft of new Boost Software License

Since boost is a spring board for standardization of a library, I'm wondering if the boost license requires the copyright notice to follow for other implementations which follow the interface of the boost library, but independently develop the implementation? In other words, if we standardize a

Re: [boost] Cvs trouble

Toon Knapen wrote: > The boost-sandbox is showing some strange behaviour. > When checking out the boost-sandbox/numeric/bindings/traits/type.h using > the :ext: server I get version 1.3 (on the HEAD), with :pserver: it's > only 1.2. The WebCVS also only shows up to version 1.2. That's the same as

Re: [boost] Cvs trouble

[2003-06-26] Toon Knapen wrote: >The boost-sandbox is showing some strange behaviour. >When checking out the boost-sandbox/numeric/bindings/traits/type.h using >the :ext: server I get version 1.3 (on the HEAD), with :pserver: it's >only 1.2. The WebCVS also only shows up to version 1.2. > >Could

Re: [boost] Cvs trouble

Toon Knapen wrote: The boost-sandbox is showing some strange behaviour. When checking out the boost-sandbox/numeric/bindings/traits/type.h using the :ext: server I get version 1.3 (on the HEAD), with :pserver: it's only 1.2. The WebCVS also only shows up to version 1.2. Could others with both :e

Re: [boost] API Review request: XML API for C++, second round

Hamish Mackenzie wrote: On Wed, 2003-06-25 at 20:45, Stefan Seefeld wrote: Why should the node-wrappers keep the document alive? for consistency, and convenience. In the same way you can get down from the document to the individual nodes you can get up: node.parent() and node.document() provide t

[boost] Cvs trouble

The boost-sandbox is showing some strange behaviour. When checking out the boost-sandbox/numeric/bindings/traits/type.h using the :ext: server I get version 1.3 (on the HEAD), with :pserver: it's only 1.2. The WebCVS also only shows up to version 1.2. Could others with both :ext: and :pserver: ac

[boost] Re: compose_f_gxy_hxy

Peter Dimov wrote: You've considered bind(f, bind(g, _1, _2), bind(h, _1, _2)) right? ;-) Sure. But still compose.hpp is in itself incomplete. And it completes the standard's parts on function objects so I think it might be desirable to supply compose_f_gxy_hxy. If we take bind into account he

RE: [boost] Draft of new Boost Software License

Thanks Beman, >No, including the Boost license doesn't make your source open. There is >nothing in either the new or old Boost licenses which requires that source >code be redistributed or otherwise made available. I understand the intention and realize that this is the way it has always been. I

[boost] Re: Interest in FC++?

Brian McNamara wrote: I would like to see if there is interest in incorporating the FC++ library into Boost. I've glanced over the papers a bit. It seems very, very interesting. See below though. So I am sending this mail to see: (1) If there is still interest in adding FC++ to Boost, and (2)

[boost] [Signals] BCB patchlet

This removes a "possible use of 'tag' before definition" warning with BCB. --- slot.hpp.orig Thu Jun 26 13:29:32 2003 +++ slot.hppThu Jun 26 13:30:28 2003 @@ -88,8 +88,14 @@ namespace boost { typename BOOST_SIGNALS_NAMESPACE::detail::get_slot_tag::type tag_type(const F&) {

Re: [boost] compose_f_gxy_hxy

Daniel Frey wrote: >> Inspired by an article at the CUJ from Andrei Alexandrescu, I was >> finally able to come up with a compose_f_gxy_hxy-adapter. You've considered bind(f, bind(g, _1, _2), bind(h, _1, _2)) right? ;-) ___ Unsubscribe & other changes:

[boost] Re: Draft of new Boost Software License

David Abrahams wrote: [...] > Nothing is legally bullet-proof. People should not have illusions > about that. Well, I'd say that "opinions" (dissents aside) issues by "panels" like http://www.supremecourtus.gov (and alike) are pretty bullet-proof. Oder? ;-) regards, alexander. -- "SCO to sue

[boost] Re: Draft of new Boost Software License

Beman Dawes wrote: > > At 01:50 PM 6/25/2003, Alexander Terekhov wrote: > > > >Beman Dawes wrote: > >[...] > >> * Boosters (or their lawyers) from countries other than the US; do they > >> spot any issues missed by Boost's US-centric legal team? > > > >They seem to have missed a whole bunc

RE: [boost] Interest in FC++?

| -Original Message- | From: [EMAIL PROTECTED] | [mailto:[EMAIL PROTECTED] Behalf Of Brian McNamara | Sent: Wednesday, June 25, 2003 7:46 PM | To: [EMAIL PROTECTED] | Subject: [boost] Interest in FC++? | | | I would like to see if there is interest in incorporating the FC++ | library into

RE: [boost] Draft of new Boost Software License

| -Original Message- | From: [EMAIL PROTECTED] | [mailto:[EMAIL PROTECTED] Behalf Of Rene Rivera | Sent: Wednesday, June 25, 2003 8:26 PM | To: Boost mailing list | Subject: Re: [boost] Draft of new Boost Software License | | Spanish is my first, but English is a very close second. | The

[boost] Re: Draft of new Boost Software License

Beman Dawes wrote: At 01:10 PM 6/25/2003, Daniel Frey wrote: > I think that the term >used in the suggested new boost license could be a problem here. Reading the entire sentence, the phrase "of the Software" appears three times. Note the capitalization of "Software". That makes it clear that

Re: [boost] API Review request: XML API for C++, second round

On Thu, 2003-06-26 at 01:19, Stefan Seefeld wrote: > I believe _ptr and _ref are fairly equivalent. I think CORBA predates even original STL. In STL meaning of pointer and reference is... typedef foo & foo_reference; typedef foo * foo_pointer; *ptr <==> ref ptr->x() <==> ref.x() So you would no

Re: [boost] API Review request: XML API for C++, second round

On Wed, 2003-06-25 at 20:45, Stefan Seefeld wrote: > > Why should the node-wrappers keep the document alive? > > for consistency, and convenience. In the same way you can get down from > the document to the individual nodes you can get up: node.parent() and > node.document() provide the means to