Re: [boost] [Signals] BCB patchlet
This removes a possible use of 'tag' before definition warning with BCB. I didn't use this actual patch (I'd rather avoid pragmas when there's a reasonable in-language workaround), but the code I checked in should get rid of the warning on BCB (not that Signals compiles at the moment!). Sorry for the delay. Doug ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Review request: enable_if
Howard Hinnant wrote: On Wednesday, July 9, 2003, at 04:31 PM, Jaakko Jarvi wrote: Yes it would be possible. Just committed in. Thanks! Breaks in g++ 3.2. ICC 7 accepts. Metrowerks? Must works, you wouldn't have asked otherwise, right :) chuckle Yes, it works, and yes I do have ulterior motives, though they are probably not what it would seem. I'm hoping this will work in g++ asap, and I figured this was the fastest way. :-) Well, a bug report at http://gcc.gnu.org/bugzilla/ has a similar effect. See e.g. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11511 which crops up with boost::mpl. Putting gcc-killer code in boost is a nice approach but has the disadvantage of some delay until developers get aware of it. Also the side effect is that my boost-based code does not compile with gcc from time to time, which leaves me rather unproductive. Please (!) go and file an appropriate bug report at the site I mentioned. Markus - who hopes the new gcc parser will get stable some day :-( -- Build your own Expression Template Library with Daixtrose! Visit http://daixtrose.sourceforge.net/ ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Review request: enable_if
Thomas Witt wrote: 3. To me the disable templates don't add any value. They are just duplicating the amount of code without any real benefit. I know this is a matter of taste, it's just that I would prefer a minimal interface. Following David's arguments towards mpl compatibility and removing direct use of || etc. I'd prefer template class T, class U typename disable_ifmpl::andis_matrixT, is_vectorU ,...::type operator*(const T t, const U u); and feel uncomfortable about adding another not, just because _my_ code is ugly enough already template class T, class U typename enable_ifmpl::notmpl::andis_matrixT, is_vectorU ,... ::type operator*(const T t, const U u); So please keep disable_if. Markus -- Build your own Expression Template Library with Daixtrose! Visit http://daixtrose.sourceforge.net/ ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: mpl/loki
Peter Dimov wrote: David Abrahams wrote: But that's only true as long as void_ is being used for internal purposes. Once you give it up to users as you suggest, it loses that correspondence, and we'll have some other internal name which has that correspondence to void. Maybe the problems are caused by overloading void_. I haven't looked at MPL recently, but as a general observation I have identified at least three uses of a void_-like entity. 1. A type parameter used to emulate a variable argument template. I use '_missing' for this purpose (leading underscore for implementation details.) templateclass A1 = _missing, class A2 = _missing, ... struct F; 2. An optional parameter that, when not supplied, has a reasonable (dependent) default. I use 'unspecified'. templateclass R = unspecified, class F ... bind(F f); 3. A type that is guaranteed to be distinct from all other useful types. 'nil' is what Lisp calls it; void_ is fine, too. From my experience it's a bad idea to have one general, user-documented type that is used as a default for variable argument templates. The problem is that when a user knows the type's name and thus the type (be it called void_, nan or whatever), he might also expect to be able to work with it like with any other type. If forming a container-type (mpl::vector, ...), it should be possible to inject the type like all other types because otherwise, well, it wouldn't be a type and the user will be surprised no matter whether you document it or not. I therefore think that each library should have an internal type that the user doesn't know about and that might then be put it into a namespace detail or something and called depending on it's semantics. Makes it easier to understand the type's role inside the library, thus increases readability and maintainability and improved orthogonality of different libraries. Also, I wonder what reasons are there to create a general type for this purpose. Avoiding code duplication doesn't sound reasonable as we only replace a single line per such class with an include. Some libraries might even need a declaration-only-type, other might needs an (empty) implementation. So, what benefit would a general type give to us? Regards, Daniel -- Daniel Frey aixigo AG - financial training, research and technology Schloß-Rahe-Straße 15, 52072 Aachen, Germany fon: +49 (0)241 936737-42, fax: +49 (0)241 936737-99 eMail: [EMAIL PROTECTED], web: http://www.aixigo.de ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] multi_array and new iterator adaptors fix
Dear Boosters, Since the update of the iterator adaptor library broke boost multi_array (or at least my CVS version of it), I tried to fix it and came up with the patch below which makes my codes compile again. Since I do not have documentation of the new version of the iterator adaptors (either my CVS checkout is messed up or maybe it is not in the CVS yet), I am not sure whether this is the correct fix. Can somebody familiar with the iterator adaptor library check the patch and apply it if it is correct? Matthias cvs diff -u iterator.hpp Index: iterator.hpp === RCS file: /cvsroot/boost/boost/boost/multi_array/iterator.hpp,v retrieving revision 1.4 diff -u -r1.4 iterator.hpp --- iterator.hpp30 Jan 2003 16:55:31 - 1.4 +++ iterator.hpp14 Jul 2003 08:30:31 - @@ -21,6 +21,7 @@ #include boost/multi_array/base.hpp #include boost/multi_array/iterator_adaptors.hpp #include boost/iterator_adaptors.hpp +#include boost/iterator/reverse_iterator.hpp #include cstddef #include iterator @@ -150,7 +151,7 @@ typedef typename iterator_gen_helperT,base_type,NumDims,value_type, reference_type,tag,difference_type::type it_type; public: - typedef typename boost::reverse_iterator_generatorit_type::type type; + typedef boost::reverse_iteratorit_type type; }; template typename T, std::size_t NumDims, typename value_type, @@ -161,7 +162,7 @@ typedef typename iterator_gen_helperT,base_type,NumDims,value_type, reference_type,tag,difference_type::type it_type; public: - typedef typename boost::reverse_iterator_generatorit_type::type type; + typedef boost::reverse_iteratorit_type type; }; } // namespace multi_array ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] More compile problems
Hi, I now get the following compile-time error on MacOS X using g++ v. 3.1: /Users/troyer/src/boost/boost/iterator/iterator_adaptor.hpp:282: `sizeof' applied to incomplete type `boost::STATIC_ASSERTION_FAILUREfalse' Can anybody help? Matthias ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: mpl/loki
On Monday, July 14, 2003, at 05:18 AM, John wrote:
class nat {nat();};
How about not_a_type?
It's a little more to type, but looks much better (IMHO).
And shouldn't it be :
struct not_a_type {};
As Peter pointed out, such a class can have several uses. In some of
the contexts I've used it, I wanted to make sure that client code could
not construct an instance. Perhaps such a constraint would not be
appropriate in all use cases.
-Howard
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] About member extraction
Daryle Walker ha escrito:
But doesn't the PtrToMember template parameter already imply the
Type and Class parameters? So specifying all three would be
redundant. Could we reduce it by:
//
template typename PtrToMember
struct member_extractor
{
// Don't know if this is a real type-traits class
BOOST_STATIC_ASSERT(is_pointer_data_memberPtrToMember::value);
// The extractor traits classes aren't real (yet, maybe)
typedef get_class_typePtrToMember argument_type;
typedef get_member_typePtrToMember return_type;
return_type const operator ()( argument_type const c ) const
{ return c.*PtrToMember; }
return_type operator ()( argument_type c ) const
{ return c.*PtrToMember; }
};
Of the approaches you propose, this is the one that I like best, but
I'm afraid it cannot be implemented: Note that PtrToMember is a
*type* (something like int A::*), not a pointer to member.
member_extractor would have to defined as
template typename PtrToMember, PtrToMember ptr
struct member_extractor
and used as
member_extractorint A::*,A::x; // x is an int member of A
which takes us again to the redundancy we were trying to avoid.
Something in the way of eliminating this redundancy, however, would be
a boon. Maybe some metaprogramming gurus here can think of
something.
Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Signals and multi_array? [was: Problem compiling boost.filesystem]
At 09:50 PM 7/13/2003, David Abrahams wrote: Matthias Troyer [EMAIL PROTECTED] writes: ... I hope that multi_array will also be fixed soon Somebody has to make that fix, whatever it is. multi_array used to use its own private version of iterator_adaptors. Doesn't look like there has been any activity on signals and multi_array. Are the developers aware of the need for action? --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: rw_lock / next thread version
Howard Hinnant wrote:
[...]
class rw_mutex
{
public:
typedef detail::read_lockrw_mutex read_lock;
typedef detail::write_lockrw_mutex write_lock;
...
};
[...]
This looks slightly more readable and writable to me. And will avoid
unlock() having to check what kind of lock (read or write) it is trying
to unlock.
Yup.
http://google.com/groups?threadm=3ef71197%40usenet01.boi.hp.com
(Subject: Re: newbie question)
quote
And, you know, the fact POSIX threading API doesn't have rdunlock()
and wrunlock() operations [separate calls] makes me kinda wonder WHY
someone was definitely NOT thinking in the direction of reducing
the amount of reordering constraints imposed on the implementation
[i.e. compiler, in the first place; things like IPA aside] to the
absolute minimum that's actually needed when the current threading
API was created/voted. You keep telling me about the mutex... think
of a read-write lock for a second, please.
Believe me, I've thought about it for a lot more than a second.
As for the combined unlock function, all I can say is that I always thought
that was a bad idea too. Not just for potential efficiency, but also
because it restricts error checking. That is, if someone accidentally calls
pthread_rwlock_wrunlock() twice, you can cause it to fail. But readers
generally aren't identified, merely counted, so if a writer calls
pthread_rwlock_unlock() twice, and on the second call there's one or more
readers, the call can do nothing but successfully unlock for read. The
alternative would be to keep a list of all active readers; but that gets
messy quickly when you have to account for a thread possibly holding
multiple read locks at the same time.
You can take this as evidence that POSIX doesn't always listen to me. ;-)
/quote
regards,
alexander.
P.S. Butenhof is, of course totally wrong in the rest of that article. ;-)
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: multi_array and new iterator adaptors fix
Matthias Troyer [EMAIL PROTECTED] writes: I do not have documentation of the new version of the iterator adaptors (either my CVS checkout is messed up or maybe it is not in the CVS yet) http://tinyurl.com/gv90 http://tinyurl.com/gv91 I am not sure whether this is the correct fix. Looks good, but please always post patches as attachments. This one failed to be correctly applied on my machine. Can somebody familiar with the iterator adaptor library check the patch and apply it if it is correct? Done. -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: More compile problems
Matthias Troyer [EMAIL PROTECTED] writes: I now get the following compile-time error on MacOS X using g++ v. 3.1: /Users/troyer/src/boost/boost/iterator/iterator_adaptor.hpp:282: sizeof' applied to incomplete type `boost::STATIC_ASSERTION_FAILUREfalse' Can anybody help? What were you compiling? Reproducible case, please! -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Problem compiling boost.filesystem library
Beman Dawes wrote: msvc: C:\boost\site\boost/iterator/iterator_facade.hpp(365) : error C2899: typename cannot be used outside a template declaration Fixed. -- Dipl.-Ing. Thomas Witt Institut fuer Verkehrswesen, Eisenbahnbau und -betrieb, Universitaet Hannover voice: +49(0) 511 762 - 4273, fax: +49(0) 511 762-3001 http://www.ive.uni-hannover.de ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] About member extraction
Subject: Re: [boost] About member extraction
From: Joaquín Mª López Muñoz [EMAIL PROTECTED]
Date: Mon, 14 Jul 2003 14:24:37 +0200
To: Boost mailing list [EMAIL PROTECTED]
Daryle Walker ha escrito:
But doesn't the PtrToMember template parameter already imply the
Type and Class parameters? So specifying all three would be
redundant. Could we reduce it by:
//
template typename PtrToMember
struct member_extractor
{
// Don't know if this is a real type-traits class
BOOST_STATIC_ASSERT(is_pointer_data_memberPtrToMember::value);
// The extractor traits classes aren't real (yet, maybe)
typedef get_class_typePtrToMember argument_type;
typedef get_member_typePtrToMember return_type;
return_type const operator ()( argument_type const c ) const
{ return c.*PtrToMember; }
return_type operator ()( argument_type c ) const
{ return c.*PtrToMember; }
};
Of the approaches you propose, this is the one that I like best, but
I'm afraid it cannot be implemented: Note that PtrToMember is a
*type* (something like int A::*), not a pointer to member.
member_extractor would have to defined as
template typename PtrToMember, PtrToMember ptr
struct member_extractor
and used as
member_extractorint A::*,A::x; // x is an int member of A
Actually, I think it's worse (I don't have a C++ compiler with me right now:-( )
Something in the lines of:
template typename type, typename result, result type::* ptr
struct member_extractor
which takes us again to the redundancy we were trying to avoid.
Something in the way of eliminating this redundancy, however, would be
a boon. Maybe some metaprogramming gurus here can think of
something.
I would really love to see a solution to this ;-)
Best,
John
Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Problem compiling boost.filesystem library
Beman Dawes [EMAIL PROTECTED] writes: At 06:02 PM 7/13/2003, Matthias Troyer wrote: it now works again ... It broke again for Win32 due to a Sun fix from Jens that inadvertently broke Win32 compiles. That is now fixed. Also Dave fixed an iterator_facade glitch, so filesystem is working for more compilers. On Win32, there still seem to be iterator_facade issues for como-win32 and VC++ 6.0 See below. --Beman como-win32: C:\boost\site\boost/iterator/iterator_facade.hpp, line 285: error #864: iterator_facade is not a template BOOST_ITERATOR_FACADE_RELATION(==) msvc: C:\boost\site\boost/iterator/iterator_facade.hpp(365) : error C2899: typename cannot be used outside a template declaration Please try again. The msvc bug has been worked-around. I believe I got the right fix for como, but since Greg only gives working compilers to you wink I can't tell for sure. -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: functors for taking apart std::pair?
At 06:15 PM 7/12/2003, Aleksey Gurtovoy wrote: Brian McNamara wrote: If and when I get FC++ ( http://www.cc.gatech.edu/~yannis/fc++/ ) into Boost, FC++ has the same kind of selectors you've shown above (named fst and snd, as in Haskell). Whereas these function objects also cannot be used with STL algorithms requiring adaptables (for the reason you mention above), it can be used with the analogous algorithms in FC++, since the FC++ infrastructure enables return-type-deduction for template function objects. So do Boost.Lambda and Phoenix infrustructures, and unification of these is proposed for the TR1 - http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/papers/2003/n1454.html A slight clarification: N1454 isn't just proposed; it has been accepted by full committee vote:-) It is possible for the full committee to reverse itself, and remove something that has previously been accepted. But that's fairly unusual, so you can expect N1454 to be in the TR. --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Problems with CVS?
At 01:27 PM 7/13/2003, Marshall Clow wrote: At 11:49 AM 7/9/2003, Marshall Clow wrote: At 7:09 PM -0700 7/6/03, Marshall Clow wrote: The last 3 or 4 times that I have tried to check out the latest boost, the checkout gets most of the way through, and then hangs. Is anyone else seeing this, or am I the only one? If you are accessing CVS via SSH (developer), you should not have any problem. In fact CVS access has been very fast and reliable lately for me doing SSH access. Beman - I've read the SF docs, generated some keys, and attempted to connect to SF using SSH -- all I've got is a bunch of timeouts. I would sure appreciate it if you would send me a couple of CVS commands that you use to do this. I use: cvs -z9 update -P -d My CVS_RSH environmental variable is set to the path of the ssh program I use. It takes care of all the security stuff; from my perspective it is just magic that works without any action on my part. I just glanced at the S/F Mac OS documentation, and it doesn't seem to give a test procedure. The Windows docs have a Testing automatic authentication section. The idea being to verify the ssh setup using the facilities of the ssh client program before actually trying to execute any cvs commands. That would seem to be a sensible approach. Some ssh clients have verbose modes that help greatly in debugging authentication issues. HTH, --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Revised streambuf library
A little over a month ago, I posted a library for creating streambufs from objects with socket-like interfaces. In response, several people requested filtering capabilities, and others have since posted filtering streambuf code (Larry Evans, Daryle Walker, Paul Bristow) and related material (Maxim Egoruskin.) I have posted a new version of my library, which has been rewritten to incorporate filtering as a basic construct. (http://groups.yahoo.com/group/boost/files/streambuf_lib.zip) In addition to allowing the easy creation of streams and streambuf from objects with socket-like interfaces, it provides a convenient interface for defining i/o filters and for combining them in various ways with each other and with types from the standard library (streams, streambufs, containers, sequences, codecvts.) The library is now implemented as a collection of pluggable components. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Signals and multi_array? [was: Problem compilingboost.filesystem]
Beman Dawes [EMAIL PROTECTED] writes: At 09:50 PM 7/13/2003, David Abrahams wrote: Matthias Troyer [EMAIL PROTECTED] writes: ... I hope that multi_array will also be fixed soon Somebody has to make that fix, whatever it is. multi_array used to use its own private version of iterator_adaptors. Doesn't look like there has been any activity on signals and multi_array. Are the developers aware of the need for action? multi_array is fixed. Doug, let me know if you need help with signals. -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Problem compiling boost.filesystem library
David Abrahams [EMAIL PROTECTED] writes: Please try again. The msvc bug has been worked-around. I believe I got the right fix for como, but since Greg only gives working compilers to you wink I can't tell for sure. Oh, feathers. My checkin never happened because SF CVS is broken :( -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Problems with CVS?
Beman Dawes [EMAIL PROTECTED] writes: Beman - I've read the SF docs, generated some keys, and attempted to connect to SF using SSH -- all I've got is a bunch of timeouts. That may be because their ssh has been intermittently broken, as it is right now: [EMAIL PROTECTED] /cygdrive/c/src/dcforum $ ssh -v cvs.sourceforge.net OpenSSH_3.6.1p1, SSH protocols 1.5/2.0, OpenSSL 0x0090702f debug1: Reading configuration data /home/dave/.ssh/config debug1: Rhosts Authentication disabled, originating port will not be trusted. debug1: Connecting to cvs.sourceforge.net [66.35.250.207] port 22. debug1: Connection established. debug1: identity file /home/dave/.ssh/identity type 0 debug1: identity file /home/dave/.ssh/id_rsa type 1 debug1: identity file /home/dave/.ssh/id_dsa type 2 debug1: Remote protocol version 1.99, remote software version OpenSSH_3.1p1 debug1: match: OpenSSH_3.1p1 pat OpenSSH_2.*,OpenSSH_3.0*,OpenSSH_3.1* debug1: Local version string SSH-1.5-OpenSSH_3.6.1p1 debug1: Waiting for server public key. debug1: Received server public key (768 bits) and host key (1024 bits). debug1: Host 'cvs.sourceforge.net' is known and matches the RSA1 host key. debug1: Found key in /home/dave/.ssh/known_hosts:33 debug1: Encryption type: 3des debug1: Sent encrypted session key. debug1: Installing crc compensation attack detector. debug1: Received encrypted confirmation. debug1: Trying RSA authentication with key '/home/dave/.ssh/identity' ^C (hung) [EMAIL PROTECTED] /cygdrive/c/src/dcforum $ ssh -v cvs.sourceforge.net OpenSSH_3.6.1p1, SSH protocols 1.5/2.0, OpenSSL 0x0090702f debug1: Reading configuration data /home/dave/.ssh/config debug1: Rhosts Authentication disabled, originating port will not be trusted. debug1: Connecting to cvs.sourceforge.net [66.35.250.207] port 22. debug1: Connection established. debug1: identity file /home/dave/.ssh/identity type 0 debug1: identity file /home/dave/.ssh/id_rsa type 1 debug1: identity file /home/dave/.ssh/id_dsa type 2 ssh_exchange_identification: Connection closed by remote host debug1: Calling cleanup 0x41b2a0(0x0) -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] CVS login vs Anonymous
Hello Everybody I would just like to tell everybody that Sourceforge has switched to using backup servers for the anonymous logins, so they are 24 hours behind. Ben ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Formal Review: fixed-point decimal library
Hi, this is my review of the Fixed-Point Decimal Library.
I cannot vote as it is now.
I will vote subject to the resolution of the 'scale' issue I explain below:
Problems with 'scale':
==
To understand it, I wrote the following function which just creates two
decimals given a source integer and two scales:
void Show( int s, int scn, int scm)
{
decimal n(scn, s);
decimal m(scm, s);
cout s= s endl
decscale
[ scn ,s]= n endl
[ scm ,s]= m endl
endl ;
}
When called with:
Show(numeric_limitsint::max(),9,10);
Show(9,17,18);
Show(10,17,18);
Show(0,17,18);
the output (in a system were int_type is __int64) is:
s=2147483647
[9,s]=2147483647.0
[10,s]=302809239.6290448384
s=9
[17,s]=9.0
[18,s]=9.00
s=10
[17,s]=10.0
[18,s]=-8.446744073709551616
s=0
[17,s]=0.0
[18,s]=0.00
Furhetmore, the following:
decimal eps = numeric_limitsdecimal::epsilon() ;
decimal a = eps + 9 ;
decimal b = eps + 10 ;
cout decscale
numeric_limitsdecimal::digits10
eps
a endl
b endl ;
outputs:
18
0.01
9.01
-8.446744073709551615
These results seems to clearly show that 'scale' is actually the maximum
number of decimal digits allowed IIF only one digit is used for the whole
part.
If the whole part uses more than one digit, say N, the decimal part won't be
able to represent 'scale' digits, it will only represent 'scale+1-N' digits,
as shown by the following:
max with scale=0 : 9223372036854775807
max with scale=1 : 922337203685477580.7
max with scale=2 : 92233720368547758.07
max with scale=3 : 9223372036854775.807
max with scale=4 : 922337203685477.5807
max with scale=5 : 92233720368547.75807
max with scale=6 : 9223372036854.775807
max with scale=7 : 922337203685.4775807
max with scale=8 : 92233720368.54775807
max with scale=9 : 9223372036.854775807
max with scale=10 : 922337203.6854775807
max with scale=11 : 92233720.36854775807
max with scale=12 : 9223372.036854775807
max with scale=13 : 922337.2036854775807
max with scale=14 : 92233.72036854775807
max with scale=15 : 9223.372036854775807
max with scale=16 : 922.3372036854775807
max with scale=17 : 92.23372036854775807
max with scale=18 : 9.223372036854775807
Notice that the total number of represtanble digits is scale+1.
Therefore, I really dislike the term 'scale' and its explanation.
IMO, it should be called: 'digits', and it should be defaulted to 1 +
[int_type].digits10
(i.e 19),
Additionally, numeric_limitsdecimal::digits and digits10 should be
max_scale+1,
not max_scale.
Here is a list of other minor issues:
=
I don't think that is_bounded and is_modulo should be inherited from
int_type.
is_bounded is intended to be false only for those types which can represent
numbers in any range. Even if int_type were unbounded (is_bounded=false),
decimal itself will always be bounded, so it should fix is_bounded to true.
Similarly, is_modulo tells whether the numeric type uses modulo arithmetic,
as do the unsigned integral types, yet decimal does not do that even if
int_type where unsigned, so this should be fixed to 'false'.
***
Currently, the library cannot be put in a precompiled header using BCC
because of the 'max_val,min_val' constants. This can be solved by making
those constants inlined functions.
I can send you a patch if you like.
The documentation is clearly written with some 'old' version in mind. I
think all references and comparisons with that older version should be
removed from the docs, or at least, put aside on a 'history' section.
*
IMO the documentation should begin with a brief (but complete) overview of
what is a 'fixed decimal' number, including the concept of a 'scale' (or
'digits' as I much prefer), and of rounding modes.
**
I understand why it is not supported to construct a decimal from an
int_type, but I think that construction from 'unsigned int' should be
supported since, AFAICT, the promotion rules won't give ambiguity if that
additional ctor is added.
The docs say:
The conversion will be exact if the string contains no more than scale
digits to the right of the decimal point; otherwise the value will be
rounded as specified
This is incorrect, I think. If the string contains more than (scale+1)
digits, whether to the left or right of the decimal point (or both),
rounding will ocurr.
**
Best,
Fernando Cacciola
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Problems with CVS?
If you are accessing CVS via SSH (developer), you should not have any problem. In fact CVS access has been very fast and reliable lately for me doing SSH access. Not for me. :ext: access using SSH is certainly less unreliable but it's not reliable at all. But this might be different in europe and the US (I understood from the SourceForge guys that they have mirrored servers in europe) toon ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Problem compiling boost.filesystem library
At 09:17 AM 7/14/2003, David Abrahams wrote: como-win32: C:\boost\site\boost/iterator/iterator_facade.hpp, line 285: error #864: iterator_facade is not a template BOOST_ITERATOR_FACADE_RELATION(==) msvc: C:\boost\site\boost/iterator/iterator_facade.hpp(365) : error C2899: typename cannot be used outside a template declaration Please try again. The msvc bug has been worked-around. I believe I got the right fix for como ... Thanks. I'm getting CVS timeout errors right now, so can't test yet. but since Greg only gives working compilers to you wink I can't tell for sure. Ha, ha! I just spent the last hour installing the latest como beta, and then having to back it out because it produced libcomo build errors. The recycle bin comes in handy! --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Problem compiling boost.filesystem library
At 10:06 AM 7/14/2003, David Abrahams wrote: David Abrahams [EMAIL PROTECTED] writes: Please try again. The msvc bug has been worked-around. I believe I got the right fix for como, but since Greg only gives working compilers to you wink I can't tell for sure. Oh, feathers. My checkin never happened because SF CVS is broken :( Hum... CVS problems are starting to get worrisome:-( --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Problems with CVS?
At 11:40 AM 7/14/2003, Toon Knapen wrote: If you are accessing CVS via SSH (developer), you should not have any problem. In fact CVS access has been very fast and reliable lately for me doing SSH access. Not for me. :ext: access using SSH is certainly less unreliable but it's not reliable at all. But this might be different in europe and the US (I understood from the SourceForge guys that they have mirrored servers in europe) What I'm now seeing in the US (Virginia) is SSH continuing to be very fast when it is working, but with several time periods a day when I get: cvs update: warning: unrecognized response `FATAL ERROR: Network error: Connection timed out' from cvs server cvs [update aborted]: end of file from server (consult above messages if any) --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Problems with CVS?
Toon Knapen [EMAIL PROTECTED] writes: If you are accessing CVS via SSH (developer), you should not have any problem. In fact CVS access has been very fast and reliable lately for me doing SSH access. Not for me. :ext: access using SSH is certainly less unreliable but it's not reliable at all. But this might be different in europe and the US (I understood from the SourceForge guys that they have mirrored servers in europe) I'm wondering again whether we should take up the offer to have our CVS hosted elsewhere. We have unreliable access for both developers and users at the moment. If we want to keep a repository in synch at sourceforge that should be fairly easy to automate. -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Problems with CVS?
Beman wrote: What I'm now seeing in the US (Virginia) is SSH continuing to be very fast when it is working, but with several time periods a day when I get: cvs update: warning: unrecognized response `FATAL ERROR: Network error: Connection timed out' from cvs server cvs [update aborted]: end of file from server (consult above messages if any) That's been what I've been seeing every time for the last 4 days. -- -- Marshall Marshall Clow Idio Software mailto:[EMAIL PROTECTED] Hey! Who messed with my anti-paranoia shot? ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] About member extraction
John Torjo ha escrito:
Subject: Re: [boost] About member extraction
From: Joaquín Mª López Muñoz [EMAIL PROTECTED]
Date: Mon, 14 Jul 2003 14:24:37 +0200
To: Boost mailing list [EMAIL PROTECTED]
Daryle Walker ha escrito:
But doesn't the PtrToMember template parameter already imply the
Type and Class parameters? So specifying all three would be
redundant. Could we reduce it by:
//
template typename PtrToMember
struct member_extractor
{
// Don't know if this is a real type-traits class
BOOST_STATIC_ASSERT(is_pointer_data_memberPtrToMember::value);
// The extractor traits classes aren't real (yet, maybe)
typedef get_class_typePtrToMember argument_type;
typedef get_member_typePtrToMember return_type;
return_type const operator ()( argument_type const c ) const
{ return c.*PtrToMember; }
return_type operator ()( argument_type c ) const
{ return c.*PtrToMember; }
};
Of the approaches you propose, this is the one that I like best, but
I'm afraid it cannot be implemented: Note that PtrToMember is a
*type* (something like int A::*), not a pointer to member.
member_extractor would have to defined as
template typename PtrToMember, PtrToMember ptr
struct member_extractor
and used as
member_extractorint A::*,A::x; // x is an int member of A
Actually, I think it's worse (I don't have a C++ compiler with me right now:-( )
Something in the lines of:
template typename type, typename result, result type::* ptr
struct member_extractor
Actually, extracting A and int from int A::* is easy:
#include boost/static_assert.hpp
#include boost/type_traits.hpp
using namespace std;
struct A
{
int x;
};
template typename PtrToMember
struct ptr_to_member_descriptor;
template typename Class,typename Member
struct ptr_to_member_descriptorMember Class::*
{
typedef Class class_type;
typedef Member member_type;
};
int main()
{
BOOST_STATIC_ASSERT((
boost::is_same
ptr_to_member_descriptorint A::*::class_type,
A::value));
BOOST_STATIC_ASSERT((
boost::is_same
ptr_to_member_descriptorint A::*::member_type,
int::value));
return 0;
}
The really hard part is how to obtain int A::* from A::x. I don't
think this is possible, but then again people here sometimes do magic :)
Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: About member extraction
Joaquín Mª López Muñoz [EMAIL PROTECTED] writes: The really hard part is how to obtain int A::* from A::x. I don't think this is possible, but then again people here sometimes do magic :) No, it's not possible to do at compile time. I've long had this complaint that we can't simply deduce int A::* in contexts like this one. -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: About member extraction
Joaquín Mª López Muñoz [EMAIL PROTECTED] writes: The really hard part is how to obtain int A::* from A::x. I don't think this is possible, but then again people here sometimes do magic :) No, it's not possible to do at compile time. I've long had this complaint that we can't simply deduce int A::* in contexts like this one. -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Signals and multi_array? [was: Problem compiling boost.filesystem]
On Mon, 14 Jul 2003, Beman Dawes wrote: At 09:50 PM 7/13/2003, David Abrahams wrote: Matthias Troyer [EMAIL PROTECTED] writes: ... I hope that multi_array will also be fixed soon Somebody has to make that fix, whatever it is. multi_array used to use its own private version of iterator_adaptors. Doesn't look like there has been any activity on signals and multi_array. Are the developers aware of the need for action? I'll try to work on Signals tonight. Doug ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: plans for a bugfix release ?
The following message is a courtesy copy of an article that has been posted to gmane.comp.python.c++ as well. Dominique Devriese [EMAIL PROTECTED] writes: Hi, I'm the main developer of Kig [1]. I have just committed the code for python scripting to the CVS repository Using Boost.Python? Cool! but I'm receiving bug reports from people not able to compile the new code because of the small typename problem that was fixed in Boost.Python some time ago [2] ( the fix is in CVS, right ? ). Yes. Are there any plans to release a fixed version of Boost.Python any time soon No specific plans, no. and what is the policy on Boost.Python releases in general ? In general, they are released when all of Boost is ready. I think it would be a *really* good idea for Boost to do at least one minor version release shortly after any major version release. Now that we have a reasonable testing strategy it should be relatively easy. Boost 1.30.0 went out with several bugs IIRC. thanks domi Footnotes: [1] http://edu.kde.org/kig [2] http://mail.python.org/pipermail/c++-sig/2003-May/003889.html and http://mail.python.org/pipermail/c++-sig/2003-May/003896.html Until we get our act together, I would suggest you supply people with a Boost patch. Use BOOST_DEDUCED_TYPENAME instead of typename so you don't break VC6. Sorry, -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Signals and multi_array? [was: Problem compiling boost.filesystem]
Douglas Paul Gregor [EMAIL PROTECTED] writes: Doesn't look like there has been any activity on signals and multi_array. Are the developers aware of the need for action? I'll try to work on Signals tonight. Hint: turn the body of your policies class into the body of your iterator. -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] rw_lock / next thread version
On Sunday, July 13, 2003, at 07:04 PM, Howard Hinnant wrote:
class rw_mutex
{
public:
typedef detail::read_lockrw_mutex read_lock;
typedef detail::write_lockrw_mutex write_lock;
...
};
I'm not picky about the names read_lock and write_lock. Then these
locks could have the standard scoped_lock interface. So the A
example above would look more like:
class A
{
public:
...
void read() const
{
boost::rw_mutex::read_lock lock(mut_);
...
}
void write()
{
boost::rw_mutex::write_lock lock(mut_);
...
}
...
private:
...
mutable boost::rw_mutex mut_;
};
I've been thinking about this a little more...
A (try_)scoped_lock of multiple (say 2) try_scoped_lock's would be very
handy. Something like:
template class TryLock1, class TryLock2
class lock2
{
public:
lock2(TryLock1 m1, TryLock2 m2, bool lock_it = true);
~lock2();
void lock();
bool try_lock();
void unlock();
bool locked() const;
operator int bool_type::* () const;
private:
lock2(const lock2);
lock2 operator=(const lock2);
};
(I'm not happy with the name lock2)
TryLock12 are models of scoped_try_lock, not try_mutex. lock2 will
atomically lock m1 and m2 without deadlocking (perhaps using the try
and back off algorithm).
Given lock2, and if the read/write_lock's model a try_lock, then the
example A above can be expanded to include A's operator=:
A
A::operator=(const A a)
{
typedef rw_mutex::write_lock write_lock;
typedef rw_mutex::read_lock read_lock;
typedef lock2write_lock, read_lock rw_lock;
if (this != a)
{
write_lock w(mut_, false);
read_lock r(a.mut_, false);
rw_lock lock(w, r);
// Now you can safely do assign ...
}
return *this;
}
Comments?
-Howard
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: multi_array and new iterator adaptors fix
On Monday, July 14, 2003, at 11:04 PM, David Abrahams wrote: Matthias Troyer [EMAIL PROTECTED] writes: I do not have documentation of the new version of the iterator adaptors (either my CVS checkout is messed up or maybe it is not in the CVS yet) http://tinyurl.com/gv90 http://tinyurl.com/gv91 I am not sure whether this is the correct fix. Looks good, but please always post patches as attachments. This one failed to be correctly applied on my machine. I'll remember that. Can somebody familiar with the iterator adaptor library check the patch and apply it if it is correct? Done. Thanks, Matthias ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: More compile problems
On Monday, July 14, 2003, at 11:04 PM, David Abrahams wrote:
Matthias Troyer [EMAIL PROTECTED] writes:
I now get the following compile-time error on MacOS X using g++ v.
3.1:
/Users/troyer/src/boost/boost/iterator/iterator_adaptor.hpp:282:
sizeof'
applied to incomplete type
`boost::STATIC_ASSERTION_FAILUREfalse'
Can anybody help?
What were you compiling? Reproducible case, please!
Sorry, Here is an example that shows the problem in a simple case:
#include boost/graph/adjacency_list.hpp
#include iostream
int main()
{
boost::adjacency_listboost::vecS,boost::vecS,boost::undirectedS,
boost::no_property, boost::no_property, boost::no_property,
boost::vecS g;
std::cout boost::source(*(boost::edges(g).first+4),g) std::endl;
return 0;
}
The problem is adding an integer to an edge iterator of this graph. Is
this a problem of the iterator adaptor library or of the BGL?
Matthias
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: More compile problems
Matthias Troyer [EMAIL PROTECTED] writes:
On Monday, July 14, 2003, at 11:04 PM, David Abrahams wrote:
Matthias Troyer [EMAIL PROTECTED] writes:
I now get the following compile-time error on MacOS X using g++
v. 3.1:
/Users/troyer/src/boost/boost/iterator/iterator_adaptor.hpp:282:
sizeof'
applied to incomplete type
boost::STATIC_ASSERTION_FAILUREfalse'
Can anybody help?
What were you compiling? Reproducible case, please!
Sorry, Here is an example that shows the problem in a simple case:
#include boost/graph/adjacency_list.hpp
#include iostream
int main()
{
boost::adjacency_listboost::vecS,boost::vecS,boost::undirectedS,
boost::no_property, boost::no_property, boost::no_property,
boost::vecS g;
std::cout boost::source(*(boost::edges(g).first+4),g) std::endl;
return 0;
}
The problem is adding an integer to an edge iterator of this graph. Is
this a problem of the iterator adaptor library or of the BGL?
It's a BGL problem, specifically in the way it used to label its
iterators and the way I translated them. These iterators were always
given the multi_pass_input_iterator tag, because they didn't
dereference lvalues yet copies could be guaranteed to traverse the
same elements. The old iterator adaptors were more permissive in
allowing you to take advantage of operations which weren't accounted
for by the iterator category, when defined (because we didn't have a
good way of expressing the iterator's real category anyway), and I
guess the BGL took advantage of that. I believe that the BGL's
iterators should really have a traversal category equal to that of
the iterators they're adapting. It's sort-of too bad we don't have a
way to express that.
Hmm, we could say that when you pass a tag which is just a traversal
category tag or just an access category tag as iterator_adaptor's
Category parameter, it takes the other part of the category from the
Base iterator.
Thoughts?
Who's going to fix up the graph library?
--
Dave Abrahams
Boost Consulting
www.boost-consulting.com
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Revised streambuf library
Maxim Egorushkin [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED]... I don't get the idea of reinventing the stream classes. One can use their rdbuf() member function to change the buffer. Could you please elaborate on that? True, the stream classes are thin wrappers. You don't have to use them if you don't wan't to. You have read/write member functions of your source/sink/filter concepts virtual. If one went for efficiency she would stay away from virtual functions. With such a design you leave a user no choice. Source/sink/filter classes don't have to derive from the basic implementations which use virtual functions. The adapters which call the source/sink/filters know the fully-derived types of the source/sink/filters and shouldn't have to use virtual function dispatch. There does seem to be a need for one non-inlinable function at each junction, if non-trivial filtering is taking place. I address this in the efiiciency section. There are too many adapters, IMHO. It obscures. Since each STL sequence support iterators why don't use it? Generally speaking, there should be only two adapters (input and output) that take any STL sequence represented by begin/end iterators. The factory functions address this. You just call new_source or new_sink with whatever object you want to make into a source/sink. This is less verbose than using, e.g., streambuf iterators. Also, in the case of strings, the factories return adapters which are better than generic container adapters; with SFINAE you should be able to pass a string literal to new_source. Examples: new_sourcechar(v); // simpler than using // iterator_source vectorchar::iterator (v.begin(), v.end()) new_sinkchar(sb); // simpler than using // iterator_source ostreambu_iteratorchar // ( ostreambuf_iteratorchar(sb), streambuf_iteratorchar() ); new_sourcechar(hello); // simpler than string h(hello); // iterator_source(h.begin(), h.end()). ... P.S. There is a very good article by Alexandre Duret-Lutz and Thierry Geraud Improving Object-Oriented Generic Programming. I'll look at it. Thanks. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
