Re: [boost] [Signals] BCB patchlet

[Douglas Gregor]

> This removes a "possible use of 'tag' before definition" warning with
> BCB.

I didn't use this actual patch (I'd rather avoid pragmas when there's a
reasonable in-language workaround), but the code I checked in should get rid
of the warning on BCB (not that Signals compiles at the moment!). Sorry for
the delay.

Doug

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

Re: [boost] boost::signal patch

[Douglas Gregor]

MSVC 7.1 complains: warning  C4099:
> 'boost::signals::detail::real_get_signal_impl<0,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.

Thanks, it's done now.

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

Re: [boost] rw_lock / next thread version

[Douglas Gregor]

> Ok, enough of the review.  Assuming that rw_lock is destined for
> release, I propose that whether you want to lock for reading, or for
> writing, is usually a decision made at compile time, and that this fact
> can be made to slightly simplify the scoped_lock interface, and make it
> slightly more efficient.  So as a minor twist to the interface, I
> propose:
>
> class rw_mutex
> {
> public:
>  typedef detail::read_lock  read_lock;
> typedef detail::write_lock write_lock;
>   ...
> };

I too would prefer this interface,  because I feel it is much cleaner. I
*hate* enums and constants, btw :)

Doug

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

[boost] Re: Problem compiling boost.filesystem library

[David Abrahams]

Matthias Troyer <[EMAIL PROTECTED]> writes:

> Thanks Beman
>
> it now works again and I hope that multi_array will also be fixed soon

Somebody has to make that fix, whatever it is.  multi_array used to
use its own private version of iterator_adaptors.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com

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

[boost] rw_lock / next thread version

[Howard Hinnant]

I'm not positive if a read/write lock is being contemplated for a 
future boost::threads version or not.  But I was stumbling through 
thread_dev and came upon a rw_mutex which might be used something like:

class A
{
public:
...
void read() const
{
boost::rw_mutex::scoped_rw_lock lock(mut_);
...
}
void write()
{
boost::rw_mutex::scoped_rw_lock lock(mut_, boost::EXCL_LOCK);
...
}
...
private:
...
mutable boost::rw_mutex mut_;
};
And if you needed to "manually" lock the scoped_rw_lock, it would look 
like:

lock.rdlock();

or

lock.wrlock();

Unlocking a scoped_rw_lock follows the more familiar:

lock.unlock();

which then figures out at run time whether it is unlocking a reader or 
a writer.

Ok, enough of the review.  Assuming that rw_lock is destined for 
release, I propose that whether you want to lock for reading, or for 
writing, is usually a decision made at compile time, and that this fact 
can be made to slightly simplify the scoped_lock interface, and make it 
slightly more efficient.  So as a minor twist to the interface, I 
propose:

class rw_mutex
{
public:
typedef detail::read_lock  read_lock;
typedef detail::write_lock write_lock;
 ...
};
I'm not picky about the names read_lock and write_lock.  Then these 
locks could have the "standard" scoped_lock interface.  So the "A" 
example above would look more like:

class A
{
public:
...
void read() const
{
boost::rw_mutex::read_lock lock(mut_);
...
}
void write()
{
boost::rw_mutex::write_lock lock(mut_);
...
}
...
private:
...
mutable boost::rw_mutex mut_;
};
And if you needed to lock these manually, then you could say:

lock.lock();

instead of

lock.rdlock() or lock.wrlock();

This looks slightly more readable and writable to me.  And will avoid 
unlock() having to check what kind of lock (read or write) it is trying 
to unlock.

-Howard

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

[boost] Re: N1477 Single Pass Iterators and *r++

[David Abrahams]

Beman Dawes <[EMAIL PROTECTED]> writes:

> I guess it depends on how long it is likely to be before Boost
> documentation for the library is available. If it is a matter of days,
> I wouldn't bother with the committee papers. But if it is going to be
> awhile, well, then the committee paper is way better than nothing. In
> fact, as reference documentation the committee papers are quite
> good. The only serious problem is they lack tutorial, example,
> acknowledgements, etc.

OK, the papers are updated and checked in in html form.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com

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

Re: [boost] Re: Problem compiling boost.filesystem library

[Matthias Troyer]

Thanks Beman

it now works again and I hope that multi_array will also be fixed soon

Matthias

On Monday, July 14, 2003, at 03:31 AM, Beman Dawes wrote:

At 09:40 PM 7/12/2003, Jeremy Maitin-Shepard wrote:
>Matthias Troyer wrote:
>> Dear Boosters,
>>
>> After a recent cvs update I can no longer compile the boost 
filesystem
>> library:
>
>The filesystem library was broken by the update in the main CVS to the
>new iterator adapators library, and AFAIK the changes that are needed
>have yet to be completed.

