[boost] Re: Boost talks at ACCU
Beman Dawes wrote: There are going to be several talks about Boost libraries or related topics at the ACCU conference in Oxford, UK, April 2nd through 5th: I'm going to present dynamic_any library there after the main program ( Birds of a Feather meetings section). Though it's not yet in Boost but it may be of interest anyway. Details already discussed with Francis Glassborow, David Abrahams and Douglas Gregor through private e-mail. See you there! -- Alexander Nasonov Remove minus and all between minus and at from my e-mail for timely response ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] fixes to release_procedures.htm
Hi, the attached patch fixes two typos in the release procedures document. Regards, m Index: release_procedures.htm === RCS file: /cvsroot/boost/boost/more/release_procedures.htm,v retrieving revision 1.5 diff -u -r1.5 release_procedures.htm --- release_procedures.htm 6 Mar 2003 18:42:49 - 1.5 +++ release_procedures.htm 10 Mar 2003 09:13:21 - @@ -87,7 +87,7 @@ blockquote pre[After fixed code is committed to main branch] cvs update -r RC_1_26_2 [switch to the release candidate branch] -cvs update -jmerged_to_1_26_2 -jHEAD buggycode.hpp [merge changes from the trunk to the branch] +cvs update -jmerged_to_RC_1_26_2 -jHEAD buggycode.hpp [merge changes from the trunk to the branch] --gt; RCS file: /cvsroot/boost/.../buggycode.hpp,v --gt;retrieving revision 1.4 --gt;retrieving revision 1.6 @@ -115,7 +115,7 @@ pMerge changes from main trunk into the release candidate branch:/p blockquote pModify | Update selection... | -Update settings | Merge options | Only this rev/tag: codemerged_to_1_26_2/code +Update settings | Merge options | Only this rev/tag: codemerged_to_RC_1_26_2/code | Plus with this rev/tag: codeHEAD/code | OK/p /blockquote pCommit merge results:/p @@ -151,4 +151,4 @@ /body -/html \ No newline at end of file +/html ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: PRB with type_traits::is_member_function_pointer
Beman Dawes wrote: At 09:00 AM 2/18/2003, Markus Schöpflin wrote: Hi there, currently, the is_member_func_test fails for VACPP6 with the following error messages: /home/auto/schoepf/src/extern/boost-cvs/boost/type_traits/is_member_functio n_pointer.hpp, line 37.29: 1540-1206 (S) The class template instantiation of is_mem_fun_pointer_implvoid (UDT::*)() is ambiguous. /home/auto/schoepf/src/extern/boost- ... When looking at is_mem_fun_pointer_impl.hpp it looks like the Metrowerks compiler has the same problem. Could anyone please add a check for __IBMCPP__ =600 at line 345 of this file and regenerate it? Markus, It doesn't look like this change was ever made. Would you still like to see it made? Does anyone have an objection? It would only affect the IBM compiler. Yes, please go ahead and make the change. I didn't want to change that header on my own. And besides that, it needs regeneration after the change and I can't find any docs on how this has to be done. (I'm trying to make sure that patches haven't fallen on the floor. Please excuse the bother if the patch was not applied because it was rejected, and I just didn't see any message indicating that.) I'll make the change if it is still needed. Thanks, --Beman Thanks for your efforts. Markus ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] When will be the next boost released?
Hi all, I have to port a Linux application that is using spirit on the VS. NET 2003. Unfortunately the current release of the spirit is crashing the VC++ 2003 compiler, so I asked the spirit guys when the next version (1.5.2) will be released. Their answer was that the next version will be released together with boost, so I would like to know when the new version of boost (1.30) will be released, if there is already a date set for this? Thanks in advance, Viv ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Meta programming 'debug' mode.
Jaap Suter wrote: [snip] #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 Yes much better. I don't see any problems with this, does anyone? Regards, Dirk Gerrits ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] 1.30.0b1 thread.hpp bug
Geurt Vos said: Just downloaded the 1.30.0-beta1 zip. There boost/thread.hpp is slightly wrong. Line 16 reads: #include boost/thread/conditin.hpp but should be: #include boost/thread/condition.hpp Fixed. Thanks. -- William E. Kempf ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] rpms and small fix for RedHat
I really appreciate the boost rpms that have been made available. I hope we can improve one thing in the upcoming release. rpm -q --requires boost-python-devel boost-devel libpython-devel Unfortuantely, on RedHat it's called python-devel I hope there is some way to fix this. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] boost::threads thread_dev
Just a quick question: Are the changes made on the thread_dev branch for the thread library going to make it into the 1.30.0 release or are they being held back for a future release? Thanks Russell ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: New stuff into sandbox and Yahoo files section
On Sun, 09 Mar 2003 18:46:47 -0500, David Abrahams
[EMAIL PROTECTED] wrote:
Well, why hardcoding that dependency?
You don't have to; it was just an example implementation. Another
implementation would be:
template class T
struct const_min
{
BOOST_STATIC_CONSTANT(T, value = /*whatever*/);
typedef const_minT type;
typedef T value_type;
};
Ah, sure! :-) Now this is really metaprogramming-compatible rather
than boost::mpl-dependent. Gone! Thanks for the idea.
[...]
I still don't understand... it must be one of those C++ programmers
eccentricities ;-)
Bingo.
:-)
Genny.
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Meta programming 'debug' mode.
On Sun, 09 Mar 2003 20:23:39 -0500, David Abrahams
[EMAIL PROTECTED] wrote:
Comeau says [...]
In C++: A function definition ... does not end with a semicolon
nitpick
A function definition appearing within a class definition may end with
a semicolon though:
class X {
void foo() {}; // see grammar in 9.2
};
/nitpick
Genny.
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] When will be the next boost released?
- Original Message - From: Joel de Guzman [EMAIL PROTECTED] To: Boost mailing list [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Monday, March 10, 2003 4:54 PM Subject: Re: [boost] When will be the next boost released? vc wrote: Hi all, I have to port a Linux application that is using spirit on the VS. NET 2003. Unfortunately the current release of the spirit is crashing the VC++ 2003 compiler, You mean VC7.1 is crashing? Yes. I get the error: boost\spirit\iterator\impl\msvc_ps_helper.hpp(60) : fatal error C1001: INTERNAL COMPILER ERROR (compiler file 'msc1.cpp', line 2701) so I asked the spirit guys when the next version (1.5.2) will be released. Their answer was that the next version will be released together with boost, so I would like to know when the new version of boost (1.30) will be released, if there is already a date set for this? You can get the beta 1.30.0 here. It has Spirit v1.5.2: http://boost.sourceforge.net/regression-logs/boost_1_30_0_b1.zip Thanks. I will give it a try. Viv ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] When will be the next boost released?
vc [EMAIL PROTECTED] writes: - Original Message - From: Joel de Guzman [EMAIL PROTECTED] To: Boost mailing list [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Monday, March 10, 2003 4:54 PM Subject: Re: [boost] When will be the next boost released? vc wrote: Hi all, I have to port a Linux application that is using spirit on the VS. NET 2003. Unfortunately the current release of the spirit is crashing the VC++ 2003 compiler, You mean VC7.1 is crashing? Yes. I get the error: boost\spirit\iterator\impl\msvc_ps_helper.hpp(60) : fatal error C1001: INTERNAL COMPILER ERROR (compiler file 'msc1.cpp', line 2701) Have you reported this to Microsoft? -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Meta programming 'debug' mode.
#define BOOST_STATIC_ASSERT( B ) \ typedef void BOOST_JOIN(boost_static_assert_typedef_, __LINE__) ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Meta programming 'debug' mode.
On Sun, 09 Mar 2003 20:23:39 -0500, David Abrahams
[EMAIL PROTECTED] wrote:
is ; legal where a declaration is expected?
class X
{
; // legal?
};
No. C++ has a null statement (expression-statement without the
expression part) but not no null declaration. The grammar seems to
allow it but that is incompatible with the semantic restrictions in
clause 7. So, in any context where you can have declarations but not
statements (e.g. namespace scope) you can't put a free semicolon.
Anyway, as Terje says, if the compile-time cost of the static
assertion is mainly in the evaluation of the condition then the
'release mode' definition could simply be
#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. But all this conjectures
should be backed up by some measurement. Jaap?
Genny.
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] [Bug] boost does not compile with Sun CC
We just got this message on the LyX bug-tracker. This is from the RC_1_30_0 branch, is there any fixed planned for 1.30.0 proper? ---BeginMessage--- http://bugzilla.lyx.org/show_bug.cgi?id=935 Summary: boost does not compile with Sun CC Product: LyX Version: 1.3.0 Platform: Sun OS/Version: Solaris Status: UNCONFIRMED Severity: major Priority: P2 Component: build AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] QAContact: [EMAIL PROTECTED] The boost sub-package does not compile with cc: Sun WorkShop 6 update 1 C 5.2 2000/09/11 CC -DHAVE_CONFIG_H -I. -I. -I../../../../src -I../../../../boost -I/usr/local/include -I/usr/openwin/include -I/usr/local/include -c cregex.cpp ../../../../boost/boost/type_traits/add_const.hpp, line 34: Warning: Too few arguments in macro BOOST_PP_CHECK_2. ../../../../boost/boost/type_traits/add_const.hpp, line 34: Warning: Too few arguments in macro BOOST_PP_CHECK_2. ../../../../boost/boost/type_traits/add_const.hpp, line 34: Warning: Too few arguments in macro BOOST_PP_CHECK_2. ../../../../boost/boost/type_traits/add_const.hpp, line 34: Error: BOOST_PP_LIST_FOR_EACH_I_M is not defined. [...lots more] This message on the boost mail list seems to indicate that some fixes may be available http://lists.boost.org/MailArchives/boost/msg41995.php. --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. ---End Message--- -- Lgb ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] When will be the next boost released?
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. And indeed 2 weeks ago I took the spirit sources from the cvs and I didn't get that error anymore. - Original Message - From: David Abrahams [EMAIL PROTECTED] To: Boost mailing list [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Monday, March 10, 2003 5:48 PM Subject: Re: [boost] When will be the next boost released? vc [EMAIL PROTECTED] writes: - Original Message - From: Joel de Guzman [EMAIL PROTECTED] To: Boost mailing list [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Monday, March 10, 2003 4:54 PM Subject: Re: [boost] When will be the next boost released? vc wrote: Hi all, I have to port a Linux application that is using spirit on the VS. NET 2003. Unfortunately the current release of the spirit is crashing the VC++ 2003 compiler, You mean VC7.1 is crashing? Yes. I get the error: boost\spirit\iterator\impl\msvc_ps_helper.hpp(60) : fatal error C1001: INTERNAL COMPILER ERROR (compiler file 'msc1.cpp', line 2701) Have you reported this to Microsoft? -- 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] 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
RE: [boost] When will be the next boost released?
Joel de Guzman wrote: I have to port a Linux application that is using spirit on the VS. NET 2003. Unfortunately the current release of the spirit is crashing the VC++ 2003 compiler, You mean VC7.1 is crashing? so I asked the spirit guys when the next version (1.5.2) will be released. Their answer was that the next version will be released together with boost, so I would like to know when the new version of boost (1.30) will be released, if there is already a date set for this? You can get the beta 1.30.0 here. It has Spirit v1.5.2: http://boost.sourceforge.net/regression-logs/boost_1_30_0_b1.zip I also wish to ask until when the beta will run. I think the beta is a good idea. Hopefully some unforseen problems will be caught. When the final 1.30.0 will be released, I wish to bump the Spirit version bundled with Boost 1.30.0 to v1.6.0 (a stable release) Spirit v1.5.2 (developmental) version will still be released in parallel (at spirit.sf.net). All new (and experimental) stuff will take place on the 1.5.x branch. By convention, Spirit stable releases have even numbered minor versions while developmental releases have odd numbered versions. It makes sense to include only the stable versions to Boost final releases. As of now, all the experimental (and unstable) parts of the library has been removed. Thoughts? Martin, Hartmut, Dan? No objections here. Regards Hartmut ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] [Bug] boost does not compile with Sun CC
CC -DHAVE_CONFIG_H -I. -I. -I../../../../src -I../../../../boost -I/usr/local/include -I/usr/openwin/include -I/usr/local/include -c cregex.cpp ../../../../boost/boost/type_traits/add_const.hpp, line 34: Warning: Too few arguments in macro BOOST_PP_CHECK_2. ../../../../boost/boost/type_traits/add_const.hpp, line 34: Warning: Too few arguments in macro BOOST_PP_CHECK_2. ../../../../boost/boost/type_traits/add_const.hpp, line 34: Warning: Too few arguments in macro BOOST_PP_CHECK_2. ../../../../boost/boost/type_traits/add_const.hpp, line 34: Error: BOOST_PP_LIST_FOR_EACH_I_M is not defined. [...lots more] This message on the boost mail list seems to indicate that some fixes may be available http://lists.boost.org/MailArchives/boost/msg41995.php. Lars Gullik Bjønnes wrote: We just got this message on the LyX bug-tracker. This is from the RC_1_30_0 branch, is there any fixed planned for 1.30.0 proper? Are you certain that this is 1.30? This should already be fixed. In particular, the Sun preprocessor should be using the Borland configuration of the pp-lib--which should not be using the BOOST_PP_CHECK macros--especially not for list handling. Paul Mensonides ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] [Bug] boost does not compile with Sun CC
Paul Mensonides [EMAIL PROTECTED] writes: | CC -DHAVE_CONFIG_H -I. -I. -I../../../../src -I../../../../boost | -I/usr/local/include -I/usr/openwin/include -I/usr/local/include -c | cregex.cpp ../../../../boost/boost/type_traits/add_const.hpp, line | 34: Warning: Too few arguments in macro BOOST_PP_CHECK_2. | ../../../../boost/boost/type_traits/add_const.hpp, line 34: | Warning: Too few arguments in macro BOOST_PP_CHECK_2. | ../../../../boost/boost/type_traits/add_const.hpp, line 34: | Warning: Too few arguments in macro BOOST_PP_CHECK_2. | ../../../../boost/boost/type_traits/add_const.hpp, line 34: Error: | BOOST_PP_LIST_FOR_EACH_I_M is not defined. | [...lots more] | | This message on the boost mail list seems to indicate that some fixes | may be available | http://lists.boost.org/MailArchives/boost/msg41995.php. | | Lars Gullik Bjønnes wrote: | We just got this message on the LyX bug-tracker. | | This is from the RC_1_30_0 branch, is there any fixed planned for | 1.30.0 proper? | | Are you certain that this is 1.30? This should already be fixed. It is from the 1.30 branch, but not completely up to date. (or supposedly 1.30 branch.) If it is fixed: Great! I'll update shortly. (when the cvs is well again...) -- Lgb ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] boost/limits.hpp Itanium2 RC_1_30_0
Hi, We got access to a brand-new HP Itanium2 machine. Compiling with the pre-installed gcc 2.96 seems to go fine, but I had to patch boost/detail/limits.hpp. See below. I am just guessing that BOOST_BIG_ENDIAN is correct for the Itanium2. Does anybody here know if this is correct? Is there a quick-and-easy way to find out for sure? Finally, if my experiments are successful it would be very useful to include this tiny patch in 1.30.0. Ralf --- limits.hpp Wed Jul 24 09:07:41 2002 +++ /net/cci/rwgk/limits.hppMon Mar 10 15:14:47 2003 @@ -49,7 +49,7 @@ // The macros are not named appropriately. We don't care about integer // bit layout, but about floating-point NaN (etc.) bit patterns. -#if defined(__sparc) || defined(__sparc__) || defined(__powerpc__) || defined(__ppc__) || defined(__hppa) || defined(_MIPSEB) || defined(_POWER) +#if defined(__sparc) || defined(__sparc__) || defined(__powerpc__) || defined(__ppc__) || defined(__hppa) || defined(_MIPSEB) || defined(_POWER) || defined(__ia64__) #define BOOST_BIG_ENDIAN #elif defined(__i386__) || defined(__alpha__) #define BOOST_LITTLE_ENDIAN __ Do you Yahoo!? Yahoo! Tax Center - forms, calculators, tips, more http://taxes.yahoo.com/ ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] When will be the next boost released?
vc wrote: 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. And indeed 2 weeks ago I took the spirit sources from the cvs and I didn't get that error anymore. No that's not correct. VC7.1 is known to compile Spirit with no workarounds as early as January last year (v1.3.x and Spirit-X). Anyway, the msvc_ps_helper.hpp is an inadvertent wart and is now removed. Still, I think you must report the ICE. Such things should not happen. -- 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] boost/limits.hpp Itanium2 RC_1_30_0
If evaluating the output of the code below counts as a
quick-and-easy-and-conclusive test the result is that the Itanium2 must be
BOOST_LITTLE_ENDIAN like the i386 and Alpha lines. I.e. my patch needs to be
revised (see below).
I am happy to report that Boost.Python works both with gcc 2.96 and Intel 7.0
on the Itanium2. The patch below is the only modification required. Would it be
OK to check this into the RC_1_30_0 branch?
Thanks,
Ralf
#include iostream
int main()
{
double x = 1.23456789e12;
unsigned char* c = (unsigned char*) x;
for (int i=0;isizeof(double);i++) {
std::cout unsigned(c[i]) std::endl;
}
return 0;
}
Index: limits.hpp
===
RCS file: /cvsroot/boost/boost/boost/detail/limits.hpp,v
retrieving revision 1.21
diff -r1.21 limits.hpp
54c54
#elif defined(__i386__) || defined(__alpha__)
---
#elif defined(__i386__) || defined(__alpha__) || defined(__ia64) ||
defined(__ia64__)
__
Do you Yahoo!?
Yahoo! Tax Center - forms, calculators, tips, more
http://taxes.yahoo.com/
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] boost/limits.hpp Itanium2 RC_1_30_0
Ralf W. Grosse-Kunstleve [EMAIL PROTECTED] writes: If evaluating the output of the code below counts as a quick-and-easy-and-conclusive test the result is that the Itanium2 must be BOOST_LITTLE_ENDIAN like the i386 and Alpha lines. I.e. my patch needs to be revised (see below). I am happy to report that Boost.Python works both with gcc 2.96 and Intel 7.0 on the Itanium2. The patch below is the only modification required. Would it be 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) -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] boost/limits.hpp Itanium2 RC_1_30_0
--- David Abrahams [EMAIL PROTECTED] wrote: I am happy to report that Boost.Python works both with gcc 2.96 and Intel 7.0 on the Itanium2. The patch below is the only modification required. Would it be 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) OK, done, both in the RC_1_30_0 branch and in the trunk. Ralf __ Do you Yahoo!? Yahoo! Tax Center - forms, calculators, tips, more http://taxes.yahoo.com/ ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: boost/limits.hpp Itanium2 RC_1_30_0
Ralf W. Grosse-Kunstleve wrote: If evaluating the output of the code below counts as a quick-and-easy-and-conclusive test the result is that the Itanium2 must be BOOST_LITTLE_ENDIAN like the i386 and Alpha lines. I.e. my patch needs to be revised (see below). Remember that Itanium(2) can use either Endianality - it's up to the OS/platform code to determine which Endianality is in use. It's entirely possible that there might be Itanium2 platforms with GCC that are big endian in addition to those that are little endian. Hopefully things don't work out that way... -cd ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] XML Samples, Mac OS X, CW 8.3...
I've been trying to get the xml samples to work on Mac OS X, CW 8.3 today with no success. I get the following assertion in range_run.ipp: Assertion (r.is_valid()) failed in range_run.ipp, function set, line 132 This assertion is the result of the following call in the xml_grammar::definition constructor: chset_t Char(L\x9\xA\xD\x20-\xD7FF\xE000-\xFFFD); The problem seems to be some sort of sign extension problem, or two byte versus four byte characters. If I do a memory dump on the constant wide character string in the above line of code I get the following: 0009 000A 000D 0020 002D D7FF E000 002D FFFD The assertion happens because of the sign extension, causing the end of the range to be less than the beginning of the range. First off, I don't understand why these characters are four bytes? I thought the L made them two byte characters. Second, they appear to be being treated as signed characters as you can see from the sign extension. I've looked for options to control the code generation aspects of characters. In the C++ language options panel I have enabled Use Unsigned Chars, Multi-Byte Aware, and Enable wchar_t Support. I've actually tried different combinations of these but nothing seems to change the way the code is generated for these constant wide character arrays. I know that some of you are able to build and run the XML samples successfully on Mac OS X. One more note. I'm building a Mach-o binary, console application using the MSL Mach-o libraries. Thanks, Michael- On Saturday, March 8, 2003, at 05:27 PM, Joel de Guzman wrote: Michael Burbidge wrote: I've been trying to use the XML samples in libs/example/application/xml. They build fine, but get a runtime assert when given even the simplest xml file. Are these samples kept up to date? Here's the assert that I get: Assertion (r.is_valid()) failed in range_run.ipp, function set, line 132 This is on Mac OS X using CodeWarrior 8. I assume this is a Spirit related question. Before anything else, please post Spirit support related questions to: [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/spirit-general Also, it would be best to write a more descriptive title. Otherwise, your post might probably be easy to miss. Ok, nuff said... The XML stuff has been tested and works with no problems on Windows and Linux. I come from the Mac but unfortunately I do not have access to a Mac and CW8 right now. Fortunately Paul Snively volunteered to check Spirit on CW8 on the Mac. You can also help out by giving us a more detailed account. For instance, what is the current state of the range (r) when the assertion fired? Please post subsequent messages to Spirit's mailing lits. Let's continue this thread there. Thank you. -- 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 ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Getting iterator into original string from token_iterator
If I have a token_iterator, is there any way for me to get an iterator into the original string that corresponds to the position of the token_iterator? I have some code where I want to create a tokenizer from a string, get some tokens from it, then return the remainder of the string, ignoring any further tokenization. Joe Gottman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Meta programming 'debug' mode.
Anyway, as Terje says, if the compile-time cost of the static assertion is mainly in the evaluation of the condition then the 'release mode' definition could simply be #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. 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. Regards, Jaap Suter ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] release procedure typo(?)
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? Gennadiy. 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? ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] MPL's round lambda
A few months ago, Aleksey posted a cool way of doing lambda using function
notation. I hadn't followed the thread at the time, but I read up on it
recently. Like many others, I found it hard to understand how it worked, so
I asked Aleksey if he could make a minimal example of it, which he did.
For the benefit of anybody else interested in knowing how it works, I post
the example here. I found it much easier to understand how it works, with
such a minimal example.
--- Start ---
#include boost/mpl/quote.hpp
#include boost/mpl/apply.hpp
#include boost/mpl/bind.hpp
#include boost/type_traits/is_same.hpp
#include boost/static_assert.hpp
using namespace boost::mpl;
templatetypename T
struct expr
{
typedef T type;
};
templatetypename F, typename T1, typename T2
struct exprF (T1, T2) : bind2F, typename exprT1::type, typename
exprT2::type {};
struct is_same : quote2boost::is_same {};
// Here:
typedef applyexpris_same(_, int), int::type type;
BOOST_STATIC_ASSERT(type::value);
--- End ---
Regards,
Terje
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
