Re: [boost] Any progress in bit_iterator?
--- Gennaro Prota <[EMAIL PROTECTED]> wrote: > Note that you can't work on "raw memory" in the sense > that you ignore the type of the objects and treat them as sequences of > unsigned chars: that's because you could end up treating padding bits = 1 as > "real bits" (value bits). Well, that could be exactly the intent, but not always :-) Genny. __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Any progress in bit_iterator?
--- Alexander Nasonov <[EMAIL PROTECTED]> wrote: > Google shows me a few links about bit_iterator. > > http://lists.boost.org/MailArchives/boost/msg03435.php > http://groups.yahoo.com/group/Boost-Users/message/994 > > Any progress since these messages have been posted? > > Definitely, I have an interest in bit_iterator. But I don't have enough time > to implement it :( I understand that it is not the same thing you want here, but dynamic_bitset will have two functions, find_first and find_next, which allow iteration upon "on" bits (see the sandbox). I'm not sure that having an "iterator interface" is a good idea, since the class wouldn't satisfy the iterator requirements anyway (proxy). In any case, it's trivial to construct a "dynamic_bitset pseudo-iterator" based on those functions. Internally the two functions work on an array of Blocks. Note that you can't work on "raw memory" in the sense that you ignore the type of the objects and treat them as sequences of unsigned chars: that's because you could end up treating padding bits = 1 as "real bits" (value bits). So, using a "typed array" is probably the best way to go (if the element type has padding you can see that at compile time). The implementation, actually, is trivial: in my case, I simply find the first element of the array != 0 and then compute a log to base 2. Genny. __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: BOOST_EXPLICIT_TEMPLATE_TYPE
On Sun, 10 Aug 2003 03:33:50 -0400, "Eric Friedman"
<[EMAIL PROTECTED]> wrote:
>Dave (and others):
>
>Eric Friedman wrote:
>> David Abrahams wrote:
>> >
>> > Hi,
>> >
>> > BOOST_EXPLICIT_TEMPLATE_TYPE is great!
>> >
>> > However:
>> [snip]
>> > // specialization
>> > template <>
>> > int f( /*what goes here?*/ )
>> > {
>> >
>> > }
>> >
>> > we have no mechanism for handling these. Any ideas?
>>
>> Wouldn't BOOST_EXPLICIT_TEMPLATE_TYPE(void) work?
>
>Ooops, you're right. Guess I don't know the standard well enough.
>
>I've added BOOST_EXPLICIT_TEMPLATE_TYPE_SPEC (and so on) helper macros to
>address this problem (in config/suffix.hpp) since it's actually been
>creating problems with variant under gcc. Let me know if this solution
>doesn't meet your expectations.
It may help to paste here what I said to Dave in the first place (he
wrote privately too, and since I wasn't following the list I didn't
notice that a copy was also posted here):
--
> However:
>
> template
> int f(BOOST_EXPLICIT_TEMPLATE_TYPE(T))
> {
>...
> }
>
> // specialization
> template <>
> int f( /*what goes here?*/ )
> {
>
> }
>
> we have no mechanism for handling these. Any ideas?
Hmm... no, because then you clash with other VC6 bugs (concerning
default arguments).
Of course you can't put BOOST_EXPLICIT_TEMPLATE_TYPE(void) because it
re-defaults the dummy argument (which is illegal) but even without the
default... :-( For instance:
template
int f( boost::type* = 0 )
{
return 0;
}
// specialization
template <>
int f( boost::type * )
{
return 1;
}
int main()
{
std::cout << f() << '\n';
std::cout << f() << '\n';
return 0;
}
VC6 says "error C2660: 'f' : function does not take 0 parameters" at
the line that contains the call to f.
--
Genny.
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Proposal: BOOST_NO_TEMPLATED_STREAMS config macro andhelpers
On Sat, 26 Jul 2003 01:08:00 -0400, "Eric Friedman" <[EMAIL PROTECTED]> wrote: >In adding output streaming support for variant, I've realized the >standard library packaged with gcc 2.9.7 and below does not support the >templated stream classes. I've also realized that Boost.Tuple features a >workaround addressing this same problem, with a comment to add a defect >macro to boost/config.hpp in the future. The test in Boost.Tuple however is totally wrong (it just tests for the compiler, while it should test for the library - also IIRC the library that ships with gcc 2.95 doesn't have the templated iostreams either). I had this problem with dynamic_bitset and, after discussing it with Phil Edwards (who is one of the maintainers of libstdc++), I came up with the macro that is currently in http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/boost-sandbox/boost-sandbox/boost/dynamic_bitset.hpp?rev=1.28&content-type=text/vnd.viewcvs-markup Basically I just wanted to support pre-3.0 versions of libstdc++, at least the ones that are still in wide usage, and I don't know whether that macro actually detects all of them or not; but it worked on the versions I tried it on and there appears to be nothing better to test for (libstdc++ 3 identifies itself with a suitable macro, __GLIBCPP__, but previous versions don't). Of course I agree that having a single macro in a single place is good, but your solution seems overkilling to me: consider that, though there are cases where you are able, with a couple of macros, to write an inserter or an extractor that works with both old and new iostreams, there are many other cases where the two versions are quite different; take a look, for instance, at the new dynamic_bitset extractor: it is totally different from a (yet to come) old-iostreams version because it uses the stream buffer directly and because it takes into account throwing for eofbit, failbit, etc. In such cases I don't claim that boost developers always write an old-iostream version too, so your macros would probably be far less used than it might appear at first sight) Genny. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: [dynamic_bitset] - small fix for workaround macro
On Fri, 25 Jul 2003 19:24:54 +0200, "Pavel Vozenilek" <[EMAIL PROTECTED]> wrote: >dynamic_bitset.hpp defines macro >BOOST_WORKAROUND_REPEAT_DEFAULT_TEMPLATE_ARGUMENTS that can be trivially >replaced by BOOST_WORKAROUND. The macro is used only in this header. I know. It was only meant as kind of self-documentation. If everybody prefers using BOOST_WORKAROUND directly I can do that too (I have never liked the macro too much either :-)) >Diff for 1.30: You mean boost 1.30? > Ok. In general, please refer (for now) to the sandbox version of dynamic_bitset, which is the one actively maintained (and, as you can see, it already uses BOOST_WORKAROUND, though just to define BOOST_WORKAROUND_BLA_BLA_BLA). I hope to move it soon to the main repository. Thanks for your suggestion. Genny. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Dangerous no_type-definition in signals_common.hpp
On Mon, 21 Jul 2003 10:45:13 -0400, David Abrahams <[EMAIL PROTECTED]> wrote: >The use of char[8] in the type_traits header serves as a kind of >"anti-documentation", IMO. IMO too :-) http://article.gmane.org/gmane.comp.lib.boost.devel/17895 Genny. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Changes with new release
--- Edward Diener <[EMAIL PROTECTED]> wrote: > Is it really so hard for a library implementor, who has made changes in how > his library works between releases, to write a paragraph or a page > explaining the change(s) in functionality so that others can see where the > library is going and what new or different usage it entails ? Not hard, no, but it certainly takes more time than it might appear. FWIW, I've started such a section for dynamic_bitset. The doc file, for now, is in the boost sandbox, subfolder /libs/dynamic_bitset. > If I were a > library implementor, whether Boost or otherwise, I would want to explain my > ideas to the outside world as a way of promoting good technology. Ahehm... :-) Genny. __ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Slight revision to more-I/O
--- Daryle Walker <[EMAIL PROTECTED]> wrote: > Actually, I don't think the Review Manager ever gave a final answer. > Well, he and everyone else can take a quick look. It seems that some > people around here are jumpy for a release, so we should get this > review resolved soon. Actually I was under the impression that most of the stuff was rejected (I gave up following the review because most of my comments http://article.gmane.org/gmane.comp.lib.boost.devel/17500 were simply ignored, but I didn't see very positive comments either). Am I wrong? Did everybody like this? Genny. __ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: WCHAR_MIN/MAX not defined for NetBSD in integer_traits.h
On Mon, 23 Jun 2003 18:27:43 -0400, felix zaslavskiy <[EMAIL PROTECTED]> wrote: > >NetBSD does not have WCHAR_MIN/MAX using gcc3.3 basicaly the min/max for >wchar_t is INT_MIN/MAX similarly to freeBSD > >I encountered this problem when trying to compile boost.python which >failed because of this problem. I don't know what's the situation for boost.python, however I collected all the WCHAR_MIN/MAX workarounds that were in integer_traits.hpp into the file wchar_min_max.hpp, available here: http://groups.yahoo.com/group/boost/files/MoreTraits.zip We could put that file somewhere in boost, so that it's usable by any library that needs WCHAR_MIN or WCHAR_MAX. Dave? Genny. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Advanced match constants scheme
On Sun, 22 Jun 2003 00:50:32 +0200 (CEST), Guillaume Melquiond
<[EMAIL PROTECTED]> wrote:
>We are sure c_l is the nearest 'long double'. Now we want the nearest
>'double'. Can we simply do:
>
>double c_d() { return c_l(); }
>
>No, we can't.
We already agreed that a different definition must be provided for
each type (float, double, long double, and possibly UDTs in some of
the proposed approaches). Is this the only objection? I haven't
analyzed the rest of the post because this could be a crucial
misunderstanding (I've read everything, only a little more
absent-mindedly).
Genny.
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Advanced match constants scheme
On Fri, 20 Jun 2003 22:04:53 +0200 (CEST), Guillaume Melquiond <[EMAIL PROTECTED]> wrote: [...] >I know this part of the standard. But it doesn't apply in the situation I >was describing. I was describing the case of a constant whose decimal (and >consequently binary) representation is not finite. It can be an irrational >number like pi; but it can also simply be a rational like 1/3. I was just trying to start from something sure, such as the standard requirements. I had some difficulties in understanding your example. The way I read the paragraph quoted above, "the scaled value" is the value intended in the mathematical sense, not its truncated internal representation. So the compiler must behave *as if* it considered all the digits you provide and choose the nearest element (smaller or larger - BTW C99 is different in this regard). In your example: the constant is 1.00050001236454786005785305678 you write it with 7 seven digits: 1.000500 the floating-point format only uses 4 digits you wouldn't write 1.000500 but, for instance, 1.00050001 and the hypothetical base-10 implementation should then consider all the digits even if it can store only 4 of them. Thus if it chooses the *larger* value nearest to that it chooses 1.001. Of course if it chooses the smaller..., but that's another story. Just to understand each other: suppose I write double d = 2348542582773833227889480596789337027375682548908319870707290971532209025114608443463698998384768703031934976.0; // 2**360 The value is 2**360. On my implementation, where DBL_MAX_EXP is 1024 and FLT_RADIX is 2, isn't the compiler required to accept and represent it exactly? > >When manipulating such a number, you can only give a finite number of >decimal digit. And so the phenomenon of double rounding I was describing >will occur since you first do a rounding to have a finite number of >digits and then the compiler do another rounding (which is described by >the part of the standard you are quoting) to fit the constant in >the floating-point format. I'm not very expert in this area. Can you give a real example (constant given in decimal and internal representation non-decimal)? [...] > >> "chosen in an implementation-defined manner" above could simply mean >> "randomly" as long as the fact is documented. > >The fact that it does it randomly is another problem. Even if it was not >random but perfectly known (for example round-to-nearest-even like in the >IEEE-754 standard), it wouldn't change anything: it would still be a >second rounding. As I said, it is more of an arithmetic problem than of a >compilation problem. But can you give a concrete example? [...] >> float x = 1.2f; >> assert(x == 1.2); >> >> fails on most machines. > >Yes, but it's not what I was talking about. I hope it's a bit more clear >now. This was the result of some sloppy editing :-) Actually it was (with an f suffix in both occurrences of the literal) in a little digression about the fact that floating literals can be evaluated with more precision than their corresponding type. But last time I've read this it was in the C99 standard and I don't remember whether a similar freedom is explicitly granted by C++ too. In short, ignore the example, I should have erased it together with the digression. Genny. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Advanced match constants scheme
On Fri, 20 Jun 2003 18:30:48 +0200 (CEST), Guillaume Melquiond <[EMAIL PROTECTED]> wrote: >On Fri, 20 Jun 2003, Paul A Bristow wrote: > >[snip] > >> | [*] It is not even true. Due to "double rounding" troubles, >> | using a higher precision can lead to a value that is not the >> | nearest number. >> >> Is this true even when you have a few more digits than necessary? >> Kahan's article suggested to me that adding two guard decimal digits >> avoids this problem. This why 40 was chosen. > >I don't know if we are speaking about the same thing. I don't know either. What I know is the way floating literals should work: A floating literal consists of an integer part, a decimal point, a fraction part, an e or E, an optionally signed integer exponent, and an optional type suffix. [...] If the scaled value is in the range of representable values for its type, the result is the scaled value if representable, else the larger or smaller representable value nearest the scaled value, chosen in an implementation-defined manner. Of course "the nearest" means nearest to what you've actually written. Also, AFAICS, there's no requirement that any representable value can be written as a (decimal) string literal. And, theoretically, the "chosen in an implementation-defined manner" above could simply mean "randomly" as long as the fact is documented. Now, I don't even get you when you say "more digits than necessary". One thing is the number of digits you provide in the literal, one other thing is what can effectively be stored in an object. I think you all know that something as simple as float x = 1.2f; assert(x == 1.2); fails on most machines. Genny. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Math Constants Formal Review - using namespaces toselectfloatsize is simpler?
On Thu, 19 Jun 2003 19:51:31 +0100, "Paul A Bristow"
<[EMAIL PROTECTED]> wrote:
>| Well, you wanted to know what is likely to be accepted. In a
>| formal review (this isn't anymore, AFAIU, is it?) I would
>| vote no to your approach.
>
>But would you vote yes if the only presentation was Daniel's method?
Overall? What I like in his code is the use of template specialization
to provide the values for different types, and the possibility to add
UDTs. OTOH, I'm not sure whether the conversion function template and
the pre-built binary operators (see ADD_OPERATOR) are worth having.
Personally I won't probably use those operators, as they are just
syntactic sugar to avoid an explicit cast of the constant instance to
the type of its (left or right) "neighbour". Of course that's
different from what we are used to with built-in constant variables
(floating point promotion). Example: if I have
const double pi = ...;
then in
pi * f * d
the language assures me that f is promoted to a double as well and the
result is a double. When I use "class pi" instead the selected type of
the constant (through pi_value) becomes the one of the adjacent
operand, which is quite a different thing. So you have a familiar
appearance (you write the expression as if 'pi' had a built-in type,
with the usual operators etc.) with an unfamiliar behavior. I'm not
saying that is necessarily wrong but, not having any concrete
experience with it, I'm not sure it is a good thing
either. However, one can explicitly static_cast, so those who want to
be "safe" can be.
Of course, if you leave there the conversion function but not the
operators you end up with the same behavior in most cases, thanks to
the built-in candidates in overload resolution. And a conversion
function can't be made 'explicit' (for now?). A possibility could be
to use some "floating point promotion" traits (one trivial
implementation is in the Yahoo files section), to select the
*promoted* neighbour type, but that's probably not worth the trouble.
Summarizing: I think Daniel is on the right track, but I'm not
particularly fond of the automatic "conversions" (actually they are
automatic "selections" of the type, based on the context of usage -
and since the selection mechanism is different from the built-in
one...)
>I am only really concerned that the accurate constants become more
>standardised, in name and value.
Yes. Just to stimulate discussion, and without any offence towards
Daniel's solution, this is an approach without the conversion function
and the operator overloads. Beware that it's completely untested.
namespace math
{
// Generic base class for all constants
template< typename T /*, template< class > class F*/ >
struct constant {};
// value_type selector basically says what's the
// template class (pi_value, gamma_value, etc.) whose
// specializations give the different values. It avoids
// using template template parameters, which aren't
// supported by all compilers.
template
struct value_selector;
template
U as(const constant & c) {
value_selector::type::spec obj;
return obj();
};
// Here's the definition for pi for some
// usual types (can be extended by UDTs)
//
template struct pi_value;
template<> struct pi_value
{ float operator()() { return 3.14f; } };
template<> struct pi_value
{ double operator()() { return 3.1415; } };
template<> struct pi_value
{ long double operator()() { return 3.141592L; } };
// Here's the single line to create a useful interface
struct pi_type : constant< pi_type > {} pi;
// Here's the line to tell that the value of type T
// for the constant pi is given by pi_value
template <> struct value_selector
{
template
struct type {
typedef pi_value spec;
};
};
//-
// another constant (pi ** 2)
template< typename T > struct pi2_value;
template<> struct pi2_value
{ float operator()() const { return 9.87f; } };
template<> struct pi2_value
{ double operator()() const { return 9.8696; } };
template<> struct pi2_value
{ long double operator()() const { return 9.8696044L; } };
struct pi2_type : constant {} pi2;
template <> struct value_selector
{
template
struct type {
typedef pi2_value spec;
};
};
//---
// Some obvious (?) constants:
//
#define CONSTANT_VALUE( name, value ) \
template< typename T > struct name##_value \
{ T operator()() const { return value; } }; \
\
struct name##_type : constant {} name; \
\
template<> \
struct value_selector {
[boost] Re: BOOST_STATIC_WARNING ?
On Fri, 20 Jun 2003 00:49:42 -0400, Daryle Walker <[EMAIL PROTECTED]>
wrote:
>On Wednesday, June 18, 2003, at 9:59 PM, David Abrahams wrote:
>> Slightly. They are still "non-portable constructions made up by
>> compiler makers."
>
>As I understand it, the #include directive dumps the contents of a file
>found from the standard (<>) and/or user ("") header space. The only
>degrees of variance is how the mapping of header names to files/sources
>occurs and how the standard headers are handled.
Really?
http://www.google.com/groups?threadm=plfbev89vgf08s0o3848bjssetqtqn0at9%404ax.com
Also, I have resisted once but now you want to make me suffer :-)
>From another post in this thread:
>Warnings are completely non-portable, since:
>1. They have no official standing in the standard, just errors do
^^
Really?
>[...]
>3. They are 100% legal code, the vendor just doesn't like it
Really?
>Equating the
>implementation-defined parts of #include to the warning concept, which
>has no official standing, is a gross misrepresentation.
I don't think Dave was really equating. He was probably just saying
that features not exactly specified, or not specified at all, by the
standard can still be useful in practice.
Not that I'm for BOOST_STATIC_WARNING, just to avoid such erroneous
information about what is standard and what is not.
Genny.
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Experimental audience-targeted regression results
On Thu, 19 Jun 2003 08:06:48 -0500, Aleksey Gurtovoy <[EMAIL PROTECTED]> wrote: >Gennaro Prota wrote: >> I particularly like the fact that they are organized by >> library, rather than by platforms as were the latest regression logs I >> have seen. > >Well, actually at the moment these are for a single platform only (win32). >Having the most recent results for each platform collected into a nice >single summary table is something that I hope somebody will address further >down the road. Or even single tables, with links (e.g. '-> next platform') that allow the developer to rapidly have a look-through and see how his/her library behaves everywhere. >[...] > >> Also, since 'doesn't work' and 'broken' (in the user summary) are >> practically synonyms, I would simply use a dash or an empty cell >> instead of the former. > >Uhm, they are not, though! 'broken' on the user summary page indicates that >_the current_ CVS state is broken, probably to somebody's erroneous checkin, >but, as its legend says, that doesn't at all mean that the library is not >usable on that compiler. Basically it says "if you get me know, I won't >compile". Ah :-) I meant that, without an explanation (as the one above), it was difficult to understand what was the supposed difference. Out of context, the two terms means almost the same thing. Well, for 'broken' I would suggest 'broken cvs', 'bad status', 'bad cvs', 'cvs mess' or 'screwed up'. If you are also looking for alternatives to 'doesn't work' (reply to Rene), well, what about 'no hope'? ;-) Seriously, for the latter I would simply use a dash. > As soon as the regression is fixed, all broken statuses will >become "OK" or "OK*". "doesn't work" means, well, doesn't work, permanently. > >> But these are really minor points. >> >> More importantly instead, would it be possible to also have a sign >> indicating regressions? A little gif comes to mind, but even something >> as simple as an asterisk could be ok. > >Hmm, I am not sure I understand what we are talking about here. Anyway, >ultimately, the developer summary page is supposed to serve as a regressions >indicator, but for it to work every library author need to go through the >trouble of specifying the expected failures and fixing everything else. What I was thinking to is an "automatic" indicator that the result of a test is different from the previous running or from a "reference running" (especially when it is worse ;-)). In practice, I guess, it isn't easy to remember whether for compiler xyz on platform abc a given library was already failing or not, especially for those who are authors of several libraries. Or is it just me and you, guys, all remember such things? :-O > >Thanks for the thoughts, Thanks to you. I do know that this is a thankless work. At least with C++ there's a lot of fun :-) Genny. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Math Constants Formal Review - using namespaces toselectfloat size is simpler?
On Thu, 19 Jun 2003 14:30:56 +0100, "Paul A Bristow" <[EMAIL PROTECTED]> wrote: >I stand better informed than I really wanted to be, Is this an idiomatic expression? Because, to the letter, it means you didn't want to understand the details (which are, by the way, very simple). Of, course, that's quite another matter. >and only quacking quietly from getting my mind round >the implications of these rather complex rules. >(They remind me of PL/1 automatic conversions which were >designed by IBM sales managers to sell computers >but ended up being a maze of snares for the unwary.) > >This scheme may offer more surprises to the many naive users (like me) >than an explicit (and convenient 'global') choice, for example: > >using boost::math::double_constants; > >to ensure that the expected size is used. Well, you wanted to know what is likely to be accepted. In a formal review (this isn't anymore, AFAIU, is it?) I would vote no to your approach. Genny. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Math Constants Formal Review - does static_cast merely select?
On Wed, 18 Jun 2003 22:27:27 +0100, "Paul A Bristow"
<[EMAIL PROTECTED]> wrote:
>| -Original Message-
>| From: [EMAIL PROTECTED]
>| [mailto:[EMAIL PROTECTED] On Behalf Of Gennaro Prota
>| [...]
>|
>| In Daniel's solution static_cast(x) simply "selects"
>| the corresponding specialization of x_value. So
>|
>|static_cast(pi)
>|
>| is fundamentally different from, say,
>|
>|double pi = ...;
>|static_cast(pi)
>
>Perhaps naively, I find this surprising - but I am not a language guru.
>
>Can you/anyone confirm that this is required by the Standard
> - and is in fact what happens when compilers process this?
Yes :-) Note that all "conversions" from a constant pass through
template< typename U > operator U() const { return F< U >()(); }
Now, F()() means (ignoring some technical differences irrelevant
here):
F object; // construct an x_value object
return object(); // invoke operator() on it and return
Now, if you use the binary operators, like in:
pi * f;
with f being a float then the selected specialization is float; i.e.
the constant "takes the type" of its adjacent operand (left operand if
it exists, right operand otherwise). This is, of course, different
from what normally happens when you do
double pi = ...;
pi * f; // floating point promotion on f
and is IMHO a caveat. But, still, there are no truncations. Only
selection of the target specialization. If no target specialization
exists, e.g.
static_cast(pi)
you have a compile-time error.
>
>If it walks like a duck and quacks like a duck ...
This walks quite differently. And doesn't quack :-)
Genny.
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Experimental audience-targeted regression results
On Wed, 18 Jun 2003 10:01:58 -0500, Aleksey Gurtovoy <[EMAIL PROTECTED]> wrote: >... as per http://article.gmane.org/gmane.comp.lib.boost.devel/20648 are >available from here: > > * user summary page - >http://boost.sourceforge.net/regression-logs/user_summary_page.html > * developer summary page - >http://boost.sourceforge.net/regression-logs/developer_summary_page.html > >Please comment! Nice :-) I particularly like the fact that they are organized by library, rather than by platforms as were the latest regression logs I have seen. Personally I would like the green fail (in the developer summary) to read 'expected fail', for instance (or an abbreviation, such as 'exp. fail'). I'm the kind of guy that when faced with a 'fail' in a green cell begins wondering whether there was an error in the script :-) Also, since 'doesn't work' and 'broken' (in the user summary) are practically synonyms, I would simply use a dash or an empty cell instead of the former. But these are really minor points. More importantly instead, would it be possible to also have a sign indicating regressions? A little gif comes to mind, but even something as simple as an asterisk could be ok. Genny. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Math Constants Formal Review - accuracy is vital too
On Wed, 18 Jun 2003 15:15:24 +0100, "Paul A Bristow" <[EMAIL PROTECTED]> wrote: [...] >Maximum possible accuracy is a central feature, >promising the best possible portability, >especially for intervals where every really bit really counts. > >It was also agree that any casting to obtain other types did not >garanteed accuracy and this was why the proposed code uses namespaces >to allow selection of the FP size either individually: In Daniel's solution static_cast(x) simply "selects" the corresponding specialization of x_value. So static_cast(pi) is fundamentally different from, say, double pi = ...; static_cast(pi) [...] > >Although your operators are neat, speeding -sin(pi/two), >my suspicion is that it is better to pre-calculate as many >constants as possible, and as accurately as possible. >I don't think this counts as "premature optimisation" :-) In fact it's not a matter of speed, but of precision. I'm sure there are compilers where the -sin(pi/2.) in the example code is faster than -sin(pi/two ). However an overload allows you to specify that the value of, say, arccos(-1) [math::acos(minus_one)] is exactly pi. Genny. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Math Constants Formal Review - ()s are a key issue.
On Wed, 18 Jun 2003 09:47:50 +0200, Daniel Frey <[EMAIL PROTECTED]> wrote: >Paul A Bristow wrote: >> I am confident that your system also generates efficient code using an >> efficient compiler. >> But have you considered or tried debugging? > >Currently, I don't have time for that. Maybe at the weekend, but I can't >promise. But I agree that it should be verified in practice. What should be verified? > >What I'd also like to hear is opinions from others here on the list. >What do you think? FWIW, I agree with everything you've said (except, maybe, the comment about debugging above). The arguments that Paul gives for his approach(es) are something beyond me. Genny. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] max_size() workaround?
Is this of any interest for boost? Some library implementations (for
instance STLport) return a value of container::max_size that doesn't
depend on the corresponding allocator. For instance, for vector
STLport returns:
size_type(-1) / sizeof(T)
As a result, if one uses his own allocator which has, say, a maximum
size = 255, there's no hope that the user of vector can see the limit.
Would something like this be ok?
template
typename T::size_type max_size(const T& t)
{
// Note that there's no requirement for a container's
// size_type to match its allocator size_type.
// There is for basic_string.
//
typedef typename T::allocator_type allocator_type;
const typename allocator_type::size_type max_alloc =
t.get_allocator().max_size();
const typename T::size_type max_cont = t.max_size();
return max_alloc < max_cont? max_alloc : max_cont;
}
Genny.
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Up-to-date std::auto_ptr?
On Fri, 13 Jun 2003 17:59:37 -0400, Daryle Walker <[EMAIL PROTECTED]> wrote: >I've occasionally read that the std::auto_ptr system was changed in an >update document, due to some problems in the standard's specification. >Is this true? AFAIK, no. Well, there was lib issue 127 (plus a couple of NAD), which is now part of TC1. There's also at least one core DR related to auto_ptr, so it can be useful to check both issue lists. I think you've heard about "auto_ptr update" in relation to Scott Meyer's MEC++. But that's an update _ to the book _, not to the standard. You can find it (starting from) here: http://www.awl.com/cseng/titles/0-201-63371-X/auto_ptr.html Genny. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Math Constants Formal Review
On Sun, 08 Jun 2003 22:13:24 -0400, Beman Dawes <[EMAIL PROTECTED]> wrote: >What Daryle is talking about is not the sandbox CVS itself, but >boost-sandbox project web space that you get from SourceForge, separate >from the CVS. Ah, thanks! At least I was right when thinking you could clarify :-) Genny. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Math Constants Formal Review
On Sun, 8 Jun 2003 15:56:53 +0100, "Paul A Bristow" <[EMAIL PROTECTED]> wrote: >If someone would like to do this, I'd be grateful. > >(Memories of how to use commandlines and CVS have decayed). IIUC, the boost sandbox is, so to speak, a more precious resource than the Yahoo files section. So, unless there's a need to "develop there" (for instance because many people should simultaneously work at the files, or because it's appropriate to have a record of all the changes and who made them) the Yahoo section or any private web spaces should be preferred. It seems a waste to use a cvs repository just to provide a place to get things from. But, maybe, the policy is different and I don't know. It would be nice to have a confirmation. I'm sure Beman or Dave can give it. Genny. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Math Constants Formal Review
On Sat, 7 Jun 2003 10:33:20 +0100, "Paul A Bristow" <[EMAIL PROTECTED]> wrote: >None of the material is yet ready for inclusion in Boost, >(with the possible exception of the C Macro values). > >What I would like to get is agreement on the presentation of constants. You mean macros vs. constant variables vs. inline functions? This is another thing I didn't understand by looking at the documentation: the FAQ section seems sometimes to imply you have already done a choice in this regard; for instance: Q. Why not use floating-point hardware constants? A. Because only a few are available, they are often not the right size, are not available on all processors, and most important are sometimes not accurate enough. but then, in another point: Q. Why are functions like double pi() which return constants provided? A. It provides a framework whereby users can plug in special implementation and hardware-specific versions Before that, there's even another answer: "Because some compilers may be able to produce smaller and/or faster code.(For example, note that MSVC 7 Standard edition only inlines "__inline", so this will produce slower and longer code)." Maybe you meant: "because some compilers generate better code with a manifest constant and others better code with a function"? I agree with Daniel that the material need some cleanups if you want us to understand it. Genny. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Math Constants Formal Review
On Fri, 6 Jun 2003 06:45:45 -0700, "Jaap Suter" <[EMAIL PROTECTED]> wrote: >To all, > >Today is the start of the formal review of the Math Constants library by >Paul Bristow. The review will run until Sunday June 15th. I tried to have a look but was assailed by a fairly large amount of material :-) Can we a have a .zip with just what is candidate for inclusion into boost? Genny. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Better Intel-Win32 support
On Wed, 04 Jun 2003 15:54:21 -0400, Beman Dawes <[EMAIL PROTECTED]> wrote: >Yes, I think so. Won't boost::is_same< unsigned short, wchar_t >::value be >true if wchar_t is a typedef, and false if a distinct type? > >I'll do some experiments. In addition to what Dave says (can't use the result in preprocessing) I heartily advise you to save your time. I went through these Intel conundrums about one year ago and was quite upset! http://lists.boost.org/MailArchives/boost/msg32588.php Genny. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] ctype- and traits-based function objects
The attached file contains some predicates that allow using standard
algorithms on character ranges in a locale-aware fashion. For instance
they allow writing the classical ltrim() function (remove all trailing
whitespaces) as:
template
stringT ltrim(const stringT& s, const std::locale & loc
= std::locale())
{
typedef typename stringT::value_type char_type;
typename stringT::const_iterator it =
std::find_if(
s.begin(), s.end(),
std::not1(is_classified_as(std::ctype_base::space,
loc))
);
return stringT(it, s.end());
}
I'm posting them here to have some feedback and ask if there's any
interest for inclusion into boost. They are quite trivial stuff but
IMHO useful enough to have it somewhere in a reusable form :-)
There are some little design details which are not settled yet.
Comments on them are very welcome. In particular:
- is_classified_as<> defaults its template parameter to char, for ease
of use. Objections?
- should is_classified_as::m_ctype be a reference or a non-const
pointer? That has of course to do with whether we want the function
object to be assignable with the compiler-generated operator=().
Thoughts?
Please, Beware that the code is untested. Just checking if there's
interest...
Genny.
begin 644 char_functors.hpp
M#0HO+R!!(&)U;F-H(&]F('1R:[EMAIL PROTECTED]2`R,#`S#0H-"@[EMAIL PROTECTED]@24Y#3%5$12!'54%2
M1"`M+2T-"@T*#0HC:6YC;'5D92`\;&]C86QE/@T*(VEN8VQU9&4@/&9U;F-T
M:6]N86P^#0H-"B\O(%%U97-T:6]NPT*<')I=F%T93H-"[EMAIL PROTECTED]PT*("`@(')E='5R
M;B!M7V-T+3YIPT*<'5B;&[EMAIL PROTECTED]("`@('1Y<&[EMAIL PROTECTED]'EP
M96YA;[EMAIL PROTECTED]')A:71S5#HZ8VAA7!E(&-H87)?='EP93L-"@T*("`@(&)O
M;VP@;W!E7!E("[EMAIL
PROTECTED](I(&-O;G-T#0H@("`@
M>R!R971U<[EMAIL PROTECTED]')A:71S5#HZ97$H8S$L(&,[EMAIL PROTECTED]
M9&5N=&[EMAIL PROTECTED]&[EMAIL PROTECTED]&AE(&%B;W9E+"[EMAIL
PROTECTED]@;VX@:6YT7W1Y<&4-
M"G1E;7!L871E(#QC;&%S7!E;F%M92!T7!E+`T*("`@("`@("`@("`@("`@("`@
M("`@("`@("`@("`@("[EMAIL PROTECTED];`T*("`@("`@("`@("`@("`@("`@("`@("`@
M("`^#0I[#0IP=6)L:6,Z#0H@("[EMAIL PROTECTED]'EP961E9B!T>7!E;F%M92!T7!E*'@Q+"!X,BD[('T-"@T*?3L-"@T*#0H-"B\O($-A;B!A
M;B!I;7!L96UE;G1A=&EO;B!R971U<[EMAIL PROTECTED]&EF9F5R96YT('9A;'5E2!C87-E(&ET)W,@<[EMAIL PROTECTED]&AA=`T*
[EMAIL PROTECTED]:6YT7W1Y<&[EMAIL PROTECTED]:W,@87,@[EMAIL PROTECTED](Q+C$N,2!486)L
M92`S-RD-"B\O('-O('=E(&-A;B!C86-H92!T:&[EMAIL PROTECTED]@;[EMAIL PROTECTED]
M(&EN('1H92!C;VYS=')U8W1O<@T*+R\-"G1E;7!L871E(#QT>7!E;F%M92!T
M7!E*&,L(&U?96]F*3L-"B`@("[EMAIL PROTECTED]('!R:79A=&4Z#0H@("`@(&EN
5=%]T>7!E(&U?96]F.PT*#0I].PT*
`
end
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: checked_delete without assignment to 0 - why?
On Wed, 14 May 2003 12:39:09 +0200, Markus Werle
<[EMAIL PROTECTED]> wrote:
>Hi!
>
>In one of Herb Sutters articles I saw that
>after deleting a pointer (a pimpl) he assigns 0 afterwards
>which seems to me like a good idea.
>(see e.g. http://www.gotw.ca/gotw/028.htm or http://tinyurl.com/bq8o)
>
>Maybe there is a good reason (efficiency?)
>why checked_delete omits this extra step.
>Please explain.
>
>template inline void checked_delete(T * x)
>{
> typedef char type_must_be_complete[sizeof(T)];
> delete x;
> // why not ?
> x = 0;
>}
This is mostly appropriate for alt.comp.lang.learn.c-c++. But let's
take it briefly, to avoid noise here: first of all, you can't nullify
the pointer if all you have is a copy of it. Secondly, it can be
nullified with something like:
#include
template
void delete_and_null(T*& p) {
delete p;
p = NULL;
}
but then you can't pass an rvalue:
int* f();
delete_and_null( f() ); // can't do
Thirdly, nullifying the pointer is generally considered a way to
_hide_ bugs, rather than eliminating them. I don't want to be dogmatic
here, but I've never encountered the necessity to double delete
anything.
Genny.
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: ENFORCE
--- Daniel Frey <[EMAIL PROTECTED]> wrote: > Gennaro Prota wrote: > > On Thu, 8 May 2003 15:06:02 +0300, "John Torjo" <[EMAIL PROTECTED]> > > wrote: > > > >>Unfortunately, we can't use the do-while(0) idiom, since we don't know when > >>while(0) will be ;-) > >> > > > > Oops, no. That's not the problem. The problem is that I read Daniel's > > reply out of context and too absent-mindedly :-) I thought it was > > something like > > > > if (false) ; else > > > > whereas he is really testing for a condition > > > > if(expr)... > > > > However, if you are going to abort at the end (or throw, but I don't > > want to enter in this matter) you can simply replace 'if' with > > 'while': > > But that does not give you any benefit at all, does it? Just that Borland won't warn on BOOST_INVARIANT(false). Admittedly not a big one :-) > The > do-while-idiom is very different from the while-version you suggest. Indeed. I did say that I misread your post. Sorry for the noise. Genny. __ Do you Yahoo!? The New Yahoo! Search - Faster. Easier. Bingo. http://search.yahoo.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: ENFORCE
On Thu, 8 May 2003 15:06:02 +0300, "John Torjo" <[EMAIL PROTECTED]> wrote: >Unfortunately, we can't use the do-while(0) idiom, since we don't know when >while(0) will be ;-) > >Example: >BOOST_ASSERT(i != j)(i)(j); > >or > >BOOST_ASSERT(i > 1000)(i); Oops, no. That's not the problem. The problem is that I read Daniel's reply out of context and too absent-mindedly :-) I thought it was something like if (false) ; else whereas he is really testing for a condition if(expr)... However, if you are going to abort at the end (or throw, but I don't want to enter in this matter) you can simply replace 'if' with 'while': #define BOOST_INVARIANT(expr) \ while /*if*/ (!(expr))\ boost::invariant(), \ std::clog << "invariant failure: " #expr, \ boost::BOOST_INVARIANT_A \ \ /**/ But don't care about that. Had I noticed that there was really a condition I wouldn't have replied. And, then, Borland will find some way to warn in any case :-) >note: see the 'smart assert' thread, where we discuss details about the >interface/ implementation of the smart assert (BOOST_ASSERT) I have no time. And, from the little I've read, I've noticed quite a confusion between exceptions and asserts. Genny. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: CVS status
On Thu, 08 May 2003 15:30:05 +0400, Vladimir Prus <[EMAIL PROTECTED]> wrote: >Gennaro Prota wrote: > >> I drop an idea: suppose that when there's a new >> commit the CVS informs, via e-mail, the penultimate people that had >> done a commit. This way I (the generic developer) can do the >> following: before doing any commit check out the whole repository (in >> order to have the newest state of everything), then _until I receive >> the informative mail_, I do keep my copy. When I receive the mail I >> know that the duty to keep the files is up to someone else. Of course >> that doesn't protect against failures of the "last committor" machine, >> but... As a further precaution we could advice for keeping a fresh >> checkout for at least one day, regardless of informative mails >> (provided that we can setup something similar). Thoughts? > >I think this is a bit more complicated that it should be. Why don't just >create boost-wide commit emails mailing list? Off-hand _this one_ seems more complicated, because it involves more people than necessary and forces to keep the diffs (though just for, say, a couple of days - longer than that, we have the daily backups). However I'm not confident enough into CVS to say if my idea works well with branching (I have my doubts), which can be an advantage of yours. Genny. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: ENFORCE
On Mon, 5 May 2003 20:12:13 -0700, "Paul Mensonides" <[EMAIL PROTECTED]> wrote: >Daniel Frey wrote: >> Paul Mensonides wrote: >> >>> #define BOOST_INVARIANT(expr) \ >>> if (!(expr)) \ >> >> One possible enhancment: >> >>if( expr ); else >> >> It prevents problems when the macro is used in other >> if-else-structures. > >Thanks Daniel, I forgot about that... That's right. But if this will ever get into boost maybe we'll better use the classical do-while(0). Borland warns on if(false), and assert(false) is quite common, for instance, in the default case of switch statements. BOOST_INVARIANT(false) could be used similarly (Though, depending on the people who would speak in the formal review, we could choose to have a separate macro for 'assert always'-like cases, with no condition argument) Genny. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: CVS status
On Thu, 8 May 2003 05:20:11 -0500, Aleksey Gurtovoy <[EMAIL PROTECTED]> wrote: > >I just restored the lost revisions for these three headers: > >boost/config/platform/win32.hpp >boost/config/stdlib/stlport.hpp >boost/filesystem/convenience.hpp > Thanks Aleksey. I was particularly interested to stlport.hpp (incidentally: though that doesn't affect the good functioning of the file, the space between # and endif: http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/boost/boost/boost/config/stdlib/stlport.hpp.diff?r1=1.19&r2=1.20 surprises me a bit. Don't call me pedantic, but I'm a curious one :-) I had seen the colored diff before and didn't notice it. Note that without the space the line shown in green is, I guess, the following one, so that's unlikely to get unnoticed when you visually try to match the #if-s) >and, comparing what is probably the most recent "before-the-disk-crash" CVS >snapshot to the current CVS state, it seems that collectively we've been >able to restore everything. Still, if we have resources for that, may be >it's worthy to set up a backup job somewhere to copy everything off-site, >nightly or so - we might not be so lucky next time. I'm not against that. However, as far as I've understood from the mail that Beman quoted, the sourcefourge people make daily backups anyway. I think what we should have (ideally) is not a daily backup, but a "newest version" backup (if nothing else, the "daily" and "nightly" concepts fail miserably for boost, since we have developers in many different timezones). I drop an idea: suppose that when there's a new commit the CVS informs, via e-mail, the penultimate people that had done a commit. This way I (the generic developer) can do the following: before doing any commit check out the whole repository (in order to have the newest state of everything), then _until I receive the informative mail_, I do keep my copy. When I receive the mail I know that the duty to keep the files is up to someone else. Of course that doesn't protect against failures of the "last committor" machine, but... As a further precaution we could advice for keeping a fresh checkout for at least one day, regardless of informative mails (provided that we can setup something similar). Thoughts? Genny. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: CVS problem?
On Wed, 07 May 2003 15:54:14 -0400, Beman Dawes <[EMAIL PROTECTED]> wrote: >At 03:30 PM 5/7/2003, Douglas Gregor wrote: > > >Would you mind adding these directories and files back? My checkout is >too > >old to be of use, so we really need those that have the newest files to > >check them back in. Then when others update, they'll see the new files > >and get conflicts if there were any problems with the files already > >re-committed. > >OK, I'll give it a try. Maybe I'm missing something here, but I thought a simple way to cope with this was to post a message on the list asking for people who did commits in the last 3 days. Out of my head, John Maddock is a likely candidate. Even if we don't find a person who checked out a fresh copy of the whole repository still the "union" of all the commits should give the right state (because each people has the newest version of the specific files he committed). No? Genny. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: boost::dynamic_bitset supports multi-thread?
On Fri, 18 Apr 2003 9:20:59 +0800, "jacon wang" <[EMAIL PROTECTED]> wrote: >hi, >I want to know if boost::dynamic_bitset supports multi-thread. >Now,when I use boost::dynamic_bitset with VC++ 6.0 and use run-time >libarary multi-threaded dll,It will cause a INTERNAL COMPILER ERROR(1001). >So I'm confused.Could anyone give me some advice? ICEs (Internal compiler errors) are problems in the compiler (a.k.a. bugs) detected by the compiler itself. You can think of them as sorts of asserts in the compiler code. So, they should never happen. Please, try to post a complete (short) example to reproduce the problem and I'll see if there's a way to avoid it. Genny. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: [config] New workaround macro
On Thu, 17 Apr 2003 16:09:11 +0100, "John Maddock" <[EMAIL PROTECTED]> wrote: >The names are a little long Yeah, I don't like them either :-) But I was afraid shorter names would have been considered imprecise. If we can bear a little abuse of language I think we could accept: BOOST_EXPLICIT_TEMPLATE_TYPE BOOST_APPEND_EXPLICIT_TEMPLATE_TYPE BOOST_EXPLICIT_TEMPLATE_NON_TYPE BOOST_APPEND_EXPLICIT_TEMPLATE_NON_TYPE If this inspires you any variation, that's welcome too :-) Genny. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: [dynamic_bitset::reference] - questions to the users (and to the gurus)
A couple of corrections to my previous post: > And even if, how could one use a reference considering > that all its constructors are private? All non-copy constructors, actually. Client code can easily create a reference object by copy: dynamic_bitset<>::reference ref = b[0]; This brings the question: should we disable copy construction? Note that vector has a member function to swap two references // see 23.2.5 static void swap(reference x, reference y); which, of course, requires a copy constructor. Should dynamic_bitset have it too? In that case we could implement a private copy constructor, which would be available to dynamic_bitset::swap (for friendship) but not to the user; otherwise we could simply leave it undefined: private: reference(reference&); // undefined >In effect, declaring the copy-assignment operator has the pleasant >effect to force an explicit definition, showing that the shallow-copy >is intentional Sorry, I was thinking to the copy constructor (implicitly declared), that makes a shallow copy. The copy assignment operator does something completely different. Genny. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: [dynamic_bitset::reference] - questions to the users (and to the gurus)
On Thu, 03 Apr 2003 14:15:27 +0200, Gennaro Prota
<[EMAIL PROTECTED]> wrote:
>Now, for the gurus: this is the current interface of reference:
>
>class reference
>{
>friend class dynamic_bitset;
>
>// the one and only non-copy ctor
>reference(dynamic_bitset& bs_, size_type bit_);
Please don't scold me about the use of the term "interface" here. Just
sloppy language.
>public:
>...
>reference& operator=(const reference& j); // for b[i] = b[j]
>reference& operator|=(const reference& j); // for b[i] |= b[j]
>...
In case this is confusing: the declarations and the corresponding
comments use the letter j with different meanings. I would have better
written:
reference& operator=(const reference& rhs); // for b[i] = b[j]
...
Genny.
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] [dynamic_bitset::reference] - questions to the users (and to the gurus)
Among the several changes I've planned to dynamic_bitset there's one
which affects semantics and that, therefore, I would like to discuss
with you a bit. Note however that the old semantics were never
specified in the docs, so this would break nothing but adventurous
usages of undocumented features on the users part.
Here's the issue: dynamic_bitset<>::reference currently stores a
pointer to its bitset object and an index. For that reason:
- after a swap of bitsets, references come to refer to
different elements: they get track of the address of the
bitset they are referencing, and the bitset has changed
its contents.
- value changing operations on the dynamic_bitset *don't*
invalidate references unless they make the corresponding
index out of range (by shrinking the bitset). In other
words: semantics are intrinsecally those of a *pair*
(bitset address, index); as long as the index remains
valid for the pointed to bitset everything is fine.
But then one wonders: why not using an index directly?
And even if, how could one use a reference considering
that all its constructors are private?
Both points above are the exact contrary of what one would expect by
analogy with references, pointers, or iterators (The standard
guarantees that no standard library swap() function invalidates any
references, pointers, or iterators referring to *the elements* of the
containers being swapped. To state it metaphorically: the elements
change containers but references "follow" them).
Now, the first question is: ok to change semantics and document the
new behavior? (BTW, the new semantics can be implemented much more
efficiently, e.g. by storing a pointer to a block and a *precomputed*
mask)
Second question: any interest in having this new reference as a
separate class? (In this case dynamic_bitset::reference would really
become a typedef as stated in the docs, rather than a nested class
:-))
Now, for the gurus: this is the current interface of reference:
class reference
{
friend class dynamic_bitset;
// the one and only non-copy ctor
reference(dynamic_bitset& bs_, size_type bit_);
public:
operator bool() const; // for x = b[i]
bool operator~() const;// flips the bit
reference& flip(); // for b[i].flip();
reference& operator=(bool value); // for b[i] = x
reference& operator|=(bool value); // for b[i] |= x
reference& operator&=(bool value); // for b[i] &= x
reference& operator^=(bool value); // for b[i] ^= x
reference& operator-=(bool value); // for b[i] -= x
reference& operator=(const reference& j); // for b[i] = b[j]
reference& operator|=(const reference& j); // for b[i] |= b[j]
reference& operator&=(const reference& j); // for b[i] &= b[j]
reference& operator^=(const reference& j); // for b[i] ^= b[j]
reference& operator-=(const reference& j); // for b[i] -= b[j]
};
Note the last two groups of 5 functions: they are identical except
that those of the first group take a bool and those of the second one
a const reference &. But since we have an operator bool() const
wouldn't the first group be enough?
In effect, declaring the copy-assignment operator has the pleasant
effect to force an explicit definition, showing that the shallow-copy
is intentional, but what about the other 4 functions? What's their
purpose? If we drop them, an expression like
b[i] |= b[j]
changes from
(b.operator[](i)).operator |= ( b.operator[](j) )
to
(b.operator[](i)).operator |= ( b.operator[](j).operator bool() )
But I can't see any problem with that, even with self-assignment. Am I
missing something?
Genny.
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: compare
On Fri, 28 Mar 2003 12:28:56 -0500, Jan Langer <[EMAIL PROTECTED]>
wrote:
>Gennaro Prota wrote:
>> The point is that your operator bool is a loss
>> of information. Ever heard of lexicographical_compare_3way?
>
>yes, but never used so far. but the non_3way lexicographic compare
>algorithm has the same problem.
Indeed.
>[...]
>> Hoped to make some more intelligent point, but if we don't understand
>> each other on such basics first... :-(
>
>i dont really know what you mean.
Ok. This is my last post in this thread. Let me just add that your
conversion function to bool, together with the default constructor you
provide, lets the user take the "result of the comparison" without
actually doing any call to operator().
I would rather see an approach which forces a call before enabling any
implicit conversion. Just to illustrate the idea (don't expect this to
compile, I'll just type it in the news-reader window):
class compare
{
public:
enum result { minus, equiv, plus };
private:
class R {
friend class compare;
result v_;
R():v_(equiv) {} // it's not really "equiv", because
// no elements have been compared,
// but the user can't see this
public:
template
R & operator()(const T& a, const T& b) {
if (v_ == equiv) {
if (a < b)
v_ = minus;
else if (b < a)
v_ = plus;
}
return *this;
}
template
R& operator()(const T&a, const T&b, Cmp cmp) {
if (v_ == equiv) {
if ( cmp(a, b) )
v_ = minus;
else if ( cmp(b, a) )
v_ = plus;
}
return *this;
}
operator result() const { return v_; }
};
mutable R result_;
public:
compare ():result_() {}
template
R &operator () (const T& a, const T& b) const
{
return result_(a, b);
}
template
R& operator()(const T& a, const T& b, Cmp cmp ) const
{
return result_(a, b, cmp);
}
};
Genny.
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: compare
On Thu, 27 Mar 2003 16:51:35 -0500, Jan Langer <[EMAIL PROTECTED]> wrote: >Gennaro Prota wrote: >> But there are more important points I think; first of all this: if all >> I can see "from the outside" is whether v_== minus [note: this is >> 'plus' in the original code] why keeping three states internally? > >because i see no reason why they should be needed. Sigh. You do keep them! The point is that your operator bool is a loss of information. Ever heard of lexicographical_compare_3way? Hoped to make some more intelligent point, but if we don't understand each other on such basics first... :-( Genny. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: compare
On Thu, 27 Mar 2003 14:01:12 -0500, [EMAIL PROTECTED] wrote:
>> -Original Message-
>> From: Jan Langer [mailto:[EMAIL PROTECTED]
>
>Just one other thing - instead of:
> enum result { minus, zero, plus };
>I would do:
> enum result { minus = -1, zero, plus };
>just for the sake of code readability and ease of understanding. It doesn't
>change the logic at all.
Well, if we are really going to discuss such quibbles, I would also
change "zero" to "equiv" because that's the usual "term" used for
strict weak ordering. And I would avoid constructs like
template
compare (T const &a, T const &b)
: v_ (compare () (a, b).v_) // <--
{}
by doing, for instance,
class compare
{
enum result { minus, equiv, plus };
result v_;
template
static result do_compare(const T& a, const T& b) {
if (a < b) return minus;
else if (b < a) return plus;
return equiv;
}
public:
compare () : v_ (equiv) {}
template
compare (T const &a, T const &b)
: v_ (do_compare(a, b))
{}
template
compare &operator () (T const &a, T const &b)
{
if (v_ == equiv)
do_compare(a, b);
return *this;
}
};
But there are more important points I think; first of all this: if all
I can see "from the outside" is whether v_== minus [note: this is
'plus' in the original code] why keeping three states internally?
Genny.
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: compare
On Thu, 27 Mar 2003 18:34:05 +0100, Gennaro Prota <[EMAIL PROTECTED]> wrote: >David Abrahams<[EMAIL PROTECTED]> wrote: > >>lexicographic? > >Indeed. We have an order relation < in X, and use what mathematicians >call lexicographic order induced in X^n by <. Yup! I should have looked better at the code. It's actually much more general than that :-) Genny. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: compare
On Thu, 27 Mar 2003 10:00:47 -0500, David Abrahams <[EMAIL PROTECTED]> wrote: >> 2) I'm not sure that the choice of the name is ideal. OTOH, I can't think >> of a better one... > >lexicographic? Indeed. We have an order relation < in X, and use what mathematicians call lexicographic order induced in X^n by <. A question worth asking ourselves, I think, is how good are current compilers at inlining this stuff. I had an application where thousands of points (coming from a VRML draw) had to be lexicographically ordered and analyzed. Given the size of the VRML files, that took generally a whole night on our machines. I don't dare to imagine what would have happened by implementing operator<() recursively without compiler optimization. Genny. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: exception context
Thanks, I've learnt some history of C++ :-) The dates in your document also allowed me to locate a relevant WP. For those interested: http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/wp/pdf/jan94/body.pdf As it appears, the specification of the standard exception classes underwent major changes in that year and only began to look like we know it now in January of the year after (Jan 95 working paper). Genny. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: MSVC++ 6.0 compiler errors with 1.30.0 (mostly lexical_cast.hpp)
On Mon, 24 Mar 2003 17:03:10 +0100, Gennaro Prota <[EMAIL PROTECTED]> wrote: >Maybe you can also add an exclamation point Ahem, exclamation mark :-) Genny. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: bad_lexical_cast
On Mon, 24 Mar 2003 07:24:38 -0500, David Abrahams
<[EMAIL PROTECTED]> wrote:
>I don't think I've ever read a
>description of LSP which doesn't leave that question completely
>unaddressed.
I've never seen a formulation of LSP which was appliable to C++.
"If for each object o1 of type S there is an object o2 of
type T such that for all programs P defined in terms of T,
the behavior of P is unchanged when o1 is substituted for
o2 then S is a subtype of T."
Even a simple overloading of two functions (if we don't want to
disturb reference binding) seems to put it in serious trouble:
void f(int) { something... }
void f(short) { something else... }
int main() {
int i = 0;
f(i);
}
This is a program defined "in terms of int". Can you substitute a
short 0 (zero) to i? Also, I've never understood how one can generally
("all programs") substitute an object (rather than a type) in a
program without modifying the program itself. Maybe that's just my
ignorance. And even modifying the program, what is the supposed
substitution LSP refers to in the above case?
a) int i = (short)0;
f(i);
b) short i = 0;
f(i)
When "o1 is substituted for o2"? Where? How?
Genny.
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: MSVC++ 6.0 compiler errors with 1.30.0 (mostly lexical_cast.hpp)
On Sun, 23 Mar 2003 13:26:04 -0500, David Abrahams <[EMAIL PROTECTED]> wrote: >That sounds right. Would you like to post a proposed replacement (or >patch) for the page as written which addresses your points? You embarrass me. I think the page is ok as long as you don't say "during" stack unwinding; also I would prefer "could exit via an exception" rather than "could throw". More-or-less: "Don't embed a std::string object or any other data member or base class whose copy constructor could exit via an exception. That could lead you straight from the point of throw to std::terminate()" Maybe you can also add an exclamation point as a pinch of sound intimidation :-) Genny. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: MSVC++ 6.0 compiler errors with 1.30.0 (mostly lexical_cast.hpp)
On Sun, 23 Mar 2003 17:17:03 +0100, Gennaro Prota <[EMAIL PROTECTED]> wrote: >the standard defines 'stack unwinding' as (15.2/3) > > The process of calling destructors for automatic objects > constructed on the path from a try block to a throw-expression > >Does this include the 'argument' of the call expression? > > throw A() > >Certainly the expression A() is part of the throw-expression, however >the quote above isn't particularly clear at saying whether "to a >throw-expression" is inclusive or not. Now that I think about it, I believe the initial copy of the exception object must logically be seen as a *part* of the evaluation of the throw-expression. Otherwise, i.e. if you make it a separate step, you either have to say that the temporary A() is not destroyed at the end of its full expression (the throw) or say that it is destroyed before you get a chance to copy it to a safe place. Don't you agree? Genny. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: MSVC++ 6.0 compiler errors with 1.30.0 (mostly lexical_cast.hpp)
On Sun, 23 Mar 2003 08:11:02 -0500, David Abrahams <[EMAIL PROTECTED]> wrote: >Gennaro Prota <[EMAIL PROTECTED]> writes: >> - "Don't embed a std::string object or any other data member or base >> class whose copy constructor could throw an exception. That could lead >> to termination during stack unwinding." >> >> I think you meant *before* (any) stack unwinding (unless you are >> thinking to catch by value, but that's highly unlikely) > >I don't actually know whether it's before or after, but it's at the >stage described by 15.1/3, so I'll clarify that. Hmmm... let's ignore the possibility to omit the copy for a moment: the standard defines 'stack unwinding' as (15.2/3) The process of calling destructors for automatic objects constructed on the path from a try block to a throw-expression Does this include the 'argument' of the call expression? throw A() Certainly the expression A() is part of the throw-expression, however the quote above isn't particularly clear at saying whether "to a throw-expression" is inclusive or not. I'm inclined to think that it is inclusive, in principle. Maybe you know something, from the committee meetings or from the standard, that contradicts this view? > [...] >I just copied the official reference text, and never knew where that >number came from. Is it really a volume number? So I guess :-) The linked to page has, at its bottom, the following "Series: Lecture Notes in Computer Science. Volume. 1766" That's itself a link and if you follow it you find a long list with one of the entries being "Volume. 1766: Jazayeri, M.; Loos, R. G.K.; Musser, D. R., (Eds.) Generic Programming" >Thanks for your remarks! Thanks to you :-) Genny. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: MSVC++ 6.0 compiler errors with 1.30.0 (mostly lexical_cast.hpp)
On Sat, 22 Mar 2003 09:38:49 -0500, David Abrahams <[EMAIL PROTECTED]> wrote: >David Abrahams <[EMAIL PROTECTED]> writes: > >> Damn, maybe I need to update more/error_handling.html > >Done. Just some notes: - "Don't embed a std::string object or any other data member or base class whose copy constructor could throw an exception. That could lead to termination during stack unwinding." I think you meant *before* (any) stack unwinding (unless you are thinking to catch by value, but that's highly unlikely) - "Similarly, it's a bad idea to use a base or member whose ordinary constructor might throw, because, though not fatal, you will report a different exception" Of course it *may* be fatal as well; it's just /not necessarily/ so. It may not lead you straight to terminate (if you have a handler for the different exception) but can in practice put the program in a disastrous state. Minor: - In section "What About Programmer Errors?" there's a little typo: "neccessary" (two 'C's) - at the beginning of the paper, there's a link to 'Generic Programming, Proc. of a Dagstuhl Seminar...' I was about to report the error in the "date" (1766) :-) Maybe it would be better to write "Volume 1766"? Genny. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: MSVC++ 6.0 compiler errors with 1.30.0 (mostly lexical_cast.hpp)
On Sat, 22 Mar 2003 20:11:23 +, Kevlin Henney
<[EMAIL PROTECTED]> wrote:
>In article <[EMAIL PROTECTED]>, Terje Slettebø
><[EMAIL PROTECTED]> writes
>>
>>Regarding the other MSVC 6 warning given in the original report, Gennaro
>>Prota has suggested using an explicit "!=", rather than relying on the
>>implicit conversion from pointer to bool. This also avoids using a cast,
>>instead.
>
>Or one could use "stream << input && true" ;-) However, I think if one
>is going to twist the expression of the code to satisfy the misplaced
>oversensitivity of VC, it may be better to be more explicit than subtle,
>ie "!(stream << input).fail()".
That's fine too. Of course these are style/personal-taste issues. I'm
sure there's someone claiming that !! is clearer :-) More to the
point, I just suggested the way I *generally* use to shut up VC in
such cases; it' obvious that !(expr).fail() is something rather
stream-specific, whereas an explicit compare with != works any time
you have a boolean conversion.
The typical case where that warning appears with VC++ is when you
attempt to return directly the result of an API call that returns a
BOOL from a function that returns bool; e.g.:
bool IsThereAMouseHere() {
return ::GetSystemMetrics(SM_MOUSEPRESENT);
}
In that case an explicit compare with FALSE seems reasonable.
Genny.
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: MSVC++ 6.0 compiler errors with 1.30.0 (mostlylexical_cast.hpp)
On Sat, 22 Mar 2003 17:39:06 +, Kevlin Henney
<[EMAIL PROTECTED]> wrote:
>Not necessarily. It would be reasonable to fold up the inheritance
>again, and simply provide a two argument constructor and a concrete
>implementation:
>
>class bad_lexical_cast : public std::bad_cast
>{
>public:
>...
>virtual const char *what() throw()
^
Do not forget const here! ---|
>[...]
>(in case anyone had decided to throw bad_lexical_cast in their own
>code)
Aargh! :-)
Genny.
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: MSVC++ 6.0 compiler errors with 1.30.0 (mostly lexical_cast.hpp)
On Sat, 22 Mar 2003 11:42:39 -0500, David Abrahams <[EMAIL PROTECTED]> wrote: >Gennaro Prota <[EMAIL PROTECTED]> writes: >> I'm happy that std::type_info has a private copy constructor. Hadn't >> it been for that, my suggestion to use just a couple of typedefs would >> have been routinely rejected :-) > >I don't think I understand what you're saying here, exactly. Nor do I! :-) I missed somehow the context of the discussion, as I was doing many things simultaneously while also having a look at the list. Sorry for the nonsense. Genny. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: MSVC++ 6.0 compiler errors with 1.30.0 (mostly lexical_cast.hpp)
On Sat, 22 Mar 2003 09:52:07 -0500, David Abrahams <[EMAIL PROTECTED]> wrote: >Kevlin Henney <[EMAIL PROTECTED]> writes: >> However, the decision as to whether this should be in the 'what' string >> is perhaps one that can be revisited. It would be feasible to avoid any >> allocation issues at all by leaving the human readable string as general >> as it was before and adding type_info members that described the source >> and target types. > >Yes, that was my suggestion. I'm happy that std::type_info has a private copy constructor. Hadn't it been for that, my suggestion to use just a couple of typedefs would have been routinely rejected :-) Genny. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: exception context
On Fri, 21 Mar 2003 10:06:45 -0700, Greg Colvin <[EMAIL PROTECTED]> wrote: >The idea of the why() member was to preserve context when one exception >gets caught and a different one gets thrown, so you could walk back the >chain of why()'s asking what() and where(). I bring it up just as a >design that might be worth resurrecting if it meets your needs. Do you have pointers to the old std::exception specification, with where() and why() members? PS: I declare myself out of this vague discussion. Just curious about those ones :-) Genny. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Boost I/O Library review status
On Wed, 19 Mar 2003 11:12:28 -0600, "Ed Brey" <[EMAIL PROTECTED]> wrote: >It's interesting that the people you read about don't think of '\n' conceptually as >an object. It's interesting that some people think they should :-) >Mis-use of endl doesn't seem to be adequet justification for a new >end-of-line specifier. However, a difference in behavior between '\n' >and endl does. Indeed. And there are obvious differences: http://article.gmane.org/gmane.comp.lib.boost.devel/17737 >>> - Why not other control functions, e.g. tab? >> >> Never thought of it. Anyway, the C and C++ standard libraries already >> have accommodations for line-based text processing, but not for other >> control characters. > >True. Presumably, then, the same subtle effects that would compel an >alternative to '\n' wouldn't do likewise for '\t'. Is that correct? The effect is exactly the same and there's nothing subtle about it. BTW, a non-flushing endl, as well as almost everything has been proposed here, are plain classics. Apart from the hundreds of newsgroup questions about '\n' vs. endl, I remember dozens of articles about array based stream buffers for instance. I don't have time to search for pointers right now (some of them were in CUJ) and, unfortunately, I don't think I would search them even if I could. Judging from the replies I got, seems like I've already wasted enough time with the review: http://article.gmane.org/gmane.comp.lib.boost.devel/17500 Genny. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: RC_1_30_0 still broken -- More lexical_cast
On Tue, 18 Mar 2003 19:45:26 -0500, "Gennadiy Rozental" <[EMAIL PROTECTED]> wrote: >> > > Notice the weird misspellings in the error messages. :) >> > >> > What do you mean? >> >> "boolle" and "intr"? :) >> >> Could this be a problem in the unit test framework? > >Could be. What should it be? >I wil try to reproduce this locally after 1.30 is out. As I see from a reply of yours in another thread this is probably fixed now. Yesterday I didn't have a CVS snapshot ready, and it takes time to download. So instead of making Terje wait for the apocalypse I tested the files using 1.29.0 (without its lexical_cast.hpp and with the addition of workaround.hpp). There are no misspellings with the latest unit test version, sorry for the alarm. Genny. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: [call_traits] bcc failure
On Mon, 17 Mar 2003 08:56:54 -0600, "David B. Held"
<[EMAIL PROTECTED]> wrote:
>"Gennaro Prota" <[EMAIL PROTECTED]> wrote
>> [...]
>> What monster are you creating, man? :-)
>
>I must be the only one here that actually writes application code,
>because it never ceases to amaze me how everyone else can follow
>all these neat and tidy rules for writing "pure" code.
It was just a joke. I don't have any rule that I follow blindly just
because it is considered 'good programming'.
[...]
>> Ok, assuming that you need so much parameters, and that there's
>> a speed gain with using call_traits,
>
>Considering that some of the fields are std::vector<>s, and some
>of them are bools, you tell me. ;)
You have the program to measure, not me :-) Of course I was hinting at
passing the mice by reference rather than the pachyderms by value.
>> [...]
>> foo f(x1, x2, x3, (void(*)(X1, X2, X3))0 );
>
>Clever, but I don't need call_traits<> that badly. ;) I'll just make
>everything a const&.
Cough... cough ... :-)
>If you could take the address of a c'tor, this
>actually might be possible. Consider this code, which illustrates
>what I want to do:
>
>#define PARAM(t) boost::call_traits::param_type
>
>template
>class wrapper
>{
>template
>wrapper(int v, PARAM(U1) v1, PARAM(U2) v2, ...,
>void (*)(U1, U2, ...) = &T::T)
>: value_added_member_(v), data(v1, v2, ...) { }
>private:
>int value_added_member_;
>T data_;
>};
>
>Unfortunately, &T::T isn't allowed. I understand why (sort of), but
>it might actually make your trick be useful (or maybe not, I don't
>know).
Not much, as you couldn't deduce T's constructor parameter types
anyway. I assumed the null pointer expression to be used in the
initializer for the "most external constructor" (wrapper::wrapper). As
I said about the other version, based on pointer-to-objects, that
expression has a role (and a form) similar to an explicit <
template-argument-list >, and has about the same limitations: you must
know what are the types to put in the list at the point where you
select the constructor.
BTW, the following paper (which probably you know)
http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/papers/2002/n1385.htm
has a nice discussion related to what you are doing.
Genny.
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: RC_1_30_0 still broken -- More lexical_cast
On Mon, 17 Mar 2003 14:47:20 +0300, Vladimir Prus <[EMAIL PROTECTED]> wrote: >Gennaro Prota wrote: > >>>Ok. I've forwarded this to Kevlin. >> >> Maybe there's more than one problem here. I see that Vladimir talks >> about warnings while Jeff about errors. Also maybe it helps to see the >> exact condition to define BOOST_NO_STRINGSTREAM in >> config/stdlib/sgi.hpp, with the comment therein? Just trying to lend a >> hand... > >I'm sorry, "warning" in my post is typo. It should have been "error", and >the error message is precisely the same as previously reported. I just >wanted to note that lexical_cast was not broken with gcc 2.95.4 until >recently. Ok. That compiler has always used the new header. I think the problem is that while the old lexical_cast just used std::stringstream the new version uses the more general std::basic_stringstream<>. To say, it is a bit more exigent as to what to take out from , and the config system doesn't tell it that the header is actually broken. Genny. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: RC_1_30_0 still broken -- More lexical_cast
On Mon, 17 Mar 2003 09:35:11 +0100, Terje Slettebø <[EMAIL PROTECTED]> wrote: >>From: "Vladimir Prus" <[EMAIL PROTECTED]> >> I don't have much to say, but lexical_cast was broken just now. My code >which >> was compiling a week ago and wasn't changed since now produces the same >> warning, after updating to RC_1_30_0. > >Ok. I've forwarded this to Kevlin. Maybe there's more than one problem here. I see that Vladimir talks about warnings while Jeff about errors. Also maybe it helps to see the exact condition to define BOOST_NO_STRINGSTREAM in config/stdlib/sgi.hpp, with the comment therein? Just trying to lend a hand... Genny. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: [call_traits] bcc failure
On Sun, 16 Mar 2003 11:47:57 -0600, "David B. Held"
<[EMAIL PROTECTED]> wrote:
>"Gennaro Prota" <[EMAIL PROTECTED]> wrote in message
>news:[EMAIL PROTECTED]
>> [...]
>> I don't know if it's useful or not but it's certainly usable. The fact
>> that deduction fails in your case doesn't mean it fails always; and
>> for named templates there's still the possibility to explicit specify
>> template arguments. In your case, you could do:
>> [...]
>> foo f(x, (X*)0 );
>> [...]
>
>The problem is that it doesn't scale very well. I would like to
>forward c'tors that take around 8-10 arguments.
What monster are you creating, man? :-) Ok, assuming that you need so
much parameters, and that there's a speed gain with using call_traits,
it's enough to add one more of them to deduce all the template
arguments. Example:
class X1 {};
class X2 {};
class X3 {};
class foo
{
public:
template
foo(typename boost::call_traits::param_type v1,
typename boost::call_traits::param_type v2,
typename boost::call_traits::param_type v3,
void(*)(U1, U2, U3)
)
{ }
};
int main()
{
X1 x1;
X2 x2;
X3 x3;
foo f(x1, x2, x3, (void(*)(X1, X2, X3))0 );
}
As ugly as sin, but shouldn't make your Frankenstein appear much worse
than it already is :-)
PS: I'm just joking!
Genny.
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: [call_traits] bcc failure
On Sat, 15 Mar 2003 13:15:59 -0600, "David B. Held"
<[EMAIL PROTECTED]> wrote:
>"Daniel Frey" <[EMAIL PROTECTED]> wrote in message
>news:[EMAIL PROTECTED]
>> [...]
>> The compiler has no idea how to deduce U as - depending on
>> U - param_type could change.
>> [...]
>
>Oh, yes, I see. I guess call_traits is only useful when T is a
>class template parameter. A bit unfortunate, isn't it? I mean, it
>isn't very useful for function forwarding then, is it?
I don't know if it's useful or not but it's certainly usable. The fact
that deduction fails in your case doesn't mean it fails always; and
for named templates there's still the possibility to explicit specify
template arguments. In your case, you could do:
class foo
{
public:
template
foo(typename boost::call_traits::param_type v, U*)
{ }
};
int main()
{
X x;
foo f(x, (X*)0 );
...
}
It's a hack, of course, but you can always see "(X*)0" as a
syntactical alternative to "" :-)
Genny.
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: [call_traits] bcc failure
On Sat, 15 Mar 2003 11:10:57 -0600, "David B. Held" <[EMAIL PROTECTED]> wrote: >Any ideas? boost::call_traits:: is a nondeduced context. Genny. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: [optional] Doc edits
On Fri, 14 Mar 2003 12:10:52 -0600, "David B. Held" <[EMAIL PROTECTED]> wrote: > >First, it is functionally similar to a tristate boolean (false, >maybe,true) -such as boost::tribool-, except that in a tristate >boolean, the maybe state represents a valid value, unlike the >corresponding state of an uninitialized optional. > >I think two hyphens should be used for the em-dashes (or the >actual em-dash character, which is probably not portable). Also, >the comma after the em-dash is probably not necessary (even >though it would be if the parenthetical phrase were not present). As far as English is concerned I'll leave the response to people who have studied in an English-speaking country, however I would be surprised if your rules *required* a comma before "except" in absence of the parenthetical phrase. Secondly, the comma just before "the maybe state" is definitely an error in Italian but, again, I'll leave to you to say if the same thing holds for English. The above notes would be of course off-topic in themselves but I think they aren't in this context, as they are meant as a rationale for proposing a correction to existing boost documentation. Genny. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: lexical_cast fixes
On Fri, 14 Mar 2003 11:30:53 +, Kevlin Henney <[EMAIL PROTECTED]> wrote: >Thomas Witt<[EMAIL PROTECTED]> writes >>The change in floating point precision handling might be >>surprising to some users. Especially to those who use lexical_cast for >>output formatting. > >I will provide a changes section. I'm particularly curious about the rationale for that stream precision logic. Genny. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Small question about yes_type/no_type
Lately I never stop finding odd things into boost sources. Here's one
from type_traits/detail/yes_no_type.hpp:
typedef char yes_type;
struct no_type
{
char padding[8]; // <--
};
Why '8'?
Genny.
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Meta programming 'debug' mode.
On Wed, 12 Mar 2003 11:13:51 -0700, Greg Colvin <[EMAIL PROTECTED]> wrote: >>Exactly. And if the time it takes is different then the effect is not >>the same to me :-) > >Measurements, please? Be patient :-) I asked for empirics too and Jaap said he will do some benchmark. Also, I said *if* the time it takes...; anyway it was just a humorous reply to Dirk's remark (or was it an assertion? :-). Genny. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: [Boost.Regex] [PATCH] Fix GCC 3.3 warnings.
On 12 Mar 2003 13:25:36 +0100, [EMAIL PROTECTED] (Lars Gullik Bjønnes) wrote: > >With GCC 3.3. there are a couple of warnings in the regex lib. >The warnings is about of the type of the array index. >Warning about char being used as index. > >This patch fixes that. (by casting to unsigned int). Actually you are casting to unsigned char. That's safe whether plain chars are signed or not, because for 3.9.1/3 the range of nonnegative values of a signed integer type is a subrange of the corresponding unsigned integer type *and* you are converting only members of the basic execution character set (guaranteed to be non-negative by 2.2/3). For arbitrary characters (and plain char = signed char) though that's not a reassuring practice. Had I proposed the patch, I would have probably suggested adding 0 to trigger integral promotion; e.g.: class_map[ 0 + '_'] |= char_class_underscore; BTW I found the program confusing as to what kind of indexing is intended for class_map (because if one wants to use arbitrary chars to index an array one declares it as: T arr [CHAR_MAX - CHAR_MIN + 1]; and not as T arr [UCHAR_MAX + 1]; In either case, then I don't see why indexing by unsigned int, like in do_update_ctype). Also, the calls to memset look suspicious, but I've not investigated further. Genny. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Meta programming 'debug' mode.
On Wed, 12 Mar 2003 02:15:48 -0800, "Jaap Suter" <[EMAIL PROTECTED]> wrote: >> 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)? > >Because if we do this to save time, we might as well make sure that we save >as much time as possible. Exactly. And if the time it takes is different then the effect is not the same to me :-) Genny. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: I/O library formal review
On Tue, 11 Mar 2003 17:14:43 -0500, "Gennadiy Rozental" <[EMAIL PROTECTED]> wrote: > > * 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'. Just to clarify a bit of confusion arisen in this thread: neither std::endl nor the newl at hand reset the width; they both behave as unformatted output functions. The difference between them is just in the flush. The difference between << 'n' and newl is precisely that the former is a formatted output operation; since there's no special behavior for out << c when c is a control character, << '\n', << 't', etc. work the same as, let's say, << 'x'. As a side note, this means, for instance, that for << '\n' std::left/std::right actually seem something like std::before/std::after :-) Genny. ___ 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] 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
[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] 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
A function definition appearing within a class definition may end with
a semicolon though:
class X {
void foo() {}; // see grammar in 9.2
};
Genny.
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: BOOST_STATIC_CONSTANT and BCC5.5.1
On Sun, 9 Mar 2003 05:44:41 -0800 (PST), Gennaro Prota <[EMAIL PROTECTED]> wrote: >This is a classic for Borland :-/ All the times I've encountered it, it always >went away by... This was just to say that this "solution" is simply what I found to work in my limited experience with the compiler in question. There's no guarantee, of course, that it works in every situation, and it is not an "official" workaround from Borland (AFAIK). Genny. ___ 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
>struct const_min
>{
>BOOST_STATIC_CONSTANT(T, value = /*whatever*/);
>typedef const_min 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: New stuff into sandbox and Yahoo files section
On Sun, 09 Mar 2003 09:11:05 -0500, David Abrahams
<[EMAIL PROTECTED]> wrote:
>Gennaro Prota <[EMAIL PROTECTED]> writes:
>
>> On Sat, 08 Mar 2003 15:31:58 -0500, David Abrahams
>> <[EMAIL PROTECTED]> wrote:
>>
>>
>>>"Make 'em MPL-compatible metafunctions."
>>^^^
>> | which ones?
>
>All of the traits. For example:
>
>template
>struct const_min
> : integral_c
>{};
Well, why hardcoding that dependency? At most I would see the mpl
versions *in addition* to the ordinary ones. Of course, the former can
be constructed upon the latter by the user
template
struct mpl_const_min :
integral_c :: value > {};
and everyone pays only for what he/she uses.
>> PS: why the quotes? :-)
>
>I couldn't resist (?)
I still don't understand... it must be one of those C++ programmers
eccentricities ;-)
Genny.
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] BOOST_STATIC_CONSTANT and BCC5.5.1
--- Craig Henderson <[EMAIL PROTECTED]> wrote:
[...]
> template
> struct myval2
> {
> BOOST_STATIC_CONSTANT(int, value=T::value);
>
> myval myval_obj; // <-- BCC error E2231
> };
This is a classic for Borland :-/ All the times I've encountered it, it always
went away by qualifying the name and adding parentheses:
myval<(myval2::value)> myval_obj;
Genny.
__
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: New stuff into sandbox and Yahoo files section
On Sat, 08 Mar 2003 15:31:58 -0500, David Abrahams <[EMAIL PROTECTED]> wrote: >"Make 'em MPL-compatible metafunctions." ^^^ | which ones? PS: why the quotes? :-) Genny. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] New stuff into sandbox and Yahoo files section
Hi everybody, this is just to let you know that I've now committed the new version of static_log2<> to the boost sandbox: http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/boost-sandbox/boost-sandbox/boost/integer/static_log2.hpp and a bunch of new traits to the Yahoo files section: http://groups.yahoo.com/group/boost/files/MoreTraits.zip Besides some templates that could IMHO be useful to improve the portability of detail/limits.hpp (width<> and precision<>) there are two simple knick-knacks, const_min<> and const_max, that I would like to take the place of the analogous components in the Integer library. Here's a complete list of the zip contents: - const_max<>, const_min<> Give maximum and minimum value of a built-in integral type as integral constants. Differently from the traits already available in Boost.Integer they don't use derivation from std::numeric_limits. - has_sign<> Tells whether the type can represent negative values. Probably useful before they clarify whether numeric_limits :: is_signed tells for built-in types the same information than this, or just says whether T is one of the four signed types listed in 3.9.1 [to illustrate the difference: char is not a "signed integer type"; but it can have negative values on many implementations] BTW, there's something similar to this in detail/numeric_traits.hpp, so it could be useful at least to refactor that code (Incidentally: Dave, the comment there seem to reveal that intent was for it to work for UDTs too. Of course it doesn't even work for built-in floating points.) - padding.hpp Gives the number of bits of an integral type that do not contribute to represent the value. - promoted.hpp Gives the promoted type for an rvalue expression of integral or floating point type. Example: promoted::type // -> int promoted::type // -> int or unsigned int, //depending on the implementation - wchar_min_max.hpp Implementation detail to make up for broken libraries lacks. - unit_test.cpp/.hpp Obvious purpose. Any comments will be greatly appreciated. Genny. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: how to avoid inclusions?
On Fri, 7 Mar 2003 18:17:56 +0100, Pavol Droba <[EMAIL PROTECTED]>
wrote:
>I wanted to do something else:
>
> template struct trait_class
> {
>
> }
>
> template struct trait_class >
> {
>
> }
>
>without #include
>
>Is this possible?
Practically speaking, no. At least not in a portable, conforming way.
You can (under certain limitations) provide specializations like
class A { };
namespace std { template<> class numeric_limits {}; }
but you can't otherwise add declarations to std. There are several
reasons for this limitation.
AFAIK the committee discussed the possibility to provide fwd versions
of standard headers other than but decided not to do so.
Genny.
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Formal Review for Boost I/O Library
On Wed, 26 Feb 2003 23:00:11 -0600, "Ed Brey" <[EMAIL PROTECTED]>
wrote:
>The formal review for the updated Boost I/O Library begins today and runs through
>March 7.
Just some quick comments:
>The I/O library contains various components for use with the standard I/O library.
>The components are as follows:
> State-saving classes for various IOStream attributes.
These are already into boost, aren't they? Are you asking for a
further review? Or weren't they reviewed when they should have been?
> Class templates to ease making streams off a new stream-buffer class.
> Stream and stream-buffer class (templates) that use an internal array.
> Additional I/O manipulator function (templates).
This part looks quite extemporaneous and incomplete. For instance, why
aren't there
template
std::basic_ostream&
htab (std::basic_ostream& os) {
return os.put(os.widen('\t'));
}
template
std::basic_ostream&
bel (std::basic_ostream& os) {
return os.put(os.widen('\a'));
}
... etc...
too?
As to the two manipulators provided:
- Though 'newl' and 'skipl' imitate the pattern of 'endl' I think it
would be better choosing more descriptive names, like new_line and
skip_until_newline. But, of course, these are religion issues :-)
- The implementation of skipl is erroneous as per lib issue 172; it
should be
template < typename Ch, class Tr >
std::basic_istream &
skip_until_new_line(std::basic_istream & is)
{
return is.ignore( std::numeric_limits< std::streamsize > :: max(),
Tr::to_int_type(is.widen( '\n' )) );
}
- The test program for iomanip.hpp could be improved, I think. Better
showing that skipl can skip any character before the newline, for
instance with something like:
// untested test program
//
char hello[] = "hello";
std::stringstream ss;
ss << hello << "AxxA" << newl << "There";
std::string s;
ss.seekg( 0 );
ss >> std::setw(sizeof hello) >> hello;
char c;
ss >> c;
BOOST_TEST(c == 'A');
ss >> skip_until_new_line >> s;
BOOST_TEST( s == "There" );
- in iomanip.hpp the function template declarations immediately before
the definitions just confuse the code IMO.
- as a general rule, I don't like having source file names too similar
to standard header-names (example: iomanip.hpp). BTW it tends to be
annoying to remember slight differences like vs. "io_fwd.hpp"
and/or remembering whether the latter is iofwd or io_fwd.
>The stream buffer classes are new and deserve primary attention in this review.
Yes. Let me start from the documentation, which is IMHO absolutely
insufficient, especially in the rationale section. Informally speaking
(up to Daryle to improve the wording from a technical perspective) I
think the real rationale goes more-or-less along these lines:
When deriving from the standard basic_istream, basic_ostream,
basic_iostream classes, *you* should provide a pointer to a suitable
stream buffer (this is not the case, for instance, when deriving from
ifstream and ofstream because those classes already contain their
stream buffer). There are several ways to do this:
a) construct a stream buffer independently and associate it with a
stream object later
b) gather the buffer from another stream; this leads to a buffer
"shared" among several stream objects. Example:
template >
class my_stream : public std::basic_ostream
{
public:
my_stream(std::basic_ostream & os):
std::basic_ostream(os.rdbuf())
{
}
};
my_stream m (std::cout);
m << "hi!\n";
Now m and std::cout share the same buffer. Sharing a stream buffer can
be useful in various situations where you want, for instance,
different format settings, or different locales, for the same stream:
in such scenarios instead of continuously switching the format
settings or the locale you use different streams which write to (or
read from) the same stream buffer
c) put a stream buffer into the derived stream; the stream buffer can
be a base sub-object or a data member. This is the typical approach
when a new buffer type is used, and _is what the following classes
help implementing_.
I've omitted, for laziness, an (obvious) example for case a).
Ok, now to the code. Sad to say, but this is the typical case where it
takes more time to understand what the existing "solution" is meant to
do than to write your own code from scratch. BTW, the fact that the
templates are identical except for the presence of 'istream',
'ostream' or 'iostream' in some places is highly suspicious. That
consideration apart, let us compare your code with what I would write
from scratch if I had to define my own stream:
struct buffer_wrapper {
std::stringbuf buffer;
};
template >
class my_stream :
virtual buffer_wrapper,
public std::ostream {
public:
my_stream() : std::ostream(&buffer) {}
};
Now convince me that the approach taken by this library is better than
the (immediat
[boost] Re: Boost.Conversion: possible problem with gcc3
On Wed, 19 Feb 2003 18:51:42 -0500, "Davlet Panech"
<[EMAIL PROTECTED]> wrote:
>Hello,
>
>I'm getting the following warning in gcc 3.2/CYGWIN/boost 1.29:
>
>% /cygdrive/c/boost/boost_1_29_0/boost/cast.hpp:178: warning: decimal
>constant is so large that it is unsigned
>
>173: static long long min()
>174: {
>175: #ifdef LONGLONG_MIN
>176:return LONGLONG_MIN;
>177: #else
>178:return -9223372036854775808LL; // hope this is portable
>179: #endif
>180: }
>
> [...]
>
>
>Is that a problem?
Whether that's a problem or not depends on your point of view. The way
I see it, it *is* an error, even if in the end it works anyway. Better
writing:
-9223372036854775807LL - 1
though of course that's not portable either.
You might be interested in this and its surrounding thread (and in
your limits.h header):
http://google.com/groups?selm=q303su804jh35pbrutlhhoa98og7572rpu%404ax.com
Genny.
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Patch for dynamic_bitset
On Thu, 20 Feb 2003 09:17:17 +0100, Markus Schöpflin <[EMAIL PROTECTED]> wrote: >> PS: I'll write to Jeremy about the merge. > >Great, thanks. Thanks to *you*! I've informed him now. Genny. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Patch for dynamic_bitset
On Wed, 19 Feb 2003 18:03:22 +0100, Markus Schöpflin <[EMAIL PROTECTED]> wrote: >The main difference is that it casts the NULL to void * and VA6 can >deal with that. I just tried. This means that the version on the >branch would work with this compiler. Ah! Here's where the misunderstanding was :-) I thought you found compiler errors on release 1.29 (that is, the branch) but erroneously referred the patch to the trunk. Just to be sure: what went out with 1.29 works with VA6, right? PS: I'll write to Jeremy about the merge. Genny. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: is_class
On Wed, 19 Feb 2003 16:09:26 +0200, "Rani Sharoni"
<[EMAIL PROTECTED]> wrote:
>> // fire-prevention
>> template
>> Burn ref(T*);
>You can improve it to deal with qualified function types (you can't have
>pointers or references for such types):
Right. However the version with the (pointer to) array
Burn ref(T(*)[1]);
requires a compiler which doesn't give an error for abstract classes
(as settled by core 337). If one doesn't have it then it's probably
better giving up qualified function types than abstract classes, being
the latter more common than the former.
>>[...]
>> BTW, I've seen how complex boost::is_reference is. Why so? What
>> compiler(s) cause(s) most problems?
>
>VC6 is problematic since the usual techniques to simulate partial
>specialization ICEd it.
>
>I remember that I came up with the same VC6 trick before I saw it in boost
>and I wonder who invented it.
Hmm... Why I'm not surprised it was VC? Just to do a little
experimenting a gave it a try, and I'm posting here some "discoveries"
so that this waste of time can be useful for someone else too :-)
Well, at the first shot, I wrote this:
template
no check_is_reference (U*); // VC++ fails in some cases with this.
// (yeah, it's able to form pointers
// to references!!!)
template
yes check_is_reference (...);
template
struct is_reference {
BOOST_STATIC_CONSTANT(bool, value =
sizeof(yes) == sizeof (::check_is_reference( 0 ))
);
};
but as you can see from the comments VC++ is able to break it :-) As
I've seen, it can easily form "pointers to references". For instance:
template
void f(T* p) {
}
f(0); // <-- works!
The problem arises when you try to use the pointer, of course.
Example:
template
T f(T* p) {
return *p; // (1)
}
f(0);
Here the line marked with (1) gives:
cannot convert from 'int *' to 'int &'
which shows that in this context our pointer to reference is actually
a pointer to pointer (at least if the error message is reliable). And
that's already nice to know for those who must cope with VC++.
On second try, I slightly modified the is_enum code to:
template
no check_is_reference (U*);
template
yes check_is_reference (...);
template
struct is_reference {
static T t;
BOOST_STATIC_CONSTANT(bool, value =
sizeof(yes) == sizeof (::check_is_reference( &t ))
);
};
In this case it seems to work. Of course it is a mystery why now it
doesn't form pointers to references anymore. Furthermore, it now even
seems to work too much! :-) That is, instead of failing for abstract
classes and function types it kindly fails on the former only :-) What
a strange world...
BTW, under VC++ the boost version (release 1.29.0) of is_reference
gives false positives with function types.
Genny.
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Patch for dynamic_bitset
On Wed, 19 Feb 2003 14:33:31 +0100, Markus Schöpflin <[EMAIL PROTECTED]> wrote: >You are right, it's a conformance problem with VA6, at least on my >installation. But the fix on the 1.29.0 branch should work. Could you >please merge it to the main trunk? Well, I think that's up to Jeremy or Chuck who are the authors of the library. Anyhow, I'm not sure we have understood each other (maybe party the fact I talked about "main branch" instead of "main trunk", sorry): the version shipped with boost 1.29.0 has no conditionals around the calls to allocate(): it simply passes the second argument explicitly. It was a deliberate goal to have a version that did work _and_ didn't have #if-s (I would have eliminated the #if-s that were there before, even if they weren't incorrect: too annoying when reading the code, in any case). Visual Age 6 doesn't like that either, but of course I would still prefer keeping the code without the conditionals. That's why I asked if changing the type of the second argument with: allocate(calc_num_blocks(num_bits), static_cast(0)) fixes the problem. Otherwise I think I will use some helper macro, like: #if ... #define BOOST_STD_ALLOCATOR_DEFAULT_HINT\ static_cast(0) #else... #define BOOST_STD_ALLOCATOR_DEFAULT_HINT /**/ #endif in a config file. Anyway, all this just refers to the sandbox (where there's by the way a much newer version of dynamic_bitset): changes to the main cvs repository, especially those going into a release, better have the authors' approval. Genny. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Patch for dynamic_bitset
On Tue, 18 Feb 2003 12:06:51 +0100, Markus Schöpflin <[EMAIL PROTECTED]> wrote: >Hi there, > >currently, dynamic bitset tests fail for VA6 because the library >doesn't correctly detect that a standard compliant allocator is available. > >Therefore I propose the attached patch to be applied to >boost/detail/dynamic_bitset.hpp. The patch uses BOOST_NO_STD_ALLOCATOR >to check if a workaround is needed. It only tries to use the >workaround if BOOST_NO_STD_ALLOCATOR is defined. Seems like the main branch hasn't been updated: the 1.29.0 version doesn't have the #if anymore. BTW, the error messages at http://boost.sourceforge.net/regression-logs/cs-AIX-links.html clearly show that a candidate with two parameters does exist. Is it really an allocator conformance issue or rather a compiler bug? Does this allocate(calc_num_blocks(num_bits), static_cast(0)) compile? Genny. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: is_class
On Tue, 18 Feb 2003 19:14:50 +0200, "Rani Sharoni"
<[EMAIL PROTECTED]> wrote:
>This is very nice technique. Just notice that you also need to handle void,
>functions and arrays types.
>
>Abstract classes, functions and array types will fail the completion on the
>burn conversion operator since they are not allowed as returns types.
Yeah. The code was just to give the idea, which I could have expressed
in English if it wasn't that my English is even worse than my C++ :-)
>IMHO the main achievement of your technique is that, unlike techniques that
>use conversion constructor to burn user defined conversion, its works for
>incomplete classes (EDG and GCC complain when trying to pass lvalue of
>incomplete class to function that take ellipsis as an argument).
Yes. Attempting lvalue-to-rvalue conversion of an expression of
incomplete type makes the program ill-formed.
>Here is a possible is_enum implementation using your technique:
>
>
>template struct convertible { operator T&() const; };
>
>template
>struct is_enum2
>{
>static yes test(int);
>static no test(...);
>
>struct not_enum {};
>
>typedef typename select_type< is_fundamental::value ||
>is_reference::value, not_enum, convertible >::type T2;
>
>static T2& make();
>};
>
>
>
>template
>struct is_enum
>{
>enum { value = sizeof(is_enum2::test(is_enum2::make())) ==
>sizeof(yes) } ;
>};
Nice :-) BTW, you can avoid the select_type machinery:
template
struct Burn {
operator T&() const;
};
// fire-prevention
template
Burn ref(T*);
template
char* ref(...);
// outside the is_enum<> template
// to help gcc
//
yes is_enum_checker (unsigned long);
no is_enum_checker (...);
template
struct is_enum {
static const bool value =
!is_integral::value
&& !is_floating::value
&& sizeof(yes) == sizeof( is_enum_checker (ref(0)) );
};
But this simple stuff is already enough to knock out a lot of
compilers :-/
BTW, I've seen how complex boost::is_reference is. Why so? What
compiler(s) cause(s) most problems?
Genny.
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: is_class
On Mon, 17 Feb 2003 10:02:58 +0100, Daniel Frey
<[EMAIL PROTECTED]> wrote:
>I started to implement my own type-traits to see if I can do it and to
>learn something. While doing so, my design lead me to some dependencies:
>is_enum needed is_class
Daniel, my apologies in advance if this is just a stupid comment. I'm
again jumping in without actually following the thread (not enough
time), however if I had to implement is_enum the first property that I
would try exploiting is the built-in convertibility (of an rvalue) to
integral types. If you immediately burn the one user-defined
conversion allowed in any implicit conversion sequence there's no need
to exclude classes, I think. The basic idea is:
template
struct is_integral {
static const bool value = false;
};
#define THIS_IS_INTEGRAL(t)\
template <> struct is_integral { \
static const bool value = true; \
} \
/**/
template
struct is_floating {
static const bool value = false;
};
#define THIS_IS_FLOATING(t)\
template<> struct is_floating { \
static const bool value = true; \
}
...
/* add cv-qualified specs here */
...
/**/
THIS_IS_INTEGRAL(bool);
THIS_IS_INTEGRAL(char);
THIS_IS_INTEGRAL(wchar_t);
THIS_IS_INTEGRAL(signed char);
THIS_IS_INTEGRAL(short);
THIS_IS_INTEGRAL(int);
THIS_IS_INTEGRAL(long);
THIS_IS_INTEGRAL(unsigned char);
THIS_IS_INTEGRAL(unsigned short);
THIS_IS_INTEGRAL(unsigned int);
THIS_IS_INTEGRAL(unsigned long);
THIS_IS_FLOATING(float);
THIS_IS_FLOATING(double);
THIS_IS_FLOATING(long double);
template
struct is_enum {
struct Burn {
operator T() const;
};
typedef char yes;
typedef char(&no)[2];
static yes is_it(unsigned long);
static no is_it(...);
template
static no check_rvalue(U&);
static yes check_rvalue(...);
static T get_T();
static const bool value =
!is_integral::value
&&
!is_floating::value
&&
sizeof(yes) == sizeof( is_it( Burn() ) )
&&
sizeof(yes) == sizeof( check_rvalue( get_T() ) )
;
};
The above is absolutely untested and off the top of my head so take it
with great great prudence :-) It was just to say that, if I'm not
mistaken, is_enum doesn't need is_class. Maybe.
Genny.
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: is_class
On Mon, 17 Feb 2003 08:34:24 -0500, David Abrahams <[EMAIL PROTECTED]> wrote: >I think even Intel 7 is using the old front-end, but Intel 6 >certainly. I don't know whether you'll _notice_ a difference, though. I don't know what is, in context, the "old front-end" here. However Intel C++ 7 for Windows uses EDG 3.0 (even if they haven't export). Don't know about the Linux version though (I don't know pretty much anything in this post... :-)) Genny. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: is_class
On Sun, 16 Feb 2003 03:12:13 +0100, Daniel Frey <[EMAIL PROTECTED]> wrote: >On Sun, 16 Feb 2003 01:14:17 +0100, David Abrahams wrote: > >> Daniel Frey <[EMAIL PROTECTED]> writes: >> >>> I won't try to fix any of these anymore. I neither understand the >>> documentation nor the implementation of boost's type-traits. I tried to >>> make the code better but AFAICS there is no interest in improvment. >> >> Does anyone understand what improvement you're trying to make? > >I have the impression that the type-traits can and should be improved. I >don't have a complete solution for everything at once and I prefer >evolution over revolution. Thus I tried to start by suggesting a new >is_class implementation. I was disappointed to see only bashing on details >instead of a discussion of the "big picture". > >The basic point was (IMHO) never answered. I tried to clean up the >implementation by providing a closed implementation of is_class for more >compilers. This should decrease the coupling of all the different parts. I >think that this is a better design than the current one. The example I >gave which I thought might show the local problem was wrong. My fault, >granted. But does it speak against cleaning up the code? > >As far as I learned right now, boost is not meant to provide a clean >implementation, instead, it provides a good documentation and an >implementation that "just works". But even the documentation confused me >several times. is_scalar doesn't mention enum, is_member_function_pointer >is not a secondary type category, the mixture of utility functions and a >framework and primary type categories are implemented using secondary >type categories. Even if it works, it is IMHO still bad code. My only >chance to understand type-traits was to create my own implementation from >scratch. But maybe it's just me... Well, I have not been following this thread closely, so my apologies if I'm taking this comment out of context, however having felt more-or-less the same about type_traits I think it is right to back up Daniel in his opinion. The few times I've looked at it, the documentation was more an obstacle than a help; the easiest way to understand the purpose was to look at the code. One of the issues is terminology. For instance what does it mean: ::boost::is_union::value Evaluates to true only if T is of union type. Currently requires some kind of compiler support, ->> otherwise unions are identified as classes. <<-- ? First of all, unions *are* classes to the standard (Well, I think this is just a terminology mistake. However the standard terminology is a reference for a C++ programmer, so if the docs adopt a different convention they should say so). Secondly, the sentence above is in the description of is_union<>, not is_class<>, and it's rather is_class that detects unions; and not "otherwise": it detects unions anyway! :-) As to the point of providing an implementation that "just works", I totally disagree. And I don't think this is the (stated) intent, otherwise I wouldn't use boost at all, and probably wouldn't even be subscribed to the list (if not to keep informed about what is going to be put in the standard). More generally, cleaning up implementations is IMHO a "must do" at this point of the boost evolution. Rather than worrying about ordinary releases, I think we should have the library undergoing a global review, focused on eliminating the noise that have been accumulating over the years, and the existence of ad hoc solutions in each library for things that could be factored out in an autonomous component (e.g. is_signed and related stuff in numeric_traits). Also, I hate the enormous degree of coupling of most type_traits components: let's say I include boost/type_traits/is_integral, which should be the most simple thing in the world to implement. Well, under the appearance of an innocent: #include "boost/type_traits/detail/bool_trait_def.hpp" I end up including: - template_arity_spec.hpp - bool_c.hpp and - lambda_support.hpp" (!!!) And lambda_support, in turn, includes so much preprocessor stuff that I think it is more than what I would have in the whole application hadn't I included is_integral. So why should I use it? After all I can write the same in portable C++. And, by portable I mean effectively portable even to broken compilers (the ones I use, of course). As to your impression, I know the feeling. BTW, I think that's partly due to a couple of reasons: first of all people tend to reply for disagreement more easily than for support, and that's in part logical because otherwise we would have a lot of replies which just said "yes", "yes" and "I agree" :-) Another point is that most people expect "approval" to come from one of the authoritative boost members (Beman, Dave, Peter, etc.). Speaking for myself, even if I agree with a change that you propose, I don't feel to reply with, let's say, a "yes, let's do it", because I don't feel to have the weight to
[boost] Re: Request: BOOST_ENABLE_LONG_LONG
On Sat, 15 Feb 2003 12:00:36 -, "John Maddock" <[EMAIL PROTECTED]> wrote: >> Can't we detect >> whether the compiler is supporting "long long" and only enable the >> long long code under those circumstances? In fact, /don't/ we do >> that? >> >> If this is just about inconvenient warnings, it seems to me that >> telling people "disable long long support or disable the warning" is a >> perfectly sensible approach. >> >> What am I missing? > >I agree completely: the issue is that older EDG compilers (prior to 3.0.0) >don't signal whether they're in strict mode or not Well, it's unfair to offload it on the compilers though. They aren't certainly obliged to tell you that a non standard type is not available. But I'm getting tired of all this discussion, I'm just replying for the equity's sake. Just to set records straight: the problem was not compilers; it's just that one should IMHO be able to compile, let's say, boost::is_integral in strict mode, unless she does use is_integral. If I just use is_integral, why should I get errors? As you know (see http://lists.boost.org/MailArchives/boost/msg29582.php ) __NO_LONG_LONG is just a 3.0 addition. There's a whole world of EDG front ends that don't have it, and there's a whole world of EDG users who want to compile in strict mode. BTW, Dave asked "can't we detect whether the compiler is supporting long long?". Can we? Genny. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Request: BOOST_ENABLE_LONG_LONG
On Thu, 13 Feb 2003 11:52:59 -, "John Maddock" <[EMAIL PROTECTED]> wrote: [..] >I hear what you say, but I keep coming back to: this is largely an Intel >compiler specific problem, No, it's a matter of not making a silent use of non standard features. >and most users really do expect their libraries >to support long long whenever the compiler does. Maybe. But we can't second such attitudes. Otherwise someone might expect __complex__, or incomplete enumeration types. Where do you stop? >Personally I don't want to >have to answer a flood of questions along the lines of "why doesn't >some_type_trait work correctly?" Oh, that's really underestimating users' intelligence. Genny. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Borland specific defects : new config defines?
On Thu, 13 Feb 2003 12:01:47 -, "John Maddock"
<[EMAIL PROTECTED]> wrote:
>I'm not sure if this is due to a compiler bug or what, but basically it's
>due to the way that STLport is set up: the names are declared in namespace
>stlport (which is an alias for either _STL or _STLD depending upon the
>build), and then imported into std with:
>
>namespace std{
>using namespace stlport;
>}
>
>in STLports _suffix.h. This works fine for most cases, but not when the
>name is already present in namespace std (as is the case with the is*
>functions for example).
Ah! I didn't realize this was the case! Yes, that's how qualified
lookup for namespace members works; if there's a direct declaration of
the searched name in the nominated namespace then any using directive
contained therein is ignored (for the purpose of looking up the name).
Strictly speaking, the standard refers that rule to user-declared
namespaces, not std. However... :-)
Genny.
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Request: BOOST_ENABLE_LONG_LONG
On Tue, 11 Feb 2003 08:09:19 -0500, David Abrahams <[EMAIL PROTECTED]> wrote: >Gennaro Prota <[EMAIL PROTECTED]> writes: >> Could we subordinate BOOST_HAS_LONG_LONG to >> defined(BOOST_ENABLE_LONG_LONG)? > >Even if we're willing to break user code and tell them they have to >define that macro explicitly, we'd have to be very careful; we have >tests that exercise long long and we don't want to break those or >disable that part of the testing. Yes. Those tests would simply have to #define BOOST_ENABLE_LONG_LONG. All the rest would remain the same. The idea was for defined(BOOST_ENABLE_LONG_LONG) to be a necessary (but not sufficient) condition to *define* BOOST_HAS_LONG_LONG. At the point of usage one would still deal with BOOST_HAS_LONG_LONG only, and the typical code snippet involving long long would still appear as: #ifdef BOOST_HAS_LONG_LONG ... #endif (Maybe the idea is clearer if one mentally renames BOOST_HAS_LONG_LONG to BOOST_USE_LONG_LONG) Genny. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Borland specific defects : new config defines?
On Tue, 04 Feb 2003 00:02:30 +, Alisdair Meredith
<[EMAIL PROTECTED]> wrote:
>The two defects are:
>The various std::isdigit, islower, isalnum etc. convenience functions
>will not compile.
Please could you post a concrete example?
[...]
>Second problem is with the STLport implementation of the STL. This
>places all std names into the namespace _STL and uses macro-magic to
>make this look like std. Unfortunately, for reason I have not fully
>determined, that magic sometimes comes up short.
>
>Often the fix is to add a using directive:
>using std::swap;
>swap( a, b );
>
>Sometimes the fix is to explicitly specify namespace _STL instead.
>
>_STL::swap( a, b );
Could you post a reproducible test case? Have you checked what does
_STL expand to in your specific case?
>There are cases where either fix works, and specific cases where only
>one form or the other works.
I think the best thing to do here is to post some complete examples.
It's difficult to suggest solutions, or even seeing if solution
suggested by others are ok, when all you have is a vague description
of the problem ('there are cases', 'often', 'sometimes', etc.).
Genny.
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Request: BOOST_ENABLE_LONG_LONG
On Tue, 11 Feb 2003 11:36:56 -, "John Maddock" <[EMAIL PROTECTED]> wrote: >> Could we subordinate BOOST_HAS_LONG_LONG to >> defined(BOOST_ENABLE_LONG_LONG)? > >I would rather that BOOST_HAS_LONG_LONG was just not defined in the first >place when EDG is in strict mode - any ideas? When Intel? Or when EDG? In the second case I would say no, because EDG based compilers usually accept long long even in strict mode if you enable it with --long_long. It's just that Intel (6.0) doesn't seem to like it :-/ Anyhow, how do you propose to avoid the warnings issued in non-strict mode? Genny. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
