[boost] Someone wanted filtered/decorated streambufs?

[Daryle Walker]

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 moment.  We would need to figure out the points 
of customizing before adding the virtual filter functions.  For 
instance, "doing_imbue" could have a virtual "do_postonly_imbue" that 
only lets the filter do its own adjusting for locale changes after the 
main stream buffer has already done its adjustments.  The "doing_sync" 
method could have a virtual "do_preonly_sync" that is called before the 
main stream buffer's syncing, and the virtual method could return a 
Boolean determining if the main buffer should continue.  The other 
"doings" could have pre- and post-actions (no "only," of course).

One difficulty would be if the reading and/or writing overrides need  
to store extra characters.  Maybe I could add reserve space in the 
filtering stream buffer

Daryle

___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

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

[Rene Rivera]

[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 the
> >Library Proposal is accepted as then some sort of license transfer to the
> >standards organization would happen.
> >
> >But I guess Beman should bring that up with the lawyers also ;-)
>
>Ha! You've never dealt with ISO, I guess. They are a world unto themselves 
>and their views on copyrights are pretty high-handed.

No I haven't. And I get the fealing that I should run away if said beast
approaches ;-)


-- grafik - Don't Assume Anything
-- rrivera (at) acm.org - grafik (at) redshift-software.com
-- 102708583 (at) icq
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: [boost] Draft of new Boost Software License

[Howard Hinnant]

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 would not have to follow the 
Boost license.


Thanks Beman.  That was most informative and useful.

-Howard

___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

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

[Rozental, Gennadiy]

 

> 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. Could you provide a small example so I could replicate the issue here?
2. Did you try to debug it? Where does it fail?
3. Try to use Boost.Test that comes with boost 1.30.0. Does it help?

I was using sucessfully the Unit test Frameowrk in above confguration. I
need more hints to tackle the issue.

Gennadiy.
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[boost] Using python/detail files in iterator_adaptor code

[Joe Gottman]

   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
possible to reorganize the iterator_adaptors library  so it is does not
depend on code from the Python library?

Joe Gottman



___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[boost] Re: Draft of new Boost Software License

[Fernando Cacciola]

"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 primary language; is the license
> understandable?
>
I'm from Argentina so Spanish if my first language.
I had no problem at all reading and understanding the license,
though I've trained myself at reading licenses way ago,
just to make sure I don't infringe copyrights while using
Open Source/Free code.

>
> * Boosters (or their lawyers) from countries other than the US; do they
> spot any issues missed by Boost's US-centric legal team?
>
None that I can tell.

> * Boost developers; if there are aspects of the license that make you
> hesitate about adopting it, what are the issues?
>
I'd like to see the issue of the coverage of the term "Software" resolved.

Motivated by A. Terekhov concerns, I think the license should, if at all
possible, expressely PROHIBIT anyone, including the copyright holder,
from patenting the covered Software and any implied intellectual production.

Just my 0.02...

BTW, make sure to express our gratitude to those lawers for their time and
great work!!

Fernando Cacciola






___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[boost] Re: tokenizer comments

[Edward Diener]

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_functions.hpp clearly shows that the default argument is
"std::basic_string::traits_type". Could this please be corrected ?"

You obviously have more charm than I do since you received some replies. So
maybe the above can be added to your corrections below of the tokenizer
documentation.

Vladimir Prus wrote:
> I have a few comments regarding the tokenizer library.
>
> 1. The documentation says that char_delimiters_separator is default
> parameter to 'tokenizer' template, and at the same time says that
> 'char_delimiters_separator' is deprecated. I think that's confusing
> and default parameter should be changed to 'char-separator'.
>
> 2. The token interator description is very brief. Specifically, it
> does not say what that iterator is usefull for, or when it's
> preferrable to direct use of tokenizer. The only way to construct the
> iterator is via make_token_iterator function which takes two
> interators as arguments. The meaning of those arguments is not
> documented.
>
> Lastly, the usage example
>
>typedef token_iterator_generator::type Iter;
>Iter beg = make_token_iterator(s.begin(),s.end(),f);
>Iter end = make_token_iterator(s.end(),s.end(),f);
>for(;beg!=end;++beg){
>
> appears to be just longer than tokenizer use:
>
>typedef tokenizer< offset_separator > tok_t;
>tok_t tok(s, f);
>for(tok_t::iterator i = tok.begin(); i != tok.end(): ++i) {
>
> so I *really* wonder what this iterator is for. OTOH, if it could be
> used like:
>
>for(token_iterator< offset_separator > i(s, f), e; i != e; ++i) {
>}
>
> it would be definitely simpler and easier. Is something like this
> possible?
>
> 3. The 'escaped_list_separator' template could have default argument
> for the first parameter, "Char".
>
> 4. I almost always try to use tokenizer when values are separated by
> commas. Believe me or not, I'm always confused as to which tokenizer
> function to use. This time, I read all docs for char_separator and
> only then used escaped_list separator -- which does the work out of
> the box. Maybe, a different name, like "csv_with_escapes_separator"
> or "extended_csv_separator" would help?
> It would make immediately clear what this separator is for.



___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

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

[Beman Dawes]

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 then some sort of license transfer to the
>standards organization would happen.
>
>But I guess Beman should bring that up with the lawyers also ;-)
Ha! You've never dealt with ISO, I guess. They are a world unto themselves 
and their views on copyrights are pretty high-handed.

At one time standards at least acknowledged all the people who contributed. 
But ISO doesn't even allow that nowadays, let alone acknowledging that a 
lot of what goes into a standard is closely related to if not downright 
derived from copyrighted works.

The point of the Boost license is to grant various permissions to everyday 
users. Special uses such as ISO standardization, or maybe some corporation 
that wants a different license, can be dealt with on a case-by-case basis. 
That's a nice aspect of the developer retaining copyright. The developer 
can cut a special deal if he or she wishes (but of course is under no 
obligation to do so).

--Beman

___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

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

[Beman Dawes]

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, zipWith,
>   etc.) and datatypes (like Maybe) have the exact same names and
>   behavior as their counterparts in the Haskell programming language.
>   I've named them this way to cater to programmers coming from a
>   Haskell background, and am hesitant to change them.
Don't underrate Haskell programmers. The ones I know have the kind of minds 
where if you switched the names to pig latin, they wouldn't skip a beat.

>   Functoid types.  The obvious alternative to naming the type of a
>   functoid with a leading capital letter (e.g. "compose" has type
>   "Compose") is to add a suffix (e.g. make it so "compose" has type
>   "compose_type").  Functoid type names are used a lot, though, and I
>   am not fond of the idea of making the type names longer than the
>   names of the instances.
I personally dislike the use of _type in such cases, but I think consistent 
naming has enough advantages that it wins out over personal preferences. I 
probably won't vote against a library which used such names for Functoid 
types, particularly if it represented an important body of existing code, 
but why run the risk?

>I dunno if either of the examples above constitutes reason enough to
>bend the rules with regards to naming conventions, but I want to ask.
One case I'm aware of where it makes a lot of sense to bend the rules is 
with certain few mathematical names which traditionally changed meaning 
when their case changed. That's a pretty strong argument. But almost all 
other cases come down to personal preference rather than strong arguments.

--Beman 

___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

RE: [boost] PP interest in facilities for variablelengthargumentlists

[Paul Mensonides]

> -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 if you need to use the variadic argument 
> > for something else.
> 
> Very true, but in the common case you just have 1 variadic 
> list. In the remaining cases you must require the extra 
> parenthisis. For the implementation I posted, that only 
> occurs within internal library calls, and the extra 
> parenthisis are not required in the interface.

The common case is variadic auxiliary data as in FILTER, TRANSFORM,
REPEAT, FOR_EACH, etc..  The other common case is variadic state as in
constructs such as FOR, WHILE, FOLD_LEFT, FOLD_RIGHT, etc..  If you use
the variadic parameter to store your data type that you are processing,
that means that you cannot have variadic auxiliary data or variadic
state.  I'll give you a small example.  If I was to implement addition:

// WHILE(pred, op, state)

#define ADD(x, y) \
TUPLE_ELEM( \
2, 0, \
WHILE(ADD_P, ADD_O, (x, y)) \
) \
/**/
#define ADD_P(d, xy) TUPLE_ELEM(2, 1, xy)
#define ADD_O(d, xy) \
( INC(TUPLE_ELEM(2, 0, xy)), DEC(TUPLE_ELEM(2, 1, xy)) )
/**/

// WHILE(pred, op, ...)

#define ADD(x, y) \
VARIADIC_ELEM( \
0, WHILE(ADD_P, ADD_O, x, y) \
 ) \
/**/
#define ADD_P(d, x, y) y
#define ADD_O(d, x, y) INC(x), DEC(y)

That's an example of how much cleaner and more efficient it is with
variadic state.  The same applies to auxiliary data also:

#define BETWEEN(list, x, y) \
FILTER(BETWEEN_P, list, x, y) \
/**/
#define BETWEEN_P(d, elem, x, y) \
BITAND( LESS_EQUAL(x, elem), LESS_EQUAL(elem, y) ) \
/**/

The point is this:  it is *far* more useful to allow variadic auxiliary
data or state than it is half-support a data type that consistents of
pure variadic data.

The framework is there in Chaos to define such things fairly easily.
They just won't match anything else in the library.  There is no such
framework in the pp-lib, however.

> It seems to me that "empty" is a close enough approximation 
> to "end of the parameters," in practice. Here is an 
> implementation of IS_EMPTY that I don't think relies on any 
> undefined behavior. With two caveats: 

Empty is a valid element.  It is not an approximation of "end of
parameters".  So, first, you can't use that a rogue value.  Instead, you
have to use something much more pathological.

