RE: [boost] Eric Ford's Unit package
(Reporting including title) Sorry. Paul > This looks most interesting, and there most definitely remains a > great need for > a units handling package. > > I presume you have looked at W W Brown's SI units proposal > > http://home.fnal.gov/~wb/SItempl8.pdf > > and wonder why you rejected it and how your proposal is different. > > Paul > > PS It seems that time gets into global namespace. I agree it should not be > there but don't know how to fix it. I hit the same problem in my previous > (rudimentary) attempt with units. > > Paul A Bristow, Prizet Farmhouse, Kendal, Cumbria, LA8 8AB UK > +44 1539 561830 Mobile +44 7714 33 02 04 > Mobile mailto:[EMAIL PROTECTED] > mailto:[EMAIL PROTECTED] > > > > -Original Message- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] Behalf Of Eric Ford > > Sent: Friday, February 28, 2003 8:46 AM > > To: [EMAIL PROTECTED] > > Subject: [boost] (no subject) > > > > > > I decided that I needed a workable units library, so I wrote one. It > > allows for weakly typed dimensioned quantities (so a length divided by > > a time is automatically converted to a velocity). It also allows > > users to use strong typeing for quantities of the same dimension which > > shouldn't be confused (so you don't set a mass of apples equal to a > > mass of oranges). > > > > I attempted to make it pretty general, allowing for all the standard > > SI dimensions, a dimension for money (since that is something lots of > > people care about), and I've left one dimension avaliable for users. > > Fractional powers of dimnensions are allowed. (It also includes a > > compile-time fractions header file that might be useful for other > > purposes.) Power users could setup units using their own classes > > for the internal numeric type or even provide their own systems of units. > > > > I uploaded the first draft version of it to the vault a ebf_units.zip. > > I've included several demonstration programs to show how it can be used. > > > > example1.cpp demonstrates the use of simple SI units, including arithmetic > > on such variable and automatic conversion when multiplying or dividing > > dimensioned quantities. > > > > example2.cpp demonstrates how you could use multiple representations > > (e.g., float and double) in the same program. I've included extremely crude > > numeric type promtion mainly for demonstration purposes. > > > > example3.cpp demonstrates the use of multiple systems of units in a > > single program (e.g., including both standard/si/mks units and > > "relativistic units where the speed of light is set to unity). > > SIUnits only allows one in a program. Any conversions > > between systems must be made explicitly. > > > > example4.cpp demonstrates basic use of "qualifiers". These allow > > users to make strongly typed units, so that quantities of the same > > dimension, but different meaning can't be confused. (e.g., a mass > > of apples and a mass of oranges) > > > > example5.cpp demonstrates how a user can extend this to allow for > > some automatic conversions (e.g., automatically convert apples to > > fruits, but not vice versa, or add apples and oranges and assign > > the result to fruits). > > > > Known bugs/limitations: > > > > - In the mks_double and mks_single namespaces, time is non-standard in > > that it is capitalized unlike all the other dimenions. This is due to > > my compiler (g++ 3.0.4 on rh) having conflicts with time (which I > > beleive should be in the std namespace). Help on solving this would > > be appreciated. > > > > - Many more dimensions could be predefined in the standard system > > (basically SI). However, I'd prefer not to define every possible unit > > (like SIunits), particularlly those that are not frequently used > > (e.g., furlong) and/or those which can be easily constructed by the > > user (e.g., meters per second). > > > > - Headers for other internal numeric representations (e.g., mks_int > > ???) could be included. > > > > - Other systems (quantum, natural, planetary, ...) could be included. > > > > - The system tag classes (e.g., mks_tag, which provides for > > identifying which system of units is being used and labeling the > > dimension of quantities) could be made more intelligent. For example, > > SIUnits allows users to set the default unit that they'd like a > > quantity with a certain dimension to be displayed as. Since one can > > simply divide by whatever unit they want their result in, I don't see > > much point. However, if someone wanted this, they should be able to > > add such features by replacing the sytem tag class class without touching > > the rest. > > > > Bugfixes, improvements, encouragment, and other feedback would be welcome. > > > > > > > > > > > > > > -- > > Protect yourself from spam, > > use http://sneakemail.com > > ___ > > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost >
Re: [boost] Formal Review Requst: String Algorithm Library
Phil, On Monday 03 March 2003 23:28, Phil Nash wrote: > This request seems to have been left up in the air. I know that many are > busy with the release schedule, and there is an identified shortage of > review managers, but it would have been nice to have at least acknowledged > this request (unless it has been done offlist). Pavols request is already in the queue. This has been done off list. Thomas Boost Review Wizard -- 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
[boost] Does this compiler need configuring?
I'm trying to use the more_io.zip stuff currently under review with a
copy of Metrowerks CodeWarrior Developement Studio (Mac OS X Edition,
v8). I haven't got anything to compile. I get errors like:
//==
Error : undefined identifier 'ptrdiff_t'
(included from:
config.hpp:57
array_stream.hpp:15
array_stream_test.cpp:12)
suffix.hpp line 245 namespace std { using ::ptrdiff_t; using
::size_t; }
Error : undefined identifier 'strlen'
(included from:
minimal.hpp:45
array_stream_test.cpp:13)
execution_monitor.cpp line 41 namespace std { using ::strlen; using
::strncat; }
Error : the file 'wtypes.h' cannot be opened
(included from:
minimal.hpp:45
array_stream_test.cpp:13)
execution_monitor.cpp line 48 #include
Error : the file 'winbase.h' cannot be opened
(included from:
minimal.hpp:45
array_stream_test.cpp:13)
execution_monitor.cpp line 49 #include
Error : the file 'excpt.h' cannot be opened
(included from:
minimal.hpp:45
array_stream_test.cpp:13)
execution_monitor.cpp line 50 #include
Error : the file 'eh.h' cannot be opened
(included from:
minimal.hpp:45
array_stream_test.cpp:13)
execution_monitor.cpp line 51 #include
Error : declaration syntax error
(included from:
minimal.hpp:45
array_stream_test.cpp:13)
execution_monitor.cpp line 108 void ms_se_trans_func( unsigned int
id, _EXCEPTION_POINTERS * exps );
Error : undefined identifier '_set_se_translator'
(included from:
minimal.hpp:45
array_stream_test.cpp:13)
execution_monitor.cpp line 148 _set_se_translator(
detail::ms_se_trans_func );
Error : declaration syntax error
(included from:
minimal.hpp:45
array_stream_test.cpp:13)
execution_monitor.cpp line 355 ms_se_trans_func( unsigned int id,
_EXCEPTION_POINTERS* /* exps */ )
Error : declaration syntax error
(included from:
minimal.hpp:45
array_stream_test.cpp:13)
execution_monitor.cpp line 356 {
Error : declaration syntax error
(included from:
minimal.hpp:45
array_stream_test.cpp:13)
execution_monitor.cpp line 357 throw ms_se_exception( id );
Error : undefined identifier 'EXCEPTION_ACCESS_VIOLATION'
(included from:
minimal.hpp:45
array_stream_test.cpp:13)
execution_monitor.cpp line 367 case EXCEPTION_ACCESS_VIOLATION:
Error : undefined identifier 'EXCEPTION_ILLEGAL_INSTRUCTION'
(included from:
minimal.hpp:45
array_stream_test.cpp:13)
execution_monitor.cpp line 372 case EXCEPTION_ILLEGAL_INSTRUCTION:
Error : undefined identifier 'EXCEPTION_PRIV_INSTRUCTION'
(included from:
minimal.hpp:45
array_stream_test.cpp:13)
execution_monitor.cpp line 377 case EXCEPTION_PRIV_INSTRUCTION:
Error : undefined identifier 'EXCEPTION_IN_PAGE_ERROR'
(included from:
minimal.hpp:45
array_stream_test.cpp:13)
execution_monitor.cpp line 382 case EXCEPTION_IN_PAGE_ERROR:
Error : undefined identifier 'EXCEPTION_STACK_OVERFLOW'
(included from:
minimal.hpp:45
array_stream_test.cpp:13)
execution_monitor.cpp line 387 case EXCEPTION_STACK_OVERFLOW:
Error : undefined identifier 'EXCEPTION_DATATYPE_MISALIGNMENT'
(included from:
minimal.hpp:45
array_stream_test.cpp:13)
execution_monitor.cpp line 393 case EXCEPTION_DATATYPE_MISALIGNMENT:
Error : undefined identifier 'EXCEPTION_INT_DIVIDE_BY_ZERO'
(included from:
minimal.hpp:45
array_stream_test.cpp:13)
execution_monitor.cpp line 398 case EXCEPTION_INT_DIVIDE_BY_ZERO:
Error : undefined identifier 'EXCEPTION_INT_OVERFLOW'
(included from:
minimal.hpp:45
array_stream_test.cpp:13)
execution_monitor.cpp line 403 case EXCEPTION_INT_OVERFLOW:
Error : undefined identifier 'EXCEPTION_ARRAY_BOUNDS_EXCEEDED'
(included from:
minimal.hpp:45
array_stream_test.cpp:13)
execution_monitor.cpp line 408 case EXCEPTION_ARRAY_BOUNDS_EXCEEDED:
Error : undefined identifier 'EXCEPTION_FLT_DIVIDE_BY_ZERO'
(included from:
minimal.hpp:45
array_stream_test.cpp:13)
execution_monitor.cpp line 413 case EXCEPTION_FLT_DIVIDE_BY_ZERO:
Error : undefined identifier 'EXCEPTION_FLT_STACK_CHECK'
(included from:
minimal.hpp:45
array_stream_test.cpp:13)
execution_monitor.cpp line 418 case EXCEPTION_FLT_STACK_CHECK:
Error : undefined identifier 'EXCEPTION_FLT_DENORMAL_OPERAND'
(included from:
minimal.hpp:45
array_stream_test.cpp:13)
execution_monitor.cpp line 423 case EXCEPTION_FLT_DENORMAL_OPERAND:
Error : undefined identifier 'EXCEPTION_FLT_INEXACT_RESULT'
(included from:
minimal.hpp:45
array_stream_test.cpp:13)
execution_monitor.cpp line 424 case EXCEPTION_FLT_INEXACT_RESULT:
Error : undefined identifier 'EXCEPTION_FLT_INVALID_OPERATION'
(included from:
minimal.hpp:45
array_stream_test.cpp:13)
execution_monitor.cpp line 425 case EXCEPTION_FLT_INVALID_OPERATION:
Error : undefined identifier 'EXCEPTION_FLT_OVERFLOW'
(included from:
minimal.hpp:45
array_stream_test.cpp:13)
execution_monitor.cpp line 426 case EXCEPTION_FLT_OVERFLOW:
Error : undefined identifier 'EXCEPTION_FLT_UNDERFLOW'
(included from:
mi
[boost] will lexical_cast improvements be in 1.30.0?
http://lists.boost.org/MailArchives/boost/msg36221.php references an improved lexical_cast. Will it or a similar improvement will be included in the 1.30 release? Specifically, I'm looking for point 2: casting between C-style strings and std::strings that accepts spaces within the text instead of emitting the bad lexical cast error. Dave -- Dave Gomboc M.Sc. Student1-41 Athabasca Hall Department of Computing Science Edmonton, Alberta, University of AlbertaCanada T6G 2E5 ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Sockets - what's the latest?
On Mon, 3 Mar 2003 18:17:45 +0100, Wesley W. Terpstra <[EMAIL PROTECTED] darmstadt.de> wrote: How about BEEP ? It's not only P2P protocol, but also refactoring of some protocols. #beepcore.org http://www.beepcore.org/ #XML Watch: Bird's-eye BEEP Part 1 of an introduction to the Blocks Extensible Exchange Protocol standard of the IETF http://www-106.ibm.com/developerworks/xml/library/x-beep/ Part 2 of an introduction to the Blocks Extensible Exchange Protocol standard http://www-106.ibm.com/developerworks/xml/library/x-beep2.html #Beep BEEP! http://www.xml.com/pub/a/2002/10/16/ends.html On Wed, Feb 12, 2003 at 06:11:59PM -0500, Jason House wrote: Once I heard there was a generic socket library in development, I thought I'd add a quick feature request. I would like to see the ability to have multiple streams through the same socket. This boils down to providing two distinct benefits. 1: Programs can easily perform complex communications over a single port. 2: Without multiple streams, problems can occur when there are multiple clients behind a proxy connecting to a host outside of the proxy. If the client only forms a single connection to the host, there won't be a problem because the random source port will differentiate each stream. So, when multiple clients connect to a host from behind a proxy, the host can only differentiate each stream by the random source port. So, when the clients form a second connection to the host, each stream gets differentiated from each other, but there is no mapping of random source port ot the distinct client. What you are asking for here is: http://chorus.sourceforge.net/ ... in my slightly biased opinion. ;-) This gives you a stackable transport framework which includes (among other things) a multiplexed channel. This project is still really new, but is shaping up nicely. However, it has no relation to boost and is primarily targetted at building distributed hash tables (p2p apps) that can go through any data channel. -- shelarcy <[EMAIL PROTECTED]> http://page.freett.com/shelarcy/ ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] boost::bind - simple test case does not work...
On Monday 03 March 2003 05:03 pm, Marc Jacobs wrote: > bind( &X::f, &x, _1 )( 6 ); // error! You can't pass rvalues to boost::bind function objects, because of the forwarding problem in C++. If you use this it should work: int i = 6; bind( &X::f, &x, _1 )( i ); There's a good description of the forwarding problem here: http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/papers/2002/n1385.htm Doug ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Formal Review for Boost I/O Library
I vote for acceptance of this package (from reading the documentation and
glancing at the code and examples - which could be more commented?).
I noted two tiny mistakes in the documentation streambuf_wrapping.html
in
Rationale
... is defined with the appropiate <<< mis-spelt
appropriate
..accessing that stream buffer, and checking if that stream didn't switch to an
external stream buffer.
'if that' doesn't make sense. 'if' or 'that'?
(You might also like to consider adding the following
// Usage: out << automatic ... << noadjust
using std::ios_base;
inline ios_base& __cdecl automatic(ios_base& _I)
{_I.unsetf(ios_base::floatfield); // Neither fixed nor scientific.
return (_I); // This is the default.
}
inline ios_base& __cdecl noadjust(ios_base& _I)
{_I.unsetf(ios_base::adjustfield); // Neither left, right nor internal.
return (_I); // This is the default.
}
two helpful manipulators which are needed to avoid using 'unsetf' a less
familiar feature that naive users should not need to know about to get back to
the default floating point layout.
Paul
Paul A Bristow, Prizet Farmhouse, Kendal, Cumbria, LA8 8AB UK
+44 1539 561830 Mobile +44 7714 33 02 04
Mobile mailto:[EMAIL PROTECTED]
mailto:[EMAIL PROTECTED]
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] Behalf Of Ed Brey
> Sent: Thursday, February 27, 2003 5:00 AM
> To: [EMAIL PROTECTED]
> Subject: [boost] Formal Review for Boost I/O Library
>
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] (no subject)
This looks most interesting, and there most definitely remains a great need for a units handling package. I presume you have looked at W W Brown's SI units proposal http://home.fnal.gov/~wb/SItempl8.pdf and wonder why you rejected it and how your proposal is different. Paul PS It seems that time gets into global namespace. I agree it should not be there but don't know how to fix it. I hit the same problem in my previous (rudimentary) attempt with units. Paul A Bristow, Prizet Farmhouse, Kendal, Cumbria, LA8 8AB UK +44 1539 561830 Mobile +44 7714 33 02 04 Mobile mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Behalf Of Eric Ford > Sent: Friday, February 28, 2003 8:46 AM > To: [EMAIL PROTECTED] > Subject: [boost] (no subject) > > > I decided that I needed a workable units library, so I wrote one. It > allows for weakly typed dimensioned quantities (so a length divided by > a time is automatically converted to a velocity). It also allows > users to use strong typeing for quantities of the same dimension which > shouldn't be confused (so you don't set a mass of apples equal to a > mass of oranges). > > I attempted to make it pretty general, allowing for all the standard > SI dimensions, a dimension for money (since that is something lots of > people care about), and I've left one dimension avaliable for users. > Fractional powers of dimnensions are allowed. (It also includes a > compile-time fractions header file that might be useful for other > purposes.) Power users could setup units using their own classes > for the internal numeric type or even provide their own systems of units. > > I uploaded the first draft version of it to the vault a ebf_units.zip. > I've included several demonstration programs to show how it can be used. > > example1.cpp demonstrates the use of simple SI units, including arithmetic > on such variable and automatic conversion when multiplying or dividing > dimensioned quantities. > > example2.cpp demonstrates how you could use multiple representations > (e.g., float and double) in the same program. I've included extremely crude > numeric type promtion mainly for demonstration purposes. > > example3.cpp demonstrates the use of multiple systems of units in a > single program (e.g., including both standard/si/mks units and > "relativistic units where the speed of light is set to unity). > SIUnits only allows one in a program. Any conversions > between systems must be made explicitly. > > example4.cpp demonstrates basic use of "qualifiers". These allow > users to make strongly typed units, so that quantities of the same > dimension, but different meaning can't be confused. (e.g., a mass > of apples and a mass of oranges) > > example5.cpp demonstrates how a user can extend this to allow for > some automatic conversions (e.g., automatically convert apples to > fruits, but not vice versa, or add apples and oranges and assign > the result to fruits). > > Known bugs/limitations: > > - In the mks_double and mks_single namespaces, time is non-standard in > that it is capitalized unlike all the other dimenions. This is due to > my compiler (g++ 3.0.4 on rh) having conflicts with time (which I > beleive should be in the std namespace). Help on solving this would > be appreciated. > > - Many more dimensions could be predefined in the standard system > (basically SI). However, I'd prefer not to define every possible unit > (like SIunits), particularlly those that are not frequently used > (e.g., furlong) and/or those which can be easily constructed by the > user (e.g., meters per second). > > - Headers for other internal numeric representations (e.g., mks_int > ???) could be included. > > - Other systems (quantum, natural, planetary, ...) could be included. > > - The system tag classes (e.g., mks_tag, which provides for > identifying which system of units is being used and labeling the > dimension of quantities) could be made more intelligent. For example, > SIUnits allows users to set the default unit that they'd like a > quantity with a certain dimension to be displayed as. Since one can > simply divide by whatever unit they want their result in, I don't see > much point. However, if someone wanted this, they should be able to > add such features by replacing the sytem tag class class without touching > the rest. > > Bugfixes, improvements, encouragment, and other feedback would be welcome. > > > > > > > -- > Protect yourself from spam, > use http://sneakemail.com > ___ > Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost > ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Draft dimensions and units library uploaded
I posted a message regarding this earlier, but somehow I left the subject line blank. Since I know there was previously a great deal of interest in a dimensions and units library, I'm guessing the lack of replies is due to my omission of a subject line. The message with a description of the code is avaliable at: http://aspn.activestate.com/ASPN/Mail/Message/boost/1555707 and the current code for the library is avaliable at: http://groups.yahoo.com/group/boost/files/ebf_units.zip Sorry for the confusion, Eford BTW- Moderators: this upload effectively superceeds my previous upload in the qualified_unit folder (many additional features, as well as replacing uses of deprecated boost macros). But my change of email address seems to prohibit my deleting of my own uploads. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Formal Review Requst: String Algorithm Library
This request seems to have been left up in the air. I know that many are busy with the release schedule, and there is an identified shortage of review managers, but it would have been nice to have at least acknowledged this request (unless it has been done offlist). Personally I am very keen to see a library like this included - Although generally quite simple I have to rewrite many of these algorithms for each project I work on (or copy from one to the other when I can get round IPR issues). Having said that I haven't looked at Pavol's submission in depth yet - but would certainly make a point of doing so for a review. Regards, [)o IhIL.. - Original Message - From: "Pavol Droba" <[EMAIL PROTECTED]> To: "Boost mailing list" <[EMAIL PROTECTED]> Sent: Wednesday, February 26, 2003 5:39 PM Subject: [boost] Formal Review Requst: String Algorithm Library > Hi Boosters, > > I'd like to ask for scheduling a formal review for the string algorithm library. > > It is mostly finished ( only some final polishing of the documentation is in progress ). > > Its implementation can be found in the boost sandbox. > ( Is it required to upload it to yahoo groups before the review is scheduled? ) > > Overview: >"The String Algorithm Library provides a generic implementation of various string-related > algorithms which are missing in STL. It is an extension to the algorithms library of STL. > Algorithms in this library include trimming, case conversion, predicates and find/replace > functions. All of them come in different variants so it is easier to choose the best fit for > a particular need. " > > Regards, > > Pavol > ___ > Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost > ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] boost::bind - simple test case does not work...
While I've successfully used boost::bind before, I cannot seem to get this
simple test case to work.
#include
#include
using namespace boost;
using namespace std;
struct X
{
void f( int i )
{
cout << i << "\n";
}
};
int main( int argc, char * argv[] )
{
X x;
bind( &X::f, &x, 6 )(); // works
bind( &X::f, &x, _1 )( 6 ); // error!
return 0;
}
It fails during compilation with the following error messages:
callback.cpp: In function `int main (int, char **)':
callback.cpp:20: no match for call to `(boost::_bi::bind_t, boost::_bi::list2, boost::arg<1> > >) (int)'
/usr/local/include/boost/bind/bind_template.hpp:19: candidates are: typename
boost::_bi::result_traits::type boost::_bi::bind_t::operator() () [with R = void, F =
boost::_mfi::mf1, L = boost::_bi::list2, boost::arg<1> >]
/usr/local/include/boost/bind/bind_template.hpp:25: typename
boost::_bi::result_traits::type boost::_bi::bind_t::operator() () const [with R = void,
F = boost::_mfi::mf1, L =
boost::_bi::list2, boost::arg<1> >]
/usr/local/include/boost/bind/bind_template.hpp:31: typename
boost::_bi::result_traits::type boost::_bi::bind_t::operator() (A1 &) [with A1 = int, R
= void, F = boost::_mfi::mf1, L =
boost::_bi::list2, boost::arg<1>
>]
/usr/local/include/boost/bind/bind_template.hpp:37: typename
boost::_bi::result_traits::type boost::_bi::bind_t::operator() (A1 &) const [with A1 =
int, R = void, F = boost::_mfi::mf1, L =
boost::_bi::list2,
boost::arg<1> >]
Suggestions?
Marc
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] 1.30.0 branch-for-release complete
Is it time we introduced beta releases into the release procedure? It seems to me that it would be a good idea to tar up 1.30.0 RC and give everyone a chance to try it out and report feedback without having to use CVS. I know CVS puts me off. Questions include How much of a hassle would it be for someone? (Beman?) How many extra people would be encourage to test the beta? How many beta releases should we do? Mark ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Formal Review for Boost I/O Library
Keith Burton wrote: > > In lieu of a zip file , I would vote for inclusion on the basis of > previous use of the io state savers The subject of this review is the delta between the previous accepted I/O library and Daryle's updated version. The state savers are part of the existing and are not up for review (although comments are always welcome). The file more_io.zip contains only elements of the I/O library that are new and hence up for review. http://groups.yahoo.com/group/boost/files/more_io.zip ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] once_flag
Noel Yap said: > Just wondering, looking at boost/thread/once.hpp, I see that once_flag > is typedef'd to long, why not bool or char to take up less memory? For compatibility with the underlying system APIs. -- William E. Kempf ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: Formal Review for Boost I/O Library
Many thanks - this took all of several seconds to download - (and could easily have been added as an attachment). CVS undoubtledly has its benefits, but this is much more convenient. Paul > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Behalf Of Ed Brey > Sent: Monday, March 03, 2003 5:16 PM > To: [EMAIL PROTECTED] > Subject: [boost] Re: Formal Review for Boost I/O Library > > > Paul A. Bristow wrote: > > For those of us who find CVS difficult, a zip of the whole > > modest-sized package would be more friendly. > > Daryle has posted a zip file containing the submission at this URL: > > http://groups.yahoo.com/group/boost/files/more_io.zip > > > ___ > Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost > ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] once_flag
Just wondering, looking at boost/thread/once.hpp, I see that once_flag is typedef'd to long, why not bool or char to take up less memory? Thanks, Noel -- NOTICE: If received in error, please destroy and notify sender. Sender does not waive confidentiality or privilege, and use is prohibited. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] RC_1_30_0 compile error with SGI MIPSpro Compilers
The regression tests (version 3) are running, and it may be a while
before they are done. In the meantime, the results of preprocessing the
file give more details of the error:
cc-1108 CC: ERROR File =
/mnt/vracs001/home9/users/patrick/src/Boost/boost-1.30.0-cvs/boost/type_traits/is_base_and_derived.hpp,
Line = 106
The indicated expression must have pointer-to-function type.
static const bool value = sizeof(bd_helper ::check(Host(),
0)) == sizeof(type_traits::yes_type);
^
The code in question comes from the following:
template
struct bd_helper
{
template
static type_traits::yes_type check(D const volatile *, T);
static type_traits::no_type check(B const volatile *, int);
};
template
struct is_base_and_derived_impl2
{
struct Host
{
operator B const volatile *() const;
operator D const volatile *();
};
static const bool value = sizeof(bd_helper ::check(Host(), 0))
== sizeof(type_traits::yes_type);
};
This looks okay to me (though I am not familiar with the Boost
internals), but I think I have seen a similar error with this compiler.
A cast might have been necessary to coerce the compiler into dealing with
the code, but I'm guessing that is not appropriate in this case.
-Patrick
David Abrahams wrote:
Patrick Hartling <[EMAIL PROTECTED]> writes:
Is there a recommended procedure I can follow for tracking this down
and submitting a patch?
I would start by preprocessing the file to see what's going on behind
that macro, then tweaking it until it works.
For example, I was considering running the regression tests for the
MIPSpro Compilers. Would that be helpful,
Very much so
or is someone on the Boost team on top of this already?
Not that I know of.
--
Patrick L. Hartling | Research Assistant, VRAC
[EMAIL PROTECTED]| 2624 Howe Hall: 1.515.294.4916
http://www.137.org/patrick/ | http://www.vrac.iastate.edu/
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Proposal: strings as template parameters?
Robert Klarer wrote: There was some discussion among the extensions subgroup of the C++ standard committee about the question of how the language might be extended to allow string literals to be used as template arguments. That discussion was inconclusive. It seems to me that the root of the problem is that C-style strings, and hence string literals, are not first-class builtin types in C++. I've been experimenting with one possible solution to that problem: I've (partially) implemented a "static_string" library and uploaded it to the 'Files' section of Boost's Yahoo Group. Here is the abstract from the (also partial) introductory document: "The static_string C++ library is an alternative to both string literals and the standard C++ type const std::basic_string. Any operation that can be performed upon a const std::basic_string object at runtime can be performed by the static_string library. Furthermore, the static_string library implements a number of metafunctions that allow these operations to be performed at program compile time. The static_string library is significantly more efficient in its use of both time and space than const std::basic_string." The static_string library allows strings to be represented by types, so that they can be used as template arguments. The syntax for using static_string is awkward, but a language extension that would make a library like static_string convenient to use might be worth considering as an alternative to the wholesale introduction of string-literals-as-template-arguments to the core language. A woefully incomplete version of the static_string library can be found at: http://groups.yahoo.com/group/boost/files/static_string.zip I guess it's not possible to generate the character sequence out of a string literal with the Boost Preprocessor library? That'd make this a whole lot more convenient to use. Dirk Gerrits ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Formal Review for Boost I/O Library
Another CVS challenged voice In lieu of a zip file , I would vote for inclusion on the basis of previous use of the io state savers Keith Burton ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Boost.signal with gcc 3.3 or gcc 3.4
Gabriel Dos Reis <[EMAIL PROTECTED]> writes: | [EMAIL PROTECTED] (Lars Gullik Bjønnes) writes: | | | g++ -g -O -W -Wall -Winline -c signal_base.ii | | ../../../../boost/boost/function/function_template.hpp: In constructor | | ` | |boost::signals::detail::signal_base_impl::signal_base_impl(const | |boost::function2 >&)': | | ../../../../boost/boost/function/function_template.hpp:389: internal | | compiler error: in | |c_expand_expr, at c-common.c:4319 | | | | This is with current boost cvs. (~1.30.0 I guess) | | It would be helpful if you could report this to GCC developers. I have done so several weeks ago: PR 9524 I also see that this pr has been updated lately to reflect that this is an regression from 3.2. and thus of high pri for 3.3. -- Lgb ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Sockets - what's the latest?
On Wed, Feb 12, 2003 at 06:11:59PM -0500, Jason House wrote: > Once I heard there was a generic socket library in development, I thought I'd add > a quick feature request. I would like to see the ability to have multiple > streams through the same socket. > > This boils down to providing two distinct benefits. > 1: Programs can easily perform complex communications over a single port. > 2: Without multiple streams, problems can occur when there are multiple clients > behind a proxy connecting to a host outside of the proxy. If the client only > forms a single connection to the host, there won't be a problem because the random > source port will differentiate each stream. So, when multiple clients connect to > a host from behind a proxy, the host can only differentiate each stream by the > random source port. So, when the clients form a second connection to the host, > each stream gets differentiated from each other, but there is no mapping of random > source port ot the distinct client. What you are asking for here is: http://chorus.sourceforge.net/ ... in my slightly biased opinion. ;-) This gives you a stackable transport framework which includes (among other things) a multiplexed channel. This project is still really new, but is shaping up nicely. However, it has no relation to boost and is primarily targetted at building distributed hash tables (p2p apps) that can go through any data channel. --- Wes ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Formal Review for Boost I/O Library
Paul A. Bristow wrote: > For those of us who find CVS difficult, a zip of the whole > modest-sized package would be more friendly. Daryle has posted a zip file containing the submission at this URL: http://groups.yahoo.com/group/boost/files/more_io.zip ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Boost.signal with gcc 3.3 or gcc 3.4
On Monday 03 March 2003 11:42 am, Lars Gullik Bjønnes wrote: > I have been trying, but gcc failes with an ICE. Of course gcc should > not segfault, but I am trying to find out if it is an segfault on > valid code or if it is an segfault on illegal code. > I have not been successful on finding a small testcase so far... I believe it is valid code. The EDG front end accepts it on its strictest mode, if that means anything. Doug ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Boost.signal with gcc 3.3 or gcc 3.4
[EMAIL PROTECTED] (Lars Gullik Bjønnes) writes: | g++ -g -O -W -Wall -Winline -c signal_base.ii | ../../../../boost/boost/function/function_template.hpp: In constructor | ` |boost::signals::detail::signal_base_impl::signal_base_impl(const |boost::function2 >&)': | ../../../../boost/boost/function/function_template.hpp:389: internal | compiler error: in |c_expand_expr, at c-common.c:4319 | | This is with current boost cvs. (~1.30.0 I guess) It would be helpful if you could report this to GCC developers. -- Gaby ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] RC_1_30_0 compile error with SGI MIPSpro Compilers
Patrick Hartling <[EMAIL PROTECTED]> writes: > Is there a recommended procedure I can follow for tracking this down > and submitting a patch? I would start by preprocessing the file to see what's going on behind that macro, then tweaking it until it works. > For example, I was considering running the regression tests for the > MIPSpro Compilers. Would that be helpful, Very much so > or is someone on the Boost team on top of this already? Not that I know of. -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Proposal: strings as template parameters?
I took a quick look at http://groups.yahoo.com/group/boost/files/static_string.zip Basically it treats static string kind of like a tuple of all characters? That seems like a reasonable implementation. (As basic idea, I have not truly reviewed it). Of course, language support for making usage easier would be nice. I would have to imagine that a proposal for support of type lists/tuples is under way... it would be interesting if since normal strings (char *) are not supported if a string was expanded into a list of characters when used in templates. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] RC_1_30_0 compile error with SGI MIPSpro Compilers
I just grabbed the latest code from the RC_1_30_0 branch, and I got a compile failure when building the Boost.Filesystem library with the MIPSpro Compilers (7.3.1.3m): mipspro-C++-action ../../../libs/filesystem/build/bin/libfs.a/mipspro/debug/exception.o cc-1108 CC: ERROR File = /mnt/vracs001/home9/users/patrick/src/Boost/boost-1.30.0-cvs/boost/type_traits/is_base_and_derived.hpp, Line = 106 The indicated expression must have pointer-to-function type. BOOST_STATIC_CONSTANT(bool, value = ^ 1 error detected in the compilation of "../src/exception.cpp". "/usr/bin/CC" -c \ \ \ "-nostdinc" "-LANG:std" "-OPT:Olimit=0" "-OPT:IEEE_NaN_inf=ON" "-no_auto_include" "-n32" "-mips3" "-O0" "-g" "-INLINE:none" \ \ "-I../../../libs/filesystem/build" "-I/mnt/vracs001/home9/users/patrick/src/Boost/boost-1.30.0-cvs" \ "-I/usr/include/CC" "-I//usr/include/CC" "-I/mnt/vracs001/home9/users/patrick/src/Boost/boost-1.30.0-cvs/boost/compatibility/cpp_c_headers" \ "-I/usr/include" "-I//usr/include" "-I/mnt/vracs001/home9/users/patrick/src/Boost/boost-1.30.0-cvs" \ -o "../../../libs/filesystem/build/bin/libfs.a/mipspro/debug/exception.o" \ "../src/exception.cpp" ...failed mipspro-C++-action ../../../libs/filesystem/build/bin/libfs.a/mipspro/debug/exception.o... Is there a recommended procedure I can follow for tracking this down and submitting a patch? For example, I was considering running the regression tests for the MIPSpro Compilers. Would that be helpful, or is someone on the Boost team on top of this already? -Patrick -- Patrick L. Hartling | Research Assistant, VRAC [EMAIL PROTECTED]| 2624 Howe Hall: 1.515.294.4916 http://www.137.org/patrick/ | http://www.vrac.iastate.edu/ ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Boost.signal with gcc 3.3 or gcc 3.4
I am well aware that gcc 3.3/3.4 has not been released yet, but I'd like to know if anyone has tried Boost with any of those versions (from gcc cvs obviously). I have been trying, but gcc failes with an ICE. Of course gcc should not segfault, but I am trying to find out if it is an segfault on valid code or if it is an segfault on illegal code. I have not been successful on finding a small testcase so far... g++ -g -O -W -Wall -Winline -c signal_base.ii ../../../../boost/boost/function/function_template.hpp: In constructor ` boost::signals::detail::signal_base_impl::signal_base_impl(const boost::function2 >&)': ../../../../boost/boost/function/function_template.hpp:389: internal compiler error: in c_expand_expr, at c-common.c:4319 This is with current boost cvs. (~1.30.0 I guess) -- Lgb ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Formal Review for Boost I/O Library
For those of us who find CVS difficult, a zip of the whole modest-sized package would be more friendly. Paul Paul A Bristow, Prizet Farmhouse, Kendal, Cumbria, LA8 8AB UK +44 1539 561830 Mobile +44 7714 33 02 04 Mobile mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Behalf Of Ed Brey > Sent: Thursday, February 27, 2003 5:00 AM > To: [EMAIL PROTECTED] > Subject: [boost] Formal Review for Boost I/O Library > > > The formal review for the updated Boost I/O Library begins today and > runs through March 7. > > 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. > 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). > > The stream buffer classes are new and deserve primary attention in > this review. > > You can obtain the latest version of the library from the CVS > sandbox. For web access to the library, use this URLs: > > http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/boost-sandbox/boost-san dbox/boost/io/ http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/boost-sandbox/boost-sandbox/libs/ io/ Please state in review comments how you reviewed the library and whether the you think the library should be accepted into Boost. Further guidelines for writing reviews can be found on the website at: http://www.boost.org/more/formal_review_process.htm#Comments Thanks, Ed (Review Manager) ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Proposal: strings as template parameters?
There was some discussion among the extensions subgroup of the C++ standard committee about the question of how the language might be extended to allow string literals to be used as template arguments. That discussion was inconclusive. It seems to me that the root of the problem is that C-style strings, and hence string literals, are not first-class builtin types in C++. I've been experimenting with one possible solution to that problem: I've (partially) implemented a "static_string" library and uploaded it to the 'Files' section of Boost's Yahoo Group. Here is the abstract from the (also partial) introductory document: "The static_string C++ library is an alternative to both string literals and the standard C++ type const std::basic_string. Any operation that can be performed upon a const std::basic_string object at runtime can be performed by the static_string library. Furthermore, the static_string library implements a number of metafunctions that allow these operations to be performed at program compile time. The static_string library is significantly more efficient in its use of both time and space than const std::basic_string." The static_string library allows strings to be represented by types, so that they can be used as template arguments. The syntax for using static_string is awkward, but a language extension that would make a library like static_string convenient to use might be worth considering as an alternative to the wholesale introduction of string-literals-as-template-arguments to the core language. A woefully incomplete version of the static_string library can be found at: http://groups.yahoo.com/group/boost/files/static_string.zip ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Increase in binary size
I see that when upgrading LyX to use the upcomming 1.30.0 release instead of the 1.29.0 release our binary size increases by more than 125kB... I have not tried to figure out where that increase comes from, but the usual suspecs are regex, function and signal since that is what we use most. The bloat could very well be placed all over, a bit here and a bit there. Kindo hard to find out. FYI! List of header files changed between 1.29 and 1.30 as seen by LyX: So the additional 125kB must be hidden somewhere in here... M boost/any.hpp M boost/array.hpp M boost/assert.hpp M boost/bind.hpp M boost/call_traits.hpp M boost/cast.hpp M boost/checked_delete.hpp M boost/compose.hpp M boost/concept_archetype.hpp M boost/concept_check.hpp M boost/config.hpp M boost/counting_iterator.hpp M boost/crc.hpp M boost/cregex.hpp M boost/cstdint.hpp M boost/cstdlib.hpp M boost/current_function.hpp M boost/format.hpp M boost/function.hpp M boost/functional.hpp M boost/generator_iterator.hpp A boost/get_pointer.hpp M boost/integer.hpp M boost/integer_fwd.hpp M boost/integer_traits.hpp M boost/intrusive_ptr.hpp M boost/iterator.hpp M boost/iterator_adaptors.hpp M boost/last_value.hpp M boost/lexical_cast.hpp M boost/limits.hpp M boost/mem_fn.hpp M boost/multi_array.hpp A boost/next_prior.hpp A boost/noncopyable.hpp M boost/operators.hpp M boost/permutation_iterator.hpp M boost/preprocessor.hpp M boost/progress.hpp M boost/property_map.hpp M boost/property_map_iterator.hpp M boost/rational.hpp M boost/ref.hpp M boost/regex.h M boost/regex.hpp M boost/regex_fwd.hpp M boost/scoped_array.hpp M boost/scoped_ptr.hpp M boost/shared_array.hpp M boost/shared_ptr.hpp M boost/signal.hpp M boost/smart_ptr.hpp M boost/static_assert.hpp M boost/throw_exception.hpp M boost/timer.hpp M boost/token_functions.hpp M boost/token_iterator.hpp M boost/tokenizer.hpp M boost/type_traits.hpp M boost/utility.hpp M boost/utility_fwd.hpp M boost/version.hpp M boost/visit_each.hpp M boost/weak_ptr.hpp M boost/bind/placeholders.hpp M boost/config/posix_features.hpp M boost/config/select_stdlib_config.hpp M boost/config/suffix.hpp M boost/config/compiler/common_edg.hpp M boost/config/compiler/gcc.hpp M boost/config/compiler/hp_acc.hpp M boost/config/compiler/intel.hpp M boost/config/compiler/metrowerks.hpp M boost/config/compiler/sunpro_cc.hpp M boost/config/compiler/vacpp.hpp M boost/config/compiler/visualc.hpp M boost/config/platform/bsd.hpp M boost/config/platform/cygwin.hpp M boost/config/platform/hpux.hpp M boost/config/platform/macos.hpp M boost/config/platform/win32.hpp M boost/config/stdlib/dinkumware.hpp M boost/config/stdlib/roguewave.hpp M boost/config/stdlib/stlport.hpp M boost/detail/allocator.hpp M boost/detail/atomic_count.hpp M boost/detail/atomic_count_win32.hpp M boost/detail/iterator.hpp M boost/detail/lightweight_mutex.hpp M boost/detail/lwm_win32.hpp M boost/detail/lwm_win32_cs.hpp M boost/detail/shared_count.hpp A boost/detail/workaround.hpp M boost/format/feed_args.hpp M boost/format/format_class.hpp R boost/format/format_config.hpp M boost/format/format_fwd.hpp M boost/format/format_implementation.hpp M boost/format/free_funcs.hpp M boost/format/group.hpp M boost/format/internals.hpp A boost/format/macros_default.hpp A boost/format/macros_stlport.hpp M boost/format/parsing.hpp M boost/function/function0.hpp M boost/function/function1.hpp M boost/function/function10.hpp M boost/function/function2.hpp M boost/function/function3.hpp M boost/function/function4.hpp M boost/function/function5.hpp M boost/function/function6.hpp M boost/function/function7.hpp M boost/function/function8.hpp M boost/function/function9.hpp M boost/function/function_base.hpp M boost/function/function_template.hpp M boost/function/gen_function_N.pl A boost/function/detail/function_iterate.hpp A boost/function/detail/gen_maybe_include.pl A boost/function/detail/maybe_include.hpp A boost/function/detail/prologue.hpp A boost/mpl/bool.hpp M boost/mpl/if.hpp M boost/mpl/integral_c.hpp M boost/mpl/void.hpp A boost/mpl/aux_/algorithm_namespace.hpp M boost/mpl/aux_/arity.hpp A boost/mpl/aux_/has_xxx.hpp A boost/mpl/aux_/ice_cast.hpp A boost/mpl/aux_/integral_wrapper.hpp M boost/mpl/aux_/lambda_support.hpp A boost/mpl/aux_/type_wrapper.hpp M boost/mpl/aux_/value_wknd.hpp M boost/mpl/aux_/void_spec.hpp A boost/mpl/aux_/yes_no.hpp A boost/mpl/aux_/config/ctps.hpp A boost/mpl/aux_/config/eti.hpp A boost/mpl/aux_/config/msvc.hpp A boost/mpl/aux_/config/msvc_typename.hpp A boost/mpl/aux_/config/nttp.hpp A boost/mpl/aux_/config/static_constant.hpp A boost/mpl/aux_/config/workaround.hpp M boost/mpl/aux_/preprocessor/def_params_tail.hpp M boost/multi_array/iterator.hpp M boost/multi_array/multi_array_ref.hpp M boost/multi_array/subarray.hpp M boost/multi_array/view.hpp M boost/preprocessor/array.hpp M boost/preprocessor/tuple.hpp A boost/preprocessor/arithmetic/dec.hpp A boost/preprocessor/array/data.hpp A boost/preprocessor/array/elem.hpp A boost/preprocessor/array/size.hpp M b
[boost] Re: postponed<> proposal
Fernando Cacciola wrote:
[...]
>> Maybe it would be better to simply disable EH overhead with some
>> BOOST macro. _That_ would be really really great then...
>>
>>
> Which EH overhead?
Exception Handlings. Actually, there is one: BOOST_NO_EXCEPTIONS but I
cannot compile with -fno-exceptions under gcc (some try / catch were still
there).
> Anyway, the problem with your proposal is that as I said before the
> boolean flag is initialized before the object is really constructed.
Actually postponed<> looked like the following and initilialized<> is a list
of booleans set to false:
template
struct postponed : storage, initialized
{
typedef T type;
typedef storage storage_t;
typedef initialized initialized_t;
template
partial::type::value_t> & set()
{
static_cast::type &>(*
this).value = true;
return static_cast::type &>(*
this).value;
}
template
typename type_at::type::value_t const & get()
const
{
return static_cast::type
const &>(* this).value.get();
}
};
Philippe A. Bouchard
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Proposal: strings as template parameters?
Dirk Gerrits wrote:
>
> Jason House wrote:
> > I'm thinking that it would be nice to be able to us define distinct
> > types based on strings (the fundamental type const char * and not
> > std::string). The intended use is in templates.
>
> Well I'm just curious how you would like to accomplish this. String
> literals as template parameters don't really work all that well, if I
> recall correctly. Then again, I might be wrong.
Well, I know that in MSVC simply refuses to use strings as template
parameters... If this truly is illegal by the standard, then a string
template parameter could default to a type for that string. As far as
use in other places, maybe use of some keyword as a function. Like
maybe struct("foo").
I was hoping to try and get discussion about utility before trying to
figure out the best way to try and get it to be available.
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: How to convert a template parameter into a string
- Original Message - From: "Peter Dimov" <[EMAIL PROTECTED]> To: "Boost mailing list" <[EMAIL PROTECTED]> Sent: Monday, March 03, 2003 7:59 AM Subject: Re: [boost] Re: How to convert a template parameter into a string > Robert Allan Schwartz wrote: > >>> I believe a "standardized" (within Boost), portable, and *readable* > >>> text representation of T makes my proposal better than typeid(). > >> > >> I think if readability is the main criterion we'd do much better to > >> invest in decoding the typeids generated by GCC. I believe there's > >> even a library that comes with it that does that job. > > > > Why should millions of programmers have to make that "invest"ment? > > > > Wouldn't it be better if gcc simply generated better type names? > > Sure, if there existed an unambiguous definition of "better type name". Maybe there's no "perfect" definition of "better", but let's see how far we can go with a "good-enough" definition. T is P4base T is 4base T is PC4base T is 4base when compiled by g++ and executed in cygwin, is "not good enough". Anyone disagree? T is class base * T is class base T is class base const * T is class base when compiled and executed by MSVC 6.0, is "good enough", but it could be "better" if it eliminated the redundant "class" specifier. We could argue about the difference between "base const *" and "base const*" (i.e. whitespace). We could argue about the difference between "base const" and "const base". But I still think we should fix the gap in the Standard, and choose standard, portable, type names. If we don't do that, then at least my proposal lets each developer choose what THEY want for type names. Robert ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: How to convert a template parameter into a string
Robert Allan Schwartz wrote: >>> I believe a "standardized" (within Boost), portable, and *readable* >>> text representation of T makes my proposal better than typeid(). >> >> I think if readability is the main criterion we'd do much better to >> invest in decoding the typeids generated by GCC. I believe there's >> even a library that comes with it that does that job. > > Why should millions of programmers have to make that "invest"ment? > > Wouldn't it be better if gcc simply generated better type names? Sure, if there existed an unambiguous definition of "better type name". ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] 1.30.0 branch-for-release complete
At 06:45 PM 3/1/2003, David Abrahams wrote: >Beman Dawes <[EMAIL PROTECTED]> writes: > >> The tag is RC_1_30_0 > >Didn't we agree that we were going to tag the trunk and generally do >any merges from the trunk to the branch? This tag appears to be on >the branch AFAICT. There was a lot of discussion, but more\release_procedures.htm never got updated AFAIK. I don't mind using a new procedure, but it needs to be documented. Someone (Jeff Garland?) circulated a draft, but I don't think it was ever finalized. See http://aspn.activestate.com/ASPN/Mail/Message/1411802/release_procedures.htm --Beman ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Variant Formal Review Closed
The Variant Review is now closed. Thanks to all who participated. I will be collating the results and will post them in the next few days. Jeff ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: static_assert.hpp queries
John Maddock wrote: > I don't know, it seems to be a really weird compiler bug, because adding > extra parenthesis around a > expression doesn't help. I think it is a parser/lexer issue, where the '<' and '>' tokens are taken for template syntax rather than boolean comparison. Adding parens does not fix the problem whereas changing the token to <= or >= does (hence my 'fix') I am wondering if the best place to record this sort of library-specific workaround might be on the Wiki? Potentially every test/file might merit comments some some compiler combination, and it is certainly beyond the scope of the library authors to maintain up-to-date documentation of workarounds for every compiler ever. -- AlisdairM Team Thai Kingdom ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] static_assert.hpp queries
> However, I am not happy patching test-cases rather than libraries. On > the other hand, having diagnosed the problem with a viable workaround, I > don't see where else to record the information. Do we have a way of > documenting known workarounds for a library? I don't know, it seems to be a really weird compiler bug, because adding extra parenthesis around a > expression doesn't help. John. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Unused template parameters
Daryle Walker wrote: > > On Thursday, February 13, 2003, at 6:11 AM, Daniel Frey wrote: > > > Markus Schöpflin wrote: > >> > >> Daniel Frey wrote: > >> > >>> Markus Schöpflin wrote: > >> > This was the original source: > > template struct enable_if; > ---^ > > Visual Age doesn't like this, it needs a name here. > >>> > >>> ^^ > >>> > >>> Ah, that's the reason. But given my recent discomfort about > >>> unmaintainable code, look at it again: > >>> > >>> # if BOOST_WORKAROUND(__HP_aCC, <= 33900) > >>> template struct enable_if; > >>> # else > >>> template struct enable_if; > >>> # endif > >>> > >>> Does this really makes sense? Shouldn't we just keep one version > >>> with names for template parameters? AFAICS this should work for all > >>> compilers and it could be a general boost coding guideline to always > >>> provide names for template parameters. Comments? > >> > >> Agreed, if it works for all compilers, let's just keep the version > >> with the names. (And add a comment that it should stay like it is!) > > > > No, don't add a comment. Let's make it a boost coding guideline, > > otherwise we will clutter the code again with comments instead of > > workarounds. Remember that this is only one example of a line with > > template parameters. Would you like to add a comment for every line > > all over boost? > > Should the template parameter names be something like Unused (if > there's exactly one) or Unused1, Unused2, etc.? Technically, this would work, but see below... > Later, on February 16, 2003, at 9:29 PM, Dave Gomboc wrote: > > >> So you would prefer > >> > >> #if BOOST_WORKAROUND(__HP_aCC, <= 33900) > >> template struct enable_if; > >> #elif BOOST_WORKAROUND(__VisualAge, <= 12345) // Dummy values > >> template struct enable_if; > >> #else > >> template struct enable_if; > >> #endif > >> > >> over > >> > >> template struct enable_if; > >> > >> If that is the case, then we disagree. Do you have any reason to > >> prefer the first version? > > > > No, I would prefer > > > > #if BOOST_WORKAROUND(__HP_aCC, <=33900) || > > BOOST_WORKAROUND(__VisualAge, > > <=12345) > > template struct enable_if; > > #else > > template struct enable_if; > > #endif > > > > I already explained the reason: C++ compiler vendors use Boost with > > BOOST_NO_CONFIG for conformance testing. I'd rather see broken > > compilers get fixed than developers forever spending time finding > > workarounds. > > If vendors want to do this check, then they could #define Unused, > Unused1, Unused2, etc. to be nothing. (Make sure to check all the > files to see if my suggestion is the only use of these words.) There are two problems I see: The name is not unique enough and should thus be something like BOOST_UNUSED_PARAMETER. It should also be a MACRO-name (all caps) to indicate that the preprocessor is going to fiddle with it. If it is not and it would be something like BoostUnusedParameter, people would IMHO wonder why it's not boost::UnusedParameter and will forget that they cannot use it for function parameter names of variables. The second problem is, that it might be useful for function parameters, too. This would be a problem if we have a compiler that likes left-out parameter names for functions but not for templates. You cannot remove them depending on the context, thus the context needs to be merged into the name. This leads to BOOST_UNUSED_TEMPLATE_PARAMETER which is much longer than just Unused. Now to the numbering of Unused1, Unused2, etc. There are two cases to think about: More than one unused parameter in one template declaration and nested templates. Especially for the latter I don't think it's a good idea to add some kind of counter. "Real" identifiers are much more maintainable and have the added benefit of telling me something - Unused42 doesn't (except it's unused of course :). To sum it up: I think we should stick with Dave G.'s solution - all in all it is the best alternative when faced with stup^H^H^H^Hbroken compilers :) 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] Variant Library Review
Hi,
Here is my a bit late review for the variant library. In spite of several
concerns that I have, I incline to vote to ACCEPT this submission.
Design concerns I would like to be discussed and either accepted or
dismissed. Implementation issues are less important. Rest is mostly
comments.
Here follows my detailed review. I was not able to follow closely to the
others review, so it may intersects. Issues listen in no particular order.
Design
_
In most part design of the library looks solid and well thought-out( I think
we definitely ought to give Andrei credits for this also). There are several
things that bother me though.
1. Two types requirement
It's unreasonable. ! or even zero sized variants should be allowed.
2. Top level const requirement on bounded types.
It's unreasonable. I should be able to define variant with const types. It
will be as usable as usual constant types are. The only requirements that we
may incur is that if one types is const, rest should be also.
3. Copy Constructible/Assignable requirements on bounded types
This only need to be required if variant should have appropriate feature.
4. DefaultConstructible requirements on first bounded types
This only need to be required if variant need to be default constructible.
5. Usage std::type_info for reflection
I don't think we should enforce RTTI for the variant users. We should be
able to postpone the decision on what kind of reflection information user
want till instantiation time.
6. extract
I not like this name. It does not reflect the essence of the operation it
performs. It does not extract juice from orange. It provides an access to
the varant value. It basically external access method. So the name get,
get_value would be more appropriate. Also I think we need free function form
of value extraction. In other case it would be difficult to place extract in
context where template parameter is deduced. And check function is not that
important in most cases.
7. Variant size
Unfortunately I was not able to follow exact logic behind usage of 2
different storages. But one thing I know:
sizeof(boost::variant) could not be 28.
>From what I view it seems that types that are used to construct storage2
also used when constructed storage1. So we definitely have size duplication
here. Separate issue is the type of which field. Having it as int is an
overkill. It would be enough in majority of the cases have char. But we
should be able to deduce the correct type depends on number of argument
types.
8. Visitation algorithm
In sketch presented visitation algorithm look like this:
void foo1( which, visitor )
{
if( n = 1 )
visitor(...)
else
foo2( which, visitor );
}
void foo2( which, visitor )
{
if( n = 2 )
visitor(...)
else
foo3( which, visitor );
}
In a pseudo code it could be rewritten like this
foo( visitor )
{
if( which == 1 ) visitor( first field );
else if( which == 2 ) visitor( second field );
...
else if( which == n ) visitor( nth field );
}
It's obvious that switch-based algorithm will be more effective. And I
believe that given at compile time number of the types supplied (or maximum
possible types variant accepts we should be able to generate one (even if we
will need to use PP for that )
9. Design of the container move function
I do not see a way how with current design and implementation of the
container move function I could move content of one vector into another
originally empty vector.
move(src.begin(),src.end(),trg.begin() ) will move to garbage memory
move(src.begin(),src.end(), back_inserter( trg ) ) will copy instead of move
Do we need something like back_move_inserter?
Implementation
_
General comment: I believe that all template functions in header files need
to be defined inline.
static_visitor.hpp
Line template fails to compile with MSVC6.5. SO to make
it work I was forced to use following form
template
This and also the fact that MSVC6.5 could not handle return void construct,
forced me to change all the visitors defined in visitor.hpp to return
boost::mpl::void_. Maybe you could find better workaround
static_visitable.hpp
1. I believe that implementation of this concept could be enhanced. The
major problem as I see it is that static_visitable_traits could not be
instantiated with const type. That force you to propagate switch on
const/non const in many different places. While you could do this only once
in static_visitable_traits implementation. See attached file for details.
Once you do this the implementation of unary apply_visitable will became as
simple as this:
template
typename Visitor::result_type
apply_visitor( Visitor& visitor, Visitable& visitable )
{
return static_visitable_traits
::apply_visitor(visitor, visitable);
}
You will see simplification in several other places.
2. is_static_visitable description states that thi
