Re: [boost] Re: Signals and multi_array? [was: Problem compilingboost.filesystem]
Douglas Paul Gregor [EMAIL PROTECTED] writes: Doesn't look like there has been any activity on signals and multi_array. Are the developers aware of the need for action? I'll try to work on Signals tonight. Hint: turn the body of your policies class into the body of your iterator. 'tis done, and it was _very_ easy, and the result is as clean as is conceivable. Nice job! Doug ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Thoughts on fixdec
This is on version 2.2 that is dated on 5 July 2003. I haven't read
any messages since July 12th, so I haven't seen any other reviews yet.
I think this library should be accepted. I have some suggestions for
fixes and other changes.
1. We have two math-related namespaces already. The boost::math
namespace leans to theoretical work and boost::numeric leans to
hard-core computation. You should probably pick one of those
namespaces (numeric?) and possibly rename the class to fixed_decimal.
Lots of the current free-functions that are specific to the state of
your class could move to static-member functions.
2. There is a boost/limits.hpp header to give deficient systems the
std::numeric_limits class template (and pass through if limits
exists). You can use that and get rid of all your non-limits
contingency code.
3. Instead of playing around with determining the significand type,
just #include boost/cstdint.hpp, use boost::intmax_t and be done with
it. With the static-member idea I gave in [1], the class would start
off with:
class decimal
{
public:
typedef ::boost::intmax_t significand_type;
typedef intscale_type;
//...
};
4. What, no (safe-)Boolean conversion?
5. The conversion from int needs to check for overflow. The
conversion from double needs to check also for underflow. The
conversion from strings needs to check also for bad formats.
6. There should only be conversions from strings, and _no_ mixed
operations with strings. At least int and double is in the same
family of types as decimal, but strings aren't. There should be no
illusion that strings and numbers are generally compatible, so
operations with strings need to be explicitly converted.
7. Does the scale need to be first in all constructors? If it can be
placed second, then converting constructors can be made and most of the
mixed operator functions can go away.
class decimal
{
public:
//...
decimal( intmax_t value = 0, int scale = 0 );
decimal( uintmax_t value, int scale = 0 );
decimal( long double value, int scale = 0, rounding_mode =
default_rounding() );
explicit decimal( char const *representation, int scale = 0,
rounding_mode = default_rounding() );
explicit decimal( wchar_t const *representation, int scale = 0,
rounding_mode = default_rounding() );
//...
};
(Yes, I know that some numeric purists [and GCC] hate long double,
but I want to maximize the capabilities.)
8. The round_down and round_up functions don't seem clear enough.
They could mean:
round_towards_zero and round_fleeing_zero
or
round_towards_negative_infinity and round_towards_positive_infinity
I read later on, so I know you meant the first pair. Maybe you can
change the names, and add two more functions corresponding to the
second pair.
class decimal
{
//...
enum remainder
{
zero, less, half, more
};
typedef void (*rounding_mode)( significand_type , remainder, bool
);
static rounding_mode default_rounding();
static rounding_mode default_rounding( rounding_mode );
//...
};
void round_towards_zero( decimal::significand_type ,
decimal::remainder, bool );
void round_fleeing_zero( decimal::significand_type ,
decimal::remainder, bool );
void round_nearest( decimal::significand_type , decimal::remainder,
bool );
void round_bankers( decimal::significand_type , decimal::remainder,
bool );
void round_ceiling( decimal::significand_type , decimal::remainder,
bool );
void round_floor( decimal::significand_type , decimal::remainder,
bool );
9. What, no operator nor operator ? (The shift would be a
power of ten.)
10. The class is no longer a template, but some of the wording in the
code and docs act like it's still a template. (When you're rewording,
there's some HTML errors to fix.)
11. [This is general speculation.] Maybe all numeric types should have
member functions that change an object to its inverse inline. Examples:
class MyNum
{
public:
//...
MyNum negate(); // additive inverse
MyNum reciprocate(); // multiplicative inverse
MyNum complement(); // bit(like) flip
MyNum conjugate();// complex (or above) conjugation
//...
};
This would save time to do these operations without extra copying:
negate eliminates x = -x
with reciprocate: x / y - x * y.reciprocate()
complement eliminates x = ~x
conjugate eliminates x = conj(x)
Each operation would only be defined if it's appropriate. Types
without additive inverses don't get negate. The reciprocate
operation requires EXACT (not approximate nor quotient remainder)
multiplicative inverses, like rational or modulo types. The
complement needs something supporting operator ~(). The
conjugate operation would use complex types, or a higher level type
(like quaterions). You could define it for real number types, if you
don't mind a no-op.
Getting back on-topic, decimal would
[boost] Re: plans for a bugfix release ?
Hi,
On Tue, 15 Jul 2003 23:38:12 +0200, Daniel Frey wrote:
I think it's too late, let's go for a 1.31.0. I think that we'll hear
about problems with the 1.31.0 really soon after release and probably a
1.31.1 can follow shortly after.
Agreed.
At our company we use a slightly different approach. We have two development
streams, which we call 'Master' and 'Release'. At some time, when we are
releasing a version from our main development branch ('Master'), we just make
a copy of the current 'Master' state and check it into a different source
control database ('Release'). Bug fixes will be added into the 'Master' and
into the 'Release' branch. However, new functionality and interface changes
are only added into the 'Master'. Of course it is a little bit more work to
add the bug fixes into two seperate RCS. But this way, we are able to bring
bug fix releases to our clients whenever there is a demand for it. Additionally,
it then is possible to make complete structural changes to the 'Master' without
concernig about the 'Release'.
Regards, Johannes
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Review request: enable_if
In our last exciting episode Markus Werle wrote:
Lines: 24
Mail-Copies-To: [EMAIL PROTECTED]
User-Agent: KNode/0.6.1
Jaakko Jarvi wrote code that looks like this:
template bool B, class T = void
struct disable_if: public enable_if !B, T {};
I have a question regarding compile time:
Do you have experience about whether this elegant solution
might have some compile time penalty due to inheritance?
Or is this faster than doubling the code?
We have made no measurements. The use of inheritance is motivated by getting
a miniscule bit of reuse.
If another formulation leads to better compile-time or runtime
performance, it's worth while to change.
Cheers, Jaakko
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Inconsistency using BOOST_WORKAROUND in format library
Hello, There was a message few weeks ago that did not get satisfactory answer IMHO. It's about compiler workaround in boost/format/feed_args.hpp (note that we use VC7.1): [original] #if BOOST_WORKAROUND( BOOST_MSVC, BOOST_TESTED_AT(1300)) [fixed] #if BOOST_WORKAROUND( BOOST_MSVC, = 1300) At the same time, in msvc_disambiguater.hpp: [working] #if defined(BOOST_MSVC) BOOST_MSVC = 1300 // this whole header is specifically for msvc The problem is that macro [working] is, well, working, but the [original] doesn't, and they should work together (by design) - again, all this with VC7.1. My proposal is that if we are all to use these macros, we should use them consistently, and if we do, I'd rather see the version marked as [fixed] above - it does the same thing (according to the docs) and is more readable, or we fix the macro (or the compiler :) I don't know who is to blame (macro or compiler or both), but after reading boost/detail/workaround.hpp I don't see any advantage in using [original] over [fixed], IMHO the [fixed] is more readable and clearly states intent. In my company we have fixed this in our own CVS, but I feel uneasy patching external libraries like this, so if someone with full access to boost CVS could fix this, we would very much appreciate it. Drazen ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: plans for a bugfix release ?
Beman Dawes wrote: Seems like we are very close to being ready to do a 1.31.0 release. One new library has been added since 1.30.0, at least two libraries have had interface upgrades, and a large number of bugs have been fixed in numerous libraries. How about 1 or maybe more betas of 1.31.0 (like we had for 1.30.0) so that hopefully some problems can be found before the final release? Cheers Russell ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Draft of new Boost Software License
Beman Dawes [EMAIL PROTECTED] wrote ... Thanks to Dave Abrahams, Diane Cabell, Devin Smith, and Eva Chen, we now have a pretty close to final draft of a new Boost Software License. For as many Boost libraries as possible, the plan is to replace the individual licenses with the official Boost license. Of course, the developers who hold the copyrights for each library must agree. We'll also submit the Boost license to the OSI (http://www.opensource.org/) for certification. This draft represents a lot of discussion between the lawyers and Boost moderators, and both groups are quite happy with the results. So now it's time to open it up for comments from the whole Boost community. For more background, including rationale, a FAQ, and acknowledgements, see http://boost.sourceforge.net/misc/license-background.html The draft license itself is at http://boost.sourceforge.net/misc/LICENSE.txt maybe a dumb question, but I just simulated an interested new boost user but didnt find anything about 'the' current license on www.boost.org, only the faq and lib-guidelines telling some requirements for interested boost contributers. For more info, downloading the complete package seems to be necessary. IMO it would be usefull, not only for me, to add a page with a prominent location to www.boost.org, telling whatever is generally known to apply to the complete current boost version (e.g. containing a copy of the upper license.txt), and then pointing out that each file may have additional terms, being part of that file, maybe copypaste an example of existing per-file-license. Regards, Markus. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] [BGL] subgraph.hpp patch
Hi, This patch fixes compilation error with gcc 3.2 (mingw) Regards, Janusz --- subgraph.hpp.orig 2003-07-15 08:32:48.0 +0200 +++ subgraph.hpp 2003-07-16 10:32:08.0 +0200 @@ -202,14 +202,14 @@ // Return the children subgraphs of this graph/subgraph. // Use a list of pointers because the VC++ std::list doesn't like // storing incomplete type. -typedef typename indirect_iterator +typedef indirect_iterator typename ChildrenList::const_iterator , subgraphGraph , std::bidirectional_iterator_tag children_iterator; -typedef typename indirect_iterator +typedef indirect_iterator typename ChildrenList::const_iterator , subgraphGraph const , std::bidirectional_iterator_tag ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: plans for a bugfix release ?
David Abrahams wrote: [Beman Dawes] Hum... You must be seeing some way of getting a 1.30.1 release out that eludes me. What would go into 1.30.1? Exactly what's on the end of the RC_1_30_0 branch plus whatever additional small fixes were deemed important and can be applied in a day or two; release to happen in a week. Spirit has also just released its next version, should this also be integrated into any boost 1.30.1? [I will ask same question on Spirit list, and direct discussion back here] Only *critical* fixes to the 1.30.0 release. What about updated compiler configs? For instance, Borland released a compiler update pretty much the same week that Boost 1.30 went out, so several version checks fail. Any other compilers release a point upgrade that can be easily integrated? By releasing one week from now? Agressive dealine will certainly focus us on 'needs' not 'wants' g -- AlisdairM Team Thai Kingdom ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: [Boost-Users] smart pointer test failed
hlh771 wrote: hello,everybody I want to test smart pointer library,but got some compile failure: vc- C++ ..\..\..\libs\smart_ptr\test\bin\shared_ptr_alloc_test.test\msvc\d ebug\runtime-link-dynamic\shared_ptr_alloc_test.obj shared_ptr_alloc_test.cpp M:\develop\boost_1_30_0\boost/detail/quick_allocator.hpp(165) : fatal error C1001: INTERNAL COMPILER ERROR (compiler file 'msc1.cpp', line 1794) Please choose the Technical Support command on the Visual C++ Help menu, or open the Technical Support help file for more information [...] my test command is:bjam -sTOOLS=msvc test my compiler is vc6+sp5 It's seems like the compiler's error,but because the test's failure, I'm not sure it will work correctly if use it in my app. Thanks in advance. shared_ptr_alloc_test is a performance test. It compares the relative speed of the optional quick_allocator that is enabled when you #define BOOST_SP_USE_QUICK_ALLOCATOR. Quick_allocator does not compile on MSVC 6 (and some other compilers) but this doesn't matter unless you explicitly request it to be used via the #define. The smart pointers library works correctly on MSVC 6. I am not sure why shared_ptr_alloc_test is being run at all, it is supposed to be run only when named: bjam -sTOOLS=msvc shared_ptr_alloc_test I'll CC: the developer list, maybe we should fix the Jamfile. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Revised streambuf library
Maxim Egorushkin [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Jonathan David Turkanis [EMAIL PROTECTED] wrote in message ... ... You just call new_source or new_sink with whatever object you want to make into a source/sink. This is less verbose than using, e.g., streambuf iterators. ... I agree. This is just a matter of taste. I would prefer to write more generic adapter classes and a bunch of factories. Are you suggesting factories like new_streambuf_source? This sounds okay. I prefer sticking with new_source and new_sink, because it is less typing :-). At any rate, I realize you were right that my adapters contained unnecessary duplication. I rewrote istream_source et al. to make them derive from the iterator-based adapters. Now they just consist of some typedefs and simple inline constructors. Thanks, Jonathan ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: Intel 7.1 bug report for boost::checked_delete?
Peter Dimov wrote: But I don't have access to Intel C++. I do now, fixed (hopefully), thanks for the report. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: plans for a bugfix release ?
Alisdair Meredith [EMAIL PROTECTED] writes: David Abrahams wrote: [Beman Dawes] Hum... You must be seeing some way of getting a 1.30.1 release out that eludes me. What would go into 1.30.1? Exactly what's on the end of the RC_1_30_0 branch plus whatever additional small fixes were deemed important and can be applied in a day or two; release to happen in a week. Spirit has also just released its next version, should this also be integrated into any boost 1.30.1? No. Those are not *critical* fixes. [I will ask same question on Spirit list, and direct discussion back here] Only *critical* fixes to the 1.30.0 release. What about updated compiler configs? For instance, Borland released a compiler update pretty much the same week that Boost 1.30 went out, so several version checks fail. Any other compilers release a point upgrade that can be easily integrated? By releasing one week from now? Agressive dealine will certainly focus us on 'needs' not 'wants' g That would be the idea. -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: plans for a bugfix release ?
Johannes Brunen [EMAIL PROTECTED] writes:
At our company we use a slightly different approach. We have two development
streams, which we call 'Master' and 'Release'. At some time, when we are
releasing a version from our main development branch ('Master'), we just make
a copy of the current 'Master' state and check it into a different source
control database ('Release').
Bug fixes will be added into the 'Master' and into the 'Release'
branch. However, new functionality and interface changes are only
added into the 'Master'.
Presumably that's exactly what we're doing with branches.
Of course it is a little bit more work to add the bug fixes into two
seperate RCS.
So why not simply branch instead? It's better than making a whole
new copy.
But this way, we are able to bring bug fix releases to
our clients whenever there is a demand for it. Additionally, it then
is possible to make complete structural changes to the 'Master'
without concernig about the 'Release'.
There's no reason to use a separate CVS for this. I guess if you're
using RCS you might not be able to do it; I don't recall whether it
supports branching directly.
--
Dave Abrahams
Boost Consulting
www.boost-consulting.com
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: plans for a bugfix release ?
From: Alisdair Meredith [EMAIL PROTECTED] Only *critical* fixes to the 1.30.0 release. What about updated compiler configs? For instance, Borland released a compiler update pretty much the same week that Boost 1.30 went out, so several version checks fail. Any other compilers release a point upgrade that can be easily integrated? Yes. g++ 3.3 is not recornized by 1.30.0. This is mostly harmeless, except for a annoying warning on using almost every boost header. - Volodya ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: plans for a bugfix release ?
At 08:36 PM 7/15/2003, David Abrahams wrote: Beman Dawes [EMAIL PROTECTED] writes: ... Hum... You must be seeing some way of getting a 1.30.1 release out that eludes me. What would go into 1.30.1? Exactly what's on the end of the RC_1_30_0 branch plus whatever additional small fixes were deemed important and can be applied in a day or two; release to happen in a week. Ah! That is much more doable. Who will act as release manager? I guess I'd have to reluctantly volunteer, now that I've suggested it. Sounds like you just talked your way into a new job:-) So a schedule might look something like the following? -- 1.30.1 - Selected bug fixes only (details up to release manager). Schedule: a week or two from now -- 1.31.0 - New library, breaking interface changes, many fixes. Schedule: TBA, but work is basically already well underway. --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: plans for a bugfix release ?
At 06:17 AM 7/16/2003, Alisdair Meredith wrote: David Abrahams wrote: Only *critical* fixes to the 1.30.0 release. What about updated compiler configs? For instance, Borland released a compiler update pretty much the same week that Boost 1.30 went out, so several version checks fail. Any other compilers release a point upgrade that can be easily integrated? VC++ 7.1 required two or three workarounds IIRC. --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: plans for a bugfix release ?
Alisdair Meredith wrote: Spirit has also just released its next version, should this also be integrated into any boost 1.30.1? Yes, Spirit 1.6.1 should be incorporated into a Boost 1.30.1 release (if we actually decide to release 1.30.1). [I will ask same question on Spirit list, and direct discussion back here] Alisdair, I think most (if not all) Spirit developers have also subscribed to this mailing list. Only *critical* fixes to the 1.30.0 release. Spirit 1.6.1 only fixes bugs of Spirit 1.6.0, no features have been added. Boost.Spirit users would benefit from a Boost 1.30.1 release. However, Boost 1.30 users can replace Boost.Spirit with the contents of Spirit 1.6.1. So, from this point of view, a 1.30.1 release is not necessary. Personally, I think 1.30.1 would be a good thing to have. My impression is that many people try to access the Boost CVS in order to pick some fixes that were made right after the release of Boost 1.30. Given the lousy quality of public CVS access we're experiencing at the moment, users will likely appreciate a 1.30.1 release. Regards, m ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] circular buffer
Hi all!
The updated implementation and docs of the circular buffer (formerly called cyclic
buffer) can be found at
http://groups.yahoo.com/group/boost/files/circular_buffer.zip
To Howard Hinnant:
Probably I won't have time for doing the circular_deque but you can achieve the
insert method by adapting the circular buffer.
template class T class Adaptor {
private:
circular_bufferT m_buff;
public:
typedef typename circular_bufferT::iterator iterator;
typedef typename circular_bufferT::size_type size_type;
Adaptor(size_type capacity) : m_buff(capacity) {}
template class InputIterator
Adaptor(size_type capacity, InputIterator first, InputIterator last)
: m_buff(capacity, first, last) {}
iterator begin() { return m_buff.begin(); }
iterator end() { return m_buff.end(); }
size_type size() const { return m_buff.size(); }
size_type capacity() const { return m_buff.capacity(); }
T operator [] (size_type index) { return m_buff[index]; }
template class InputIterator
void insert(iterator pos, InputIterator first, InputIterator last) {
size_type new_size = size() + distance(first, last);
if (new_size capacity()) {
circular_bufferT buff(new_size, begin(), pos);
buff.insert(buff.end(), first, last);
buff.insert(buff.end(), pos, end());
m_buff.swap(buff);
} else {
m_buff.insert(pos, first, last);
}
}
};
Regards,
Jan
--
Jan Gaspar | [EMAIL PROTECTED]
Whitestein Technologies | www.whitestein.com
Panenska 28 | SK-81103 Bratislava | Slovak Republic
Tel +421(2)5930-0735 | Fax +421(2)5443-5512
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: Inconsistency using BOOST_WORKAROUND in formatlibrary
No it does *not*. Please re-read the docs. OK, mea culpa, I've read them again. I have no opinion on which one is better for this case, but they are different! Good, goes along well with my point - boost code for format uses _different_ macros to detect the same thing. The result is that code wants to use msvc_disambiguater (wrongly) and then can't see it's definiton (correctly). For BOOST_TESTED_AT to do anything useful, we MUST define BOOST_DETECT_OUTDATED_WORKAROUNDS, otherwise fix stays even if new compiler obsoletes workaround, which is what happened in this case. On the other hand, without BOOST_TESTED_AT, assumption is that new compiler _always_ obsoletes the workaround, so I see that for some cases it (BOOST_TESTED_AT) is useful. But for this particular case, it should at least be the same macro for two dependent places in the code, no? Drazen ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Thoughts on fixdec
Daryle Walker wrote:
I think this library should be accepted.
Thanks.
1.We have two math-related namespaces already. The boost::math
namespace leans to theoretical work and boost::numeric leans to
hard-core computation.
I don't know that there's anything particularly theoretical about
decimal representations; and the library's target audience is not
those users who do hard-code computation, which I understand to
mean numerical programming (in the sense of scientific and
statical programming).
It's not a major issue for me; and I'll do whatever the majority
wants.
You should probably pick one of those namespaces (numeric?) and
possibly rename the class to fixed_decimal.
I'm reticent to require the user to type the extra fixed_ in
every declaration of such an object.
2.There is a boost/limits.hpp header to give deficient systems
the std::numeric_limits class template (and pass through if limits
exists).
I had that in a previous version but wasn't satisfied with it. I can't
remember why; so I'll look at the old code and see what it was that
I didn't like.
3.Instead of playing around with determining the significand type,
just #include boost/cstdint.hpp, ...
I do.
... use boost::intmax_t and be done with it.
You're right. My mind got stuck on int_least64_t; and I completely
forgot about intmax_t. Also, that might solve the boost/limits.hpp
problem (whatever that was) if numeric_limitsintmax_t::is_specialized
and numeric_limitsintmax_t::digits10 is a constant expression. I'll
check that out.
4.What, no (safe-)Boolean conversion?
Ack! You're right!
5.The conversion from int needs to check for overflow.
The conversion from double needs to check also for underflow.
The conversion from strings needs to check also for bad formats.
But that would require some users to pay for something they don't
need. Users who need that level of correctness can write their
own checks; and others (probably most of the library's target
audience) get better efficiency.
6.There should only be conversions from strings, and _no_
mixed operations with strings.
In the absence of decimal literals, I think it's easier for the
user to be able to use strings as pseudo-literals in all contexts;
and I don't see how the mixed operations do any harm. In particular,
I'm willing to give the user credit for knowing that
my_decimal += The quick brown fox...;
doesn't make any sense.
7.Does the scale need to be first in all constructors? If it
can be placed second, then converting constructors can be made
and most of the mixed operator functions can go away.
[ctor examples]
I'd want to see use cases for all those conversions before I agreed
to add them. Remember, the library's target audience is folk who
are writing financial software. It's not intended as a general-
purpose number-crunching library.
8.The round_down and round_up functions don't seem clear enough.
They're intended to be clear to accountants who deal only with
non-negative debits and non-negative credits; and whether a value
is a debit or a credit is orthogonal to the mathematical notion
of sign.
Remember the instructions on your tax return form that tell you,
if line x is less than line y, subtract line x from line y and
write the answer over here; otherwise subtract line y from line x
and write the answer over there? Sure, that's a howler for
mathematicians; but it makes perfect sense to accountants. 8-)
9.What, no operator nor operator ? (The shift would
be a power of ten.)
Those operators don't exist for the floating-point types, and with
good reason IMO. Their use is best reserved for twiddling bits,
not for scaling. Even for binary integers, i 1 is not generally
the same thing as i * 2 except on 2's-complement boxes.
10. The class is no longer a template, but some of the wording
in the code and docs act like it's still a template. (When you're
rewording, there's some HTML errors to fix.)
Could you point them out?
11. ...
...
class MyNum
{
public:
//...
bool is_negative() const;
//...
};
... would save time over doing a (possible) conversion from zero
and a comparison.
But (my_decimal 0) doesn't do a conversion; and it lets the user
use decimals the way they would use other arithmetic types.
12. [use pword to save rounding mode I/O state]
Yes, much better. I'll play with that.
13. You have strange (regular) assignment semantics. You try to
change the receiver's logical value to the source's logical value,
but retain the receiver's original scale (internally shifting the
new significand and doing any rounding if needed). ... you will
get strange effects if you try to change containers of decimal
through assignment.
I thought it would be less surprising if a decimal object's scale
were immutable. This matches prior art (the BCD type on IBM
mainframes, for example) in which
RE: [boost] Re: Boost Bibliography?
Since most academic journals are moving to abolish printed versions (by pricing out of reach), I think we would be a bit silly to exclude on-line only stuff. Paul Paul A Bristow, Prizet Farmhouse, Kendal, Cumbria, LA8 8AB UK +44 1539 561830 Mobile +44 7714 33 02 04 Mobile mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] | -Original Message- | From: [EMAIL PROTECTED] | [mailto:[EMAIL PROTECTED] Behalf Of Beman Dawes | Sent: Thursday, July 10, 2003 8:57 PM | To: Boost mailing list; Boost mailing list | Subject: Re: [boost] Re: Boost Bibliography? | | | At 12:12 PM 7/10/2003, Rene Rivera wrote: | [2003-07-10] James Curran wrote: | | How directly must the article relate to Boost? I spend about 4 | paragraphs discussing Boost shared_ptr in: | Access Raw Data with Performance Counters in Visual C++ | DevX.com: http://www.devx.com/cplus/article/7951 | | I have a similar question; is online only material to be included? For | example this one: | | http://www.codeproject.com/vcpp/stl/BoostIntro.asp | The Code Project - An Introduction to Boost - STL | | Another dimension? Print vs Online? | | --Beman | | ___ | 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: Thoughts on fixdec
Title: RE: [boost] Re: Thoughts on fixdec
6. There should only be conversions from strings, and _no_
mixed operations with strings.
In the absence of decimal literals, I think it's easier for the
user to be able to use strings as pseudo-literals in all contexts;
and I don't see how the mixed operations do any harm. In particular,
I'm willing to give the user credit for knowing that
my_decimal += The quick brown fox...;
doesn't make any sense.
I don't have an opinion, but one other case that I've seen from people use to using std::string is:
string error = The number + my_decimal + is too big;
Glen
-Original Message-
From: Bill Seymour
To: [EMAIL PROTECTED]
Sent: 7/16/03 5:55 AM
Subject: [boost] Re: Thoughts on fixdec
Daryle Walker wrote:
I think this library should be accepted.
Thanks.
1. We have two math-related namespaces already. The boost::math
namespace leans to theoretical work and boost::numeric leans to
hard-core computation.
I don't know that there's anything particularly theoretical about
decimal representations; and the library's target audience is not
those users who do hard-code computation, which I understand to
mean numerical programming (in the sense of scientific and
statical programming).
It's not a major issue for me; and I'll do whatever the majority
wants.
You should probably pick one of those namespaces (numeric?) and
possibly rename the class to fixed_decimal.
I'm reticent to require the user to type the extra fixed_ in
every declaration of such an object.
2. There is a boost/limits.hpp header to give deficient systems
the std::numeric_limits class template (and pass through if limits
exists).
I had that in a previous version but wasn't satisfied with it. I can't
remember why; so I'll look at the old code and see what it was that
I didn't like.
3. Instead of playing around with determining the significand type,
just #include boost/cstdint.hpp, ...
I do.
... use boost::intmax_t and be done with it.
You're right. My mind got stuck on int_least64_t; and I completely
forgot about intmax_t. Also, that might solve the boost/limits.hpp
problem (whatever that was) if numeric_limitsintmax_t::is_specialized
and numeric_limitsintmax_t::digits10 is a constant _expression_. I'll
check that out.
4. What, no (safe-)Boolean conversion?
Ack! You're right!
5. The conversion from int needs to check for overflow.
The conversion from double needs to check also for underflow.
The conversion from strings needs to check also for bad formats.
But that would require some users to pay for something they don't
need. Users who need that level of correctness can write their
own checks; and others (probably most of the library's target
audience) get better efficiency.
6. There should only be conversions from strings, and _no_
mixed operations with strings.
In the absence of decimal literals, I think it's easier for the
user to be able to use strings as pseudo-literals in all contexts;
and I don't see how the mixed operations do any harm. In particular,
I'm willing to give the user credit for knowing that
my_decimal += The quick brown fox...;
doesn't make any sense.
7. Does the scale need to be first in all constructors? If it
can be placed second, then converting constructors can be made
and most of the mixed operator functions can go away.
[ctor examples]
I'd want to see use cases for all those conversions before I agreed
to add them. Remember, the library's target audience is folk who
are writing financial software. It's not intended as a general-
purpose number-crunching library.
8. The round_down and round_up functions don't seem clear
enough.
They're intended to be clear to accountants who deal only with
non-negative debits and non-negative credits; and whether a value
is a debit or a credit is orthogonal to the mathematical notion
of sign.
Remember the instructions on your tax return form that tell you,
if line x is less than line y, subtract line x from line y and
write the answer over here; otherwise subtract line y from line x
and write the answer over there? Sure, that's a howler for
mathematicians; but it makes perfect sense to accountants. 8-)
9. What, no operator nor operator ? (The shift would
be a power of ten.)
Those operators don't exist for the floating-point types, and with
good reason IMO. Their use is best reserved for twiddling bits,
not for scaling. Even for binary integers, i 1 is not generally
the same thing as i * 2 except on 2's-complement boxes.
10. The class is no longer a template, but some of the wording
in the code and docs act like it's still a template. (When you're
rewording, there's some HTML errors to fix.)
Could you point them out?
11. ...
...
class MyNum
{
public:
//...
bool is_negative() const;
//...
};
... would save time over doing a (possible) conversion from zero
and a comparison.
But
[boost] Re: plans for a bugfix release ?
Beman Dawes [EMAIL PROTECTED] writes: At 08:36 PM 7/15/2003, David Abrahams wrote: Beman Dawes [EMAIL PROTECTED] writes: ... Hum... You must be seeing some way of getting a 1.30.1 release out that eludes me. What would go into 1.30.1? Exactly what's on the end of the RC_1_30_0 branch plus whatever additional small fixes were deemed important and can be applied in a day or two; release to happen in a week. Ah! That is much more doable. Who will act as release manager? I guess I'd have to reluctantly volunteer, now that I've suggested it. Sounds like you just talked your way into a new job:-) So a schedule might look something like the following? -- 1.30.1 - Selected bug fixes only (details up to release manager). Schedule: a week or two from now I would be more hard-*ssed about it. A week. -- 1.31.0 - New library, breaking interface changes, many fixes. Schedule: TBA, but work is basically already well underway. Sounds fine to me. The only issue remaining is how we can get the testing infrastructure to start testing RC_1_30_0. I would like to see the results of a round of testing on the current CVS state of that branch before we commit to a 1.30.1 release, just to make sure it's viable. -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Spirit rules
I obviously have not understood how spirit rules are supposed to work. The
simple program below fails to compile (spewing out 42 lines of error messages).
If I replace the application of 'Id' with int_p directly it works OK.
What am I supposed to do to get the intended effect?
#include iostream
#include boost/spirit.hpp
using namespace std;
using namespace boost::spirit;
int main(int *argc, char *argv[])
{
int ID;
rule Id = int_p;
if (parse(argv[1],
Id [assign(ID)],
space_p).full)
{
cout Value = ID endl;
}
else
{
cout Failed\n;
}
}
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Thoughts on fixdec
Bill Seymour [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Daryle Walker wrote: (Yes, I know that some numeric purists [and GCC] hate long double, but I want to maximize the capabilities.) The problem with a 'long double' ctor, either with or without 'double' ctor, is that long double is never the target of floating-point promotions, so decimal construction would become ambiguous from some types. 1. We have two math-related namespaces already. The boost::math namespace leans to theoretical work and boost::numeric leans to hard-core computation. I don't know that there's anything particularly theoretical about decimal representations; and the library's target audience is not those users who do hard-code computation, which I understand to mean numerical programming (in the sense of scientific and statical programming). It's not a major issue for me; and I'll do whatever the majority wants. I'm inclined toward boost::numeric. You should probably pick one of those namespaces (numeric?) and possibly rename the class to fixed_decimal. I'm reticent to require the user to type the extra fixed_ in every declaration of such an object. I prefer just 'decimal' because most decimal numbers I know of are fixed-point. So I think 'fixed' can be left implicit. 5. The conversion from int needs to check for overflow. The conversion from double needs to check also for underflow. The conversion from strings needs to check also for bad formats. But that would require some users to pay for something they don't need. Users who need that level of correctness can write their own checks; and others (probably most of the library's target audience) get better efficiency. Couldn't this be provided as a postcondition, in terms of BOOST_ASSERT? 6. There should only be conversions from strings, and _no_ mixed operations with strings. In the absence of decimal literals, I think it's easier for the user to be able to use strings as pseudo-literals in all contexts; and I don't see how the mixed operations do any harm. The problem is that quite unfortunately, string literals are just pointers to constant char, but such pointers are also used to access raw memory, so, char const* is the target to implicit conversions from a lot more than string literals. This would lead to unexpected implicit conversions. 9. What, no operator nor operator ? (The shift would be a power of ten.) Those operators don't exist for the floating-point types, and with good reason IMO. Their use is best reserved for twiddling bits, not for scaling. Even for binary integers, i 1 is not generally the same thing as i * 2 except on 2's-complement boxes. I agree. 13. You have strange (regular) assignment semantics. You try to change the receiver's logical value to the source's logical value, but retain the receiver's original scale (internally shifting the new significand and doing any rounding if needed). ... you will get strange effects if you try to change containers of decimal through assignment. I thought it would be less surprising if a decimal object's scale were immutable. This matches prior art (the BCD type on IBM mainframes, for example) in which the scale is part of the type. You're right about containerdecimal; but remember that this class isn't intended for number-crunching; so I don't really care about assigning matrices, etc. But this isn't about assigning matrices and number-crunching, it's about C++ assignment semantics. The postcondition of equivalence for assignment is a strongly fundamental feature of the C++ object model, and everything and everyone, not just containers, relies on that. No class, specially a class modeling a number, should violate that. You can use something of the form x[keep_scale]=y; for that special semantics. Fernando Cacciola ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: plans for a bugfix release ?
Martin Wille [EMAIL PROTECTED] writes: F David Abrahams wrote: Martin Wille writes: Hi, you wrote: Sounds fine to me. The only issue remaining is how we can get the testing infrastructure to start testing RC_1_30_0. I would like to see the results of a round of testing on the current CVS state of that branch before we commit to a 1.30.1 release, just to make sure it's viable. I'll run the tests for Linux and upload them as Linux-rc-1.30.0. They should be available in a few hours. Can you arrange the html so that it shows regressions from the 1.30.0 release results? Hmm, I'd have to find out how I would do that. Is there already some support for showing diffs between two versions of the test result tables? Yes. Beman? If there isn't such a thing I would try to implement something that reads two tables and marks the differences. That would take a day or two, I guess. In the meantime I'll publish tests for the 1.30.0 release and the for release candidate unmodified. I think the results are useful even without having the differences marked. Regards, m PS: Linux-rc-1_30_0 is available now. I'll run the tests for 1.30.0 release tonight. They will be available in about 9 hours. Thanks! -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: Re: is_nan - how to flag missing values?
| -Original Message- | From: [EMAIL PROTECTED] | [mailto:[EMAIL PROTECTED] Behalf Of Gabriel Dos Reis | Sent: Sunday, July 13, 2003 9:22 AM | To: Boost mailing list | Subject: Re: [boost] Re: Re: is_nan | | | Paul A. Bristow [EMAIL PROTECTED] writes: | | There is also a single IEEE FP pattern called 'indeterminate' or | what Intel call | | 'NotAVal (0x1fffe000...) which might become useful as a Portable Standard | | missing value marker if portably supported? | I won't take that road. Well if not then can you suggest a potentially Portable and Standard way to indicate 'missing values' in arrays etc of floating point values. I'm not sure that a qNaN is the best way to do this - it seems better suited to the result of compuational mishaps. | Signalling NaNs are used to indicate missing initialization values. This is OK for catching missing initialization by mistake - but not for OK for deliberately missing because there really is no value (measurement missing). In this case, for example calculating the mean, you want to test if the value is present/valid 'is_not_missing' before you add it to the sum and increment the count. Testing !is_nan is possible solution but I'm not sure it is ideal. Suggestions? Paul Paul A Bristow, Prizet Farmhouse, Kendal, Cumbria, LA8 8AB UK +44 1539 561830 Mobile +44 7714 33 02 04 Mobile mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: Re: is_nan
| -Original Message- | From: [EMAIL PROTECTED] | [mailto:[EMAIL PROTECTED] Behalf Of Gabriel Dos Reis | Sent: Sunday, July 13, 2003 9:22 AM | To: Boost mailing list | Subject: Re: [boost] Re: Re: is_nan | | | 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 If you 'show' a qNaN (or indeed an sNaN) with MSVC, you get cout The quiet NaN for type float is: numeric_limitsfloat::quiet_NaN( ) endl; Output: The quiet NaN for type float is: 1.#QNAN But suppose you want to display another message instead, perhaps to output data for input by some other system that recognizes all qNaNs as, say, NaN, so the output would be The quiet NaN for type float is: NaN AND would be portable for all platforms, of course. Similarly for infs, max, min - if you get floating point inf, max or min as a result of a calculation, it should be shown as special to the reader? Paul PS IMHO This is more important than it may appear because it, with the lack of a Standard isnan test, is preventing real-life use of NaNs. Paul A Bristow, Prizet Farmhouse, Kendal, Cumbria, LA8 8AB UK +44 1539 561830 Mobile +44 7714 33 02 04 Mobile mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: Re: test_fp_comparisons and rounding errors
| -Original Message- | From: [EMAIL PROTECTED] | [mailto:[EMAIL PROTECTED] Behalf Of Rozental, Gennadiy | Sent: Friday, July 11, 2003 7:39 PM | To: 'Boost mailing list' | Subject: RE: [boost] Re: Re: test_fp_comparisons and rounding errors | | | Do I understand correctly that | | BOOST_CHECK_CLOSE(v1, v2, 2. * std::numeric_limits::epsilon() ); | | would check that the absolute difference between v1 and v2 is | not more than two eps? | | Paul | | No. BOOST_CHECK_CLOSE performs relative errors comparison. See | http://www.boost.org/libs/test/doc/floating_point_comparison.htm | | (Ignore part that tries to calculate the tolerance based on number of | rounding errors) | | Gennadiy. Yes of course - sorry. So how would I achieve the above test? Personally I would still like to have the option of picking the absolute number of epsilons difference allowed - the number of least significant bits that are different. You are right that relative difference is usually what one wants - but not always in my experience. But I think that presenting it as 'number of rounds' is what is confusing and contentious. Paul ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: Re: test_fp_comparisons and rounding errors
| -Original Message- | From: [EMAIL PROTECTED] | [mailto:[EMAIL PROTECTED] Behalf Of Rozental, Gennadiy | Sent: Friday, July 11, 2003 7:39 PM | To: 'Boost mailing list' | Subject: RE: [boost] Re: Re: test_fp_comparisons and rounding errors | | | Do I understand correctly that | | BOOST_CHECK_CLOSE(v1, v2, 2. * std::numeric_limits::epsilon() ); | | would check that the absolute difference between v1 and v2 is | not more than two eps? | | Paul | | No. BOOST_CHECK_CLOSE performs relative errors comparison. See | http://www.boost.org/libs/test/doc/floating_point_comparison.htm | | (Ignore part that tries to calculate the tolerance based on number of | rounding errors) | | Gennadiy. | | ___ | Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost | | ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Documenting/testing boost::incomplete?
With the addition of the variant library has come several closely-related components such as boost::getT, boost::apply_visitor, boost::static_visitor, and boost::visitor_ptr. While I do plan to submit a more general-purpose visitation library for review in the near feature, currently these components are essentially useless outside of their use with boost::variant. Other components, however, are more general purpose -- namely, boost::empty and boost::incomplete. Since boost::empty is almost trivial, I plan to document and test it as part of the utility library. But boost::incomplete is generally quite useful (for example, in implementing the pimpl idiom), and I think Boosters may employ it often without boost::variant. My question then: should boost::incomplete be given its own libs/incomplete directory and an announcement on the main html page? Any input welcome. Thanks, Eric ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: is_nan - how to flag missing values?
Paul A. Bristow [EMAIL PROTECTED] writes: | | Signalling NaNs are used to indicate missing initialization values. | | This is OK for catching missing initialization by mistake - but not | for OK for deliberately missing because there really is no value | (measurement missing). There is not just one qNaN (nor just one sNaN). There is a range for NaNs. And most of the systems I worked with, the pattern bits in a NaN is used to communicate the reason of being of the NaN. For example, it may output sNaN(missing-value). Note: C99 provides a pseudo-standard way to produce NaNs, through the functions double nan(const char*); float nanf(const char*); long double nanl(const char*); | | In this case, for example calculating the mean, you want to test if the value is | present/valid 'is_not_missing' before you add it to the sum and increment the | count. | | Testing !is_nan is possible solution but I'm not sure it is ideal. Indeed, it is no good. | Suggestions? I would first make a summary of the usage of the bit patterns for NaNs and decide on one and document it. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Missing functional files in CVS?
In my copy of the main CVS, looking at ROOT/boost/libs/libraries.htm, the links to function and signals, both by Doug Gregor, don't work. Hopefully this is temporary?... Daryle ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Spirit rules
replace
rule Id = int_p;
with
rulephrase_scanner_t Id = int_p;
Lucas/
Kai-Mikael Jää-Aro [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
I obviously have not understood how spirit rules are supposed to work.
The
simple program below fails to compile (spewing out 42 lines of error
messages).
If I replace the application of 'Id' with int_p directly it works OK.
What am I supposed to do to get the intended effect?
#include iostream
#include boost/spirit.hpp
using namespace std;
using namespace boost::spirit;
int main(int *argc, char *argv[])
{
int ID;
rule Id = int_p;
if (parse(argv[1],
Id [assign(ID)],
space_p).full)
{
cout Value = ID endl;
}
else
{
cout Failed\n;
}
}
___
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: plans for a bugfix release ?
At 11:50 AM 7/16/2003, David Abrahams wrote: Beman Dawes [EMAIL PROTECTED] writes: So a schedule might look something like the following? -- 1.30.1 - Selected bug fixes only (details up to release manager). Schedule: a week or two from now I would be more hard-*ssed about it. A week. OK. I'll try to get a Win32 regression test run the 1_30_0 branch ASAP. --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: plans for a bugfix release ?
At 04:54 PM 7/16/2003, David Abrahams wrote: Martin Wille [EMAIL PROTECTED] writes: Hmm, I'd have to find out how I would do that. Is there already some support for showing diffs between two versions of the test result tables? Yes. Beman? I have a hack that I use to produce http://boost.sourceforge.net/regression-logs/cs-win32-diff.html It proves the concept, so to speak, but is way too unreliable. Fails when new compilers are added, for example. What is really needed is to add a history element to the test_log.xml files. That would be far more reliable. Let me think about it overnight. --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Problem with preprocessor library on IBM Regatta servers
Dear Boosters, In trying to port my codes and boost to an IBM Regatta (Power-4) massively parallel machine, I encountered compilation problems like the following that I cannot solve when compiling with IBM's xlC C++ compiler. Can anyone provide some insight or should I forget about the IBM compiler and try to get g++ to compile and run on the machine? Matthias xlC -c -I/users/troyer/boost /users/troyer/boost/libs/date_time/src/gregorian/greg_month.cpp -o boost/greg_month.o /users/troyer/boost/boost/operators.hpp, line 253.2: 1540-0816 (W) Too many arguments are specified for the macro BOOST_PP_SEQ_CAT_O_I. The extra arguments are ignored. /users/troyer/boost/boost/preprocessor/seq/cat.hpp, line 30.10: 1540-0425 (I) BOOST_PP_SEQ_CAT_O_I is defined on line 30 of /users/troyer/boost/libs/date_time/src/gregorian/greg_month.cpp. /users/troyer/boost/boost/operators.hpp, line 253.2: 1540-0861 (S) Too few arguments are specified for macro BOOST_PP_IIF_0. Empty arguments are used. /users/troyer/boost/boost/preprocessor/control/iif.hpp, line 32.10: 1540-0425 (I) BOOST_PP_IIF_0 is defined on line 32 of /users/troyer/boost/libs/date_time/src/gregorian/greg_month.cpp. /users/troyer/boost/boost/operators.hpp, line 253.2: 1540-0861 (S) Too few arguments are specified for macro BOOST_PP_SEQ_ELEM_III. Empty arguments are used. /users/troyer/boost/boost/preprocessor/seq/elem.hpp, line 40.13: 1540-0425 (I) BOOST_PP_SEQ_ELEM_III is defined on line 40 of /users/troyer/boost/libs/date_time/src/gregorian/greg_month.cpp. /users/troyer/boost/boost/operators.hpp, line 254.2: 1540-0816 (W) Too many arguments are specified for the macro BOOST_PP_SEQ_CAT_O_I. The extra arguments are ignored. /users/troyer/boost/boost/preprocessor/seq/cat.hpp, line 30.10: 1540-0425 (I) BOOST_PP_SEQ_CAT_O_I is defined on line 30 of /users/troyer/boost/libs/date_time/src/gregorian/greg_month.cpp. /users/troyer/boost/boost/operators.hpp, line 254.2: 1540-0861 (S) Too few arguments are specified for macro BOOST_PP_IIF_0. Empty arguments are used. /users/troyer/boost/boost/preprocessor/control/iif.hpp, line 32.10: 1540-0425 (I) BOOST_PP_IIF_0 is defined on line 32 of /users/troyer/boost/libs/date_time/src/gregorian/greg_month.cpp. /users/troyer/boost/boost/operators.hpp, line 254.2: 1540-0861 (S) Too few arguments are specified for macro BOOST_PP_SEQ_ELEM_III. Empty arguments are used. /users/troyer/boost/boost/preprocessor/seq/elem.hpp, line 40.13: 1540-0425 (I) BOOST_PP_SEQ_ELEM_III is defined on line 40 of /users/troyer/boost/libs/date_time/src/gregorian/greg_month.cpp. /users/troyer/boost/boost/operators.hpp, line 255.2: 1540-0816 (W) Too many arguments are specified for the macro BOOST_PP_SEQ_CAT_O_I. The extra arguments are ignored. /users/troyer/boost/boost/preprocessor/seq/cat.hpp, line 30.10: 1540-0425 (I) BOOST_PP_SEQ_CAT_O_I is defined on line 30 of /users/troyer/boost/libs/date_time/src/gregorian/greg_month.cpp. /users/troyer/boost/boost/operators.hpp, line 255.2: 1540-0861 (S) Too few arguments are specified for macro BOOST_PP_IIF_0. Empty arguments are used. /users/troyer/boost/boost/preprocessor/control/iif.hpp, line 32.10: 1540-0425 (I) BOOST_PP_IIF_0 is defined on line 32 of /users/troyer/boost/libs/date_time/src/gregorian/greg_month.cpp. /users/troyer/boost/boost/operators.hpp, line 255.2: 1540-0861 (S) Too few arguments are specified for macro BOOST_PP_SEQ_ELEM_III. Empty arguments are used. /users/troyer/boost/boost/preprocessor/seq/elem.hpp, line 40.13: 1540-0425 (I) BOOST_PP_SEQ_ELEM_III is defined on line 40 of /users/troyer/boost/libs/date_time/src/gregorian/greg_month.cpp. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Spirit rules
Kai-Mikael Jää-Aro [EMAIL PROTECTED] wrote:
I obviously have not understood how spirit rules are supposed to work. The
simple program below fails to compile (spewing out 42 lines of error
messages). If I replace the application of 'Id' with int_p directly it works
OK.
What am I supposed to do to get the intended effect?
#include iostream
#include boost/spirit.hpp
using namespace std;
using namespace boost::spirit;
int main(int *argc, char *argv[])
{
int ID;
rule Id = int_p;
if (parse(argv[1],
Id [assign(ID)],
space_p).full)
{
cout Value = ID endl;
}
else
{
cout Failed\n;
}
}
Hi,
See the FAQ The Scanner Business. It's always a good idea
to scan the FAQ first.
BTW, Spirit has its own mailing list:
Spirit-general mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/spirit-general
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: plans for a bugfix release ?
From: David Abrahams [mailto:[EMAIL PROTECTED] Sent: Wednesday, July 16, 2003 10:51 AM Sounds fine to me. The only issue remaining is how we can get the testing infrastructure to start testing RC_1_30_0. I would like to see the results of a round of testing on the current CVS state of that branch before we commit to a 1.30.1 release, just to make sure it's viable. Here are the results we have: 1.30.0 tarball: http://tinyurl.com/h6cx CVS main trunk (relative to 1.30.0 tarball): http://tinyurl.com/h6d0 CVS RC_1_30_0 branch (relative to 1.30.0 tarball): http://tinyurl.com/h6d7 (will be available in 9 hours) Our plan is to have the up-to-date CVS RC_1_30_0 branch and CVS main trunk results every day. Misha Bergal MetaCommunications Engineering ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: plans for a bugfix release ?
Martin Wille writes: I'll run the tests for Linux and upload them as Linux-rc-1.30.0. They should be available in a few hours. Can you arrange the html so that it shows regressions from the 1.30.0 release results? Hmm, I'd have to find out how I would do that. Is there already some support for showing diffs between two versions of the test result tables? For the new regression report format, yes. For instance, here's the CVS main trunk report against the 1.30.0 tarball - http://www.meta-comm.com/engineering/resources/cvs_main_trunk/developer_summary_page.html If you are interested in producing these, we will provide you with the scripts. You'd need an XSLT processor and Python, but beside that it's as simple as running a Python script after the regression run. If there isn't such a thing I would try to implement something that reads two tables and marks the differences. That would take a day or two, I guess. Please, don't! If you have the prerequisits installed, setting up a step to produce the new-format reports should take about 15 minutes, and they are way much more informative. Aleksey ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: plans for a bugfix release ?
Beman Dawes wrote: At 04:54 PM 7/16/2003, David Abrahams wrote: Martin Wille [EMAIL PROTECTED] writes: Hmm, I'd have to find out how I would do that. Is there already some support for showing diffs between two versions of the test result tables? Yes. Beman? I have a hack that I use to produce http://boost.sourceforge.net/regression-logs/cs-win32-diff.html It proves the concept, so to speak, but is way too unreliable. Fails when new compilers are added, for example. What is really needed is to add a history element to the test_log.xml files. That would be far more reliable. Let me think about it overnight. The way we do it in the new reports is to extract the failures from the original regression run and pass them as expected failures to the input of the scripts producing the today's reports. The scripts merge these into extended results XML, and then produce the HTML reports basing on that. Works perfectly. All XML processing is done through XSLT, but it's very worth it - the stlysheets which do the extracting and merging are barely 100 lines long. Aleksey ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: plans for a bugfix release ?
- Original Message - From: Aleksey Gurtovoy [EMAIL PROTECTED] Beman Dawes wrote: What is really needed is to add a history element to the test_log.xml files. That would be far more reliable. Let me think about it overnight. The way we do it in the new reports is to extract the failures from the original regression run and pass them as expected failures to the input of the scripts producing the today's reports. The scripts merge these into extended results XML, and then produce the HTML reports basing on that. Works perfectly. All XML processing is done through XSLT, but it's very worth it - the stlysheets which do the extracting and merging are barely 100 lines long. Aleksey I don't have the time now, but if it's feasible for you I would absolutely _love_ if we could integrate this with BoostBook in the future. If I had my way, everything would run through the documentation system so that everything would be documented (see, e.g., the testsuite documentation and generation for Function) and in sync. Doug ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Missing functional files in CVS?
- Original Message - From: Daryle Walker [EMAIL PROTECTED] To: Boost [EMAIL PROTECTED] Sent: Wednesday, July 16, 2003 3:10 PM Subject: [boost] Missing functional files in CVS? In my copy of the main CVS, looking at ROOT/boost/libs/libraries.htm, the links to function and signals, both by Doug Gregor, don't work. Hopefully this is temporary?... Less temporary than I'd hoped, because we still don't have a good solution for the generated documentation... anyway, the documentation is all available here: http://www.cs.rpi.edu/~gregod/boost/doc/html/libraries.html From that page, you can grab the HTML documentation tarball and extract it in $BOOST_ROOT to get the documentation you seek. You can also grab the PDF file or some Unix man pages, if you prefer those :) Doug ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Documenting/testing boost::incomplete?
- Original Message - From: Eric Friedman [EMAIL PROTECTED] Other components, however, are more general purpose -- namely, boost::empty and boost::incomplete. Since boost::empty is almost trivial, I plan to document and test it as part of the utility library. But boost::incomplete is generally quite useful (for example, in implementing the pimpl idiom), and I think Boosters may employ it often without boost::variant. My question then: should boost::incomplete be given its own libs/incomplete directory and an announcement on the main html page? Any input welcome. I think both boost::empty and boost::incomplete should go into the utility library, because they are both of general utility and are relatively small. But they should be mentioned on the main HTML page in any case, because they can be useful for users. Doug ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
