headers
David Abrahams | 1 Dec 2002 01:33
Picon
Picon
Favicon
Gravatar

Re: Re: Re: Re: Boost License Issues

"Jeff Garland" <jeff <at> crystalclearsoftware.com> writes:

>> 
>> Thanks, Jeff!
>> 
>> Not to look a gift Wikimaster in the mouth, but would it be possible
>> to do something like:
>> 
>> http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?Boost_Documentation_Format/Tasks
>
>
>  
>> where each license link is listed separately, a sign-up item is
>> available, and possibly with a sub-page for each license's summary?
>
> I pulled the list of licenses off the opensource.org page and 
> set it up so that one can just click the license name to add a
> sub-page.  

Thanks!

> I'll let you add some detailed expectations on the
> process once you have done a couple :-)

I would be happy to.

> http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?Boost_License

It would help to have a link to the actual license text in some
obvious place, either next to the entry on the main page, or on the
(Continue reading)

Permalink | Reply | 0 comments |
headers
Douglas Gregor | 1 Dec 2002 02:06
Picon
Favicon

Re: bollean states

On Monday 25 November 2002 12:06 am, Ihsan Ali Al Darhi wrote:
> A while ago you discussed a library for adding a third boolean state.
> Where's this library?

It's in the Boost sandbox under the name "tribool". Information about the 
sandbox is here:
  http://www.boost.org/more/mailing_lists.htm#sandbox

	Doug
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Permalink | Reply | 4 comments |
headers
Robert Ramey | 1 Dec 2002 03:01

Re: Re:Serialization Library: review

>From: "Gennadiy Rozental" <gennadiy.rozental <at> tfn.com>

>Yes I believe we could combine input/output algorithms for stl constructs.
>In any case it should be simple template functor that wont be instantiated
>if not used.
>But I would prefer:
>/boost/seralization/stl/
>vector.hpp
>list.hpp
>...

Hmmm - thats odd to me. Why not

/boost/serialization/std/		// note std rather than stl
vector.hpp
list.hpp
...

and what about things like shared_ptr ? would that be:

/boost/serialization/boost/
shared_ptr.hpp

Robert Ramey
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Permalink | Reply | 0 comments |
headers
Aleksey Gurtovoy | 1 Dec 2002 11:51
Favicon

RE: [MPL] vector of vectors

David A. Greene wrote:
> Is it possible to have an MPL vector of MPL vectors?  

Sure. MPL sequences are polymorphic regarding their elements; everything
that is a type can be put into a sequence, and everything in MPL is a type
:).

> When I try this, the compiler (g++ 3.2) complains about an incomplete
> type for push_back_traits:

[snip code]

The error is not related to the fact that you are trying to create a "vector
of vectors"; if you try to 'push_back' an 'int' into a vector, you'll get
the same diagnostics. Basically, what compiler is trying to say here is that
'push_back' on 'vector' is currently not implemented, - sorry! I know it
differs from what the docs say, and it's on my to do list. Meanwhile, if you
switch to using 'push_front' instead, everything will work just fine.
Sometimes 'push'-ing backwards (i.e. at front) makes things much
harder/messy than they could be, though, so let me know if that's the case
here.

Aleksey
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Permalink | Reply | 0 comments |
headers
John Maddock | 1 Dec 2002 12:55
Picon

Lambda and Borland C++

I'm wondering if it's possible to get Lambda working with Borland's
compiler?  There are a couple of issues that are easy to fix, but then
things get tricky:

1) Integral constant expressions need fully qualified names:

RCS file: /cvsroot/boost/boost/boost/lambda/detail/lambda_traits.hpp,v
retrieving revision 1.3
diff -r1.3 lambda_traits.hpp
92c92
<     boost::is_function<plainT>::value,
---
>     ::boost::is_function<plainT>::value,
260c260
<       typename detail::IF<boost::is_function<T>::value, T&, const T>::RET
---
>       typename detail::IF< ::boost::is_function<T>::value, T&, const
T>::RET

2) locally declared names can't be used in integral constant expressions (a
variation of (1)):

RCS file: /cvsroot/boost/boost/boost/lambda/detail/lambda_traits.hpp,v
retrieving revision 1.3
diff -r1.3 lambda_traits.hpp
502,503c502,509
<
<   typedef
---
> #ifdef __BORLANDC__
(Continue reading)

Permalink | Reply | 3 comments |
headers
Gennadiy Rozental | 1 Dec 2002 18:28

[test] handling fatal errors

Hi, everybody

   I would like to bring your attention to some issues related to handling
by Boost.Test errors causing program to terminate in regular case. It could
be fatal error like SIGSEGV is caught or division by zero or assert
statement. Unfortunately Boost.Test a bit inconsistent in it's handling
logic. And in any case not very helpful in some cases. Seeing "memory access
violation" does not give enough information. And current logic would not
stop/produce core at the point of the error. On the other hand it may not be
convenient for regression testing.

   So let list three models of how developer used to try to locate/prevent
the errors, with respective developers preferences:

[a] Working in GUI/command line debugger
     In this case the best would be to stop exactly in the point of the
fatal failure or produce a core.
[b] Adding trace statements, running program and analyze output.
     In this case it good enough to see output together with terminating