The filesystem fixes have now been committed to CVS. Some of the Win32 
tests are still failing for certain compilers (see 
http://boost.sourceforge.net/regression-logs/) but I fairly certain 
that those problems are kinks in the iterator adaptor library. They 
should disappear as iterator_facade fixes get made.

--Beman

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

[boost] Re: Problem compiling boost.filesystem library

[David Abrahams]

Beman Dawes <[EMAIL PROTECTED]> writes:

> At 09:40 PM 7/12/2003, Jeremy Maitin-Shepard wrote:
>  >Matthias Troyer wrote:
>  >> Dear Boosters,
>  >>
>  >> After a recent cvs update I can no longer compile the boost filesystem
>  >> library:
>  >
>  >The filesystem library was broken by the update in the main CVS to the
>  >new iterator adapators library, and AFAIK the changes that are needed
>  >have yet to be completed.
>
> The filesystem fixes have now been committed to CVS. Some of the
> Win32 tests are still failing for certain compilers (see
> http://boost.sourceforge.net/regression-logs/) but I fairly certain
> that those problems are kinks in the iterator adaptor library.  They
> should disappear as iterator_facade fixes get made.

A one-word fix. Done now.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com

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

Re: [boost] Re: N1477 Single Pass Iterators and *r++

[Beman Dawes]

At 01:42 PM 7/13/2003, David Abrahams wrote:
>Beman Dawes <[EMAIL PROTECTED]> writes:
>
>> Ouch!  HTML is the Boost standard.  I work offline (with no
>> connection available) a great deal, and want the docs in the CVS
>> working directory.
>
>But these are not really boost documentation; they're committee
>papers that have been developed at Boost.
I realized that was what you were talking about after I posted the above.

The real problem is probably lack of Boost documentation. Until it is 
available, the committee papers in effect serve as Boost docs.

>Have you looked at the source?  I think you'd find it quite readable.
>
>If you still think it's a good idea, I'll check in the HTML but under
>the name that corresponds to the .rst file.
I guess it depends on how long it is likely to be before Boost 
documentation for the library is available. If it is a matter of days, I 
wouldn't bother with the committee papers. But if it is going to be awhile, 
well, then the committee paper is way better than nothing. In fact, as 
reference documentation the committee papers are quite good. The only 
serious problem is they lack tutorial, example, acknowledgements, etc.

--Beman

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

[boost] Re: N1477 Single Pass Iterators and *r++

[David Abrahams]

Beman Dawes <[EMAIL PROTECTED]> writes:

> Ouch!  HTML is the Boost standard.  I work offline (with no
> connection available) a great deal, and want the docs in the CVS
> working directory.

But these are not really boost documentation; they're committee
papers that have been developed at Boost.

Have you looked at the source?  I think you'd find it quite readable.

If you still think it's a good idea, I'll check in the HTML but under
the name that corresponds to the .rst file.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com

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

[boost] Re: mpl/loki

[David Abrahams]

"Peter Dimov" <[EMAIL PROTECTED]> writes:

> Maybe the problems are caused by overloading void_. 

Clearly.

> I haven't looked at MPL recently, but as a general observation I
> have identified at least three uses of a void_-like entity.
>
> 1. A type parameter used to emulate a variable argument template. I use
> '_missing' for this purpose (leading underscore for implementation details.)
>
> template struct F;

I think this is the one that has the special correspondence with the
real "void", but Aleksey wanted to change its name.

> 2. An optional parameter that, when not supplied, has a reasonable
> (dependent) default. I use 'unspecified'.
>
> template ... bind(F f);

I use 'not_specified' to distinguish it from the alarming
connotations of 'unspecified' behavior.
>
> 3. A type that is guaranteed to be distinct from all other useful types.
> 'nil' is what Lisp calls it; void_ is fine, too.

It depends whether it has special meaning in the library so that it
can't be manipulated as all other types are.  If so, you'd better not
use it this way.

Of course, in the case that sparked this conversation we could make
our specialization on void_ behave properly, but I'm not sure if
that's true in general.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com

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

Re: [boost] Re: mpl/loki

[Gabriel Dos Reis]

Howard Hinnant <[EMAIL PROTECTED]> writes:

| On Sunday, July 13, 2003, at 12:17  PM, Gabriel Dos Reis wrote:
| 
| > Howard Hinnant <[EMAIL PROTECTED]> writes:
| >
| > | Another possible spelling for this animal is:
| > |
| > | class nat {nat();};
| > |
| > | Inspired from nan.  In this case means Not A Type.
| >
| > Ahem, a class is a type, no matter how you name it.
| 
| Really, I didn't know that! :-)

there was a missing smiley -- sorry.  

| And a nan is still a floating point number.

No, it is not.  That is why it is called "Not a Number" :-)
It is just a continuation value, i.e. a special data which is not a
floating point number.

|  It just has a special bit
| pattern that alters the arithmetic rules a bit.
| 
| > | It is nice and
| > | short which comes in handy for when there are a lot of template
| > | parameters to default.  It is easily pronounceable, and won't be
| > | confused with any other type when discussed verbally.
| >
| > Really?  Without reading the rest of your message, I thought it was a
| > short for "natural number".  A matter of background I guess.
| 
| I'll go back to the drawing board.

I love drawings :-D

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

Re: [boost] Re: Problem compiling boost.filesystem library

[Beman Dawes]

At 09:40 PM 7/12/2003, Jeremy Maitin-Shepard wrote:
>Matthias Troyer wrote:
>> Dear Boosters,
>>
>> After a recent cvs update I can no longer compile the boost filesystem
>> library:
>
>The filesystem library was broken by the update in the main CVS to the
>new iterator adapators library, and AFAIK the changes that are needed
>have yet to be completed.
The filesystem fixes have now been committed to CVS. Some of the Win32 
tests are still failing for certain compilers (see 
http://boost.sourceforge.net/regression-logs/) but I fairly certain that 
those problems are kinks in the iterator adaptor library. They should 
disappear as iterator_facade fixes get made.

--Beman

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

Re: [boost] Problems with CVS?

[Marshall Clow]

At 11:49 AM 7/9/2003, Marshall Clow wrote:

At 7:09 PM -0700 7/6/03, Marshall Clow wrote:
The last 3 or 4 times that I have tried to check out the "latest
 >>boost", the checkout gets most of the way through, and then hangs.
 >
Is anyone else seeing this, or am I the only one?
If you are accessing CVS via SSH (developer), you should not have 
any problem. In fact CVS access has been very fast and reliable 
lately for me doing SSH access.
Beman -
I've read the SF docs, generated some keys, and attempted to
connect to SF using SSH -- all I've got is a bunch of timeouts.
I would sure appreciate it if you would send me a couple of CVS commands
that you use to do this.
Thanks!
--
-- Marshall
Marshall Clow Idio Software   
Hey! Who messed with my anti-paranoia shot?
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: [boost] Re: mpl/loki

[Howard Hinnant]

On Sunday, July 13, 2003, at 12:17  PM, Gabriel Dos Reis wrote:

Howard Hinnant <[EMAIL PROTECTED]> writes:

| Another possible spelling for this animal is:
|
| class nat {nat();};
|
| Inspired from nan.  In this case means Not A Type.
Ahem, a class is a type, no matter how you name it.
Really, I didn't know that! :-)

And a nan is still a floating point number.  It just has a special bit 
pattern that alters the arithmetic rules a bit.

| It is nice and
| short which comes in handy for when there are a lot of template
| parameters to default.  It is easily pronounceable, and won't be
| confused with any other type when discussed verbally.
Really?  Without reading the rest of your message, I thought it was a
short for "natural number".  A matter of background I guess.
I'll go back to the drawing board.  Of all the people that I thought 
might appreciate the analogy, you were at the top of my list. :-)

-Howard

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

[boost] Spirit v1.7.0 and v1.6.1 Released

[Joel de Guzman]

Hello,

Spirit v1.7.0 and v1.6.1 have been released.

Get it here:

Spirit v1.7.0: http://tinyurl.com/gssn
Spirit v1.6.1: http://tinyurl.com/gsss

Take note that by convention, odd minor version releases (e.g. 1.7.0) are 
developmental while even minor version releases (e.g. 1.6.1) are stable.

What's new:

http://spirit.sourceforge.net/distrib/change_log.html

Have fun!!!

Cheers,
--
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

Re: [boost] Re: mpl/loki

[Gabriel Dos Reis]

Howard Hinnant <[EMAIL PROTECTED]> writes:

| Another possible spelling for this animal is:
| 
| class nat {nat();};
| 
| Inspired from nan.  In this case means Not A Type.

Ahem, a class is a type, no matter how you name it.

| It is nice and
| short which comes in handy for when there are a lot of template
| parameters to default.  It is easily pronounceable, and won't be
| confused with any other type when discussed verbally.

Really?  Without reading the rest of your message, I thought it was a
short for "natural number".  A matter of background I guess.

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

Re: [boost] Re: Compiler status for GCC 3.3

[Gabriel Dos Reis]

"Ben Woodhead" <[EMAIL PROTECTED]> writes:

| Hello
| 
| Was this -fabi-version flag just there for testing different version or do
| users have to know about this?

The latter.  It is a documented flag, primarily designed for packagers
and/or distributors.

| Could you test the compiler version and set it appropriately ABI. 

Yes, you can.

| As you guys are probobly already aware of is that this 
| will lead to a ton of questions (if people read enough to know the flag
| excists) and bug reports due to ABI imcompatibilities.

Yes.  Unfortunately.

An executive summary is that -fabi-version is a flag designed to
compensate lack of enough testing before releasing the compiler.
Thus, users can now set which versions of bug compatibility they want.
A recipe for confusion.  The alternative was to release more and more
ABI incompatible compilers.

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

Re: [boost] Re: N1477 Single Pass Iterators and *r++

[Beman Dawes]

At 09:25 AM 7/13/2003, David Abrahams wrote:
>"Joel de Guzman" <[EMAIL PROTECTED]> writes:
>
>> David Abrahams <[EMAIL PROTECTED]> wrote:
>>> "Joel de Guzman" <[EMAIL PROTECTED]> writes:
>>>
 Beman Dawes <[EMAIL PROTECTED]> wrote:

>  >> In the main CVS? iterator-categories.html is still dated several 

>days
>  >> ago. Or am I looking in the wrong place?
>  >
>  >I guess so.  Why would I be editing a document in the multi_array
>lib?
>
> I was talking about
>boost-root/libs/iterator/doc/iterator-categories.html,
> committed July 7 by Joel. That is the document I was expecting to 
see
> updated.
>>>
>>> Oh, I never saw that.  Joel, it's inconvenient to have the .html file
>>> with a different name from the .rst file.  Is there any reason we
>>> can't change that so they're both named new-iter-concepts.xxx?
>>
>> I didn't put those. Those files were taken from the sandbox as-is.
>
>I'm gonna remove them from the CVS then.  I don't think I want the
>HTML for those papers checked in, just the source.  We can always
>link to the versions I keep up-to-date on my site from the actual
>library docs when we write them.

Ouch!  HTML is the Boost standard. I work offline (with no connection 
available) a great deal, and want the docs in the CVS working directory.

--Beman

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

Re: [boost] Re: mpl/loki

[Peter Dimov]

Howard Hinnant wrote:
> On Sunday, July 13, 2003, at 08:49  AM, Peter Dimov wrote:
>
>> Maybe the problems are caused by overloading void_. I haven't looked
>> at MPL
>> recently, but as a general observation I have identified at least
>> three uses
>> of a void_-like entity.
>>
>> 1. A type parameter used to emulate a variable argument template. I
>> use '_missing' for this purpose (leading underscore for
>> implementation details.)
>>
>> template struct F;
>>
>> 2. An optional parameter that, when not supplied, has a reasonable
>> (dependent) default. I use 'unspecified'.
>>
>> template ... bind(F f);
>>
>> 3. A type that is guaranteed to be distinct from all other useful
>> types.
>> 'nil' is what Lisp calls it; void_ is fine, too.
>
> Another possible spelling for this animal is:
>
> class nat {nat();};
>
> Inspired from nan.  In this case means Not A Type.  It is nice and
> short which comes in handy for when there are a lot of template
> parameters to default.

Yep. But I don't think defaulting to 'nat' is correct; defaults in this case
are 'missing'.

You can make a list of nat's, and this is not an empty list. IOW with:

template struct list;

you can't tell the difference between list<>, list, list...

In Lisp this would correspond to () (which is also nil there), (nil), (nil
nil), ...

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

Re: [boost] Re: Compiler status for GCC 3.3

[Ben Woodhead]

- Original Message - 
From: "Gabriel Dos Reis" <[EMAIL PROTECTED]>
To: "Boost mailing list" <[EMAIL PROTECTED]>
Sent: Sunday, July 13, 2003 5:07 AM
Subject: Re: [boost] Re: Compiler status for GCC 3.3


> Beman Dawes <[EMAIL PROTECTED]> writes:
>
> | At 02:44 AM 7/3/2003, Giovanni Bajo wrote:
> |
> |  >On Friday, July 04, 2003 12:38 AM [GMT+1=CET],
> |  >David Abrahams <[EMAIL PROTECTED]> wrote:
> |  >
> |  >>> On the other hand if your native compiler is GCC and your system
was
> |  >>> not configured with that setting, then you may get into trouble --
> |  >>> since you'll be mixing translation units with different ABIs.
> |  >>
> |  >> Furthermore, that sounds like a workaround.  Isn't it still a
> |  >> compiler bug that it doesn't work without -fabi-version=0?
> |  >
> |  >No, it's correctly fixed, but since it's a fix that breaks ABI,  the
> |  >version number was bumbed. By default, GCC 3.3 uses the GCC 3.2 ABI.
> |  >If you want to
> |  >activate the new version, you have to explicitally say so.
> |  >"-fabi-version=0" always selects the last version of the ABI.
> |
> | So are you are saying we should add "-fabi-version=0"?
>
> If you do that unconditionally, you may get ABI incompatible
> libraries/programs compared to what your system come with.
>
> The default ABI version for GCC-3.3.x is 1.  You might want to set it
> to 2 and see what happens (for GCC-3.3.x) -- some bugs are fixed in
> -fabi-version=2.
>
>
> This whole thing (-fabi-version) is messy.  It is what one gets by
> taking users for beta testers ;-)
>
> -- Gaby

