"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.
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
exc
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
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 tu
Martin Wille wrote:
> 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.
Is that for como on Win32 or for Unix?
Hm... We shouldn't add too many toolsets for basically
the
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 comp
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
> co
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-
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
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
> ri
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:
The Lesser GPL used to be called the Library GPL. For historical
reaso
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
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=1600684464&tid=cald&sid=1600684464&a
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_Li
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.
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.
___
Un
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"
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
rei
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
"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
"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
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 d
Title: RE: [boost] Re: Draft of new Boost Software License
From: Alexander Terekhov [mailto:[EMAIL PROTECTED]]
>David Abrahams wrote:
>> Unless you are prepared to depart
>> from your usual "hint-dropping" style and explain why you think CPL is
>> better tha
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. ;-)
>
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 ris
(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 clien
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,
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
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.
Well, sometimes it's needed at compile-time. Though, I don't know how useful
it is. Can you give an example?
Some other questions. How to map member pointers to names? How to find a
member?
--
Alexander Nasonov
Remove minus and all between minus and at from my e-mail for timely response
David
Alexander Nasonov <[EMAIL PROTECTED]> writes:
> 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_
>>
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 wit
"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 lega
"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 docu
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 ABS
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_
> {
> typedef mpl::vector bases;
>
> ty
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
> >
>
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
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
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
At the top of signal.hpp:
namespace boost {
#ifndef BOOST_NO_TEMPLATE_PARTIAL_SPECIALIZATION
namespace BOOST_SIGNALS_NAMESPACE {
namespace detail {
template
struct real_get_signal_impl;
MSVC 7.1 complains: warning C4099:
'boost::signals::detail::real_get_signal_impl<0,T1,T2,T3,
41 matches
Mail list logo
