John Maddock schrieb:
[snip]
> > If that is true: Why does the flag regbase::use_except (officially)
> > exist?
>
> It's a historical accident and should have been removed from the docs.
OK. So it seems that I should not write code which explicitely mentions
regbase::use_except?
> > Lets assume
but that is not a very nice programming style I think, according
to the general
guideline: "If you **can** handle a problem locally, do should do that".
Thank you for your help,
Daniel Spangenberg
P.S.: Please forgive me, if I obviousl
quot;Separate, Explicit Instantiation" be removed or not?
If it is removed, this fix is done by this very sentence ;-). Currently I don't
see any strict portable method, which works via the non-inheritance
trick, but maybe another one sees such a solution...
Congratulations for all your
well-explained on my side and resulted in some misunderstandings
among the "discussees" I think, that we can be assume, that the current
text proposes a non-standard feature and should be either removed or
declared as "non-portable".
If you don't think that this statement hol
the same internal floating value, but if not will
round to adjacent values."
My personal opinion is: Extend the DECIMAL_DIG definition for any floating point
type,
similar to digits10 it could be part of numeric_limits (if the standard would be
extended) or
f
Daniel Frey schrieb:
I think the OP asked about explicit instantiated
X. Daniel
(Spangenberg), please correct me if I'm wrong, but you question boils
down to something like this:
Correct. But even a simpler example, where everything is inside **one**
namespace,
either the global o
Daniel Frey schrieb:
> They needn't be visible for myclass. They only need to be visible in the
> namespace where this happened. See 3.4.2/2:
>
> "If T is a class type, its associated classes are the class itself and
> its direct and indirect base classes. Its associated namespaces are the
> nam
Daniel Frey schrieb:
> I guess you missed the fact that X in the operators library defines
> operators which take T as an argument, not X. Whether X is
> associated with T is therefore not important here, ADL matches the
> operator arguments, not the class which declared the operator.
>
> Regards,
Hello Boosters,
after some experiences I got during a the developement of a BitMaskOps
class template (as an extension of operators for enums), which can be
found on
http://groups.google.de/groups?q=BitMaskOps&hl=de&lr=&ie=UTF-8&selm=3F165079.A0CE8BAE%40bdal.de&rnum=1
I assume now, that the sect
2 bit, 64 bit, 80 bit, or 128 bit floating point types)
4) If you think that the selected_int and selected_uint class templates
are redundant
because of the capabilities that are provided by the class templates
inside boost/integer.hpp,
I think, that at least selected_real could be a base for the missing
"boost/floating_point.hpp"
header. If you like, I would prepare an implementation even for that.
Before I invest more time in a reviewable implementation (The version I
have needs
perhabs one day), I would like to hear your general opinion.
Thanks,
Daniel Spangenberg
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
David Abrahams schrieb:
> Well, that's not my philosophy FWIW. Mine is:
>
>if the condition is a programmer error, use assert
>otherwise, use a well-documented exception
>
> Occasionally, due to a "no throw" requirement, you have to choose to
> make certain things into programmer errors
"William E. Kempf" schrieb:
>
> 20.3.3/8
>
> "For templates greater, less, greater_equal, and less_equal, the
> specializations for any pointer type yield a total order, even if the
> builtin operators <, >, <=, >= do not."
Grummph, you are absolutely right, of course, and I should have known i
Hello William!
"William E. Kempf" schrieb:
> You're correct, and the solution is simply to replace the < operator with
> std::less calls.
You mean the std::less specialization on boost::mutex? (I wasn't aware, that
you provide total ordering on mutexes). Otherwise I don't see the difference,
I h
Hello Popov!
popov schrieb:
> (not sure it's the right place to post this, but it seems smart_assert is
> (or will) be part of boost, and I can't get the author email addresses. The
> article is:
>
> http://www.cuj.com/documents/s=8464/cujcexp0308alexandr/)
>
> Here's an excerpt of some code:
I
Hello, Boosters!
Today I stumbled across an unspecified behaviour which can be caused
by the example class "counter" of the Boost thread FAQ.
The errounous lines are inside the copy assignment operator of the
class:
boost::mutex::scoped_lock lock1(&m_mutex < &other.m_mutex ?
m_mutex : other
so far away from now, we would probably
prefer to wait on it...
Btw, I would like to express my very high respect for this fantastic
library
which is still growing because of the high engagement and the personal
initiative of all its participants!
Thank you,
Daniel Spangenberg from Bremen
"Ralf W. Grosse-Kunstleve" schrieb:
> --- Daniel Spangenberg <[EMAIL PROTECTED]> wrote:
> >
> > These news are very good, but what about the "thread library"?
>
> I cannot find the beginning of this thread. Where could I read the "very go
ld be an #include of (later
following
the existing "using std::min"/"using std::max"), which should provide the necessary
min/max instances.
Or did I misunderstand something?
Greetings,
Daniel Spangenberg
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
this uglyness by #include'ing before
#include'ing and immediately after this we #undef min/max,
but this
is unsatisfactory on the long run.
Thanks in advance,
Daniel Spangenberg
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
These news are very good, but what about the "thread library"?
They will not forget it, will they?
Daniel Spangenberg
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
20 matches
Mail list logo