Hello

Was this -fabi-version flag just there for testing different version or do
users have to know about this? Could you test the compiler version and set
it appropriately ABI. As you guys are probobly already aware of is that this
will lead to a ton of questions (if people read enough to know the flag
excists) and bug reports due to ABI imcompatibilities.

Ben

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

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

Re: [boost] Re: mpl/loki

[Howard Hinnant]

On Sunday, July 13, 2003, at 08:49  AM, Peter Dimov wrote:

Maybe the problems are caused by overloading void_. I haven't looked 
at MPL
recently, but as a general observation I have identified at least 
three uses
of a void_-like entity.

1. A type parameter used to emulate a variable argument template. I use
'_missing' for this purpose (leading underscore for implementation 
details.)

template struct F;

2. An optional parameter that, when not supplied, has a reasonable
(dependent) default. I use 'unspecified'.
template ... bind(F f);

3. A type that is guaranteed to be distinct from all other useful 
types.
'nil' is what Lisp calls it; void_ is fine, too.
Another possible spelling for this animal is:

class nat {nat();};

Inspired from nan.  In this case means Not A Type.  It is nice and 
short which comes in handy for when there are a lot of template 
parameters to default.  It is easily pronounceable, and won't be 
confused with any other type when discussed verbally.

-Howard

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

