On Thu, 26 Jun 2003 01:08:24 +0200, Daniel Frey wrote:
To complete the implementation of combined_argument_type, it would help
After waking up this morning, I immediately realized that the
implementation will not do what it promised. I have a better
implementation right now which is about 80%
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 walk
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
the
| -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.
|
| -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
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 bunch of issues
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 Al
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:
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_tagF::type
tag_type(const F)
{
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
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. It
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
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
[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
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
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
Matt Hurd wrote:
[...]
PS: does #include boost/any_old_header.hpp 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
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
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
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
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
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
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
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
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 legal team?
They
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
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
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
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
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?
In
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
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 document =
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
to
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' that is a
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
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.
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 of the
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
[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 implementations
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, the PP
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
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 second reference to it
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
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_;
}
bool
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
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
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 of Boost's
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
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 see
any
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
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/graph
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
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 answers to
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 nodes in the
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
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
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
-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 structure or
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, takeWhile,
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
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_traitschar. This is incorrect. The source code in
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 their
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
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).
1.
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
[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 problem when
For the past few weeks, some posters were talking about streambufs that
can decorate another stream buffer. I wrote up a general class at
http://groups.yahoo.com/group/boost/files/filter_stream.hpp.
The non-virtual filter functions act as a pass-through (i.e. no change)
filter/monitor at the
67 matches
Mail list logo
