On Tue, Dec 03, 2002 at 08:01:10PM -0500, David Abrahams wrote:
> This is a formal call for volunteers to fill out a few of the
> open-source license evaluations at
> http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?Boost_License
I've just read and answered the questions for the Mozi
Hi, everybody
I started to work with Boost.Test issues and feature requests. Today I
committed first post-release revision. Here cumulative list of changes:
* Facility for automatic registration of unit tests is introduced
It was requested during original Boost.Test review and now it supports
a
David Abrahams wrote:
> > 2) We don't recognise the compiler: assume that it is standard
> > conforming and disable all workarounds.
>
> Is this a different case from "we recognize the compiler, but not the
> compiler version"?
>
> Incidentally, I think we had some kind of agreement a while back
Gennaro Prota <[EMAIL PROTECTED]> writes:
> On Sun, 08 Dec 2002 15:45:39 -0500, David Abrahams
> <[EMAIL PROTECTED]> wrote:
>
>>Gennaro Prota <[EMAIL PROTECTED]> writes:
>>> Well, there's no problem with __SUNPRO_CCBOOST_NUMERIC_DEFINED_SUFFIX, just
>>> with __SUNPRO_CC1.
>>
>>We seem to be talkin
I'll raise the issue the committee reflector.
Gennaro Prota <[EMAIL PROTECTED]> writes:
[...]
| > | char * p = ...
| > | reinterpret_cast(p)
| > |
| > | is illegal, because the sentence above talks about conversion to *a
| > | different* type. And the conversions that are not listed cannot
On Sunday 08 December 2002 09:41, Daryle Walker wrote:
> Did the people who arrange formal reviews see this?
Yes, this time. Sorry for missing your first post. Can you give me a short
summary of what this stuff is about and whether it should be reviewed
together or seperately. Where is this supp
On Sun, 08 Dec 2002 15:45:39 -0500, David Abrahams
<[EMAIL PROTECTED]> wrote:
>Gennaro Prota <[EMAIL PROTECTED]> writes:
>> Well, there's no problem with __SUNPRO_CCBOOST_NUMERIC_DEFINED_SUFFIX, just
>> with __SUNPRO_CC1.
>
>We seem to be talking past one another. I've been trying to tell you
>tha
On Sun, 08 Dec 2002 13:16:24 -0700, Greg Colvin
<[EMAIL PROTECTED]> wrote:
>It may be time to post a question to [EMAIL PROTECTED]
Thank you very much. What is that? An internal list for the C++
committee? Is it open to everybody, or you meant that *you* are going
to post a question there?
Genny
Gennaro Prota <[EMAIL PROTECTED]> writes:
> --- David Abrahams <[EMAIL PROTECTED]> wrote:
>> Gennaro Prota <[EMAIL PROTECTED]> writes:
>>
>> > On Sun, 08 Dec 2002 12:34:48 -0500, David Abrahams
>> > <[EMAIL PROTECTED]> wrote:
>> >
>> > [snip]
>> >>> // untested
>> >>> #define BOOST_PSEUDO_IS_DEFI
It may be time to post a question to [EMAIL PROTECTED]
At 12:59 PM 12/8/2002, you wrote:
>--- Gabriel Dos Reis <[EMAIL PROTECTED]> wrote:
>
>> I'm not saying I hold the truth. I'm offering my reading, just as others
>> are doing.
>
>Yeah, that's ok. I meant: it's unlikely that we can really find
--- Gabriel Dos Reis <[EMAIL PROTECTED]> wrote:
> I'm not saying I hold the truth. I'm offering my reading, just as others
> are doing.
Yeah, that's ok. I meant: it's unlikely that we can really find a
quote from the standard that says the last word here. Maybe the intent
was to make reinterpre
Gennaro Prota <[EMAIL PROTECTED]> writes:
[...]
| > | In any case, do you agree that at least the
| > | result is unspecified?
| >
| > I don't think I agree with this part; at least if it means anything
| > other that converting a Foo* to void*.
|
| Well, then I don't think we can establish "th
--- David Abrahams <[EMAIL PROTECTED]> wrote:
> Gennaro Prota <[EMAIL PROTECTED]> writes:
>
> > On Sun, 08 Dec 2002 12:34:48 -0500, David Abrahams
> > <[EMAIL PROTECTED]> wrote:
> >
> > [snip]
> >>> // untested
> >>> #define BOOST_PSEUDO_IS_DEFINED(symbol) BOOST_JOIN(symbol, 1)
> >>> #define BOOS
"John Maddock" <[EMAIL PROTECTED]> writes:
>> >> I don't (yet). Why do we need yet another macro which means "turn off
>> >> the workarounds?" Would BOOST_STRICT_CONFIG then be obsolete?
>> >
>> > I think that the idea is that BOOST_STRICT_CONFIG applies only to
> unknown
>> > compiler versions, a
Gennaro Prota <[EMAIL PROTECTED]> writes:
> On Sun, 08 Dec 2002 12:34:48 -0500, David Abrahams
> <[EMAIL PROTECTED]> wrote:
>
> [snip]
>>> // untested
>>> #define BOOST_PSEUDO_IS_DEFINED(symbol) BOOST_JOIN(symbol, 1)
>>> #define BOOST_WORKAROUND(symbol, test) \
>>> (BOOST_PSEUDO_IS_DEFINE
Gennaro Prota <[EMAIL PROTECTED]> writes:
> On Fri, 06 Dec 2002 14:16:39 -0500, David Abrahams
> <[EMAIL PROTECTED]> wrote:
>
>>
>>I've just checked in boost/detail/workaround.hpp, which defines the
>>BOOST_WORKAROUND macro.
>>
>>This macro can and should be used in place of explicit tests for
>>p
On Sun, 08 Dec 2002 12:34:48 -0500, David Abrahams
<[EMAIL PROTECTED]> wrote:
[snip]
>> // untested
>> #define BOOST_PSEUDO_IS_DEFINED(symbol) BOOST_JOIN(symbol, 1)
>> #define BOOST_WORKAROUND(symbol, test) \
>> (BOOST_PSEUDO_IS_DEFINED(symbol) && symbol test)
>
>This will fail if "symbol
--- David Abrahams <[EMAIL PROTECTED]> wrote:
> > // untested
> > #define BOOST_PSEUDO_IS_DEFINED(symbol) BOOST_JOIN(symbol, 1)
> > #define BOOST_WORKAROUND(symbol, test) \
> > (BOOST_PSEUDO_IS_DEFINED(symbol) && symbol test)
>
> This will fail if "symbol1" is defined, won't it?
Why?
"Eric Woodruff" <[EMAIL PROTECTED]> writes:
[...]
| Here's a question: Since h.storage is _meant_ to be accessed by those that
| do not know the type of the object inside, shouldn't it have been designed
I'm afraid the above is not an accurate description of the purpose of
holder.
One primary
Gennaro Prota <[EMAIL PROTECTED]> writes:
[...]
| > I haven't
| >| found a definition of "pointer to object" in the standard; anyhow
| >| certainly void is not an object type.
| >
| >void* is the generic type of "pointer to object."
|
| Well, as I said I don't find any definition of the expressi
On Fri, 06 Dec 2002 14:16:39 -0500, David Abrahams
<[EMAIL PROTECTED]> wrote:
>
>I've just checked in boost/detail/workaround.hpp, which defines the
>BOOST_WORKAROUND macro.
>
>This macro can and should be used in place of explicit tests for
>particular compiler/library/platform versions.
Just so
I don't think that anyone is going to find a new quote from the standard
that will end the discussion on reinterpret_cast. Even and email from Bjarne
okayed by three major platform compiler developers probably wouldn't suffice
anymore.
I had pointed out that instead of using any cast, one can just
On 08 Dec 2002 15:09:32 +0100, Gabriel Dos Reis
<[EMAIL PROTECTED]> wrote:
>Gennaro Prota <[EMAIL PROTECTED]> writes:
>
>[...]
>
>| If void* is not a "pointer to an object" then reinterpret_cast
>| is invalid. Otherwise it just yields an undefined result.
I should have said "unspecified", sorry.
Gennaro Prota <[EMAIL PROTECTED]> writes:
[...]
| If void* is not a "pointer to an object" then reinterpret_cast
| is invalid. Otherwise it just yields an undefined result. I haven't
| found a definition of "pointer to object" in the standard; anyhow
| certainly void is not an object type.
void*
> I've started running my boost backup script.
> Could you let me know the URL when you've got the wiki backup available?
Please contact me offline for the URL. [EMAIL PROTECTED]
Jeff
___
Unsubscribe & other changes: http://lists.boost.org/mailman/list
Yitzhak Sapir wrote:
> The date/time library provides several implementations of date/time string
>conversion.
> Unfortunately, none of these include formatted date/time conversions. In trying to
> duplicate the functionality of VarFormat for dates, I can do so (relatively) easily
What is VarF
On 07 Dec 2002 21:16:49 +0100, Gabriel Dos Reis
<[EMAIL PROTECTED]> wrote:
>Do you mean it is invalid to reinterpret_cast<> to void*?
Well, I'm not sure.
5.2.10/7: "A pointer to an object can be explicitly converted to
a pointer to an object of different type.65) Except that converting
an rva
> >> I don't (yet). Why do we need yet another macro which means "turn off
> >> the workarounds?" Would BOOST_STRICT_CONFIG then be obsolete?
> >
> > I think that the idea is that BOOST_STRICT_CONFIG applies only to
unknown
> > compiler versions, and BOOST_DISABLE_WORKAROUNDS (do we need separate
>
The date/time library provides several implementations of date/time string conversion.
Unfortunately, none of these include formatted date/time conversions. In trying to
duplicate the functionality of VarFormat for dates, I can do so (relatively) easily
only in one way (from date to string), s
29 matches
Mail list logo