[boost] Re: N1477 Single Pass Iterators and *r++

[David Abrahams]

"Joel de Guzman" <[EMAIL PROTECTED]> writes:

> David Abrahams <[EMAIL PROTECTED]> wrote:
>> "Joel de Guzman" <[EMAIL PROTECTED]> writes:
>> 
>>> Beman Dawes <[EMAIL PROTECTED]> wrote:
>>> 
  >> In the main CVS? iterator-categories.html is still dated several days
  >> ago. Or am I looking in the wrong place?
  >
  >I guess so.  Why would I be editing a document in the multi_array lib?
 
 I was talking about boost-root/libs/iterator/doc/iterator-categories.html,
 committed July 7 by Joel. That is the document I was expecting to see
 updated.
>> 
>> Oh, I never saw that.  Joel, it's inconvenient to have the .html file
>> with a different name from the .rst file.  Is there any reason we
>> can't change that so they're both named new-iter-concepts.xxx?
>
> I didn't put those. Those files were taken from the sandbox as-is.

I'm gonna remove them from the CVS then.  I don't think I want the
HTML for those papers checked in, just the source.  We can always
link to the versions I keep up-to-date on my site from the actual
library docs when we write them.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com

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

Re: [boost] Re: mpl/loki

[Peter Dimov]