> 1) it cannot differenciate between foo(a,) and foo(a) where foo is:
> 
> #define foo(x, ...) BOOST_PP_VA_IS_EMPTY(__VA_ARGS__)

Invoking 'foo' without two arguments is undefined.  You can't do this:

foo(x) // error

gcc allows this, but it is invalid.  You *must* invoke it with the
comma:

foo(x,)

> 
> 2) it causes most compilers to spit out a warning if the 
> final parameter ends in the name of a function-like macro. e.g.:
> 
> foo(a, BOOST_PP_CAT) /* causes a warning message */

This is the point.  You cannot pass certain types of data.  There is *no
way* to implement IS_EMPTY generally.  Trust me, I've implemented it a
hundred different ways.  You must always restrict some sort of input.
I.e. no function-like macros, no operators, etc..  Period.  Likewise,
you cannot detect the size of a variadic parameter without restricting
the size of the variadic parameter.  To further emphasize my point:
Wave is an extremely strict preprocessor that won't preprocess your
code.  The code is not legal.  If you want to detect whether or not
you're "at-the-end", limit the size of the variadic parameters to (for
example) 10 and do this:

#define CAT(a, ...) PRIMITIVE_CAT(a, __VA_ARGS__)
#define PRIMITIVE_CAT(a, ...) a ## __VA_ARGS__

#define SPLIT(i, ...) PRIMITIVE_CAT(SPLIT_, i)(__VA_ARGS__)
#define SPLIT_0(a, ...) a
#define SPLIT_1(a, ...) __VA_ARGS__

#define IS_VARIADIC(...) \
SPLIT(0, CAT(IS_VARIADIC_R_, IS_VARIADIC_C __VA_ARGS__)) \
/**/
#define IS_VARIADIC_C(...) 1
#define IS_VARIADIC_R_1 1,
#define IS_VARIADIC_R_IS_VARIADIC_C 0,

#define END (,,())

#define IS_END(...) IS_END_I(__VA_ARGS__,)
#define IS_END_I(x, ...) \
IS_VARIADIC(IS_END_II x,) \
/**/
#define IS_END_II(a, b, c, d, e, f, g, h, i, j, ...) __VA_ARGS__

IS_END( a, b, c, d, END )
IS_END( END )

You can expand the END value to hundreds of commas and change IS_END_II
likewise.  That, or similar pathological input, is the only way that you
can do this without undefined behavior in the absence of well-defined
token-pasting.

Regards,
Paul Mensonides

___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[boost] regex documentation bug

[Dave Gomboc]

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

___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

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

[Marc-Antoine Desroches]

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 the iostreams of stlport but also tried without : same
results. I am carefull to compile the boost test library with the
msvc-stlport tools and the correct  value.

Anybody has an idea why it doesn't work?

Marc-Antoine Desroches
Analyste-Programmeur - Software Developer
Solvision
www.solvision.net

___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: [boost] Draft of new Boost Software License

[Beman Dawes]

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 implementation?
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 would not have to follow the Boost license.

This has already happened; the Dinkumware CoreX threads library follows the 
Boost.Threads interface. But because they implemented from scratch, they 
didn't have to reproduce the copyright or license.

Now you might ask, "what about the interface, doesn't the copyright cover 
that too?" The answer is "no", as has been fought out in court several 
times. Ask a lawyer for details, but interfaces themselves aren't covered 
by copyright. The docs are covered, the header is covered, the 
implementation, test cases, etc, are all covered, but not the conceptual 
interface.

>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?
No, because the standard won't copy the actual library code. The standard 
may copy actual prose wording from the proposal, and that in turn may have 
been derived from the library's documentation, but the proposer will have 
to assign the copyright to ISO on any portion of the wording that reaches 
the actual standard document.

At one time some of us who wrote text for the standard actually had to sign 
a copyright assignment to ISO, but then IIRC ISO just decided they 
automatically became the copyright holder by some sort of international 
treaty eminent domain, and stopped actually asking for a written 
assignment.

>Will the copyright need to appear in the standard itself?

Not normally. There are three exceptions in the current standard, if you 
look at 1.10. So much of the standard wording came from three books by 
Stroustrup, Kernigahan & Ritchie, and Plauger that a special deal was cut 
with them. The three short paragraphs in 1.10 took a long time to 
negotiate.

Another aspect of standardization is that anyone who proposes something for 
standardization has to publicly announce if it is covered by a patent. 
There was a recent court case (something about hardware memory IIRC) where 
the proposer waited until after something got standardized, and then said 
"you now owe my company royalties if you implement the standard". The judge 
invalidated the patent. It would have been perfectly valid if the proposer 
had pre-announced the existence of the patent.

--Beman

___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

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

[Hamish Mackenzie]

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
> > document.
> 
> well, that's different. Do you want to know whether both documents are 
> equal, or whether they are identical, i.e. whether both references point
> to the same document ?

&doc2 == &doc would test if doc and doc2 refer to the same libxml2 doc
doc2 == doc would compare documents to see if they are equal

I think you could do the same for nodes.  The equality check would look
only at child nodes (otherwise you might as well compare the documents)

> Hmm, just to check whether we are still talking about the same thing
> here: do we agree that there can't be a 'node' type, i.e. just a 
> 'node_ref'/'node_ptr' ?
>
> Else it would be impossible to make that API a wrapper around libs like
> libxml2.

I can live without a node class.  And I don't know if it would be any
easier to make a deep copy node in MSXML or any other xml lib.

I don't think it is "impossible" just not very easy or efficient.  You
would have to copy the entire document into the node or at least part of
it.  Even then you would still need node_ptr and node_ref.  node could
look like this...

class node_ref
{
public:
  // All the node members
protected:
  xmlNode * raw_node_;
};

class node : public node_ref
{
public:
  node( node_ref source ) : doc_( source.document() )
  {
raw_node_ = find_same_node_somehow( doc_, source );
// find_same_node_somehow would look up the copy of
// the source node in the copy of the document.
  }

private:
  document doc_;
};

document doc( "test.xml" );
node new_node( doc.root() );

node_ref root = doc.root();
assert( new_node == root );
assert( &new_node != &root );

document_ref new_doc = new_node.document();
assert( new_doc == doc );
assert( &new_doc != &doc ) ;

So even erasing the root node of doc would not invalidate new_node, as
new_node has it's own copy of the document which includes all the nodes
children, parents and siblings.

I think it would work but it seems a little bonkers for value_type to
require an entire copy of the container.

I suppose you could just implement 'element' and restrict the coying to
the child nodes and not other relatives.  That way the node in question
would also be the root node of the copied document.  Can any element be
made the root of a new libxml2 document?  And does it make sense that
new_node.parent() would return null even if the original was not a root
node?

My gut feeling is that references, pointers and iterators only is best.

-- 
Hamish Mackenzie <[EMAIL PROTECTED]>

___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

RE: [boost] Draft of new Boost Software License

[Beman Dawes]

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 those questions are way too complex for an email reply. 
I'm not qualified in any case. Your best bet is to buy a book on the topic. 
Perhaps "Copyright Your Software" by Stephen Fishman. See 
http://www.nolo.com/lawstore/products/product.cfm/ObjectID/991DEF76-7EAC-402F-A36984BEADE9DB53

(I haven't read it. I've got an older book, How to Copyright Software" by 
MJ Salone, from the same publisher, but it is now out-of-print. It is 
available used on Amazon.)

>
>__
>
>If I have the desire to license source code, which uses boost code, to a
>third party, on the basis that my code may not be redistributed then
>this statement confuses the issue if I am a derivative work.
>
>For example, I build a risk system for an asset manager.  I use some
>boost, perhaps modified.  I include the license as required... and I get
>confused trying to separate the consequences in a contract with the
>third party.  I had one such messy contract that took over a year to
>resolve to mutual agreement :-(
>
>Perhaps this is a non issue as the issue may exist for alternative
>licenses.
I think other licenses have the same problem. I ran into it years before 
Boost, and solved it by keeping the open-source code clearly separated from 
the proprietary (and actually delivered on separate disks, to emphasize the 
difference.) The proprietary code used the open-source code, but was not 
derived from the open-source code. Use is one thing, derivation is 
another.
>PS:  does #include  make you a derived work?

No. That is use, but not derivation. But if instead of #include, you pasted 
in a legally significant portion of , that would 
make your program a derived work. Note that if you pasted in code from 
several sources, your code might become a derived work of each of those 
sources.

HTH,

--Beman 

___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

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

[Josh Dybnis]

> 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 minimum, two more versions of 
> about half the library. That's why I don't want to support 
> a "variadic" mode in general in the pp-lib at this point.  However, 
> that isn't why I don't want to add support for variadic parameters as

> a data type.  (I'll address that below in more detail.)

That seems justified, since it does not seem like my idea of
implementing variadics using a thin layer over the existing library
will work.

> 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 if you need to use the variadic 
> argument for something else.

Very true, but in the common case you just have 1 variadic list. In the
remaining cases you must require the extra parenthisis. For the
implementation I posted, that only occurs within internal library
calls, and the extra parenthisis are not required in the interface.

> 2) There is no way (without resorting to undefined behavior)
> of detecting whether you're at the end of the variadic parameters. 
> There are only two reasonable ways to do it:  First, make an "end" 
> rogue value that is pathological but detectable as opposed to any 
> other possible input ... second, limit the number of variadic 
> parameters.

It seems to me that "empty" is a close enough approximation to "end of
the parameters," in practice. Here is an implementation of IS_EMPTY
that I don't think relies on any undefined behavior. With two caveats: 

1) it cannot differenciate between foo(a,) and foo(a) where foo is:

#define foo(x, ...) BOOST_PP_VA_IS_EMPTY(__VA_ARGS__)

2) it causes most compilers to spit out a warning if the final
parameter ends in the name of a function-like macro. e.g.:

