[boost] [PATCH for 1.30.0] Make boost work better when BOOST_NO_WREGEXis defined
Who should I send this to, to make someone have a look at it?
---BeginMessage---
The following patch fixes some compilation problems when
BOOST_NO_WREGEX is defined (as we do in LyX). These concern OpenBSD
(first hunk: when BOOST_NO_WREGEX is defined we end up including
wchar) and something I found when trying to compile with lyxstring
(no need to define compare_string(wstring,wchar_t*)).
Note that the patch is made agaist the LyX sources, not the boost
tree.
If you want a patch that is directly applyable to boost please contact
me and I will create one.
Index: boost/ChangeLog
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/boost/ChangeLog,v
retrieving revision 1.33
diff -u -p -r1.33 ChangeLog
--- boost/ChangeLog 3 Mar 2003 15:53:39 - 1.33
+++ boost/ChangeLog 7 Mar 2003 17:20:09 -
@@ -1,3 +1,11 @@
+2003-03-07 Jean-Marc Lasgouttes [EMAIL PROTECTED]
+
+ * boost/regex/v3/regex_match.hpp (string_compare): do not declare
+ a version for wstring is BOOST_NO_WREGEX is defined.
+
+ * boost/regex/config.hpp: do not try to include cwchar and
+ cwctype when BOOST_NO_WREGEX is defined.
+
2003-03-03 Lars Gullik Bjxnnes [EMAIL PROTECTED]
* update boost to version pre-1.30.0
Index: boost/boost/regex/config.hpp
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/boost/boost/regex/config.hpp,v
retrieving revision 1.4
diff -u -p -r1.4 config.hpp
--- boost/boost/regex/config.hpp3 Mar 2003 15:53:46 - 1.4
+++ boost/boost/regex/config.hpp7 Mar 2003 17:20:09 -
@@ -125,8 +125,10 @@
// If there isn't good enough wide character support then there will
// be no wide character regular expressions:
//
-#if (defined(BOOST_NO_CWCHAR) || defined(BOOST_NO_CWCTYPE) ||
defined(BOOST_NO_STD_WSTRING)) !defined(BOOST_NO_WREGEX)
-# define BOOST_NO_WREGEX
+#if defined(BOOST_NO_CWCHAR) || defined(BOOST_NO_CWCTYPE) ||
defined(BOOST_NO_STD_WSTRING)
+# ifndef BOOST_NO_WREGEX
+#define BOOST_NO_WREGEX
+# endif
#else
# if defined(__sgi) defined(__SGI_STL_PORT)
// STLPort on IRIX is misconfigured: cwctype does not compile
Index: boost/boost/regex/v3/regex_match.hpp
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/boost/boost/regex/v3/regex_match.hpp,v
retrieving revision 1.1
diff -u -p -r1.1 regex_match.hpp
--- boost/boost/regex/v3/regex_match.hpp3 Mar 2003 15:53:46 - 1.1
+++ boost/boost/regex/v3/regex_match.hpp7 Mar 2003 17:20:09 -
@@ -56,8 +56,10 @@ inline int string_compare(const std::bas
{ return s.compare(p); }
inline int string_compare(const std::string s, const char* p)
{ return std::strcmp(s.c_str(), p); }
+# ifndef BOOST_NO_WREGEX
inline int string_compare(const std::wstring s, const wchar_t* p)
{ return std::wcscmp(s.c_str(), p); }
+# endif
# define STR_COMP(s,p) string_compare(s,p)
#endif
--
Lgb
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
---End Message---
--
Lgb
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Beta boost+spirit - VC7.1 buffer overrun error
Hi all,
I am using the VS .NET 2003 (VC7.1) on Windows 2000 and I'm porting
a Linux application on Windows. I got the BETA sources
(http://boost.sourceforge.net/regression-logs/boost_1_30_0_b1.zip)
and I give it a try, but the compiler stops with the Buffer overrun
detected! error (see Vccrash.jpg attached).
For being easier to duplicate, attached is also a sample (see
spirit-problem.cc) that has this behavior.
I have to mention that on 2003.02.18 I took the spirit sources from the cvs,
and this sample compiles
fine with those sources. That is why I assume that this is a new added
problem into the spirit sources.
As a summary, when using:
- version 1.29 of boost and cvs sources of spirit from 2003.02.18 = the
sample compiles ok
- boost 1.30 beta (boost and spirit) = the sample is not compiling ok
Can you tell me please if this is indeed a spirit problem or not?
Thanks in advance,
Viv
#include boost/spirit.hpp
#include boost/spirit/utility/chset.hpp
#include boost/spirit/attribute/closure.hpp
#include boost/spirit/phoenix/primitives.hpp
#include boost/spirit/phoenix/binders.hpp
//#include boost/phoenix/primitives.hpp
//#include boost/phoenix/binders.hpp
#include string
#include cassert
/*
compile:
g++ -Ipath-to-libs spirit-problem.cc -g -o spirit-problem
*/
using namespace std;
using namespace boost;
using namespace spirit;
using namespace phoenix;
const spirit::chsetchar lwsp_char_p( \t);
struct crlf_parser : spirit::grammarcrlf_parser
{
crlf_parser()
{
}
templatetypename scannerT
struct definition
{
definition(const crlf_parser self)
{
using namespace spirit;
first = str_p(\r\n);
}
const spirit::rulescannerT start() const
{
return first;
}
spirit::rulescannerT first;
};
};
const crlf_parser crlf_p;
struct lwsp_parser : spirit::grammarlwsp_parser
{
lwsp_parser()
{
}
templatetypename scannerT
struct definition
{
definition(const lwsp_parser self)
{
using namespace spirit;
first = lexeme_d
[
+( !crlf_p lwsp_char_p )
];
}
const spirit::rulescannerT start() const
{
return first;
}
spirit::rulescannerT first;
};
};
const lwsp_parser lwsp_p;
//---
struct content_type_line
{
const char* type;
const char* type_end;
const char* subtype;
const char* subtype_end;
const char* param;
const char* param_end;
};
struct content_type_line_closure : spirit::closurecontent_type_line_closure,
content_type_line
{
member1 val;
};
struct content_type_line_parser : spirit::grammarcontent_type_line_parser,
content_type_line_closure::context_t
{
content_type_line_parser()
{
}
templatetypename scannerT
struct definition
{
definition(const content_type_line_parser self)
{
/*
Borenstein Freed [Page 9]
RFC 1521 MIMESeptember 1993
In the Augmented BNF notation of RFC 822, a Content-Type header field
value is defined as follows:
content := Content-Type : type / subtype *(;
parameter)
; case-insensitive matching of type and subtype
type := application / audio
/ image / message
/ multipart / text
/ video / extension-token
; All values case-insensitive
extension-token := x-token / iana-token
iana-token := a publicly-defined extension token,
registered with IANA, as specified in
appendix E
x-token := The two characters X- or x- followed, with
no intervening white space, by any token
subtype := token ; case-insensitive
parameter := attribute = value
attribute := token ; case-insensitive
value := token / quoted-string
token := 1*any (ASCII) CHAR except SPACE, CTLs,
or tspecials
tspecials := ( / ) / / / @
/ , /
Re: [boost] When will be the next boost released?
I just reported it. Viv - Original Message - From: David Abrahams [EMAIL PROTECTED] To: Boost mailing list [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Monday, March 10, 2003 8:14 PM Subject: Re: [boost] When will be the next boost released? vc [EMAIL PROTECTED] writes: Have you reported this to Microsoft? No, as the guys from spirit told me that the 1.5.1 version was released before VS. NET 2003 so their code is not designed for this new compiler. That doesn't matter; any INTERNAL COMPILER ERROR represents a compiler bug that should be reported. -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ 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: possible addition to operators library
Thanks for your comments Daniel, I will update the docs with a better
rationale and post the patch soon.
As for the issue below, I also have no idea how to go about automatically
selecting either method. Plus I think this might introduce complexities
which make the compiler's job that much harder to optimise. Could well be
wrong on that though.
Essentially I think the options are to
- document its unusual behaviour in the presence of other conversion
operators
- use the private operator int method.
So if we take the plusses and minuses for each method:
safe-bool:
+ obvious error messages (see list of error messages at end)
- problems with classes that provide other user-defined conversions
operators.
- requires declaration of operator! by user, which is a bit backward.
private operator int :
+ user provides operator bool, and our helper protects it from misuse, and
provides operator!
+ no clashes with other user-defined converion operators
- fails to work with if(a func()) on MSVC 6 at least - 'operator is
ambiguous'
- less helpful diagnostic messages.
The if (a something) is quite a serious defect, but it compiles fine on
gcc 2.95.3.
So it comes down to two things,
1) How important is it to have legible diagnostics?
2) How important is it to behave properly with other user-defined
conversions?
My gut feeling is that I'd rather have the safe-bool method, but I suspect
my judgement is coloured by two things:
- I never use user defined conversion operators
- I use MSVC 6 as my main compiler, and not being able to do if (a !a)
would bother me.
San
Diagonostic samples:
--
templateclass T, class B = ::boost::detail::empty_base struct
other_bool_testable : B
{
public:
operator bool() const { return !!static_castconst T(*this); }
private:
typedef signed char private_number_type;
operator private_number_type() const;
};
#if defined(USE_OTHER_BOOL_TESTABLE)
class A : public other_bool_testableA
#else
class A : public bool_testableA
#endif
{
public:
bool operator!() const { return false; }
};
void f(int);
void g(signed char);
void test(const A a)
{
if (a !a)
{
f(a);
g(a);
}
}
MSVC 6
***
safe-bool:
test.cpp(321) : error C2664: 'f' : cannot convert parameter 1 from 'const
class A' to 'int'
No user-defined-conversion operator available that can perform this
conversion, or the operator cannot be called
private operator :
test.cpp(319) : error C2593: 'operator ' is ambiguous
// when the conversion is not an exact match to the private operator i.e.
int to signed char
test.cpp(347) : error C2664: 'f' : cannot convert parameter 1 from 'const
class A' to 'int'
Ambiguous user-defined-conversion
//when it is an exact match
test.cpp(322) : error C2248: 'operator`signed char'' : cannot access private
member declared in class 'other_bool_testableclass A,class
boost::detail::empty_base'
C:\Work\SS\debugger\CodeScape\CBuilder.cpp(323) : see declaration of
'operator`signed char''
gcc 2.95.3 :
*
safe-bool:
test.cpp: In function `void test(const A )':
test.cpp:32: `const class A' used where a `int' was expected
with the private operator some_number() :
// if the private operator is not an exact match (e.g signed char to an int)
test.cpp:32: conversion from `const A' to `int' is ambiguous
test.cpp:6: candidates are:
other_bool_testableA,boost::detail::empty_base::operator bool() const
test.cpp:9:
other_bool_testableA,boost::detail::empty_base::operator signed char()
const
// if the private operator is an exact match you get
test.cpp:32: conversion from `const A' to `signed char' is ambiguous
test.cpp:6: candidates are:
other_bool_testableA,boost::detail::empty_base::operator bool() const
test.cpp:9:
other_bool_testableA,boost::detail::empty_base::operator signed char()
const
test.cpp:9: `other_bool_testableA,boost::detail::empty_base::operator
signed char() const' is private
test.cpp:35: within this context
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Beta boost+spirit - VC7.1 buffer overrun error
vc wrote: Hi all, I am using the VS .NET 2003 (VC7.1) on Windows 2000 and I'm porting a Linux application on Windows. I got the BETA sources (http://boost.sourceforge.net/regression-logs/boost_1_30_0_b1.zip) and I give it a try, but the compiler stops with the Buffer overrun detected! error (see Vccrash.jpg attached). For being easier to duplicate, attached is also a sample (see spirit-problem.cc) that has this behavior. I have to mention that on 2003.02.18 I took the spirit sources from the cvs, and this sample compiles fine with those sources. That is why I assume that this is a new added problem into the spirit sources. As a summary, when using: - version 1.29 of boost and cvs sources of spirit from 2003.02.18 = the sample compiles ok - boost 1.30 beta (boost and spirit) = the sample is not compiling ok Can you tell me please if this is indeed a spirit problem or not? What compiler errors are you getting? If it's the attached Buffer overrun detected! error, then that's clearly a VC7.1 compiler bug. Anyway, since this is clearly a Spirit support related question, please post your reply to Spirit-general mailing list: [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/spirit-general Let's continue our discussion there. See 'ya, -- 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
[boost] tokenizer: Feature request: keep quotes with escaped_list_separator
Dear all, I need to split a string into tokens, and split the resulting tokens again in a second pass. Currently, I do this with boost::tokenizer initialized with an escaped_list_separator. The problem is that all the quote characters are swallowed during the first pass, which makes things rather ugly at the second time. One workaround I thought of, namely to use two different (sets of) quote characters, is inacceptable in our case. Are there any other? If not, it would be rather nice to have a switch to tell escaped_list_separator whether it should drop quotes or keep quotes. - Roland ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] [PATCH for 1.30.0] Make boost work better whenBOOST_NO_WREGEXis defined
Who should I send this to, to make someone have a look at it? Probably me, but I'm tied up right now, will be back around here once I get cvs etc working on my new PC. John. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] boost/limits.hpp Itanium2 RC_1_30_0
At 08:12 PM 3/10/2003, David Abrahams wrote: OK to check this into the RC_1_30_0 branch? Go for it! You don't need to ask permission to make stuff work. (it's nice to notify the list when you do, though) It helps me too; I'm trying to track outstanding issues with RC_1_30_0, so it helps to know when an issue is closed. --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] release procedure typo(?)
Gennadiy Rozental [EMAIL PROTECTED] writes: P.S. Could you, please, clarify for me again what is the purpose of this tag? How does it related to the fixes I made in trunk after branch is created? The tag marks the last trunk revision that has been merged into the branch, so that when you do a merge to the branch you can always do cvs up -jmerged_to_RC_whatever -jHEAD Then when you switch back to the trunk (HEAD) you move the merged_to_RC_whatever tag to point at the HEAD again. -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] fixes to release_procedures.htm
At 04:16 AM 3/10/2003, Martin Wille wrote: the attached patch fixes two typos in the release procedures document. Fixed. Thanks! --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] release procedure typo(?)
At 12:23 AM 3/11/2003, Gennadiy Rozental wrote: Hi, Beman In examples for release procedure you are using: merged_to_1_26_2. While in Release Procedures for the Release Manager section you are mention: merged_to_RC_n_n_n. What is correct? Should read merged_to_RC_1_26_2. Martin Wille already submitted a patch. P.S. Could you, please, clarify for me again what is the purpose of this tag? How does it related to the fixes I made in trunk after branch is created? I've added a FAQ to the page: What is the purpose of the merged_to_RC_n_n_n tag? This tag allows multiple merges from the main trunk to the release candidate branch. Without it, merging an initial main trunk fix into the release candidate branch would work, but merging a second fix from main trunk to release candidate branch would result in a merge conflict. Although this procedure seems convoluted, it works much better in practice than several prior procedures we tried. HTH, --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: release procedure typo(?)
P.S. Could you, please, clarify for me again what is the purpose of this tag? How does it related to the fixes I made in trunk after branch is created? The tag marks the last trunk revision that has been merged into the branch, so that when you do a merge to the branch you can always do cvs up -jmerged_to_RC_whatever -jHEAD Then when you switch back to the trunk (HEAD) you move the merged_to_RC_whatever tag to point at the HEAD again. Imagine I change the file abc.cpp. 1. I commited it im main trank: cvs commit abc.cpp 2. I tag it with merged_to_RC_whatever tag (? this is not in a procedure right now) 3. I merge it to the release branch Additionally if I need to change it again, before step 2 Iwill nedd to untag it: cvs tag -d merged_to_RC_whatever, which is also is not in release procedure right now. Did I get it correct? Gennadiy. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Meta programming 'debug' mode.
On Mon, 10 Mar 2003 20:41:26 -0800, Jaap Suter [EMAIL PROTECTED] wrote: #define BOOST_STATIC_ASSERT(c) \ typedef char boost_static_assert_typedef When using several asserts in the same context some compilers could complain about the duplicate typedef; if so pasting the expansion of __LINE__ shouldn't be that expensive either. That seems indeed the best solution to me (with the __LINE__ included) as most of the time is spend in calculations for the actual expression. In effect I would prefer the one without __LINE__. But if any compiler warns about duplicate typedefs than it's better having a single version, with __LINE__, than #ifs. Also I have a slight preference for using void instead of char, as suggested by Greg: typedef void boost_static_assert_typedef But all this conjectures should be backed up by some measurement. Jaap? Agreed. I will do some measurements this week and report back in a few days. Nice :-) Genny. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: release procedure typo(?)
Gennadiy Rozental [EMAIL PROTECTED] writes: P.S. Could you, please, clarify for me again what is the purpose of this tag? How does it related to the fixes I made in trunk after branch is created? The tag marks the last trunk revision that has been merged into the branch, so that when you do a merge to the branch you can always do cvs up -jmerged_to_RC_whatever -jHEAD Then when you switch back to the trunk (HEAD) you move the merged_to_RC_whatever tag to point at the HEAD again. Imagine I change the file abc.cpp. 1. I commited it im main trank: cvs commit abc.cpp 2. I tag it with merged_to_RC_whatever tag (? this is not in a procedure right now) 3. I merge it to the release branch No, you got 2 and 3 reversed, and you only do the tagging after switching back to the trunk. Additionally if I need to change it again, before step 2 Iwill nedd to untag it: cvs tag -d merged_to_RC_whatever, Absolutely not. which is also is not in release procedure right now. Did I get it correct? I guess not. The procedures as written are absolutely perfect. Why second-guess them? -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: release procedure typo(?)
At 10:36 AM 3/11/2003, Gennadiy Rozental wrote: P.S. Could you, please, clarify for me again what is the purpose of this tag? How does it related to the fixes I made in trunk after branch is created? The tag marks the last trunk revision that has been merged into the branch, so that when you do a merge to the branch you can always do cvs up -jmerged_to_RC_whatever -jHEAD Then when you switch back to the trunk (HEAD) you move the merged_to_RC_whatever tag to point at the HEAD again. Imagine I change the file abc.cpp. 1. I commited it im main trank: cvs commit abc.cpp 2. I tag it with merged_to_RC_whatever tag (? this is not in a procedure right now) No! abc.cpp will already have been tagged with merged_to_RC_whatever by the release manager (or by you, if you had previously applied a fix according to the procedure.) 3. I merge it to the release branch Additionally if I need to change it again, before step 2 Iwill nedd to untag it: cvs tag -d merged_to_RC_whatever, which is also is not in release procedure right now. Did I get it correct? No. AFAIK, the release procedure is correct as written, modulo typos. I've been using the WinCVS version repeatedly for the better part of a week now, and it is working like a charm. Much easier than previous procedures. Please look at the procedure again and see if it is still unclear. Thanks, --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Darwin regression tests
The must be something wrong with the current darwin regression tests, AFAICT. I just completed a full regression run of the latest RC version and I get far lower failure rates that the current regression results indicate (9% failures instead of 45%). I uploaded the results to the regression tests directory, they can be found here: http://boost.sourceforge.net/regression-logs/cs-Darwin-RC_1_30_0.html I don't know the exact version of MacOS installed, but I would guess it's the latest one available. Markus ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Boost I/O Library Review (Ed B.)
First, a reminder that today is the last day for sumbitting a review for the update to the I/O library. This is my review of the I/O library, which is separate from my role as review manager. I vote that the library update be accepted into boost. I examined the documentation and code. The new manipulaters will certainly be handy. The streambuf and array stream components will be used less often, but have their place. Following are suggestions for improvement: Code/design suggestions: array_stream.hpp: - In the basic_array_stream classes, the char_type and traits_type definitions seem to duplicate those provided by the basic_wrapping_istream base class. - The functions in the three basic_array_stream classes could be factored into a single base class to avoid copied code. - Why stop at stream buffers? Why not define array_stream templates? Specific documentation suggestions: streambuf_wrapping: - Provide a short hello world example at the beginning of the documentation showing how the library is useful. Since I haven't had reason to explicitly work with stream buffers for many months, it was very confusing coming on cold to this library. For the example, the reader should be able to deduce how the library makes his life easier versus not using it. Clearly, your array stream class would serve as a good example, but it needs to be digested down to a one minute tutorial version for the streambuf_wrapping documentation. array_stream: - Here again, a motivating example would be a good start to the documentation, especially if there is an array_stream class ready to use out-of-the-box. An example could be formatting I/O for output to a fixed-character device such as an LCD. iomanip: - skipl: Rationale: a dual to boost::io::newl - Rationale: a counterpart to newl General documentation comments: - Remove references to namespace boost:io, except once in the documentation header. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: release procedure typo(?)
1. I committed it in main trunk: cvs commit abc.cpp 2. I tag it with merged_to_RC_whatever tag (? this is not in a procedure right now) 3. I merge it to the release branch No, you got 2 and 3 reversed, and you only do the tagging after switching back to the trunk. I got it now. May be we could spell out explicitly what we are merging into branch: namely the deference between merged_to_RC_whatever and HEAD tags. Not all that fluent with cvs flags. Additionally if I need to change it again, before step 2 I will need to untag it: cvs tag -d merged_to_RC_whatever, Absolutely not. A! I missed -F flag. Maybe we should spell it out explicitly? Gennadiy. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Meta programming 'debug' mode.
Gennaro Prota wrote: On Mon, 10 Mar 2003 20:41:26 -0800, Jaap Suter [EMAIL PROTECTED] wrote: #define BOOST_STATIC_ASSERT(c) \ typedef char boost_static_assert_typedef When using several asserts in the same context some compilers could complain about the duplicate typedef; if so pasting the expansion of __LINE__ shouldn't be that expensive either. That seems indeed the best solution to me (with the __LINE__ included) as most of the time is spend in calculations for the actual expression. In effect I would prefer the one without __LINE__. But if any compiler warns about duplicate typedefs than it's better having a single version, with __LINE__, than #ifs. Also I have a slight preference for using void instead of char, as suggested by Greg: typedef void boost_static_assert_typedef Perhaps I missed a part of the discussion, but what is wrong with Jaap's suggestion: #ifdef BOOST_STATIC_NDEBUG #define BOOST_STATIC_ASSERT( B ) BOOST_STATIC_ASSERT_IMPL( true ) #else #define BOOST_STATIC_ASSERT( B ) BOOST_STATIC_ASSERT_IMPL( B ) #endif ? But all this conjectures should be backed up by some measurement. Jaap? Agreed. I will do some measurements this week and report back in a few days. Nice :-) Indeed. :) Dirk Gerrits ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: release procedure typo(?)
Gennadiy Rozental [EMAIL PROTECTED] writes: I got it now. May be we could spell out explicitly what we are merging into branch: namely the deference between merged_to_RC_whatever and HEAD tags. Not all that fluent with cvs flags. snip A! I missed -F flag. Maybe we should spell it out explicitly? It looks pretty explicit to me. If you think it can be improved, please propose a doc patch. -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] [BGL] subgraph isomorphism algorithm
For those of you interested in subgraph isomorphism, I put a raw version of Ullmann's algorithm at http://groups.yahoo.com/group/boost/files/ullmann.hpp It uses BGL's interface. Regards, -- vladimir josef sykora morphochem AG gmunder str. 37-37a 81379 muenchen tel. ++49-89-78005-0 fax ++49-89-78005-555 [EMAIL PROTECTED] http://www.morphochem.de ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: Re: release procedure typo(?)
It looks pretty explicit to me. If you think it can be improved,
please propose a doc patch.
May be like this. See the patch attached.
Gennadiy.
begin 666 release_procedures.diff
[EMAIL PROTECTED](')E;5AV5?')O8V5D=7)ERYH=T-CT]/3T]/3T]/3T]/3T]
M/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]
M/3T]/3T]/3T-E)#4R!F:6QE.B O8W9SF]O=]B;V]S=]B;V]S=]M;W)E
M+W)E;5AV5?')O8V5D=7)ERYH=[EMAIL PROTECTED]F5TFEE=FEN9R!R979IVEO
M;B Q+C8-[EMAIL PROTECTED]@+7(Q+C8@F5L96%S95]PF]C961UF5S+FAT;0T*
M+2TM(')E;5AV5?')O8V5D=7)ERYH=T),[EMAIL PROTECTED](#(P,#,@,30Z,[EMAIL PROTECTED]
M,S@@+3 P,# ),2XV#0HK*RL@F5L96%S95]PF]C961UF5S+FAT;0DQ,2!-
M87(@,C P,R Q-SHT-3HS-2 M,# P, T*0$ @[EMAIL PROTECTED](LX-RPS,2! 0 T*
M( @( \;D^0V]M;6%N9!,:6YE($-64SH\+VQI/@T*( @/]U;#X-B @
M(#QB;]C:W%U;W1E/@T*+2 @( \')E/EM!9G1EB!F:7AE9!C;V1E(ES
M(-O;6UI='1E9!T;R!M86EN()R86YC:%T-BUC=G,@=7!D871E(UR(%)#
M7S%?,C9?,B!;W=I=-H('1O('1H92!R96QE87-E(-A;F1I9%T92!BF%N
M8VA=#0HM8W9S('5P9%T92 M:CQA(AR968](B-M97)G961?=]?4D-?;E]N
M7VXB/FUEF=E9%]T;U]20U\Q7S(V7S(\+V$^(UJ2$5!1!B=6=G6-O94N
M:'!P(%MM97)G92!C:%N9V5S(9R;[EMAIL PROTECTED]')U;[EMAIL PROTECTED][EMAIL
PROTECTED])A;F-H70T**R @
M( \=6P^#0HK( @( @/QI/D9I5D(-O94@:7,@8V]M;6ET=5D('1O
M(UA:[EMAIL PROTECTED])A;F-H#0HK( @( @/]L:3X-BL@( @( \;D^4W=I=-H
M('1O('1H92!R96QE87-E(-A;F1I9%T92!B[EMAIL PROTECTED]BL@( @( @( \
M+W!R93YC=G,@=7!D871E(UR(%)#7S%?,C9?,CPO')E/@T**R @( @(#PO
M;D^#0HK( @( @/QI/DUEF=E(-H86YG97,@:[EMAIL PROTECTED]G5N:R!S:6YC
M92!PF5V:6]S(UEF=E('1O()R86YC: T**SQPF4^8W9S('5P9%T92 M
M:CQA(AR968](B-M97)G961?=]?4D-?;E]N7VXB/FUEF=E9%]T;U]20U\Q
M7S(V7S(\+V$^(UJ2$5!1!B=6=G6-O94N:'!P#0H@(TM)F=T.R!20U,@
[EMAIL PROTECTED]W)O;W0O8F]OW0O+BXN+V)U9V=Y8V]D92YH' [EMAIL PROTECTED]( M
M+29G=#L@( @F5TFEE=FEN9R!R979IVEO;B Q+C0-B @+2TF9W0[( @
M(')E=')I979I;F@F5V:7-I;VX@,2XV#0HM(TM)F=T.R @(!-97)G:6YG
M(1I9F9EF5N8V5S()E='=E96X@,2XT(%N9 Q+C8@:6YT;R!B=6=G6-O
M94N:'!P#0HM#0HM8W9S(-O;6UI= M;2 F75O=#M-97)[EMAIL PROTECTED](9O
MB!PF]B;5M('AYB!FF]M('1R=6YK('1O()R86YC:9Q=6]T.R!B=6=G
M6-O94N:'!P#0HM8W9S('5P9%T92 M02!;[EMAIL PROTECTED]:R!T;R!M86EN('1R
M=6YK70T*+6-VR!T86@[EMAIL PROTECTED],@;65R9V5D7W1O7U)#7S%?,CA?,B!B=6=G
M6-O94N:'!P(%MT86@;F5W(UEF=E9!P;VEN=%T-BT-BU;4F5P96%T
M(%S(YE961E9%T\+W!R93X-[EMAIL PROTECTED]( @($UEF=I;F@9EF9F5R
M96YC97,@8F5T=V5E;B [EMAIL PROTECTED](#$N-B!I;G1O()U9V=Y8V]D92YH' \
M+W!R93X-BL@( @( \+VQI/@T**R @( @(#QL:3Y#;VUM:70@;65R9V5D
M()R86YC: T**SQPF4^8W9S(-O;6UI= M;2 F75O=#M-97)[EMAIL PROTECTED]
M(9OB!PF]B;5M('AYB!FF]M('1R=6YK('1O()R86YC:9Q=6]T.R!B
M=6=G6-O94N:'!P/]PF4^#0HK( @( @/]L:3X-BL@( @( \;D^
[EMAIL PROTECTED]:R!T;R!M86EN('1R=6YK#0HK/'!R93YC=G,@=7!D871E(U!/]P
MF4^#0HK( @( @/]L:3X-BL@( @( \;D^36]V92!T86@=[EMAIL PROTECTED]
M97@;65R9V5D('!O:6YT#0HK/'!R93YC=G,@=%G(U(UC(UEF=E9%]T
M;U]20U\Q7S(X7S(@8G5G9WEC;V1E+FAP#PO')E/@T**R @( @(#PO;D^
M#0HK( @( @/QI/E)E5A=!AR!N965D960-BL@( @( \+VQI/@T*
M*R @( \+W5L/@T*( @/]B;]C:W%U;W1E/@T*( @/'5L/@T*( @( \
1;D^5VEN0U93.CPO;D^#0H`
`
end
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Bidirectionnal map
Hi, After a quick Google search, I found out that Joaquín M López, the author of a bidirectionnal map hosted on codeproject sent a message (Mon, 21 Oct 2002 21:29:18) on the boost mailing list to promote his library. David B. Held replied about using his work to include the bidirectionnal map to boost, to avoid library proliferation. So now, here's my question : Nearly 5 months later, did anyone work on this bimap? Will it be included anytime soon in an official distribution of boost? Thanks a lot for your time Cheers, Eric ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Meta programming 'debug' mode.
On Tue, 11 Mar 2003 17:46:17 +0100, Dirk Gerrits
[EMAIL PROTECTED] wrote:
In effect I would prefer the one without __LINE__. But if any compiler
warns about duplicate typedefs than it's better having a single
version, with __LINE__, than #ifs.
Also I have a slight preference for using void instead of char, as
suggested by Greg:
typedef void boost_static_assert_typedef
Perhaps I missed a part of the discussion, but what is wrong with Jaap's
suggestion:
#ifdef BOOST_STATIC_NDEBUG
#define BOOST_STATIC_ASSERT( B ) BOOST_STATIC_ASSERT_IMPL( true )
#else
#define BOOST_STATIC_ASSERT( B ) BOOST_STATIC_ASSERT_IMPL( B )
#endif
?
Well, considering that what we want is just a no-op, which do you
prefer?
a) typedef ::boost::static_assert_test
sizeof(::boost::STATIC_ASSERTION_FAILURE (bool)( true ) )
BOOST_JOIN(boost_static_assert_typedef_, __LINE__);
(I've just picked up one of the implementations in static_assert.hpp,
but the others don't differ too much.)
b) typedef void boost_static_assert_typedef;
As I said however, there can be compilers that warn about duplicate
typedefs like
namespace xyz {
typedef void boost_static_assert_typedef;
typedef void boost_static_assert_typedef;
}
(To be honest, I'm afraid some compiler even gives an error, confusing
the C rule with the C++ one. But I don't know of any (fortunately
:-)). Anyhow, let's not put the cart before the horse. If such a
compiler shows up then we'll consider using __LINE__; before that,
let's just use
typedef void boost_static_assert_typedef
Genny.
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Bad links on regression log cs-win32-RC_1_30_0.html
All the links to warnings/fails point to the d: drive and so are a little inaccessible right now g Also, is there any way to get the 'differences emphasised' view? Often a single test starts passing/failing and it is very hard to locate which one has changed, especially without the previous test results for reference. -- AlisdairM ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Meta programming 'debug' mode.
Gennaro Prota wrote: On Tue, 11 Mar 2003 17:46:17 +0100, Dirk Gerrits [EMAIL PROTECTED] wrote: Perhaps I missed a part of the discussion, but what is wrong with Jaap's suggestion: #ifdef BOOST_STATIC_NDEBUG #define BOOST_STATIC_ASSERT( B ) BOOST_STATIC_ASSERT_IMPL( true ) #else #define BOOST_STATIC_ASSERT( B ) BOOST_STATIC_ASSERT_IMPL( B ) #endif ? Well, considering that what we want is just a no-op, which do you prefer? a) typedef ::boost::static_assert_test sizeof(::boost::STATIC_ASSERTION_FAILURE (bool)( true ) ) BOOST_JOIN(boost_static_assert_typedef_, __LINE__); (I've just picked up one of the implementations in static_assert.hpp, but the others don't differ too much.) b) typedef void boost_static_assert_typedef; The effect is the same. However, (a) or BOOST_STATIC_ASSERT_IMPL( true ) avoids all of the (potential?) problems you are worrying about. So why do you prefer (b)? Regards, Dirk Gerrits ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Bidirectionnal map
Eric Martel [EMAIL PROTECTED] writes: Hi, After a quick Google search, I found out that Joaquín M López, the author of a bidirectionnal map hosted on codeproject sent a message (Mon, 21 Oct 2002 21:29:18) on the boost mailing list to promote his library. David B. Held replied about using his work to include the bidirectionnal map to boost, to avoid library proliferation. So now, here's my question : Nearly 5 months later, did anyone work on this bimap? Will it be included anytime soon in an official distribution of boost? Not unless someone requests a formal review and takes it through the formal review process. -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] 1.30.0-b1: filesystem::path::swap
At 03:23 AM 3/10/2003, Geurt Vos wrote: Hi, Is there any reason boost::filesystem::path doesn't provide a swap(path ) function? If there is, I think the docs should explain why, but if there isn't, well, can it still be implemented before 1.30.0 goes gold? Let me turn the question around and ask what your expectations would be for a swap member beyond what is already offered by std::swap? No throw guarantee? More efficient? Or are you asking that filesystem::path satisfy more container requirements? --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Bidirectionnal map
Eric Martel [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] [...] Nearly 5 months later, did anyone work on this bimap? I didn't. ;) Will it be included anytime soon in an official distribution of boost? Not unless someone ambitious like you decides to work on it some more. ;) Dave ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: I/O library formal review
* The Rationale for Array-Based Streams concludes it may have real-life applications. It would be a bit more satisfying if there was at least one example of a real-life application. I second this. Could anybody show an example where array_stream would be preferable to stringstream. In other case I do not see a reason to include this component. Maybe only as an example in .../lib/io/example * newl needs a bit more rationale. How is cout newl different from cout '\n'? How is it better? Maybe newl does not reset the manipulators? If it true it should be spelled out explicitly. In any case I also like to see an example where newl is preferable to '\n'. Gennadiy. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Bad links on regression log cs-win32-RC_1_30_0.html
At 03:57 PM 3/11/2003, Alisdair Meredith wrote: All the links to warnings/fails point to the d: drive and so are a little inaccessible right now g Argh! I've been fooling around with the setup to allow running tests on both the main trunk and the release candidate, and that is clearly having some unexpected fallout. No promises as to when it will be fixed, but we really do need to address linking problems permanently. Perhaps by pointing the links at CVS. Also, is there any way to get the 'differences emphasised' view? Often a single test starts passing/failing and it is very hard to locate which one has changed, especially without the previous test results for reference. I know! That's my favorite too. But the procedure for generating it is a horrible hack done just to prove the concept. The permanent solution would be to keep the information in the .xml file. No idea when that might be implemented, however:-( It would be particularly nice to be able to see history, but that may be a dream for the distant future. Thanks, --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] date_time on gcc linux
M. Andre wrote: So I guess the config isn't included in all files? According to the docs #include boost/date_time/posix_time/posix_time_types.hpp is an available header file with definitions without io. Looks like I introduced a bug here. Will fix. Thx, Jeff ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Spirit and regression tests
Is there any reason the Spirit tests are not integrated into the regression suite at the moment? I just updated status\jamfile to test locally and the only problem I had was an MT test running away for a VC7 build diff below === RCS file: /cvsroot/boost/boost/status/Jamfile,v retrieving revision 1.106 diff -r1.106 Jamfile 30a31 subinclude libs/spirit/test ;# test-suite spirit -- AlisdairM Team Thai Kingdom ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: possible addition to operators library
On Tue, 11 Mar 2003 12:22:19 +0100, Sam Partington wrote: As for the issue below, I also have no idea how to go about automatically selecting either method. Plus I think this might introduce complexities which make the compiler's job that much harder to optimise. Could well be wrong on that though. Optimization won't bother me that much as it should all be compile-time magic. It still has to be verified but before that, we need something that we can verify. :) Essentially I think the options are to - document its unusual behaviour in the presence of other conversion operators - use the private operator int method. So if we take the plusses and minuses for each method: safe-bool: + obvious error messages (see list of error messages at end) This is from the convenience section IMHO. But it's important. - problems with classes that provide other user-defined conversions operators. A technical thing. The question is, what do we prefer? I personally prefer a technical advantage as it creates safer overall code. I am used to work with several people in a large code-base and in my experience it's always a very helpful thing if the interface of your code leads to compile-errors when misused. Documentation will help you to reject the responsibility - it won't help you to get the job done. If the compiler rejects your code and the error message itself is anything but clear, you are at least forced to work on it. That's not nice in the moment you are faced with it, but in the long term it pays. The alternative (keep the safe-bool and document it) leads to hidden bugs that are IMHO hard to find. Remember that we have a very close view to a tiny code fraction. Imagine it to be the part of a 100.000 lines project. It compiles without a warning but calls operator int() instead of operator!(). So it comes down to two things, 1) How important is it to have legible diagnostics? 2) How important is it to behave properly with other user-defined conversions? The latter will probably be the result of a colleague adding operator int() 6 month after you developed the class. What formerly worked correctly turns into a bug silently and you will - depening on your definition of operator int() not necessarily notice it in the beginning. Maybe - and we all know Murphy - it provides the correct semantics in 99.9% of all cases. That's a nice bug to trace, isn't it? But these are just my personal opinions, other opinions welcome. My gut feeling is that I'd rather have the safe-bool method, but I suspect my judgement is coloured by two things: - I never use user defined conversion operators - I use MSVC 6 as my main compiler, and not being able to do if (a !a) would bother me. The VC issue bothers me, as I don't think I fully understand what exactly happens. Doesn't the compiler give any additional messages to explain what exactly is ambiguous for operator? Does anyone know this problem and has a work-around? Regards, Daniel ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Jamfile patches for Borland
Borland fails several tests due to missing exports from limits in its dynamic runtime library. The following two patches will use static linking on the problem libraries (for borland only) BOOST_ROOT/status jamfile for config/limits test cvs diff Jamfile (in directory C:\Projects\3rdParty\boost\status) Index: Jamfile === RCS file: /cvsroot/boost/boost/status/Jamfile,v retrieving revision 1.106 diff -r1.106 Jamfile 30a31 subinclude libs/spirit/test ;# test-suite spirit 48,49c49,56 [ run libs/config/test/config_info.cpp : : : test-infoalways_show_run_output ] [ run libs/config/test/limits_test.cpp lib../libs/test/build/boost_test_exec_monitor ] --- [ run libs/config/test/config_info.cpp : : : test-infoalways_show_run_output ] [ run libs/config/test/limits_test.cpp lib../libs/test/build/boost_test_exec_monitor : #args : #input-files : borland*runtime-linkstatic # uses limits; borland toolset doesn't have a complete limits in the dynamic library ] Also, numeric/interval/test/jamfile cvs diff Jamfile (in directory C:\Projects\3rdParty\boost\libs\numeric\interval\test\) Index: Jamfile === RCS file: /cvsroot/boost/boost/libs/numeric/interval/test/Jamfile,v retrieving revision 1.2 diff -r1.2 Jamfile 17,23c17,57 [ run libs/numeric/interval/test/add.cpp ] [ run libs/numeric/interval/test/det.cpp ] [ run libs/numeric/interval/test/fmod.cpp ] [ run libs/numeric/interval/test/mul.cpp ] [ run libs/numeric/interval/test/overflow.cpp ] [ run libs/numeric/interval/test/pi.cpp ] [ run libs/numeric/interval/test/pow.cpp ] --- [ run libs/numeric/interval/test/add.cpp : #args : #input-files : borland*runtime-linkstatic # uses limits; borland toolset doesn't have a complete limits in the dynamic library ] [ run libs/numeric/interval/test/det.cpp : #args : #input-files : borland*runtime-linkstatic # uses limits; borland toolset doesn't have a complete limits in the dynamic library ] [ run libs/numeric/interval/test/fmod.cpp : #args : #input-files : borland*runtime-linkstatic # uses limits; borland toolset doesn't have a complete limits in the dynamic library ] [ run libs/numeric/interval/test/mul.cpp : #args : #input-files : borland*runtime-linkstatic # uses limits; borland toolset doesn't have a complete limits in the dynamic library ] [ run libs/numeric/interval/test/overflow.cpp : #args : #input-files : borland*runtime-linkstatic # uses limits; borland toolset doesn't have a complete limits in the dynamic library ] [ run libs/numeric/interval/test/pi.cpp : #args : #input-files : borland*runtime-linkstatic # uses limits; borland toolset doesn't have a complete limits in the dynamic library ] [ run libs/numeric/interval/test/pow.cpp : #args : #input-files : borland*runtime-linkstatic # uses limits; borland toolset doesn't have a complete limits in the dynamic library ] 26c60,65 lib../../../test/build/boost_test_exec_monitor ] --- lib../../../test/build/boost_test_exec_monitor : #args : #input-files : borland*runtime-linkstatic # uses limits; borland toolset doesn't have a complete limits in the dynamic library ] 28c67,72 lib../../../test/build/boost_test_exec_monitor ] --- lib../../../test/build/boost_test_exec_monitor : #args : #input-files : borland*runtime-linkstatic # uses limits; borland toolset doesn't have a complete limits in the dynamic library ] 30c74,79 lib../../../test/build/boost_test_exec_monitor ] --- lib../../../test/build/boost_test_exec_monitor : #args : #input-files : borland*runtime-linkstatic # uses limits; borland toolset doesn't have a complete limits in the dynamic library ] 32c81,85 lib../../../test/build/boost_test_exec_monitor ] --- lib../../../test/build/boost_test_exec_monitor : #args : #input-files : borland*runtime-linkstatic # uses limits; borland toolset doesn't have a complete limits in the dynamic library ] -- AlisdairM ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Jamfile patches for Borland
While I realize it may be the only answer to the problems you mention, making libraries link to the static RTL where they would normally link to the dynamic RTL is IMHO a bad general solution. My reason for thinking this is the problems which always seem to occur when modules mix static and dynamic RTL routines in their linkage to other libraries. I can't prove this always causes problems but I have seen where using either all dynamic RTL or all static RTL when creating an executable and accompanying libraries is always a safe run-time solution, at least as far as reusability of the RTL is concerned. Alisdair Meredith wrote: Borland fails several tests due to missing exports from limits in its dynamic runtime library. The following two patches will use static linking on the problem libraries (for borland only) snip... ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] token_iterator: Feature request: return refernce totoken_function
I would like to suggest a change to token_iterator.hpp. I need my
token_iterator's token_function to be able to accumulate state. Therefore,
I would like to add the following public method to class
boost::detail::tokenizer_policyType, TokenizerFunc :
const TokenizerFunc func() const {return func_;}
Note that since the TokenizerFunc is owned by the token_iterator, there is
no chance of losing information if the token_iterator is copied inside some
algorithm. Also, because this function returns a const reference to the
TokenizerFunc, and both reset() and operator() are non-const member
functions of TokenizerFunc, the user will not be able to call either reset()
or operator() on the token_function using this method. The only use for
func() will be to get public state information out of the token_function,
which is precisely what I need.
Joe Gottman
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Jamfile patches for Borland
Alisdair Meredith [EMAIL PROTECTED] escribió en el mensaje news:[EMAIL PROTECTED] Borland fails several tests due to missing exports from limits in its dynamic runtime library. The following two patches will use static linking on the problem libraries (for borland only) I'm not sure if this is correct because the problem is not with boost but with STLPort numeric_limits as shipped with BCB6. (I reported this before). The problem I see is that the test will now pass but becasue of a particular condition (the static RTL). As a boost user, I wouldn't expect a 'Passed' to require something which is not explicit in the regression results and which is not very common. It wouldn't be so much of a problem, IMHO, if the status tables contained an additional column showing particular uncommon constrians. Fernando Cacciola ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: C++ Standards Committee upcoming meeting
At 07:12 PM 3/11/2003, Dietmar Kuehl wrote: Beman Dawes wrote: The C++ Standards Committee will be meeting in Oxford, UK, April 7th through 11th. As always, Boosters are welcome to attend as technical experts - See http://www.boost.org/more/cpp_committee_meetings.html. Is there going to be general Boost meeting on Sunday something like this? At the last meetings there always was some kind of Boost meeting, at least for meeting Boosters in person. Doug Gregor is tentatively planning to host a session on the Boost documentation system he has been working on. No date or time yet.c Doug, how are your plans shaping up? --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Spirit and regression tests
At 07:07 PM 3/11/2003, Alisdair Meredith wrote: Is there any reason the Spirit tests are not integrated into the regression suite at the moment? Too much for 1.30.0. The same applies to Boost.Python. As soon as 1.30.0 ships we need to review a bunch of operational issues, including regression tests, to see where to go from here. --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Jamfile patches for Borland
At 08:27 PM 3/11/2003, Alisdair Meredith wrote: Borland fails several tests due to missing exports from limits in its dynamic runtime library. One question: Is there any way to work around the missing exports by adding some Borland specific code to boost/limits.hpp? Or would that just cause problems if the user happened to link staticly? --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: C++ Standards Committee upcoming meeting
On Tuesday 11 March 2003 09:20 pm, Beman Dawes wrote: Doug Gregor is tentatively planning to host a session on the Boost documentation system he has been working on. No date or time yet.c Doug, how are your plans shaping up? --Beman I'm mainly working on usability issues now, most importantly moving the tools into their final places in the Boost CVS repository (unless there are any objections?), teaching BBv2 to handle BoostBook documents (need... help... from... experts...), and getting some good reference documentation together. As it stands, the system itself is in good shape, and the documentation for libraries I've redocumented in BoostBook is quite reasonably. I still think a BoostBook overview/tutorial at Oxford would be beneficial. Doug ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