David Abrahams wrote:
> Aleksey Gurtovoy <[EMAIL PROTECTED]> writes:
>
>> David Abrahams wrote:
>>> Aleksey Gurtovoy <[EMAIL PROTECTED]> writes:
>>>
 IMO we should just stop using 'void_' for internal purposes and
 give it up to users :).
>>>
>>> I am still unsure about 'void_' being better than 'nil' or
>>> 'null'  Users already have a type, 'void', which means void.
>>
>> ... in conventional run-time programs. Unfortunately, 'void' is not
>> special for metaprograms, many of which have a need to routinely
>> manipulate it along with all other built-in types. 'mpl::void_'
>> addresses this issue.
>>
>>> There's no correspondence between void_ and void the way there is
>>> between bool_ and bool.
>>
>> 'void_' in MPL plays a role very similar to a role of 'void' in the
>> core language.  So, conceptually, there is a correspondence.
>
> But that's only true as long as void_ is being used for internal
> purposes.  Once you "give it up to users" as you suggest, it loses
> that correspondence, and we'll have some other internal name which
> has that correspondence to void.

Maybe the problems are caused by overloading void_. I haven't looked at MPL
recently, but as a general observation I have identified at least three uses
of a void_-like entity.

1. A type parameter used to emulate a variable argument template. I use
'_missing' for this purpose (leading underscore for implementation details.)