foo(a, BOOST_PP_CAT) /* causes a warning message */

That said, here is the implementaion:

#define BOOST_PP_VA_IS_EMPTY(...)\
BOOST_PP_VA_HEAD \
(   BOOST_PP_VA_CAT1 \
(   BOOST_PP_VA_IS_EMPTY_,   \
BOOST_PP_VA_CAT1 \
(   BOOST_PP_VA_IS_EMPTY_,   \
BOOST_PP_VA_IS_EMPTY_EAT __VA_ARGS__ \
) () \
)\
   )

#define BOOST_PP_VA_IS_EMPTY_EAT(...) BOOST_PP_VA_IS_EMPTY_EATEN
#define BOOST_PP_VA_IS_EMPTY_BOOST_PP_VA_IS_EMPTY_EAT() \
BOOST_PP_VA_IS_EMPTY_EMPTY
#define BOOST_PP_VA_IS_EMPTY_BOOST_PP_VA_IS_EMPTY_EATEN \
BOOST_PP_VA_IS_EMPTY_NOT_EMPTY
#define BOOST_PP_VA_IS_EMPTY_BOOST_PP_VA_IS_EMPTY_EMPTY 1,
#define BOOST_PP_VA_IS_EMPTY_BOOST_PP_VA_IS_EMPTY_NOT_EMPTY 0,
#define
BOOST_PP_VA_IS_EMPTY_BOOST_PP_VA_IS_EMPTY_BOOST_PP_VA_IS_EMPTY_EAT 0,

#define BOOST_PP_VA_CAT1(...) BOOST_PP_VA_CAT1_I(__VA_ARGS__)
#define BOOST_PP_VA_CAT1_I(x, ...) x ## __VA_ARGS__

-Josh Dybnis

___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

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

[Bohdan]

"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 library
> as the underlying representation.


I didn't mean that dom::document==tree_container or even uses it, but
dom::document has tree_container-like interface plus some
additional domain-specific possibilities.


regards,
bohdan







___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[boost] Re: Interest in FC++?

[Dirk Gerrits]

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 
  and mem_fn.  fcpp::lambda is somewhat similar to boost::lambda.
  In each of these cases, however, none of the boost stuff can be
  reused in FC++, as FC++ uses/requires so-called "full functoids"
  to work.  FC++ must necessarily duplicate these, owing to the
  fundamental differences in the library architecture.
That's most unfortunate. Are you sure it's something that can't be 
worked out? There have been feature requests before. ;)

- Naming conventions: FC++ uses a naming convention other than Boost's
(including systematically using capital letters in identifiers).
From what I have been able to tell in such a short time, the 'camel 
hump notation' is mostly used in the implementation and only slightely 
so in the interface. For example, things like Fun0, Fun0Impl, ... are no 
problem because you want to reuse Boost's facilities for these anyway. 
And the functiods are already 'properly' named in lowercase. Of course, 
there is some work to be done here, but I don't think it would be a big 
problem, do you?


It's much more insidious than this.  There are a number of types of
names which use captial letters visible in the client interface to the
FC++ library.  Here are the major categories of examples that spring to
mind:
[snipped]

I had noticed these, I had just not fully considered the implications. 
See below.

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, zipWith,
   etc.) and datatypes (like Maybe) have the exact same names and 
   behavior as their counterparts in the Haskell programming language.  
   I've named them this way to cater to programmers coming from a
   Haskell background, and am hesitant to change them.
Understandable. Though I find the following more compelling.

   Functoid types.  The obvious alternative to naming the type of a
   functoid with a leading capital letter (e.g. "compose" has type
   "Compose") is to add a suffix (e.g. make it so "compose" has type
   "compose_type").  Functoid type names are used a lot, though, and I
   am not fond of the idea of making the type names longer than the
   names of the instances.
I see. I've been bitten by this in my personal code from time to time as 
well. My compromise has been to use the Boost naming convention for 
functions, variables, and members, and use 'camel hump notation' for 
types, exactly as you have done apparently.

I dunno if either of the examples above constitutes reason enough to
bend the rules with regards to naming conventions, but I want to ask.
I'm not sure what the official Boost policy is, but the regex lib uses a 
considerable amount of 'camel hump notation' as well. Perhaps you won't 
have to change that many names after all. ;)

Regards,
Dirk Gerrits
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

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

[Paul Mensonides]

> > 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 harm in targeting C programmers for this particular 
> library, since they could be an important user base; as long 
> as it doesn't compromise the library's usefulness for C++ programmers.

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 minimum, two more versions of about half the library.
That's why I don't want to support a "variadic" mode in general in the
pp-lib at this point.  However, that isn't why I don't want to add
support for variadic parameters as a data type.  (I'll address that
below in more detail.)

> > OTOH, the Chaos version of the library, which is nearly 
> complete, has 
> > full support for variadics and placemarkers from the ground up.
> 
> I'm looking forward to your release of Chaos. Maybe this 
> exercise is just a learning experience for me, if you already 
> have implemented better variadic support in Chaos.

Chaos is implemented from the ground up to support variadics.  However,
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 if you need to use the variadic argument for something
else.  2) There is no way (without resorting to undefined behavior) of
detecting whether you're at the end of the variadic parameters.  There
are only two reasonable ways to do it:  First, make an "end" rogue value
that is pathological but detectable as opposed to any other possible
input.  3) There is no such thing as a "nil" variadic parameter.  There
is *always* at least one parameter, though that parameter might be empty
(a.k.a. "placemarker"), and second, limit the number of variadic
parameters.  Altogether, these issues make dealing with variadics as a
data structure not worthwhile when you can just wrap the elements in
parentheses and call it a "tuple."  (BTW, even tuples are only supported
up to a fixed size in Chaos because of the "end-of-data" issues
mentioned above.)

Support for variadics in Chaos, as far as algorithms are concerned, is
to allow the data/state to be variadic.  This is far more useful in
practice, as it gets rid of a massive about of "element access" from one
structure or another.

Regards,
Paul Mensonides

___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

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

[Philip Miller]

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 time) the format the
date_time library uses for its simple format.  One choice might be an additonal
(default?) argument to to_simple_string.  Please keep in mind that these are only
suggestions regarding relatively minor nitpicks in what I consider to be a great
library.  If I am not yet annoying you with my pestering questions, could you
point me in the right direction on how I might go about solving the problem with
the operator<< and a default facet?

Thanks for your help.

Phil

P.S. Here is my attempt (approach number 1) at solving the problem.  I modified
date_format_simple.hpp and date_names_put.hpp so that each chooses
month_as_integer as the hard-wired month_format to return.  Any chance on getting
these changes into the next date_time library? :-)

Thus, I have changed simple_format::month_format to be

  //! Describe month format
 static month_format_spec month_format()
  {
//return month_as_short_string;
  return month_as_integer;
  }

and  date_names_put::do_month_format to be

  //! Default month format
  virtual month_format_spec do_month_format() const
  {
//return month_as_short_string;
return month_as_integer;
  }

Jeff Garland wrote:

> 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_simple_string(ptime) method will output
> > 2002-Jan-01 10:00:01.123456789 but the time_from_string( const
> > std::string& ) methhod will choke on "Jan".  Is this a bug or a
> > feature?  I would like a symmetric pair of functions such that the
> > following code works and t1 == t0.
> >
> > t1 = time_from_string( to_simple_string( t0 ) )
> >
> > I appreciate any feedback.
>
> Well, I guess it is a feature :-(
>
> Apparently there is no existing set of to_string/from functions that
> offer this functionality directly.  So in the short run your
> options are:
>
> 1) write your own version of to_string which is compatible
> 2) Use operator<< with an appropriate date formmatting facet
>
> Number 1 would be something like:
> //WARNING -- never compiled or tested!!
> std::string another_to_string(const boost::posix_time::ptime& t) {
>using boost::gregorian;
>date d = t.get_date();
>std::string s =
> date_time::date_formatter::date_to_string
> (t.get_date());
>s = s + ' ' + boost::posix_time::to_iso_string(t.time_of_day());
>return s;
> }
>
> HTH,
>
> Jeff
>   }
>
> ___
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost


___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

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

[Edward Diener]

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
> mission, the PP lib is arguably even more useful to C programmers than
> it is to C++ programmers. I don't see any harm in targeting C
> programmers for this particular library, since they could be an
> important user base; as long as it doesn't compromise the library's
> usefulness for C++ programmers.

The problem is that very few C++ compilers support C variadics. Boost
features need a fighting chance to work with the vast majority of C++
compilers and this is done by staying as close as possible to the current
C++ standard. C variadics are not part of the current C++ standard.



___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

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

[Paul Mensonides]

> 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 false true

true  // expands to "false", then expands to "true", then stops
false // expands to "true", then expands to "false", then stops

The problem, relative to library primitives that invoke user-defined
macros, is that a simple macro of the form WHILE(pred, op, state)
prohibits the use of WHILE when WHILE invokes the predicate and
operation macros that are supplied by the user.  What the pp-lib does is
define a large set of WHILE macros (e.g.) all implemented similarly.  It
then defines "WHILE" as an object-like macro that expands to the next
"available" (i.e. not disabled) WHILE macro.  So the expression:

WHILE(pred, op, state)

Is actually the invocation of an object-like macro (WHILE) that expands
to some available WHILE_xxx function-like macro which is invoked against
the parameters.

> I have to admit that I don't grok the magic BOOST_PP uses to 
> make recursion work. Could the same technique be used here 
> without duplicating a lot of code from the library?

No.  First, you'd have to define a large set of macros for several of
the constructs that call user-defined macros (256 in the pp-lib).
Second, you'd have to define a new library state for that construct (or
make it act like another which requires changing other parts of the
library).  Third, you'd have to double the number of macros required to
do the automatic recursion on buggy preprocessors.  Fourth, you'd have
to double number of implementation macros for EDG-based preprocessors to
make it perform at any kind of reasonable speed.  That is about what it
would take to make "some" of the structures work.  Some of the pp-lib's
algorithms don't allow recursion because of this explosion in the number
of macros. 