message from Boost.Test. On the other hand to locate the exact point of
failure may require several iteration of adding trace statements and
recompilation. It would be helpful to see as much program flow info as
possible. Boost.Test provide the means for this in a form of
BOOST_CHECKPOINT tool. But it still need to be placed in manually.
[c] Running regression tests on regular basis by some automation scripts.
    In this case developer would be interested in much more coverage as
possible. IOW one would prefer to see total statistics on all test cases
(which one passes/which one failing) even if one of them causing assert to
fire.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Beman Dawes | 1 Dec 2002 16:47
Picon
Favicon
Gravatar

Re: Re: relative/absolute paths in filesystem library

At 08:02 PM 11/29/2002, David Abrahams wrote:
 >Beman Dawes <bdawes <at> acm.org> writes:
 >
 >>  >I don't know if it was controversial, but I did bring this up during
 >>  >the review and I do think its very important. The basic definition
 >>  >of an absolute path should be a path that overrides the base path
 >>  >during a resolve. To rephrase, 'foo' is relative because it is an
 >>  >adjustment from the current directory, '/foo' on the other hand
 >>  >takes precendence over the current path. To re-rephrase, '/foo' is
 >>  >relative to the current drive, but not to the current directory.
 >>
 >> That seems like a stretch to me. With your definition, "absolute"
 >> isn't equivalent to "not relative", and that seems counter
 >> intuitive.
 >
 >Maybe, but it does seem to capture reality on Windows.

At one point we discussed using the name "is_complete" to capture the 
notion of a complete path, which on multi-rooted operating systems like 
Windows would mean having both a drive and the root directory. That name 
seems less likely to cause confusion.

I'll hold a mini-review of the library in a few days so people can look at 
class filesystem::path as a whole.

--Beman

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
(Continue reading)

Permalink | Reply | 0 comments |
headers
Beman Dawes | 1 Dec 2002 20:54
Picon
Favicon
Gravatar

boost/throw_expression.hpp specs?

If BOOST_NO_EXCEPTIONS is defined then boost::throw_expression() is 
declared but not defined.

The docs say "...the user is expected to supply an appropriate definition" 
but no other requirements are stated.

Seems there is should be an additional requirement "A user-defined 
throw_expression function must not return." or similar.

(I'm assuming that's the intent. But if it isn't, and a user-defined 
throw_expression function is in fact allowed to return, then that needs to 
be stated.)

--Beman

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Permalink | Reply | 1 comment |
headers
Beman Dawes | 1 Dec 2002 21:23
Picon
Favicon
Gravatar

Re: Possible patch to format for Borland BCB5

At 08:11 PM 11/28/2002, David Abrahams wrote:

 >> AFAIK, Metrowerks is correct, and the other compilers intend to detect
 >these errors in the future.
 >>
 >> The fix is usually to add qualification. For example,
 >foo::out_of_range_bit.
 >
 >The fix is usually to make sure that the appropriate declaration of a
 >non-dependent name is visible before the name is used. Extra
 >qualification doesn't usually help AFAICT.
 >
 >Oh, I guess that if the name is a member of a base class, then the fix
 >is to write ``this->member_name'' or ``BaseClass::member_name''
 >instead of just ``member_name''. That can be viewed as adding
 >qualification.

Yes, that was the case that came up in other libraries.

 > However, that doesn't _appear_ to be the problem in the
 >case below, and in any case I recomment using ``this->'' when possible
 >because it's more reliable.

Hum... I'll take your word for it, but to tell the truth I have trouble 
understanding what either ``this->member_name'' or 
`BaseClass::member_name'' adds. And the format library case wasn't a member 
name at all, it was an enum name, IIRC.

I guess I need a C++ for dummies level description of why these names are 
not visible, and why adding this-> or qualification makes the names
(Continue reading)

Permalink | Reply | 2 comments |
headers
David Abrahams | 1 Dec 2002 22:11
Picon
Picon
Favicon
Gravatar

Re: Possible patch to format for Borland BCB5

Beman Dawes <bdawes <at> acm.org> writes:

> At 08:11 PM 11/28/2002, David Abrahams wrote:
>
>  >> AFAIK, Metrowerks is correct, and the other compilers intend to detect
>  >these errors in the future.
>  >>
>  >> The fix is usually to add qualification. For example,
>  >foo::out_of_range_bit.
>  >
>  >The fix is usually to make sure that the appropriate declaration of a
>  >non-dependent name is visible before the name is used. Extra
>  >qualification doesn't usually help AFAICT.
>  >
>  >Oh, I guess that if the name is a member of a base class, then the fix
>  >is to write ``this->member_name'' or ``BaseClass::member_name''
>  >instead of just ``member_name''. That can be viewed as adding
>  >qualification.
>
> Yes, that was the case that came up in other libraries.
>
>  > However, that doesn't _appear_ to be the problem in the
>  >case below, and in any case I recomment using ``this->'' when possible
>  >because it's more reliable.
>
> Hum... I'll take your word for it, but to tell the truth I have
> trouble understanding what either ``this->member_name'' or
> `BaseClass::member_name'' adds. And the format library case wasn't a
> member name at all, it was an enum name, IIRC.
(Continue reading)

Permalink | Reply | 1 comment |

Gmane