template struct F;

2. An optional parameter that, when not supplied, has a reasonable
(dependent) default. I use 'unspecified'.

template ... bind(F f);

3. A type that is guaranteed to be distinct from all other useful types.
'nil' is what Lisp calls it; void_ is fine, too.

HTH :-)

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

Re: [boost] Re: is_nan

[Joel de Guzman]

Gabriel Dos Reis <[EMAIL PROTECTED]> wrote:
> "Joel de Guzman" <[EMAIL PROTECTED]> writes:
> 
>> Fernando Cacciola <[EMAIL PROTECTED]> wrote:
>>> Gabriel Dos Reis <[EMAIL PROTECTED]> wrote in
>> 
 Yes.  It is an incorrect (unfortunately popular)
 implementation.
 
>>> Right. We should say that more often. It is incorrect
>>> however popular.
>>> 
>>> Most compilers provide a non standard extension for this
>>> purpose.
>>> For instance, Borland uses _isnan.
>>> In general, these extensions are found on .
>>> The best approach, IMO, is to have a boost::is_nan() with
>>> compiler specific implementations.
>> 
>> Hi,
>> 
>> We have an is_nan(float) implementation (for quiet NaNs of course)
>> that does just that. Right now, it supports most compilers on Win32 but it
>> should be straight-forward to support others. Right now, it is tested on:
>> 
>> g++2.95.3 (MinGW)
>> g++3.1 (MinGW)
>> Borland 5.5.1
>> Comeau 4.24 (Win32)
>> Microsoft Visual C++ 6
>> Microsoft Visual C++ 7
>> Microsoft Visual C++ 7.1
>> Metrowerks CodeWarrior 7.2
>> 
>> The default implementation assumes IEEE754 floating point. It takes advantage
>> of the fact that IEEE754 has a well defined binary layout for quiet NaNs.
> 
> I'm not sure what you mean by that.  IEEE-754 defines an *abstract*
> binary model, not a concrete one.  And the exact mapping to concrete
> implementation is NOT defined.  That is not what I call a well defined
> binary layout.

Yes of course. What's important is that it defines the bits of what constitutes a 
NaN, b[0] .. b[N] and we can create a mapping from bits 0..N of the abstract
binary model to the actual (concrete) binary layout of a platform/processor.

> For example on HP boxes, the concrete binary layout of qNaNs and sNaNs
> is flipped (in the leading bits) from those of SPARCs.  Yes, both have
> IEEE-754 conforming  representations.  There are many other variants.
> (I learnt those when I tried to get compiler support for
> numeric_limits<> in GCC).  Those who are interested might want to have
> a look at gcc/real.[hc].

Nice. Thanks for the tip.

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

Re: [boost] Re: functors for taking apart std::pair?

[Daniel Wallin]

At 22:51 2003-07-10, Marshall Clow wrote:
At 7:21 AM -0400 7/10/03, David Abrahams wrote:
Marshall Clow <[EMAIL PROTECTED]> writes:

 > So, here they are. Are they useful to anyone else? Is there some 
reason that
 they don't already exist? Did I miss them somewhere?

 template 
 struct first: std::unary_function< std::pair , T1>
 {
T1 operator()(const std::pair  & x) const { return 
x.first;}
 };

 template 
 struct first: std::unary_function< std::pair , T2>
 {
T2 operator()(const std::pair  & x) const { return 
x.second;}
 };

But other than that, what do people think?
I would prefer "select_nth".

I needed them because someone had a map, and I wanted to call a 
member function
(call it "Bar") on each Foo* in the map. Turns out, that with 
boost::compose and 'second', it
was simple:

std::for_each ( m.begin (), m.end (),
boost::compose_f_gx ( std::mem_fun ( Foo::Bar ), second 
 ()));
How about:

std::for_each(m.begin(), m.end(),
  boost::compose_f_gx(std::mem_fun(Foo::Bar), select_nth<1, std::pair >()));

See
http://www.cs.umu.se/~ens01dwn/select_nth.hpp
for a sample implementation that handles boost::tuples and pairs.
---
Daniel Wallin
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: [boost] is_nan