In Chaos, OTOH, recursion is abstracted and everything that takes
user-defined macros/lambda expressions is reentrant (i.e. recursive).
Under the Chaos model, defining algorithms that operate like you mention
above is pretty easy.  Each one would require about three or four
macros, each one would be reentrant, and each one would be overloaded on
lambda expression vs. user-defined macro.

Regards,
Paul Mensonides

___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

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

[Stefan Seefeld]

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 
equal, or whether they are identical, i.e. whether both references point
to the same document ?

Hmm, just to check whether we are still talking about the same thing
here: do we agree that there can't be a 'node' type, i.e. just a 
'node_ref'/'node_ptr' ?

Else it would be impossible to make that API a wrapper around libs like
libxml2.
Stefan

___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

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

[Hamish Mackenzie]

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 operator ==( document_ref * p1, document * p2 )
> {
>   return p1->raw_ == p2->raw_;
> }

Actually that wouldn't work as &dom.root().document() would fail to
compile.  (not without caching document_ref in node_ref)  But this might
be ok..

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.

-- 
Hamish Mackenzie <[EMAIL PROTECTED]>

___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

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

[Brian McNamara]

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
> >  this.
> 
> I agree. While FC++ probably would bring in a lot of new stuff, there is 
> *considerable* overlap with Boost's current libraries.
> On the function side there's: bind, mem_fn, compose, function, 
> functional, and of course lambda. And then there are smart_ptr, mpl, and 
> preprocessor.
> 
> Reusing will probably make the implementation a lot cleaner, potentially 
> more robust, and ...

I have taken a closer look at what is and is not reusable.  Here's what
I've come up with:

Reusable: 
   smart_ptr: boost::shared_ptr and boost::intrusive_ptr seem to do
  exactly the same thing as fcpp::Ref and fcpp::IRef

   mpl: it looks like some things here, like if_ and find can be reused.
There may be more, too.

   type_traits: boost::is_base_and_derived replaces fcpp::Inherits

   concept_check: it may be possible to re-use some of the machinery
  here for reporting "custom error messages".

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 
  and mem_fn.  fcpp::lambda is somewhat similar to boost::lambda.
  In each of these cases, however, none of the boost stuff can be
  reused in FC++, as FC++ uses/requires so-called "full functoids"
  to work.  FC++ must necessarily duplicate these, owing to the
  fundamental differences in the library architecture.

> > - Naming conventions: FC++ uses a naming convention other than Boost's
> >  (including systematically using capital letters in identifiers).
> 
> From what I have been able to tell in such a short time, the 'camel 
> hump notation' is mostly used in the implementation and only slightely 
> so in the interface. For example, things like Fun0, Fun0Impl, ... are no 
> problem because you want to reuse Boost's facilities for these anyway. 
> And the functiods are already 'properly' named in lowercase. Of course, 
> there is some work to be done here, but I don't think it would be a big 
> problem, do you?

It's much more insidious than this.  There are a number of types of
names which use captial letters visible in the client interface to the
FC++ library.  Here are the major categories of examples that spring to
mind:

   Functoids.  Every functoid (like id, map, enumFrom, compose) is an
   instance of a corresponding data type which begins with a capital
   letter (Id, Map, EnumFrom, Compose).  Being able to name the type of
   any functoid is important.

   Data types.  Classes like List and Maybe have names starting with
   capital letters.

   Signature information.  We use names like Arg1Type, Arg2Type,
   and ResultType as typedefs for functoid signatures.

   LEType computer.  Lambda expressions' types are named by the LEType
   computer, which uses some all-caps names like LAM, LV, CALL, etc.

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, zipWith,
   etc.) and datatypes (like Maybe) have the exact same names and 
   behavior as their counterparts in the Haskell programming language.  
   I've named them this way to cater to programmers coming from a
   Haskell background, and am hesitant to change them.

   Functoid types.  The obvious alternative to naming the type of a
   functoid with a leading capital letter (e.g. "compose" has type
   "Compose") is to add a suffix (e.g. make it so "compose" has type
   "compose_type").  Functoid type names are used a lot, though, and I
   am not fond of the idea of making the type names longer than the
   names of the instances.

I dunno if either of the examples above constitutes reason enough to
bend the rules with regards to naming conventions, but I want to ask.
   
-- 
-Brian McNamara ([EMAIL PROTECTED])
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

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

[Hamish Mackenzie]

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
> dom::document_ptr doc2 = document.clone(); // clone it, i.e. make deep
>   copy
> >>>
> >>>
> >>>This is not consistent with the standard library or C++ in general.  It
> >>>will seem strange that the pointer class
> >>>1) Does not require dereferencing
> >>
> >>would you say the same if the class name was spelled 'document_ref'
> >>instead ?
> > 
> > 
> > 1 & 4 would be ok, but 3 would stand and having an 'operator bool' would
> > be added to the list.
> > 
> > 
> >>>3) Has a constructor such as document_ptr( "config.xml" )
> >>>4) Has member functions such as write_to_file
> >>>
> >>>The alternative would allow both...
> >>>
> >>>boost::shared_ptr< dom::document > doc( new dom::document() );
> >>>boost::shared_ptr< dom::document > doc1( doc );
> >>>dom::document doc2( *doc1 );
> >>>
> >>>and if the 'doc1' reference was non-owning...
> >>>
> >>>dom::document doc();  // Create new doc
> >>>dom::document & doc1( doc ); // Second reference
> >>>dom::document doc2( doc1 );  // Deep copy
> >>
> >>right, but given such an approach, what would nodes return in their
> >>'parent()' method ?
> > 
> > 
> > The parent is always an element (is that right?) so it would return
> > element_ptr or element_ref.
> 
> yes. Sorry, I meant to ask what 'document()' would return.

Assuming xmlNode::doc cannot be null it would return document_ref.

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 operator ==( document_ref * p1, document * p2 )
{
  return p1->raw_ == p2->raw_;
}

etc.

-- 
Hamish Mackenzie <[EMAIL PROTECTED]>

___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

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

[Jeff Garland]

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 connection (usually from my laptop when I 
> am on travel).
> 
> Is there a way for me to get a local copy of the date_time reference
> manual?  If not, since we have the source, could I get the script(s)
> needed to generate the reference manual?

If you want, I can make a downloadable .zip of the reference guide 
available -- it will just take a day or so for me to get to.

Jeff


___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

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

[Jeff Garland]

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_simple_string(ptime) method will output
> 2002-Jan-01 10:00:01.123456789 but the time_from_string( const
> std::string& ) methhod will choke on "Jan".  Is this a bug or a
> feature?  I would like a symmetric pair of functions such that the
> following code works and t1 == t0.
> 
> t1 = time_from_string( to_simple_string( t0 ) )
> 
> I appreciate any feedback.

Well, I guess it is a feature :-( 

Apparently there is no existing set of to_string/from functions that 
offer this functionality directly.  So in the short run your 
options are:

1) write your own version of to_string which is compatible
2) Use operator<< with an appropriate date formmatting facet

Number 1 would be something like:
//WARNING -- never compiled or tested!!
std::string another_to_string(const boost::posix_time::ptime& t) {
   using boost::gregorian;
   date d = t.get_date();  
   std::string s = 
date_time::date_formatter::date_to_string
(t.get_date());
   s = s + ' ' + boost::posix_time::to_iso_string(t.time_of_day());
   return s;
}
 
HTH,

Jeff  
  }



___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

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

[Josh Dybnis]

> > 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 lib is arguably even more useful to C programmers than
it is to C++ programmers. I don't see any harm in targeting C
programmers for this particular library, since they could be an
important user base; as long as it doesn't compromise the library's
usefulness for C++ programmers.
 
> OTOH, the Chaos version of the library, which is nearly complete, has
> full support for variadics and placemarkers from the ground up.

I'm looking forward to your release of Chaos. Maybe this exercise is
just a learning experience for me, if you already have implemented
better variadic support in Chaos.

-Josh Dybnis

___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

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

[Rene Rivera]

[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 which follow the interface of the boost
>>> library, but independently develop the implementation?
>>> 
>>> 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?
>> 
>> http://digital-law-online.info/lpdi1.0/treatise23.html
>> http://digital-law-online.info/lpdi1.0/treatise27.html
>> 
>>> Will the copyright need to appear in the standard itself?
>> 
>> Uhmm, why would you care?
>
>Howard writes the standard library for Metrowerks as well as sitting on the
>standards committee so I'm sure he's wondering about what happens in the
>future.

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 then some sort of license transfer to the
standards organization would happen.

But I guess Beman should bring that up with the lawyers also ;-)


-- grafik - Don't Assume Anything
-- rrivera (at) acm.org - grafik (at) redshift-software.com
-- 102708583 (at) icq
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

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

[Howard Hinnant]

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
library, but independently develop the implementation?
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?
http://digital-law-online.info/lpdi1.0/treatise23.html
http://digital-law-online.info/lpdi1.0/treatise27.html
Will the copyright need to appear in the standard itself?
Uhmm, why would you care?
My job is to implement the std::lib for Metrowerks.  Why would I /not/ 
care?

-Howard

___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

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

[Chris Little]

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 boost
>> library, but independently develop the implementation?
>> 
>> 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?
> 
> http://digital-law-online.info/lpdi1.0/treatise23.html
> http://digital-law-online.info/lpdi1.0/treatise27.html
> 
>> Will the copyright need to appear in the standard itself?
> 
> Uhmm, why would you care?

Howard writes the standard library for Metrowerks as well as sitting on the
standards committee so I'm sure he's wondering about what happens in the
future.

