[boost] minor nitpick: why signal.hpp instead of signals.hpp? (notext)
___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] boost::signal patch
At the top of signal.hpp:
namespace boost {
#ifndef BOOST_NO_TEMPLATE_PARTIAL_SPECIALIZATION
namespace BOOST_SIGNALS_NAMESPACE {
namespace detail {
templateint Arity,
typename Signature,
typename Combiner,
typename Group,
typename GroupCompare,
typename SlotFunction
struct real_get_signal_impl;
MSVC 7.1 complains: warning C4099:
'boost::signals::detail::real_get_signal_impl0,T1,T2,T3,T4,T5' : type
name first seen using 'struct' now seen using 'class'
at several later points in the same file. These can all be removed by
changing struct to class in the declaration quoted above.
Dave
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Updated Boost.Random to TR proposal
On Monday 07 July 2003 05:06 pm, Jens Maurer wrote: I've updated the current Boost.Random CVS to the interface contained in the C++ library TR proposal: http://std.dkuug.dk/jtc1/sc22/wg21/docs/papers/2003/n1452.html The boost documentation has not yet been updated, I hope to be able to do that later this week. Reading the TR proposal should give you a sufficient idea. There have been various suggestions for changes from C++ committee members, so additional (but minor) interface changes may happen after the October 2003 meeting. Just one quick question: It is vital that variate generators can hold references to engines in order to share a single engine instance, and thus guarantee independence between variate generators. The proposal supports this? ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Updated Boost.Random to TR proposal
On Monday 07 July 2003 05:06 pm, Jens Maurer wrote:
I've updated the current Boost.Random CVS to the interface
contained in the C++ library TR proposal:
http://std.dkuug.dk/jtc1/sc22/wg21/docs/papers/2003/n1452.html
The boost documentation has not yet been updated, I hope to be able
to do that later this week. Reading the TR proposal should give
you a sufficient idea.
There have been various suggestions for changes from C++
committee members, so additional (but minor) interface changes
may happen after the October 2003 meeting.
I would also like to suggest one addition that is very useful. It is very
common in communications to need a generator that produces a 1-bit sequence.
#ifndef pnseq_generator_H
#define pnseq_generator_H
#include boost/random.hpp
namespace boost
{
namespace random
{
template class RandomNumberGenerator
class pnseq_generator
{
public:
typedef pnseq_generatorRandomNumberGenerator self_type;
typedef RandomNumberGenerator base_type;
typedef bool result_type;
BOOST_STATIC_CONSTANT( bool, has_fixed_range = true );
BOOST_STATIC_CONSTANT( result_type, min_value = false );
BOOST_STATIC_CONSTANT( result_type, max_value = true );
result_type min() const
{ return min_value; }
result_type max() const
{ return max_value; }
explicit pnseq_generator (base_type rng)
: rng_( rng ), count_()
{ init(); }
template typename T
void seed( T s )
{ rng_.seed( s ); init(); }
result_type operator()()
{
bool const bit = cache_ 1;
cache_ = 1;
if ( --count_ = 0 )
init();
return bit;
}
bool validation( result_type x ) const
{ return valid == x; }
friend bool operator ==( self_type const x, self_type const y )
{
return x.rng_ == y.rng_ x.cache_ == y.cache_
x.count_ == y.count_;
}
friend bool operator !=( self_type const x, self_type const y )
{ return !(x == y); }
private:
typedef typename base_type::result_type cache_type;
void init()
{
cache_ = rng_();
count_ = std::numeric_limitscache_type::digits;
}
base_type rng_;
cache_type cache_;
int count_;
}; // boost::random::pnseq_generator
} // random
} // boost
#endif
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Interest in multiindex_set?(again)
At 06:25 PM 7/7/2003, =?windows-1252?Q?JOAQUIN_LOPEZ_MU=3FZ?= wrote: Hi Beman, - Mensaje Original - [...] * The multiindex_set name seems awkward to me. Maybe indexed_set or set_index? I don't like the name either, and would be happy if someone comes with something better. Nevertheless, I don't think indexed_set is a good choice: when picking up a name another one must be chosen for the associated namespace (and it is convenient that these two are not the same, for reasons explained vg in Boost.Tuple docs). I chose multiindex_set/multiindex. The analogous indexed_set/index does not fit: index is too broad a denomination for the namespace. I'm more interested in the class name than the namespace name. One problem at a time. If you weren't worrying about the namespace name, would you then like indexed_set as the class name? What are some other alternatives? A related question: Should boost::multiindex::multiindex_set be raised into Boost namespace as boost::multiindex_set (or whatever its final name)? Seems the standard practice, but I think it is safer to ask first. Yes, I think so. It is a bit of a judgement call, but since the library is a very general purpose tool, and assuming the library only adds a few names to the namespace it lives in, I'd rather see it in namespace boost. Others may disagree; a lot of people like tall and deep namespace hierarchies even when the components are very general purpose. typedef boost::multiindex::multiindex_set employee, boost::tuple unique employee::comp_id , non_unique employee::comp_name , unique employee_name::comp_ssnumber , employee_set; This is definitely a good idea, Fernando also hinted at symplifing the specification of unique/non-unique indices. Any suggestion on how to implement it? With two templates for unique and non-unique indices the thing is simple; it is not as simple when only one class is marked. Suggestions here are most welcome. I don't see any acceptable (non-invasive) way to implement marking only one class. But the unique/non_unique two template approach seems perfectly acceptable. You could even argue that it forces the user to consciously make the critical unique/non_unique decision for each index, so may reduce user error. [...] * It isn't clear (or I missed it) if iterators are always logically const-iterators or not. In other words, could your example have been written like this? typedef index_typeemployee_set,1::type employee_set_by_name; employee_set_by_name i=es.get1(); employee_set_by_name::iterator it=i.find(Anna Jones); it-name=Anna Smith; //she just got married to Calvin Smith No it couldn't. Iterators and const_iterators (which incidentally are the same) behave logically as const-iterators, just the same as in STL sets. update() has been carefully crafted so that strong exception-safety is provided: for that, it is necessary that a copy of the element is provided instead of allowing some sort of in-place modification of the element. This is discussed in some detail with Fernando somewhere up this thread. I understand the rationale for that, but am still concerned. There are many applications where the cost of a copy to apply a minor update is prohibitive. The user is then forced to add a layer of indirection, or use a home-made container. Ugh. This is one of the few cases I run into where a safe design is so inefficient compared to a traditional unsafe design that in real production code I might be forced to use the unsafe design. That makes me uncomfortable. Thanks for your interest. If no objection is raised I plan to submit the library for pre-formal review in a couple of weeks. Good! --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Updated Boost.Random to TR proposal
On Tuesday 08 July 2003 08:01 am, Neal D. Becker wrote:
On Monday 07 July 2003 05:06 pm, Jens Maurer wrote:
I've updated the current Boost.Random CVS to the interface
contained in the C++ library TR proposal:
http://std.dkuug.dk/jtc1/sc22/wg21/docs/papers/2003/n1452.html
The boost documentation has not yet been updated, I hope to be able
to do that later this week. Reading the TR proposal should give
you a sufficient idea.
There have been various suggestions for changes from C++
committee members, so additional (but minor) interface changes
may happen after the October 2003 meeting.
I would also like to suggest one addition that is very useful. It is very
common in communications to need a generator that produces a 1-bit
sequence.
After some reflection, I think a somewhat more generalized version might be
even better. This one can produce sequences of n-bit rather than only 1-bit.
I'm not sure what to do with max_value and min_value. It depends on
interpretation- whether you intend to sign extend the values and interpret
them as signed or zero extend and interpret as unsigned.
#ifndef pnseq_generator_H
#define pnseq_generator_H
#include boost/random.hpp
namespace boost
{
namespace random
{
template class RandomNumberGenerator, int width=1
class pnseq_generator
{
public:
typedef pnseq_generatorRandomNumberGenerator self_type;
typedef RandomNumberGenerator base_type;
typedef int result_type;
BOOST_STATIC_CONSTANT (bool, has_fixed_range = true);
BOOST_STATIC_CONSTANT (result_type, min_value = 0);
BOOST_STATIC_CONSTANT (unsigned int, max_value = ~(unsigned(-1)
width));
BOOST_STATIC_CONSTANT (int, mask = ~(unsigned(-1) width));
result_type min() const
{ return min_value; }
result_type max() const
{ return max_value; }
explicit pnseq_generator (base_type rng)
: rng_( rng ), count_()
{ init(); }
template typename T
void seed( T s )
{ rng_.seed( s ); init(); }
result_type operator()()
{
int const bits = cache_ mask;
cache_ = width;
if ( --count_ = width-1 )
init();
return bits;
}
bool validation( result_type x ) const
{ return valid == x; }
friend bool operator ==( self_type const x, self_type const y )
{
return x.rng_ == y.rng_ x.cache_ == y.cache_
x.count_ == y.count_;
}
friend bool operator !=( self_type const x, self_type const y )
{ return !(x == y); }
private:
typedef typename base_type::result_type cache_type;
void init()
{
cache_ = rng_();
count_ = std::numeric_limitscache_type::digits;
}
base_type rng_;
cache_type cache_;
int count_;
}; // boost::random::pnseq_generator
} // random
} // boost
#endif
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Visitor-based framework to describe classes with exampleofobjectdump in XML format
David Abrahams wrote:
A problem with this is that the introspection information is only
available at runtime. A more-flexible system would use GCC-XML output
to generate something like:
template
struct class_Driver
{
typedef mpl::vectorPerson bases;
typedef mpl::vector
memberint Driver::*, Driver::licence_id
, memberDate Driver::*, Driver::licence_issue_date
, membervoid (Driver::*)(), Driver::accelerate
members;
...
};
So all the introspection information could be available at
compile-time.
Sometimes it's fine to have an introspection only at runtime. I just want to
avoid duplications of class descriptions by multiple libraries. For
example, Python and luabind could share common introspection information.
This is why I'm using visitors. Every intronspection elelemnt has
correspondent node that can be visited. The challenge is to build a
complete set of nodes with a complete set of operations.
--
Alexander Nasonov
Remove minus and all between minus and at from my e-mail for timely response
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: test_fp_comparisons and rounding errors
At 05:54 PM 7/7/2003, Rozental, Gennadiy wrote: A half-way solution is to have something like: BOOST_CHECK_EQUAL_NUMBERS(x,y,IsEqual) and let users specify their own Preciates. There is BOOST_CHECK_PREDICATE By default, the Test library could provide a straight-forward ABSOLUTE-ERROR comparator: By default, the Test library provides relative error comparator, which is according to my understanding is more correct. Could you please be more specific about which Boost.Test features you think should remain and which should be removed or modified? I'm having trouble relating the discussion to the actual Boost.Test public interface. Thanks, --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Updated Boost.Random to TR proposal
Neal D. Becker [EMAIL PROTECTED] writes: On Monday 07 July 2003 05:06 pm, Jens Maurer wrote: I've updated the current Boost.Random CVS to the interface contained in the C++ library TR proposal: http://std.dkuug.dk/jtc1/sc22/wg21/docs/papers/2003/n1452.html The boost documentation has not yet been updated, I hope to be able to do that later this week. Reading the TR proposal should give you a sufficient idea. There have been various suggestions for changes from C++ committee members, so additional (but minor) interface changes may happen after the October 2003 meeting. Just one quick question: It is vital that variate generators can hold references to engines in order to share a single engine instance, and thus guarantee independence between variate generators. The proposal supports this? Neal, I don't think Jens has had much time for this stuff and now that the proposal is accepted most of the discussion has been taking place on the committee standard libraries reflector. I suggest you post your questions there. -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Draft of new Boost Software License
Peter Dimov [EMAIL PROTECTED] writes: Beman Dawes wrote: Let's see what the lawyers say before worrying too much about what may be a non-issue. I'd like to add some of my concerns to the list. First of all let me say that I fully realize that we just got a ton of free legal advice and that I do appreciate the efforts of everyone involved. And of course I am not a lawyer, not even able to impersonate one in front of laymen. But I do have some questions. Let's put the disclaimer aside for a moment; I'll return to it later. Here is the old Boost standard license (minus the disclaimer): // Permission to copy, use, modify, sell and distribute this software // is granted provided this copyright notice appears in all copies. I'll repeat here the new license (minus the disclaimer) for completeness: [start new license-- 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 others to do so, all subject to the following: The copyright notice in the Software and this entire statement, including the above license grant, this restriction and the following disclaimer, must be included in all copies of the Software, in whole or in part, and 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. -- end new license] My questions are failry obvious. * Why is the new license better? I'll get the lawyers to comment on this in more detail, but here are some answers as I understand them: Big picture: it has been vetted by lawyers for reducing ambiguity and risk for corporate legal departments, while protecting Boost developers by disclaiming implicit guarantees. It uses the correct legal terms for granting copy rights: use, reproduce, display, distribute, execute, and transmit... It is explicit about the differing requirements on source vs. object code. * Isn't there a conflict of interest between Boost contributors and the legal departments of some Boost users? Sure, at some level. Contributors want to guarantee nothing and legal departments want us to guarantee everything. Everyone benefits from better clarity, though, and that's what this license accomplishes. Which license of the two provides the better balance between the interests of these two groups? The 2nd one, IMO, because it doesn't hurt contributors at all while it helps the legal departments. In fact, it probably helps contributors by giving them a standard license with some legal foundation behind it that is less likely to cause legal SNAFUs later. Win-win. What is more important, encouraging contribution or encouraging use by large corporate clients? I don't think we have to choose. Nobody is willing to sacrifice contribution to the interests of corporate users, AFAICT, but IMO we can make the legal situation more solid and that will smooth things for everyone. * It is recognizable that the new license has been prepared with the help of a lawyer. Is this a good thing from a legal perspective? Just my opinion, but yes: it means that legal departments are getting communication in a language they understand and aggressive lawyers are less likely to mess with us. I'd like also to point out that it seems to me that the old in all copies form is better than the new one; the legal system is sufficiently flexible to reliably recognize a copy (i.e. a password protected RAR archive of an mp3 encoded song). I'm not sure about that. The problem is that the old version didn't distinguish source code copies from object code copies. The new wording seems to allow self-extracting archives of the Software to not carry the license. Good point. A simple copies of the source might work better than the wording we have now. Now the disclaimer. I am not sure to what extent we are even supposed to discuss such legal matters here; the public archives of the mailing list can be used as evidence in a hypothetical future lawsuit (SCO showed the way). So I won't go into details. Heh. Did that point kill this discussion wink ? I'll ask the lawyers. * Does free (beer) software need a disclaimer of any kind? Does it carry any implied warranties that need to be disclaimed? * Does the disclaimer provide any legal protection? Some, IIUC. Remember that the law here is applied in civil suits, so the kind of protection you need is discourages lawyers from suing because it weakens their case. That's what the disclaimer does. * Worse, if the disclaimer isn't strictly necessary and doesn't provide much legal protection, doesn't it _weaken_ our postition in a hypothetical lawsuit? Doesn't it present a convenient legal target that
[boost] Re: Re: test_fp_comparisons and rounding errors
Rozental, Gennadiy [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] A half-way solution is to have something like: BOOST_CHECK_EQUAL_NUMBERS(x,y,IsEqual) and let users specify their own Preciates. There is BOOST_CHECK_PREDICATE Yes, I know. My point was that with BOOST_CHECK_EQUAL_NUMBERS() the test library could output something readable of the form: numbers x and y are not approximately equal It could even add to the output something of the form: according to Pred ; which would use the comparator operator so it can output the relevant information such as epsilon, scale, etc.. By default, the Test library could provide a straight-forward ABSOLUTE-ERROR comparator: By default, the Test library provides relative error comparator, which is according to my understanding is more correct. But there is no such thing as a more correct way to compare FP values in the context free level of a test library. You know already that relative errors have to be scaled to be meaningful, but choosing the right scaling is the complex. A default semantic that simply scales epsilon() times any of the arguments will be simply unusable for most practical tests because actual errors will easily exceed that; yet OTOH, suppling a factor to increase the scaling will mainly lead users to the problematic Illusion of Simplicity that brought us to this discussion. A comparison based on absolute errors is pesimistic, but for unbiased comparisons it often results on what is expected, much more often that relative-error based comparisons. It isn't smart but is easy to understand. BTW: The default comparator I showed before might better be named DifferAtMostBy Fernando Cacciola ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Draft of new Boost Software License
David Abrahams wrote: [...] Now the disclaimer. I am not sure to what extent we are even supposed to discuss such legal matters here; the public archives of the mailing list can be used as evidence in a hypothetical future lawsuit (SCO showed the way). So I won't go into details. Heh. Did that point kill this discussion wink ? No doubt. regards, alexander. P.S. CPL == *WIN*-*WIN* -- http://linuxtoday.com/infrastructure/2003070400526NWEMLL (EE Times: SCO's Chief Taking Linux Beef to Japan) talkback So, this idiot at SCO (a 30 million dollar company) is going to make the CEO's of Sony Matsushita, NEC, Philips, Samsung, Sharp and Toshiba sign an NDA? These guys are going to say to Mc Bride, So me the evidence or get the hell out of my office. I hope Sony buys SCO, then makes McBride a janitor. /talkback ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Draft of new Boost Software License
Alexander Terekhov [EMAIL PROTECTED] writes: P.S. CPL == *WIN*-*WIN* These legal issues are sufficiently confusing to overwhelm the brains of most of us regular Boost people. Unless you are prepared to depart from your usual hint-dropping style and explain why you think CPL is better than what we're considering, I think it's probably going to remain... wherever it is that droppings end up. -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Interest in multiindex_set?(again)
Beman Dawes ha escrito: [...] I'm more interested in the class name than the namespace name. One problem at a time. If you weren't worrying about the namespace name, would you then like indexed_set as the class name? What are some other alternatives? If we forget about the namespace name, then I have no objections against indexed_set (though std::sets are indexed by nature, but this is probably not a common perception between users). I thought long and hard about name candidates and come up with none except multiindex_set. If no one says anything against it, I'll change it to indexed_set. The problem remains of how to name its associated namespace. [...] Yes, I think so. It is a bit of a judgement call, but since the library is a very general purpose tool, and assuming the library only adds a few names to the namespace it lives in, I'd rather see it in namespace boost. Others may disagree; a lot of people like tall and deep namespace hierarchies even when the components are very general purpose. OK, next installment will have the container promoted to boost::indexed_set. There are some auxiliary classes which I don't know exactly where to put, I'll think it over. I don't see any acceptable (non-invasive) way to implement marking only one class. But the unique/non_unique two template approach seems perfectly acceptable. You could even argue that it forces the user to consciously make the critical unique/non_unique decision for each index, so may reduce user error. I agree with you. The all-predicates-are-marked approach is even better in the light of future change (I plan to add hash indices sometime by the end of 2003). [...] I understand the rationale for that, but am still concerned. There are many applications where the cost of a copy to apply a minor update is prohibitive. The user is then forced to add a layer of indirection, or use a home-made container. Ugh. This is one of the few cases I run into where a safe design is so inefficient compared to a traditional unsafe design that in real production code I might be forced to use the unsafe design. That makes me uncomfortable. I don't think it is a question of how smartly update() is coded, but an actual conceptual impossibility. If we are to provide strong exception-safety, then no fail or throw is permitted after the element has changed its value. So, there are three scenarios: 1. Updating can possibly fail (because of collision with some other element) or reorder the updated element: no other soluction but to incur a copy of the element, as the actual updating has to take place *after* the reordering is done. 2. Updating won't fail (because the progammer knows it) but can result in reordering. Here a no-throw update is possible that doesn't require an additional copy. 3. Updating does not alter the order of the updated element (because the programmer knows it). One can just change the value in-place and forget about it. 1 is taken care of by current multiindex_set::update. 3 can be solved with appropriate const_casting: this is dangerous as any cast is, but then again the programmer *knows* what she's doing. Furthermore, this is exactly the same situation as in std::set. We are left with 2: please note that it is extremely error-prone to trust the programmer in her implicit knowing that no collision will happen (checking 3, on the other hand, is much easier, as probably what the programmer is changing are auxiliary members that no comparison predicate depend on). Now, if the no-collision guarantee is assumed, the updating can be performed without throwing. To sum it up, as it stands now mutiindex_set allows for updating in scenarios 1 and 3. Scenario 2 (programmer knows the updated element won't clash with some other element) can be realized (Fernando suggested a nice way to do it), but my opinion is that this facility would be extremely dangerous to handle. I'd rather leave things as they are now, but I'm open to suggestions, maybe I'm missing something obvious that will solve the whole problem in a fell swoop. Open issues: * Name will change to indexed_set if no one complains. What name to use for the associated namespace? * Is it advisable to provide an no-copy update facility relying on the assumption that updating won't clash with other elements in the set? Joaquín M López Muñoz Telefónica, Investigación y Desarrollo ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] smart_assert and range_ template
(not sure it's the right place to post this, but it seems smart_assert is
(or will) be part of boost, and I can't get the author email addresses. The
article is:
http://www.cuj.com/documents/s=8464/cujcexp0308alexandr/)
Here's an excerpt of some code:
template class iterator_type
inline client_ostream_type operator( client_ostream_type out, const
printer_range_t iterator_type val) {
out Range= [ *(val.m_first) , *( val.m_last) );
Values= [;
val.m_first and val.m_last are STL iterators.
The problem is with *(val.m_last) (or *(val.m_first)): if val.m_last is the
end iterator of a container, can we safely dereference it as it is done ?
What the standard is saying about that one ?
The code works properly with Microsoft STL, but fails using STLPort in debug
mode: in this latter case, the program asserts and stops at:
reference operator*() const {
_STLP_DEBUG_CHECK(_Dereferenceable(*this))
return *this-_M_iterator;
}
and STLPort outputs in the ouptut window: STL assertion failure :
_Dereferenceable(*this)
So, for STLPort, an iterator pointing to the end of a container can't be
dereferenced. That seems judicious to me, but is it in accordance with the
standard ?
If it's the case, then there is a problem in the smart_assert code.
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Draft of new Boost Software License
David Abrahams wrote: Peter Dimov [EMAIL PROTECTED] writes: * Why is the new license better? I'll get the lawyers to comment on this in more detail, but here are some answers as I understand them: Big picture: it has been vetted by lawyers for reducing ambiguity and risk for corporate legal departments, while protecting Boost developers by disclaiming implicit guarantees. The underlying assumption being that making source available for download free of charge leads to implicit guarantees. But I'm not sure that this is the case. That's why I'm asking. I'd like also to point out that it seems to me that the old in all copies form is better than the new one; the legal system is sufficiently flexible to reliably recognize a copy (i.e. a password protected RAR archive of an mp3 encoded song). I'm not sure about that. The problem is that the old version didn't distinguish source code copies from object code copies. I think it does. Object code is not a copy of the source code. The new wording seems to allow self-extracting archives of the Software to not carry the license. Good point. A simple copies of the source might work better than the wording we have now. It's redundant. The text all copies in a source file implies all copies of this source file. If you consider object code to be a copy of the source, changing copies to copies of the source doesn't help. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Draft of new Boost Software License
David Abrahams wrote: Alexander Terekhov [EMAIL PROTECTED] writes: P.S. CPL == *WIN*-*WIN* These legal issues are sufficiently confusing to overwhelm the brains of most of us regular Boost people. Uhmm. Your previous posting was not bad at all. ;-) Unless you are prepared to depart from your usual hint-dropping style and explain why you think CPL is better than what we're considering, I think it's probably going to remain... wherever it is that droppings end up. Sorry, I really can't explain it better than http://www.ibm.com/developerworks/library/os-cplfaq.html regards, alexander. P.S. http://ntxshape.sourceforge.net/opensource.html quote Common Public License There is one other license that we might have considered: the Common Public License, used for some projects on IBM's developerWorks site. It looks much like the IBM Public License, except that it is not hard-coded for IBM, and is is intended for general use. These licenses, both published by IBM, seem to strike a balance similar to that of the Mozilla Public License, but are easier for a human (as opposed to a lawyer) to read. However, the Common Public License bears a version number of 0.5. It is not a widely used license, perhaps because its version number implies instability. As a result it is not as well known as the licenses mentioned above, and has not entered into the open source vernacular. So, although it looks promising, this license does not have the same communication / project marketing value as the better known, more widely used licenses. IBM needs to release a 1.0 version of this license, and do a better job of marketing this license to developers, so that the license itself can help market IBM developerWorks' open source projects. Until they do those things, I doubt this license will get very much mindshare outside of IBM's developerWorks. /quote -- http://www.ibm.com/servers/eserver/linux/fun ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Draft of new Boost Software License
Alexander Terekhov [EMAIL PROTECTED] writes: Unless you are prepared to depart from your usual hint-dropping style and explain why you think CPL is better than what we're considering, I think it's probably going to remain... wherever it is that droppings end up. Sorry, I really can't explain it better than http://www.ibm.com/developerworks/library/os-cplfaq.html Since that faq has no entries comparing CPL to the proposed Boost license text or explaining why Alexander Terekhov considers CPL better, it doesn't even begin to address the question. I'm fairly certain that you could do a little bit better than that with only a small effort. regards, alexander. P.S. http://ntxshape.sourceforge.net/opensource.html P.S. http://www.anthro.net/guides/promotion.shtml ... I suspect most humans hate long lists of URLs without descriptions. P.P.S. http://www.thrillingdetective.com/web_guy_2.html ...long lists of URLs or ISBNs aren't even interesting to begin with. P.P.P.S. http://www.nic.com/~csy2kt/errs.htm [Mis]use of HTML - Usenet is not the Web. If your browser posts only in HTML, it's broken. If it repeats every post in text and HTML both, it's broken. Usenet is a plain text medium. You are welcome to post URLs but please explain WHY you think they are worth visiting. P.P.P.P.S. http://www.lava.net/~sch/faq.txt * Naked URLs / Empty Posts - No, we don't want you to post your entire Web page (see above -- posts written in HTML will be rejected). Posting a URL is much better, but please tell us why you are doing it! Why should we go there? etc. -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Draft of new Boost Software License
Peter Dimov [EMAIL PROTECTED] writes: David Abrahams wrote: Peter Dimov [EMAIL PROTECTED] writes: * Why is the new license better? I'll get the lawyers to comment on this in more detail, but here are some answers as I understand them: Big picture: it has been vetted by lawyers for reducing ambiguity and risk for corporate legal departments, while protecting Boost developers by disclaiming implicit guarantees. The underlying assumption being that making source available for download free of charge leads to implicit guarantees. But I'm not sure that this is the case. That's why I'm asking. Oh, one other point: if we leave the question unaddressed there appears to be uncertainty. Corporate lawyers want to know just how much risk is being assumed by the company when using our code. If they read a disclaimer, they know quickly that they are assuming basically all of the risk. Otherwise, they are left with questions, which slows adoption. -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Draft of new Boost Software License
Peter Dimov [EMAIL PROTECTED] writes: David Abrahams wrote: Peter Dimov [EMAIL PROTECTED] writes: * Why is the new license better? I'll get the lawyers to comment on this in more detail, but here are some answers as I understand them: Big picture: it has been vetted by lawyers for reducing ambiguity and risk for corporate legal departments, while protecting Boost developers by disclaiming implicit guarantees. The underlying assumption being that making source available for download free of charge leads to implicit guarantees. But I'm not sure that this is the case. That's why I'm asking. IIUC, there are no absolutes here (i.e. no law says there is an implicit guarantee). Legally, it's just a question of what looks like an attractive/vulnerable target. IIUC, the deal is that without an explicit disclaimer, lawyers feel they have more leverage in claiming that there was an implicit guarantee. I'd like also to point out that it seems to me that the old in all copies form is better than the new one; the legal system is sufficiently flexible to reliably recognize a copy (i.e. a password protected RAR archive of an mp3 encoded song). I'm not sure about that. The problem is that the old version didn't distinguish source code copies from object code copies. I think it does. Object code is not a copy of the source code. The new wording seems to allow self-extracting archives of the Software to not carry the license. Good point. A simple copies of the source might work better than the wording we have now. It's redundant. The text all copies in a source file implies all copies of this source file. If you consider object code to be a copy of the source, changing copies to copies of the source doesn't help. Sounds convincing to me, but IANAL. Let's see what the lawyers say. -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Draft of new Boost Software License
Glen Knowles wrote: [...] The Common Public License already has a section in the wiki and fails the boost requirements as shown. http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?Boost_License/Common_Public_License Yeah. That review process was really entertaining. Thanks for the reminder. Must be simple to read and understand is rather subjective, don't you think? As for Must not require that the source code be available for execution or other binary uses of the library... well, what's the problem? www.boost.org was pretty stable, thus far. regards, alexander. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Draft of new Boost Software License
On Wednesday 9 July 2003 05:48, Alexander Terekhov wrote: Common Public License The CPL is incompatible with the GPL. Whatever licence Boost settles on, it has to be compatible with the GPL. At least, unless you actually _want_ to force developers of GPL software to throw Boost out and reinvent it from scratch. See http://www.gnu.org/licenses/license-list.html -- Ross Smith . [EMAIL PROTECTED] . Auckland, New Zealand As Unix guru types go, I'm sweet, patient, and comprehensible. Unfortunately, Unix guru types don't go very far in that direction. I used to think this was a personality flaw. -- Elizabeth Zwicky ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Draft of new Boost Software License
Alexander Terekhov wrote: Glen Knowles wrote: [...] The Common Public License already has a section in the wiki and fails the boost requirements as shown. http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?Boost_License/Common_Public_License Yeah. That review process was really entertaining. Thanks for the reminder. Must be simple to read and understand is rather subjective, don't you think? As for Must not require that the source code be available for execution or other binary uses of the library... well, what's the problem? www.boost.org was pretty stable, thus far. The answers to questions 12 and 18 from http://www-106.ibm.com/developerworks/library/os-cplfaq.html seem problematic. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Draft of new Boost Software License
David Abrahams wrote: [... P.S./P.P.S./P.P.P.S./P.P.P.P.S. ...] Thanks for the information. I've bookmarked everything. regards, alexander. P.S. Please don't infringe upon my concepts and methods. We can struck a licensing deal, of course. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Draft of new Boost Software License
Alexander Terekhov [EMAIL PROTECTED] writes: Glen Knowles wrote: [...] The Common Public License already has a section in the wiki and fails the boost requirements as shown. http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?Boost_License/Common_Public_License Yeah. That review process was really entertaining. Thanks for the reminder. Glad we could brighten your day. Must be simple to read and understand is rather subjective, don't you think? Yes. That doesn't make it unimportant. As for Must not require that the source code be available for execution or other binary uses of the library... well, what's the problem? www.boost.org was pretty stable, thus far. The problem is that we don't want to force companies to assume the risk that www.boost.org will stick around. -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: Draft of new Boost Software License
Title: RE: [boost] Re: Draft of new Boost Software License From: Alexander Terekhov [mailto:[EMAIL PROTECTED]] The Common Public License already has a section in the wiki and fails the boost requirements as shown. http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?Boost_License/Common_Public_License Yeah. That review process was really entertaining. Thanks for the reminder. Must be simple to read and understand is rather subjective, don't you think? As for Must not require that the source code be available for execution or other binary uses of the library... well, what's the problem? www.boost.org was pretty stable, thus far. Now you're arguing that the boost license requirements should be changed in order to make them compatible with the CPL? That's a bit of a stretch, especially since I like the boost requirements as they are. Glen
[boost] Re: Draft of new Boost Software License
Ross Smith wrote: On Wednesday 9 July 2003 05:48, Alexander Terekhov wrote: Common Public License The CPL is incompatible with the GPL. Translation: RMS just hates patents. (and DMCA, of course) http://finance.messages.yahoo.com/bbs?board=1600684464tid=caldsid=1600684464action=mmid=17801 http://finance.messages.yahoo.com/bbs?board=1600684464tid=caldsid=1600684464action=mmid=17860 http://free.madster.com/data/free.madster.com/566/1alert2001-02-209.pdf http://faculty.babson.edu/hotchkiss/casebook/mba/amazon.htm http://www.redhat.com/legal/patent_policy.html regards, alexander. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Visitor-based framework to describe classes with exampleofobjectdump in XML format
Alexander Nasonov [EMAIL PROTECTED] writes: Well, sometimes it's needed at compile-time. Though, I don't know how useful it is. Can you give an example? Heh, you caught me! Well, if the (member) (function) pointers are available at compile time they can be inlined away so that using them becomes more efficient. Suppose I want to write serialization code? Can you serialize/deserialize with a runtime-only framework? Some other questions. How to map member pointers to names? Add a char const* const parameter? Have an additional parallel array of names? How to find a member? By name? By reverse-indexing whatever structure answers the previous question, of course! -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Draft of new Boost Software License
Peter Dimov wrote: [...] The answers to questions 12 and 18 from http://www-106.ibm.com/developerworks/library/os-cplfaq.html seem problematic. Well, http://ntxshape.sourceforge.net/opensource.html WRT q12: quote The Lesser GPL used to be called the Library GPL. For historical reasons this license still refers to the software application as the Library which can be confusing for licensees. Also, a licensee is allowed to convert the Lesser GPL to a full GPL, after which their enhancements could not be incorporated back into our version of the software. So, for us, LGPL is out. /quote WRT q18: quote This license strikes a good balance between making the source code available for use in commercial situations, while at the same time requiring that modifications / enhancements be published under the same license (thereby enabling all good enhancements to find their way back to us). /quote regards, alexander. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Draft of new Boost Software License
David Abrahams wrote: [...] As for Must not require that the source code be available for execution or other binary uses of the library... well, what's the problem? www.boost.org was pretty stable, thus far. The problem is that we don't want to force companies to assume the risk that www.boost.org will stick around. Companies will keep the code anyway. The requirement is: A Contributor may choose to distribute the Program in object code form under its own license agreement, provided that: iv) states that source code for the Program is available from such Contributor, and informs licensees how to obtain it in a reasonable manner on or through a medium customarily used for software exchange. regards, alexander. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Draft of new Boost Software License
Glen Knowles wrote: [...] Now you're arguing that the boost license requirements should be changed in order to make them compatible with the CPL? That's a bit of a stretch, especially since I like the boost requirements as they are. Frankly, I think that boost requirements make no sense. As an individual (poor one ;-) ), I'd rather go this way: http://lists.boost.org/MailArchives/boost/msg36819.php ([boost] Re: boost vs. The Lawyers (non-technical)) http://lists.boost.org/MailArchives/boost/msg46093.php ([boost] Re: Legal issues and licensing -- again) OTOH, from commercial (and OSS community) POV, I'd go CPL. regards, alexander. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Comeau toolset configuration for Unix/Linux?
It appears that the current tools/build/como-tools.jam is not usable on Unix. For example, the linker action causes REM lines to be passed to the Unix shell, which does not work. It looks to me that como-win32-tools.jam contains the Win32 configuration now, so I'd like to completely redo como-tools.jam for use on Unix/Linux. Ideas? Jens Maurer ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Comeau toolset configuration for Unix/Linux?
Jens Maurer [EMAIL PROTECTED] writes: It appears that the current tools/build/como-tools.jam is not usable on Unix. For example, the linker action causes REM lines to be passed to the Unix shell, which does not work. It looks to me that como-win32-tools.jam contains the Win32 configuration now, so I'd like to completely redo como-tools.jam for use on Unix/Linux. Fine with me. -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Comeau toolset configuration for Unix/Linux?
Jens Maurer wrote: It appears that the current tools/build/como-tools.jam is not usable on Unix. For example, the linker action causes REM lines to be passed to the Unix shell, which does not work. It looks to me that como-win32-tools.jam contains the Win32 configuration now, so I'd like to completely redo como-tools.jam for use on Unix/Linux. Ideas? I have a como-gcc toolset here that does the job for me. It wrote it using como-win32 as starting point. I could add it to the cvs if you want to. It likely can be improved. Regards, m ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: Re: is_nan
I think this would be excellent (and overdue). It needs to support double and long double (and facilitate UDTs too if possible). There is also the matter of signalling and quiet NaN. Although signalling NaN may cause an hardware exception if enabled, I suspect it is more useful if isnan returns ture for both types of NaN. At least we should make this clear. I think this is what MSVC 7.1 does but the documentation is thin. There is also a single IEEE FP pattern called 'indeterminate' or what Intel call 'NotAVal (ox1fffe000...) which might become useful as a Portable Standard missing value marker if portably supported? And can anyone help with allowing one to easily customise the display of NaNs? (and infs, max, min...?) I believe that a new (derived) num_put facet is the way to do this. Does anyone have an actual implementation of this to contribute too? 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] | -Original Message- | From: [EMAIL PROTECTED] | [mailto:[EMAIL PROTECTED] Behalf Of Joel de Guzman | Sent: Monday, July 07, 2003 5:15 PM | To: Boost mailing list | Subject: Re: [boost] Re: Re: is_nan | | | Fernando Cacciola [EMAIL PROTECTED] wrote: | Fernando Cacciola [EMAIL PROTECTED] wrote in message | news:[EMAIL PROTECTED] | | Thanks to Gabriel we may have an is_nan() right now. | | Oops! | It was Joel de Guzman who offered his is_nan() implementation. | | Sorry Joel :-) | | No problem. I thought Gaby also offered an implementation ahead of me. | So you guys are interested then? It would really be nice to have a | common boost implementation. I'll put it in the sandbox tomorrow. | | -- | Joel de Guzman | joel at boost-consulting.com | http://www.boost-consulting.com | http://spirit.sf.net | | ___ | Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost | | ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Comeau toolset configuration for Unix/Linux?
At 05:06 PM 7/8/2003, Martin Wille wrote: Jens Maurer wrote: It appears that the current tools/build/como-tools.jam is not usable on Unix. For example, the linker action causes REM lines to be passed to the Unix shell, which does not work. It looks to me that como-win32-tools.jam contains the Win32 configuration now, so I'd like to completely redo como-tools.jam for use on Unix/Linux. Ideas? I have a como-gcc toolset here that does the job for me. It wrote it using como-win32 as starting point. I could add it to the cvs if you want to. It likely can be improved. I was the one who split off como-win32 into a separate toolset. Because the Comeau uses different backends on different platforms, there is a lot of variation between the UNIX and Windows versions. I was afraid in making changes for Windows that I would break the UNIX version. The como-win32 toolset is still very much a work-in-progress. While it is basically working, issues like debugging are just starting to be addressed. I think we should continue to keep the toolsets separate for now. --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Interest in multiindex_set?(again)
Joaquín Mª López Muñoz wrote: If we forget about the namespace name, then I have no objections against indexed_set (though std::sets are indexed by nature, but this is probably not a common perception between users). I thought long and hard about name candidates and come up with none except multiindex_set. If no one says anything against it, I'll change it to indexed_set. The problem remains of how to name its associated namespace. How about indexed_table? This container is *not* a set, since there can be duplicates, but it *does* resemble a relational database table. Then it can be defined in namespace boost::table, and additionally promoted to namespace boost. I don't see any acceptable (non-invasive) way to implement marking only one class. But the unique/non_unique two template approach seems perfectly acceptable. You could even argue that it forces the user to consciously make the critical unique/non_unique decision for each index, so may reduce user error. I agree with you. The all-predicates-are-marked approach is even better in the light of future change Actually, using partial specialization, you can avoid re-specifying the default/unique. multiple would possibly be a better name than non_unique. Additionally, I would recommend allowing a specification of the default uniqueness of the indices. (I plan to add hash indices sometime by the end of 2003). A policy-based approach seems the best way to support different types of indices. Currently, I am working on a policy-based equivalent to this class which will support an ordered (binary search tree-based) index and an unordered (hash-table-based) index, as well as any user-defined index policies (which would allow a different hash table or tree implementation). This should be completed within a week or two. I don't think it is a question of how smartly update() is coded, but an actual conceptual impossibility. If we are to provide strong exception-safety, then no fail or throw is permitted after the element has changed its value. So, there are three scenarios: 1. Updating can possibly fail (because of collision with some other element) or reorder the updated element: no other soluction but to incur a copy of the element, as the actual updating has to take place *after* the reordering is done. It seems the best behavior in the case of a collision is to delete the old element with which there is a collision. This would be consistent with the semantics of insert. Instead of an update method, a modify method that takes an iterator and a one-argument (a reference to value_type) functor which it executes on the value to which the iterator points. Combined with boost.lambda and boost.bind, this system can be very convenient. In the case that the modification functor (or copy constructor, in the case of the existing update method) throws an exception, the semantics could be one of the following: 1. The container is left in an undefined state, and the exception is propogated to the caller. 2. The exception is caught, reordering is attempted; if an exception is thrown while reordering, by one of the comparison, etc. functors, the container is left in an undefined state and the exception is propogated to the caller; if reordering succeeds, the original exception thrown the by modification functor is rethrown to the caller. Thus, in either case an exception is propogated to the caller, and by the type of the exception whether the container is in an undefined state. 3. Same as (2), except that in the case that the reordering filas, before the exception thrown by a comparison function is propogated to the caller, the would-be-modified element is erased from the container, leaving it in a well-defined state. The exception thrown by the comparison function is still propogated to the user. (3) seems like the most desirable solution, thus that is the behavior I would recommend. 2. Updating won't fail (because the progammer knows it) but can result in reordering. Here a no-throw update is possible that doesn't require an additional copy. In this case, the modify method described above is sufficient, and the exception behavior is irrelevant. 3. Updating does not alter the order of the updated element (because the programmer knows it). One can just change the value in-place and forget about it. A non-const iterator should be provided. (I believe this is what has been proposed for std::set) Requiring that const_cast is used to obtain a non-const value from an iterator seems like too strong a warning. In the case where the key for an index (assuming you separate key extraction from key comparison as has been recommended) is a particular member of the value, it is often rather obvious whether a particular operation will or will not modify the key. --- Jeremy Maitin-Shepard ___ Unsubscribe other changes:
[boost] Re: Updated Boost.Random to TR proposal
David Abrahams [EMAIL PROTECTED] wrote in message Neal, I don't think Jens has had much time for this stuff and now that the proposal is accepted most of the discussion has been taking place on the committee standard libraries reflector. I suggest you post your questions there. Could you post a web address for the committee standard libraries reflector? I'd be interested in reading some of their comments, if they are open to the public. Joe Gottman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