[Gabriel Dos Reis]

Guillaume Melquiond <[EMAIL PROTECTED]> writes:

| On 4 Jul 2003, Gabriel Dos Reis wrote:
| 
| > "Toon Knapen" <[EMAIL PROTECTED]> writes:
| >
| > | > seems like this code
| > | >
| > | > template< typename T >
| > | > bool is_nan( const T& v )
| > | > {
| > | > return std::numeric_limits::has_quiet_NaN && (v != v);
| > | > }
| > | >
| > | > does not work correctly on some machines.
| > |
| > | Could you be more specific. On which machines for instance ?
| >
| > If v is a signalling NaN, and you're for example using the SPARC
| > architecture for example, you might get a trap.
| >
| > -- Gaby
| 
| Just to avoid any kind of misunderstanding, the interval library don't use
| signaling NaN.

I was answering a query about architectures.

>From your above statement,  I understand that the interval library
does not use sNaNs by itself.  What about users getting sNaNs with the
library? 

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

Re: [boost] Re: is_nan

[Gabriel Dos Reis]

"Joel de Guzman" <[EMAIL PROTECTED]> writes:

| Fernando Cacciola <[EMAIL PROTECTED]> wrote:
| > Gabriel Dos Reis <[EMAIL PROTECTED]> wrote in
| 
| >> Yes.  It is an incorrect (unfortunately popular)
| >> implementation. 
| >> 
| > Right. We should say that more often. It is incorrect
| > however popular. 
| > 
| > Most compilers provide a non standard extension for this
| > purpose. 
| > For instance, Borland uses _isnan.
| > In general, these extensions are found on .
| > The best approach, IMO, is to have a boost::is_nan() with
| > compiler specific implementations.
| 
| Hi,
| 
| We have an is_nan(float) implementation (for quiet NaNs of course) 
| that does just that. Right now, it supports most compilers on Win32 but it
| should be straight-forward to support others. Right now, it is tested on:
| 
| g++2.95.3 (MinGW)
| g++3.1 (MinGW)
| Borland 5.5.1
| Comeau 4.24 (Win32)
| Microsoft Visual C++ 6
| Microsoft Visual C++ 7
| Microsoft Visual C++ 7.1
| Metrowerks CodeWarrior 7.2
| 
| The default implementation assumes IEEE754 floating point. It takes advantage
| of the fact that IEEE754 has a well defined binary layout for quiet NaNs.

I'm not sure what you mean by that.  IEEE-754 defines an *abstract*
binary model, not a concrete one.  And the exact mapping to concrete
implementation is NOT defined.  That is not what I call a well defined
binary layout.

For example on HP boxes, the concrete binary layout of qNaNs and sNaNs
is flipped (in the leading bits) from those of SPARCs.  Yes, both have
IEEE-754 conforming  representations.  There are many other variants.
(I learnt those when I tried to get compiler support for
numeric_limits<> in GCC).  Those who are interested might want to have
a look at gcc/real.[hc].

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

Re: [boost] Re: Re: is_nan

[Gabriel Dos Reis]

"Paul A. Bristow" <[EMAIL PROTECTED]> writes:

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

Agreed.  It is no question that isnan should distinguish between Quiet
NaNs and Signalling NaNs.  They are all NaNs.

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

I won't take that road.  

Signalling NaNs are used to indicate missing initialization values.

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

I'm willing to volunteer but I'm not sure I really understand the
question. Can you elaborate a little bit?

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

Re: [boost] Re: Re: is_nan

[Gabriel Dos Reis]

Guillaume Melquiond <[EMAIL PROTECTED]> writes:

| On Sat, 5 Jul 2003, Fernando Cacciola wrote:
| 
| > Thanks to Gabriel we may have an is_nan() right now.
| > Is there anything else that the interval library uses which might be better
| > packed as a compiler-platform specific routine?
| 
| All the hardware rounding mode selection stuff. It's equivalent to the
|  C header file.

 is not the way I would like to see better support for
floating point types and access to executing environment in C++.

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

Re: [boost] Re: Re: is_nan

[Gabriel Dos Reis]

"Fernando Cacciola" <[EMAIL PROTECTED]> writes:

[...]

| > > Most compilers provide a non standard extension for this purpose.
| > > For instance, Borland uses _isnan.
| > > In general, these extensions are found on .
| >
| > In fact, since it is not specified by the C++ standard, isnan comes from
| > the C headers and is supposed to be found in .
| >
| Right.. I was actually thinking on the C header but wrote it incorrectly.
| I meant .

I would like to point out that a correct implementation of isnan would

  1) use a reference to its parameter
  2) rely on compiler extension.