Chris

___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

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

[Stefan Seefeld]

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. make deep
 copy


This is not consistent with the standard library or C++ in general.  It
will seem strange that the pointer class
1) Does not require dereferencing
would you say the same if the class name was spelled 'document_ref'
instead ?


1 & 4 would be ok, but 3 would stand and having an 'operator bool' would
be added to the list.

3) Has a constructor such as document_ptr( "config.xml" )
4) Has member functions such as write_to_file
The alternative would allow both...

boost::shared_ptr< dom::document > doc( new dom::document() );
boost::shared_ptr< dom::document > doc1( doc );
dom::document doc2( *doc1 );
and if the 'doc1' reference was non-owning...

dom::document doc();  // Create new doc
dom::document & doc1( doc ); // Second reference
dom::document doc2( doc1 );  // Deep copy
right, but given such an approach, what would nodes return in their
'parent()' method ?


The parent is always an element (is that right?) so it would return
element_ptr or element_ref.
yes. Sorry, I meant to ask what 'document()' would return.

Stefan

___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

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

[Josh Dybnis]

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 here without
duplicating a lot of code from the library?

Thanks,
-Josh Dybnis

--- Paul Mensonides <[EMAIL PROTECTED]> wrote:
> > 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 BOOST_PP_VA_.
> 
> A bit more on this part, the problem with implementing an algorithm
> on
> top of another algorithm like you do in your code, is that it makes
> the
> algorithm incapable of recursing in contexts where the algorithm
> calls
> some user-defined macro, such as a predicate or operation.
> 
> Regards,
> Paul Mensonides
> 
> ___
> Unsubscribe & other changes:
http://lists.boost.org/mailman/listinfo.cgi/boost

___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

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

[Hamish Mackenzie]

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 wrapper around document_ref.
> > 
> > 
> > The document_ref and document_ptr would only be used when a non owning
> > reference or pointer is required.  Even then you could use
> > dom::document * and dom::document & instead in most cases.
> > 
> > One big difference between a reference and a pointer is that a reference
> > must contain a valid non null value.
> 
> ok, but are these types really needed ?

IMHO yes

> My current proposal only provides dom::document_ptr, and I use implicit
> refcounting on the underlying document tree. It seems to work quite
> fine. I provide a bool operator () that tells me whether the
> document_ptr is referring to a document or not.

I would rather have a debug version that tracked
pointers/iterators/references and flagged (at runtime) their use when
they are invalid.  This could catch a wider range of problems including
the use of nodes who's parents have been erased.

> >>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. make deep
> >>   copy
> > 
> > 
> > This is not consistent with the standard library or C++ in general.  It
> > will seem strange that the pointer class
> > 1) Does not require dereferencing
> 
> would you say the same if the class name was spelled 'document_ref'
> instead ?

1 & 4 would be ok, but 3 would stand and having an 'operator bool' would
be added to the list.

> > 3) Has a constructor such as document_ptr( "config.xml" )
> > 4) Has member functions such as write_to_file
> > 
> > The alternative would allow both...
> > 
> > boost::shared_ptr< dom::document > doc( new dom::document() );
> > boost::shared_ptr< dom::document > doc1( doc );
> > dom::document doc2( *doc1 );
> > 
> > and if the 'doc1' reference was non-owning...
> > 
> > dom::document doc();  // Create new doc
> > dom::document & doc1( doc ); // Second reference
> > dom::document doc2( doc1 );  // Deep copy
> 
> right, but given such an approach, what would nodes return in their
> 'parent()' method ?

The parent is always an element (is that right?) so it would return
element_ptr or element_ref.

I feel the correct answer is element_ptr, because, presumably,
root.parent() is null and you can't have a null reference.

You can apply the same logic to doc.root().  If a document can have a
null root then doc.root() should return a pointer.  If it can't then it
should return a reference.

-- 
Hamish Mackenzie <[EMAIL PROTECTED]>

___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

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

[Philip Miller]

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.123456789 but the time_from_string( const
std::string& ) methhod will choke on "Jan".  Is this a bug or a
feature?  I would like a symmetric pair of functions such that the
following code works and t1 == t0.

t1 = time_from_string( to_simple_string( t0 ) )

I appreciate any feedback.

Phil


___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[boost] Re: Draft of new Boost Software License

[Alisdair Meredith]

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 the committee, free from any such restriction.  I'd say it is a
matter for the committee and proposer to reach the appropriate
arrangement.

Of course, this hits problems if someone proposes a library in boost
that they are not the copyright holder for (say boost::array...)

-- 
AlisdairM

___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

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

[Stefan Seefeld]

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 would only be used when a non owning
reference or pointer is required.  Even then you could use
dom::document * and dom::document & instead in most cases.
One big difference between a reference and a pointer is that a reference
must contain a valid non null value.
ok, but are these types really needed ?

My current proposal only provides dom::document_ptr, and I use implicit
refcounting on the underlying document tree. It seems to work quite
fine. I provide a bool operator () that tells me whether the
document_ptr is referring to a document or not.

dom::document_ref doc1; // Error
dom::document_ref doc2( 0 ); // Error
dom::document_ptr doc3; // Ok
dom::document_ptr doc4( 0 ); // Ok
This means you do not have to check references for null values.  A
pointer can be useful if you wish to be able to delay initialisation or
if an value is optional.
void some_function( document_ref doc ); // You must pass a doc
void some_function( document_ptr doc ); // You could pass 0
ok, I can see that as useful.

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. make deep
  copy


This is not consistent with the standard library or C++ in general.  It
will seem strange that the pointer class
1) Does not require dereferencing
would you say the same if the class name was spelled 'document_ref'
instead ?
2) Contains a valid and non null value after default construction
right, see my followup post to that mail.

3) Has a constructor such as document_ptr( "config.xml" )
4) Has member functions such as write_to_file
The alternative would allow both...

boost::shared_ptr< dom::document > doc( new dom::document() );
boost::shared_ptr< dom::document > doc1( doc );
dom::document doc2( *doc1 );
and if the 'doc1' reference was non-owning...

dom::document doc();  // Create new doc
dom::document & doc1( doc ); // Second reference
dom::document doc2( doc1 );  // Deep copy
right, but given such an approach, what would nodes return in their
'parent()' method ?
Regards,
Stefan
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

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

[Hamish Mackenzie]

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 = dom::make_document("1.0");

Hm now

dom::document doc( "1.0" );

looks even nicer :-)

-- 
Hamish Mackenzie <[EMAIL PROTECTED]>

___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[boost] Re: Draft of new Boost Software License

[Alexander Terekhov]

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 other words, if we standardize a boost library, will the library's
> copyright notice have to be in all implementations of that std::lib?

http://digital-law-online.info/lpdi1.0/treatise23.html
http://digital-law-online.info/lpdi1.0/treatise27.html

> Will the copyright need to appear in the standard itself?

Uhmm, why would you care?

regards,
alexander.

___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[boost] Re: Draft of new Boost Software License

[Alexander Terekhov]

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 lawyers (and RedHat's*** too, BTW) would be 
quite happy if you'd adopt the CPL.

***) http://www.redhat.com/legal/patent_policy.html

regards,
alexander.

___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

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

[Paul Mensonides]

> 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 BOOST_PP_VA_.

A bit more on this part, the problem with implementing an algorithm on
top of another algorithm like you do in your code, is that it makes the
algorithm incapable of recursing in contexts where the algorithm calls
some user-defined macro, such as a predicate or operation.

Regards,
Paul Mensonides

___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

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

[Paul Mensonides]

> 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 variadics and placemarkers from the ground up.

> 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 argument lists, including iteration, 
> folds, transform, etc.

1) The Chaos library implements all algorithms generically, so there is
no need to provide a specialized construct for a specific type of data
unless is drastically more efficient to do so.

2) Variadic parameters are actually quite bad for use as a data
structure.  Specifically, the lack the iterative nature of sequences in
certain contexts, the streamable capabilities of purely recursive
structure like lists, and multiple "structures" cannot be passed to the
same macro.  Given variadics, a better structure is a plain tuple,
(__VA_ARGS__).

3) Without well-defined token-pasting, there is no universally sound way
of detecting the last element of a variadic structure.  It is simply
impossible.  The best you can do is either restrict input or use some
type of pathologically unlikely but detectable "end" value.  Detection,
on something that pathological, is expensive.  One other alternative is
to limit the size of the variadic data.  If you do that, than you can
recursively convert each element to any value you want, and the postfix
a different value to indicate the end.  Of course, if the limit is high,
that is again expensive.

Nevertheless, I'll take a look at your code...

Regards,
Paul Mensonides

___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

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

[Hamish Mackenzie]

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 when a non owning
reference or pointer is required.  Even then you could use
dom::document * and dom::document & instead in most cases.

One big difference between a reference and a pointer is that a reference
must contain a valid non null value.

dom::document_ref doc1; // Error
dom::document_ref doc2( 0 ); // Error
dom::document_ptr doc3; // Ok
dom::document_ptr doc4( 0 ); // Ok

This means you do not have to check references for null values.  A
pointer can be useful if you wish to be able to delay initialisation or
if an value is optional.

void some_function( document_ref doc ); // You must pass a doc
void some_function( document_ptr doc ); // You could pass 0

> 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. make deep
>copy

This is not consistent with the standard library or C++ in general.  It
will seem strange that the pointer class
1) Does not require dereferencing
2) Contains a valid and non null value after default construction
3) Has a constructor such as document_ptr( "config.xml" )
4) Has member functions such as write_to_file

The alternative would allow both...

boost::shared_ptr< dom::document > doc( new dom::document() );
boost::shared_ptr< dom::document > doc1( doc );
dom::document doc2( *doc1 );

and if the 'doc1' reference was non-owning...

dom::document doc();  // Create new doc
dom::document & doc1( doc ); // Second reference
dom::document doc2( doc1 );  // Deep copy

Again this makes it clear when reference counting is required by the
design and when it isn't.

> > Yes, you could
> > 1) define a deep copy value_type
> 
> that doesn't work as there is no way to copy nodes 'out of the
> document'.

I am not suggesting we need this but it is possible...
class node
{
  ...
private:
  document doc_;
  node_ptr node_;
};

> > 2) typedef void value_type;
> > 3) leave it undefined

-- 
Hamish Mackenzie <[EMAIL PROTECTED]>

___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

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

[Beman Dawes]

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 seem to have missed a whole bunch of issues "surrounding" 
implied
>>  >patent license.
>>
>> THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS 

>OR
>> IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF 
MERCHANTABILITY,
>> FITNESS FOR A PARTICULAR PURPOSE, TITLE AND NON-INFRINGEMENT.
>>^^
>>
>> If I understand correctly, "TITLE AND NON-INFRINGEMENT" are basically
>legal
>> code-words which covers a vast range of issues such as ownership,
>patents,
>> trade secrets, etc.
>
>That's a disclaimer basically saying "do your own patent search", etc.

Yes, among other things.

>I'm talking about contributions from companies like IBM (my employer)
>that do have a whole bunch of patents to worry about... I mean, for
>example, enforcement right despite deliberate contribution that would
>"infringe" some contributor's patent(s).
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.

There are certainly legal issues with regards to contributions, but those 
issues are being dealt with separately. They appear to be separate from 
issues regarding the license.

Thanks,

--Beman

___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

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

[Josh Dybnis]

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 argument
lists, including iteration, folds, transform, etc.

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 BOOST_PP_VA_.

Here is an example of some of the definitions:

/* constructors for the old preprocessor data structures */
#define BOOST_PP_VA_TUPLE(...) (__VA_ARGS__)

#define BOOST_PP_VA_ARRAY(...) \
(BOOST_PP_VA_SIZE(__VA_ARGS__), (__VA_ARGS__))

#define BOOST_PP_VA_SEQ(...) \
BOOST_PP_VA_FOR_EACH(BOOST_PP_VA_TUPLE, __VA_ARGS__)

#define BOOST_PP_VA_LIST(...) \
BOOST_PP_VA_FOLD_RIGHT(BOOST_PP_VA_LIST_OP, BOOST_PP_NIL,
__VA_ARGS__)

#define BOOST_PP_VA_LIST_OP(a, b) (b, a)

BOOST_PP_VA_ARRAY(a, b, c) === (3, (a, b, c))
BOOST_PP_VA_SEQ(a, b, c) === (a)(b)(c)
BOOST_PP_VA_LIST(a, b, c) === (a, (b, (c, BOOST_PP_NIL)))

I've put the rest of the implementation at
http://groups.yahoo.com/group/boost/files/PP_VA/

Of course this requires compiler support of the C99 __VA_ARGS__
facility.

-Josh Dybnis



___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[boost] local copy of the date_time doxygen reference manual

[Philip Miller]

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 there a way for me to get a local copy of the date_time reference
manual?  If not, since we have the source, could I get the script(s)
needed to generate the reference manual?

I appreciate any help!

Phil


___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[boost] Re: compose_f_gxy_hxy

[Daniel Frey]

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 compose_f_gxy_hxy. 
The standard is moving towards 'bind' -
http://std.dkuug.dk/jtc1/sc22/wg21/docs/papers/2003/n1455.htm.
If we take bind into account here, we could just as well remove
compose.hpp completly, couldn't we? 
We might, in a couple of years. Seriously, 'bind' is superior here; it
takes some learning to switch over from the 'compose_*' family, but it's
worth it.
Well, I'm already using the lambda-library, so I'm no longer bound to 
compose_*. I just thought that completing compose.hpp might be a good 
idea. But if it's deprecated, this doesn't really make sense. Never 
mind... :)

Regards, Daniel

--
Daniel Frey
aixigo AG - financial training, research and technology
Schloß-Rahe-Straße 15, 52072 Aachen, Germany
fon: +49 (0)241 936737-42, fax: +49 (0)241 936737-99
eMail: [EMAIL PROTECTED], web: http://www.aixigo.de
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

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

[Stefan Seefeld]

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 to be created.
Then the default constructor can just create an empty pointer.
dom::document_ptr doc(document); // create second reference to it
dom::document_ptr doc2 = document.clone(); // clone it, i.e. make deep
Stefan

___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

RE: [boost] Re: compose_f_gxy_hxy

[Aleksey Gurtovoy]

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 compose_f_gxy_hxy. 

The standard is moving towards 'bind' -
http://std.dkuug.dk/jtc1/sc22/wg21/docs/papers/2003/n1455.htm.

> If we take bind into account here, we could just as well remove
> compose.hpp completly, couldn't we? 

We might, in a couple of years. Seriously, 'bind' is superior here; it
takes some learning to switch over from the 'compose_*' family, but it's
worth it.

Aleksey
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

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

[Stefan Seefeld]

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 should return a proxy
object.  Something like...
that's what it does indeed.


// non owning reference
class document_ref
{
public:
  // Define document related methods here
protected:
  document_ref() : raw_( 0 ) {}
  xmlDoc * raw_;
};
// non owning pointer
class document_ptr
{
public:
  document_ptr( document_ref * );
  document_ref operator *() { return ref_; }
  document_ref * operator ->() { return &ref_; }
private:
  document_ref ref_;
};
// owning object with deep copy
class document : public document_ref
{
public:
  explicit document( const std::string & file );
  document( document_ref source )
  {
// Deep copy here
  }
  ~document() { xmlFreeDoc( raw_ ); }
};
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.
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. make deep
  copy
root->document() can return document_ptr or document_ref.
indeed, that's what it does.



value_types could exist but it would require a deep copy to be
consistent.  If you do want to define it then I suggest
you mean if I do *not* want to define it ?


Yes, you could
1) define a deep copy value_type
that doesn't work as there is no way to copy nodes 'out of the
document'.
2) typedef void value_type;
3) leave it undefined

Your iterator types look good.  Why is there an extra level of
indirection in basic_element_const_iterator?
the const iterator is non-functional right now. I'v been wondering
how to provide one. It seems I would need to define a 'const_node_ptr'
set of classes.


I think that is right.  I would prefer it to be

typedef node_pointer< node_ref > node_ptr;
typedef node_pointer< const_node_ref > const_node_ptr;
In fact you will probably need const_ versions for all your reference,
pointer and iterator types. Though the pointers and iterators should
just be additional instances of template classes.
yes

Stefan



___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

RE: [boost] compose_f_gxy_hxy

[Aleksey Gurtovoy]

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 changes: http://lists.boost.org/mailman/listinfo.cgi/boost

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

[Hamish Mackenzie]

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
protected:
  document_ref() : raw_( 0 ) {}
  xmlDoc * raw_;
};

// non owning pointer
class document_ptr
{
public:
  document_ptr( document_ref * );
  document_ref operator *() { return ref_; }
  document_ref * operator ->() { return &ref_; }
private:
  document_ref ref_;
};

// owning object with deep copy
class document : public document_ref
{
public:
  explicit document( const std::string & file );
  document( document_ref source )
  {
// Deep copy here
  }
  ~document() { xmlFreeDoc( raw_ ); }
};

root->document() can return document_ptr or document_ref.

> > value_types could exist but it would require a deep copy to be
> > consistent.  If you do want to define it then I suggest
> 
> you mean if I do *not* want to define it ?

Yes, you could
1) define a deep copy value_type
2) typedef void value_type;
3) leave it undefined

> > Your iterator types look good.  Why is there an extra level of
> > indirection in basic_element_const_iterator?
> 
> the const iterator is non-functional right now. I'v been wondering
> how to provide one. It seems I would need to define a 'const_node_ptr'
> set of classes.

I think that is right.  I would prefer it to be

typedef node_pointer< node_ref > node_ptr;
typedef node_pointer< const_node_ref > const_node_ptr;

In fact you will probably need const_ versions for all your reference,
pointer and iterator types. Though the pointers and iterators should
just be additional instances of template classes.

-- 
Hamish Mackenzie <[EMAIL PROTECTED]>

___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[boost] Re: Draft of new Boost Software License

[Alexander Terekhov]

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 
authorization of the owner(s) of the copyright in the original work. The 
distinction between idea and expression may be difficult and in order to 
understand recursion you must first understand recursion. IANALBIPOOTN.

regards,
alexander.

___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[boost] Re: compose_f_gxy_hxy

[Russell Hind]

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 was this your suggestion?

I thought bind was the preferred method over compose now.  This lead me 
to believe that compose was left in for backwards compatibility.  I 
haven't actually used compose, so don't know if there are things it can 
do that bind doesn't, mind you.

Thanks

Russell

___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: [boost] Draft of new Boost Software License

[Howard Hinnant]

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 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?

-Howard

___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: [boost] Cvs trouble

[Vladimir Prus]

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 with main boost repository. All pserver accesses and 
ViewCVS accesses go to backup server. As some document on sourceforce says, 
the performance of hardware that they have is not enough to serve all acesses 
from main server.

- Volodya



___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: [boost] Cvs trouble

[Rene Rivera]