(I'll try to get built-in support for isnan in GCC).

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

Re: [boost] Re: is_nan

[Gabriel Dos Reis]

Guillaume Melquiond <[EMAIL PROTECTED]> writes:

| On Fri, 4 Jul 2003, Fernando Cacciola wrote:
| 
| > Gabriel Dos Reis <[EMAIL PROTECTED]> wrote in message
| > news:[EMAIL PROTECTED]
| > > "jvd" <[EMAIL PROTECTED]> writes:
| > >
| > > | Dear boosters,
| > > |
| > > | seems like this code
| > > |
| > > | template< typename T >
| > > | bool is_nan( const T& v )
| > > | {
| > > | return std::numeric_limits::has_quiet_NaN && (v != v);
| > > | }
| > > |
| > > | does not work correctly on some machines.
| > >
| > > Yes.  It is an incorrect (unfortunately popular) implementation.
| > >
| > Right. We should say that more often. It is incorrect however popular.
| 
| Yes, it is incorrect for C++. But it's something we can hope to see one
| day. For example, in the LIA-1 annex I about C langage bindings, it is
| written that != is a binding for IEEE-754 ?<> operator (unordered
| compare). In the C9X annex F.8.3 about relational operators, it is written
| that the optimization "x != x -> false" is not allowed since "The
| statement x != x is true if x is a NaN". And so on.

You seem to forget that C99 does not consider Signalling NaNs -- which
are other missing parts of C99.  For those NaNs, the comparaison might
just trap.

Please, be careful when quoting.

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

Re: [boost] Re: Compiler status for GCC 3.3

[Gabriel Dos Reis]

Beman Dawes <[EMAIL PROTECTED]> writes:

| At 02:44 AM 7/3/2003, Giovanni Bajo wrote:
| 
|  >On Friday, July 04, 2003 12:38 AM [GMT+1=CET],
|  >David Abrahams <[EMAIL PROTECTED]> wrote:
|  >
|  >>> On the other hand if your native compiler is GCC and your system was
|  >>> not configured with that setting, then you may get into trouble --
|  >>> since you'll be mixing translation units with different ABIs.
|  >>
|  >> Furthermore, that sounds like a workaround.  Isn't it still a
|  >> compiler bug that it doesn't work without -fabi-version=0?
|  >
|  >No, it's correctly fixed, but since it's a fix that breaks ABI,  the
|  >version number was bumbed. By default, GCC 3.3 uses the GCC 3.2 ABI.
|  >If you want to
|  >activate the new version, you have to explicitally say so.
|  >"-fabi-version=0" always selects the last version of the ABI.
| 
| So are you are saying we should add "-fabi-version=0"?

If you do that unconditionally, you may get ABI incompatible
libraries/programs compared to what your system come with.

The default ABI version for GCC-3.3.x is 1.  You might want to set it
to 2 and see what happens (for GCC-3.3.x) -- some bugs are fixed in
-fabi-version=2.


This whole thing (-fabi-version) is messy.  It is what one gets by
taking users for beta testers ;-)

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

Re: [boost] Compiler status for GCC 3.3

[Gabriel Dos Reis]

[EMAIL PROTECTED] (Joerg Walter) writes:

| - Original Message -
| From: "Gabriel Dos Reis" <[EMAIL PROTECTED]>
| To: "Boost mailing list" <[EMAIL PROTECTED]>
| Sent: Monday, June 30, 2003 12:06 PM
| Subject: Re: [boost] Compiler status for GCC 3.3
| 
| 
| [...]
| 
| > | I'm not sure about this. Paul C. Leopardi and Guillaume Melquiond
| already
| > | reported the issue, Paul also analyzed it here
| > | http://groups.yahoo.com/group/ublas-dev/message/676
| > |
| > | In essence: setting -fabi-version=0 should solve the problem.
| >
| > On the other hand if your native compiler is GCC and your system was
| > not configured with that setting, then you may get into trouble --
| > since you'll be mixing translation units with different ABIs.
| 
| It sounds as if GCC 3.3 itself could be affected by -fabi-version=?. If say
| for example libstdc++ isn't binary compatible when build with
| different -fabi-version settings don't we have two different compilers
| depending on configure's -fabi-version then?

-fabi-version is a flag that controls the GNU C++ front-end, it is not
communicated to the library and since this is a core front-end issue,
I don't see any way in which libstdc++-v3 could protected itself.

On the other hand, libstdc++-v3 has some abi testing testsuite and we
didn't notice any regression on that topic (at least I'm not aware of
any such).

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