[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 others with both :ext: and :pserver: access confirm this ?
>(I must be doing soth wrong here because this is too crazy but there are
>no branches, I've updated using '-APCd' and all )

SF switched to using a cached version of CVS for anoncvs access some time
ago. I think it was part of their restructuring to reduce anon access
slowing down developer access.


-- grafik - Don't Assume Anything
-- rrivera (at) acm.org - grafik (at) redshift-software.com
-- 102708583 (at) icq
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: [boost] Cvs trouble

[Martin Wille]

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 :ext: and :pserver: access confirm this ?
(I must be doing soth wrong here because this is too crazy but there are
no branches, I've updated using '-APCd' and all )
On their website they write:

  In the mean time, the following steps will be taken by SourceForge.net
  staff: developer (SSH) CVS access will not be changed; pserver-based
  CVS access from the project shell servers (i.e. from cron jobs) will
  not be changed, but the overall cap of pserver connections from the
  shell will be lowered to a more reasonable level; pserver-based CVS
  access from external hosts (i.e. not the project shell server) will be
  served against the backup CVS server, which contains data roughly 24
  hours older than that on the primary CVS server
and:

  These measures are temporary and will be removed pending the
  successful completion of our work to improve performance on the
  primary CVS server.
See http://sourceforge.net/docman/display_doc.php?docid=2352&group_id=1
for the full text.
Regards,
m
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

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

[Stefan Seefeld]

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 the means to walk up towards the document root.


And yet it does not keep it's parent() alive.  How is that consistent?  

In what way would you be unable to walk toward the document if it was
not add reffed?
dom::node_ptr root;
{
  dom::document_ptr = document("foo.xml");
  root = document.root_node();
}
at this point document would go out of scope and so the tree would
be destructed, making root invalid. With root holding a reference
to the document it is not, and the following will work:
dom::document_ptr document = root.document();
// continue here...
[...]

With the implicit add ref it is hard to tell what the intent of the code
is.  Your example illustrates this problem well, but consider this
simpler version
yes, letting the user explicitely manage the document would be the alternative.
I'm not sure that nodes referencing their document is less clear, though.
{
xml::document_ptr doc( "config.xml" );
some_function( doc->root_node() );
}
I cannot tell what the writer intended the scope of doc to be without
examining some_function and understanding what it does.  It might add
ref the document it might not.
What about the relationship between the document and dom::document_ptr ?
So even if 'doc' (a document pointer) is limitted, the callee could
set its own member
some_function(dom::node_ptr node)
{
  my_doc = node->document()
}
and just by looking at the API it is not clear that the 'doc'
variable above is really the master document pointer. Being
able to write things like
dom::document_ptr doc("config.xml");
dom::document_ptr doc2(doc);
somehow suggests that either the document is not managed by
dom::document_ptr at all, or by all of them (and thus by
extension by dom::node_ptr)
[...]

Here is the analogy I think works best...

container --> document
container::value_type --> node
container::iterator --> node_iterator
container::pointer_type --> node_pointer
container::reference_type --> node_reference
hmm, that makes it look simpler than it actually is: is there really
a single 'value_type' ?


True you need attribute_, element_ etc. variations which you already
have.
value_types could exist but it would require a deep copy to be
consistent.  If you do want to define it then I suggest
you mean if I do *not* want to define it ?

typedef void value_type;


Your iterator types look good.  Why is there an extra level of
indirection in basic_element_const_iterator?
the const iterator is non-functional right now. I'v been wondering
how to provide one. It seems I would need to define a 'const_node_ptr'
set of classes.
Regards,
Stefan
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[boost] Cvs trouble

[Toon Knapen]

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: access confirm this ?
(I must be doing soth wrong here because this is too crazy but there are
no branches, I've updated using '-APCd' and all )


RCS file:
/cvsroot/boost-sandbox/boost-sandbox/boost/numeric/bindings/traits/type.
h,v
Working file: type.h
head: 1.3
branch:
locks: strict
access list:
symbolic names:
keyword substitution: kv
total revisions: 3; selected revisions: 3
description:

revision 1.3
date: 2003/06/23 16:12:01;  author: tknapen;  state: Exp;  lines: +20 -2
new type conversions

revision 1.2
date: 2003/06/03 14:38:28;  author: tknapen;  state: Exp;  lines: +9 -4
made include guards uppercase

revision 1.1
date: 2002/10/25 20:42:28;  author: tknapen;  state: Exp;
another rework by Kresimir

=



RCS file:
/cvsroot/boost-sandbox/boost-sandbox/boost/numeric/bindings/traits/type.
h,v
Working file: type.h
head: 1.2
branch:
locks: strict
access list:
symbolic names:
keyword substitution: kv
total revisions: 2; selected revisions: 2
description:

revision 1.2
date: 2003/06/03 14:38:28;  author: tknapen;  state: Exp;  lines: +9 -4
made include guards uppercase

revision 1.1
date: 2002/10/25 20:42:28;  author: tknapen;  state: Exp;
another rework by Kresimir

=


___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[boost] Re: compose_f_gxy_hxy

[Daniel Frey]

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 
here, we could just as well remove compose.hpp completly, couldn't we? 
Or was this your suggestion?

Regards, Daniel

--
Daniel Frey
aixigo AG - financial training, research and technology
Schloß-Rahe-Straße 15, 52072 Aachen, Germany
fon: +49 (0)241 936737-42, fax: +49 (0)241 936737-99
eMail: [EMAIL PROTECTED], web: http://www.aixigo.de
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

RE: [boost] Draft of new Boost Software License

[Matt Hurd]

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 is wonderful to have great work like boost at the
finger tips.

"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.

>When you cut-and-paste a bit of copyrighted code into your own code,
you've
>created a derived work of the copyrighted code. That's the way
copyright
>law works, even if your code is really large and the cut-and-paste
>copyright code is fairly trivial. (Under some circumstances copying a
small
>portion can be considered "fair use", but that is starting to drift
>off-topic.)

If a work is a derivate work and you do redistribute, sell or otherwise
license your own proprietary _source_ what is the impact of including
the following statement?
__

Permission is hereby granted, free of charge, to any person or
organization 
obtaining a copy of the software covered by this license (the
"Software") 
to use, reproduce, display, distribute, execute, and transmit the
Software, 
and to prepare derivative works of the Software, and to permit 
third-parties to whom the Software is furnished to do so, all subject to

the following
__

If I have the desire to license source code, which uses boost code, to a
third party, on the basis that my code may not be redistributed then
this statement confuses the issue if I am a derivative work.

For example, I build a risk system for an asset manager.  I use some
boost, perhaps modified.  I include the license as required... and I get
confused trying to separate the consequences in a contract with the
third party.  I had one such messy contract that took over a year to
resolve to mutual agreement :-(

Perhaps this is a non issue as the issue may exist for alternative
licenses.  

If you desire to have your derivative work under a different umbrella
for source distribution then the issue seems significant to me.

Cheers,

Matt.

PS:  does #include  make you a derived work?


___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[boost] Re: Interest in FC++?

[Dirk Gerrits]

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) If there is interest, what-all needs to be changed with the FC++ 
 library to make it meet the standards of Boost.

With regards to (1), I hope yes, but the Boost Lambda Library has a bit
of conceptual overlap with FC++, so I can imagine this issue being
potentially contentious.  (FC++ and Lambda ostensibly provide much of the
same kinds of functionality, but while there is overlap, each library
does a lot of "its own thing" too.  I (and Jaakko too, probably) can say
more about this if necessary.)
With regards to (2), I have been reading all the stuff on the Boost web 
site regarding submissions, and so I am aware of a number of issues, 
including:
 - 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
  this.
I agree. While FC++ probably would bring in a lot of new stuff, there is 
*considerable* overlap with Boost's current libraries.
On the function side there's: bind, mem_fn, compose, function, 
functional, and of course lambda. And then there are smart_ptr, mpl, and 
preprocessor.

Reusing will probably make the implementation a lot cleaner, potentially 
more robust, and ...

 - Documentation: as of yet, there is no good singular "users guide" for
  FC++ aimed at the audience of C++ programmers; I'd need to write 
  one.
... you won't have to re-document the things that Boost already provides. ;)

 - Naming conventions: FC++ uses a naming convention other than Boost's
  (including systematically using capital letters in identifiers).
From what I have been able to tell in such a short time, the 'camel 
hump notation' is mostly used in the implementation and only slightely 
so in the interface. For example, things like Fun0, Fun0Impl, ... are no 
problem because you want to reuse Boost's facilities for these anyway. 
And the functiods are already 'properly' named in lowercase. Of course, 
there is some work to be done here, but I don't think it would be a big 
problem, do you?

But at this point I'm probably already getting ahead of myself.  So I'll
stop talking and ask people to comment with regards to "interest" in
FC++.
I'd have to look deeper into it, for which I don't have the time at the 
moment because I'm right in the middle of my exams. But from what I've 
seen so far, it's pretty cool!

Regards,
Dirk Gerrits
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[boost] [Signals] BCB patchlet

[Malte Starostik]

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&)
 {
+#ifdef __BORLANDC__
+# pragma option push -w-8013
+#endif
   typename BOOST_SIGNALS_NAMESPACE::detail::get_slot_tag::type
tag;
   return tag;
+#ifdef __BORLANDC__
+# pragma option pop
+#endif
 }

   } // end namespace BOOST_SIGNALS_NAMESPACE

Regards,
-Malte

___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: [boost] compose_f_gxy_hxy

[Peter Dimov]

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: http://lists.boost.org/mailman/listinfo.cgi/boost

[boost] Re: Draft of new Boost Software License

[Alexander Terekhov]

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 Gore

 In a dramatic move, SCO today filed suit against Al Gore 
 alleging misappropriations of trade secrets and unfair 
 competition for inventing the Internet. SCO Executive 
 Chris Sontag was quoted as saying "This internet thing 
 is a Unix derivative and our contracts from AT&T clearly 
 give us all IP rights to Unix derivatives. What Al Gore 
 did is to transfer our rights to the world. Our lawsuit 
 is aimed at preserving our intellectual property rights." 

 When asked if he was on crack, Sontag replied, "No, I'm 
 on SCO, but crack is clearly a derivative of Unix and we 
 intend to sue the Colombian cocaine cartel next."."

  -- bryan_w_taylor, SCOX board at yahoo

___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[boost] Re: Draft of new Boost Software License

[Alexander Terekhov]

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 "surrounding" implied
>  >patent license.
> 
> THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
> IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> FITNESS FOR A PARTICULAR PURPOSE, TITLE AND NON-INFRINGEMENT.
>^^
> 
> If I understand correctly, "TITLE AND NON-INFRINGEMENT" are basically legal
> code-words which covers a vast range of issues such as ownership, patents,
> trade secrets, etc.

That's a disclaimer basically saying "do your own patent search", etc. 
I'm talking about contributions from companies like IBM (my employer) 
that do have a whole bunch of patents to worry about... I mean, for 
example, enforcement right despite deliberate contribution that would
"infringe" some contributor's patent(s). Consider:

http://www.ohjelmisto.org/Legal_Aspects_of_OpenSource.PDF


The Patent Issue

- Patents implicitly licensed, to what extent?

- Even worse: what if patents are not licensed?

- GPL and exhaustion of certain exclusive
  distribution rights of the patent holder...

- General misperception that relevance only for
  the "bad software patents" like Amazon "one-
  click"-patent

- Problem of "leak out" of patent licenses
  through contributions

- Reason for "mushrooming" of new licenses like
  Mozilla License, IBM licenses, Nokia OpenSource 
  license (NOKOS)



regards,
alexander.

--
http://europa.eu.int/comm/internal_market/en/indprop/comp/eicta.pdf

Uhmm, ...

"New SCO Press Release
 by: martin_lvnv 
 
 For Immediate Release:

 SCO has determined through further research that even IBM mainframes 
 use propriety SCO methods and concepts without a license. Since almost 
 all computer software derives from unix, and mainframes use software, 
 we have determined that IBM mainframes use SCO IP. SCO hereby declares 
 them all "illegal" and demands they be unplugged.

 IBM mainframes use "usernames" and "passwords", concepts that were 
 proprietary to SCO since they were in used the oldest version of SYSV 
 unix. We were surprised to find IBM has been using these concepts 
 without license since before SCO was even incorporated. Misuse dates 
 back to some of IBMs earliest computers in the 1950s. 

 "We knew IBM had been transferring SCO technology from sys V Unix to 
 Linux" stated SCO CEO Daryl MacBride "but we didn't realize they were 
 transferring the technology to MVS, IBMs mainframe operating system 
 too". SCO will be asking for damages going all the way back to the 
 dawn of the computer era in the 1950s. It seems all of IBMs success 
 over the decades has been from stealing SCO IP, so we're going to sue 
 them for every dime they ever made. And then double it for punitive 
 damages.

 Asked to comment on the new allegations, an IBM spokesman responded 
 "Blow Me".

 In other news SCO announces the licensing of the "username" and 
 "password" concepts to Microsoft. A Microsoft spokesman admitted: 
 "We thought we stole it from IBM or Apple or acquired in from some 
 company we crushed. As soon as we determined it was SCO's 
 legitimate IP, we licensed these important concepts".

 Including Microsofts one time license fee of $84 million dollars, 
 SCO announced they turned a small profit this quarter. "

-- SCOX board at yahoo

___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

RE: [boost] Interest in FC++?

[Paul A. Bristow]

| -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 Boost.  

This has got to be interesting.

Paul
Paul A Bristow, Prizet Farmhouse, Kendal, Cumbria, LA8 8AB  UK
+44 1539 561830   Mobile +44 7714 33 02 04
Mobile mailto:[EMAIL PROTECTED]
mailto:[EMAIL PROTECTED]
 
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

RE: [boost] Draft of new Boost Software License

[Paul A. Bristow]

| -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 impression I got is that it's somewhat hard to parse as it is.
|
| The second paragraph is long; and without any separators other than the commas
it's
| hard to read.
|
| Here's an edited version which might be better for non-english readers to
| understand:
|
| 
| Permission is hereby granted ...

| all derivative works of the Software. Unless such copies or derivative works
| are solely in the form of machine-executable object code generated by a
| source language processor.

As someone whose first language really is english - unlike the majority of
ex-colonial Boosters :-))

I really must protest that the last 'sentence' isn't one!

Seriously, overall I think this is excellent.

It isn't meant to be read by human beings, only lawyers - and they are used to
this stuff.

And:

//  (C) Jane Programmer, 2003
//   See www.boost.org/license for license terms and conditions
//   See www.boost.org/libs/janes-lib for documentation

Looks fine to me, though I prefer "Copyright" to (C)

Paul

Paul A Bristow, Prizet Farmhouse, Kendal, Cumbria, LA8 8AB  UK
+44 1539 561830   Mobile +44 7714 33 02 04
Mobile mailto:[EMAIL PROTECTED]
mailto:[EMAIL PROTECTED]

___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[boost] Re: Draft of new Boost Software License

[Daniel Frey]

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 copyright, license, etc, reproduction requirement only applies to 
any Boost software, not any non-Boost portions. It doesn't matter what 
form the non-Boost portions are in; they aren't covered by the license.

The inclusion of the "of the Software" phrase prevents the problem you 
are worried about AFAICS.
Well, I hope so. I'm not a lawyer, so I can't decide. Personally, I 
think I understood and respect the spirit and boost and I don't fear to 
be sued. The problem is that lawyers have to accept it, but I think your 
interpretation of "the Software" should tame them. Thanks for clarifying.

Regards, Daniel

--
Daniel Frey
aixigo AG - financial training, research and technology
Schloß-Rahe-Straße 15, 52072 Aachen, Germany
fon: +49 (0)241 936737-42, fax: +49 (0)241 936737-99
eMail: [EMAIL PROTECTED], web: http://www.aixigo.de
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

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

[Hamish Mackenzie]

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 not expect a pointer to have any
members other than those for managing the pointer. 

Plus a reference should never be null.

See my other post on how to make both pointers and references.

-- 
Hamish Mackenzie <[EMAIL PROTECTED]>

___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

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

[Hamish Mackenzie]

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 up towards the document root.

And yet it does not keep it's parent() alive.  How is that consistent?  

In what way would you be unable to walk toward the document if it was
not add reffed?

> Imagine a factory object that is initialized with a dom::node_ptr
> (holding configurational data, say). Whenever you access its method,
> the object looks up data in the node...
> 
> 
> class factory
> {
> public:
>factory(dom::node_ptr n) : my_node(n) {}
>foo create_foo(); /* access my_node */
>bar create_bar(); /* access my_node */
> private:
>dom::node_ptr my_node;
> };
> 
> factory 'owns' the node, so whereever you instantiate the factory,
> you'd read in a dom::document, look up the relevant node, and pass
> that to the constructor:
> 
> factory *f;
> {
>dom::document_ptr document("config.xml");
>dom::node_set set = document.root_node().find("//factory.info");
>f = new factory(set[0]);
> } // document and set are now deleted, but factory still references
>// the document through its 'my_node' member
> 
> 
> If the document wasn't ref-counted, you'd need to pass it along with
> the node to the factory, as only the factory would know when to drop
> it (in its destructor, presumably).

One of the following should be ok...

// Each factory has its own document
class factory : boost::noncopyable
{
public:
  factory( ... );
private:
  dom::node_ptr node_;
  std::auto_ptr< dom::document > doc_;
};

// They share documents
class factory
{
public:
  factory( ... );
private:
  dom::node_ptr node_;
  std::shared_ptr< dom::document > doc_;
};

// All factories use the same document
class factory_ref
{
private:
  factory_ref( dom::node_ptr node ) : node_( node )
  {
  }
  dom::node_ptr node_;
  friend class factories;
};

class factories : boost::noncopyable
{
public:
  factory_ref get_factory( ... );

private:
  std::auto_ptr< dom::document > doc_;
};

By making the user manage the document object it forces them to consider
which of these models they want.

With the implicit add ref it is hard to tell what the intent of the code
is.  Your example illustrates this problem well, but consider this
simpler version

{
xml::document_ptr doc( "config.xml" );
some_function( doc->root_node() );
}

I cannot tell what the writer intended the scope of doc to be without
examining some_function and understanding what it does.  It might add
ref the document it might not.

Now without the add ref stuff we could have 

{
xml::document doc( "config.xml" );
some_function( doc->root_node() );
}

and

{
std::auto_ptr< xml::document > doc( new xml::document( "config.xml" ) );
some_function( doc, doc->root_node() );
}

Now we know if some_function is allowed to extend the life of the
document or not.

> > Here is the analogy I think works best...
> > 
> > container --> document
> > container::value_type --> node
> > container::iterator --> node_iterator
> > container::pointer_type --> node_pointer
> > container::reference_type --> node_reference
> 
> hmm, that makes it look simpler than it actually is: is there really
> a single 'value_type' ?

True you need attribute_, element_ etc. variations which you already
have.

value_types could exist but it would require a deep copy to be
consistent.  If you do want to define it then I suggest

typedef void value_type;

Along with an explanation.  That way if I write

node_iterator::value_type temp( *i ); // Make a copy for later
(*i).some_non_const_function();

I would get a compiler error rather than a nasty surprise when I use
temp.

> Is there really a single iterator ? (iterating 
> over all child nodes of a given parent and iterating over all attributes
> is not the same)

Your iterator types look good.  Why is there an extra level of
indirection in basic_element_const_iterator?

> Also, what is a node_reference (as opposed to a pointer) ?
If you renamed your _ptr classes as _ref or _reference and replace _ptr
with instances of basic_node_pointer.  (Make basic_node_pointer by
taking basic_element_iterator and stripping the ++ and -- operators).

Then some_pointer->x() and some_iterator->x() would call the same x()
member of the _reference class.

-- 

Hamish Mackenzie <[EMAIL PROTECTED]>

___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost