- Boost - lists.boost.org

License and new version
by Jared McIntyre 11 Nov '04

11 Nov '04

I'm guessing from reading through the 1.32 tarball docs that the this release will still have some libraries that are not under the Boost 1 license. Is this the case? If so, is there a definitive list of these projects? Jared McIntyre

5 6

RE: [boost] Library TR draft available
by Randy Bowen 10 Nov '04

10 Nov '04

Is there a problem with that site? I've yet to be able to download the document, or even fully load the index page on which it's referenced. > -----Original Message----- > From: Beman Dawes [mailto:bdawes@acm.org] > Sent: Tuesday, November 09, 2004 5:39 PM > To: Boost mailing list > Subject: [boost] Library TR draft available > > The latest draft of the C++ Standard Library Technical Report > is now available at > http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1711.pdf > > There may be editorial (non-substantiative) changes to the > final version of the TR document, but this latest draft is > believed to be final in terms of technical content. Thus it > should be safe for implementors or users to write code based > on this latest draft. > > It will be several years before most compilers come with a > full implementation of the TR. But some vendors (Metrowerks, > for example) are already shipping a few TR components. That > brings up the question of what Boost code does during the transition. > > To insure Boost code works with various TR implementations, > some Boost code will want to use the compiler vendor's > version of the TR if the TR component required is available, > but otherwise will want to use Boost equivalent code. How do > we handle that? The TR doesn't provide in configuration > macros, so I guess we will have to roll our own. > > --Beman > > _______________________________________________ > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost >

4 3

Math functions - requirements 'spec'
by Paul A Bristow 10 Nov '04

10 Nov '04

Following the view of C and C++ Working groups at Redmond that a working implementation of my proposal for math functions was a necessary condition for consideration for a TR-2 standard, I have been skirmishing with the problems of converting Stephen Moshier's Cephes code into something that works for both C++ and C. Several issues have emerged, mainly revealing my ignorance with C - a state of bliss in which I would have preferred to remain ;-) 1 Should I no longer cater for non-compliant compilers (usually old-style function specifications? I only have MSVC 8.0 available. 2 How do I check that my code is Standard C compatible (as well as C++)? 3 How do I tell whether the compiler is a C compiler or a C++ compiler (for #if ing). #if __cplusplus #if _STDC__ ... ? 4 I have compiled a module #including <cmath> OK with explicit project property "compile with C++", but when I change this to "compile with C" and no extensions so the /Za option is on the command line, it does not define __STDC__ == 1 as I have expected. What am I doing wrong. 5 Do I have to use exclusively C /* */ style comments :-((? (Or can I assume that C compilers will understand // comments?) I have also immediately come up against the problems of IEEE 754 compliance, argument checks, NaN, infs and exception throwing. 6 Should I assume IEEE 754 compliance and signal #error "Only works with IEEE compliant compilers"? How do I check with C - numeric_limits :: is_IEC559 equivalent? Or would it be foolish to rule out the some older DEC machines? 7 Do you recommend making NaN and inf checks optional? 8 How do I find if they are available, automatically but portably? 9 Can I assume isnan(float, double and long double) with C and with C++? 10 How do I detect isinf? Do I use FPclass for detecting isinf? (pos and neg?) 11 Do you recommend making throwing exceptions optional with C++? 12 Should I scrap all the hexadecimal (mainly polynomial) constants on the grounds that conforming compilers should read decimal digit strings 'correctly' - getting the nearest representable value. Is this true for both C and C++? 13 Do you also recommend making checking arguments optional (with #ifdefs)? So that those who want the ultimate in speed at any risk can switch checking off? Comments welcome. Paul PS Slightly updated versions of my TR2 proposal are at http://www.hetp.u-net.com/public/math_stats_functions_tr2_v2.doc http://www.hetp.u-net.com/public/math_stats_functions_tr2_v2.pdf Paul A Bristow Prizet Farmhouse, Kendal, Cumbria UK LA8 8AB +44 1539 561830 +44 7714 330204 mailto: pbristow(a)hetp.u-net.com

6 20

Boost.Thread (1.32draft) -- release library not built
by James Harris 10 Nov '04

10 Nov '04

Hi All, I have just downloaded the v1.32 draft and built the thread libraries, however it seems as though only the debug static lib has been built. I'm using VC7.1 and am trying to link to "libboost_thread-vc71-mt-s-1_32.lib" which has not been built. The following files were built successfully: - libboost_thread-vc71-mt-sgd-1_32.lib - boost_thread-vc71-mt-gd-1_32.lib - boost_thread-vc71-mt-gd-1_32.dll Is there a specific reason this lib is not being built, or is it that I've missed something somewhat important during the bjam build process? TIA - James.

3 2

Problem compiling boost::python : Script seems to require version 2.2 of python.
by JOLY Loic 10 Nov '04

10 Nov '04

Hello, I'm trying to build boost::python on my windows box, but I encounter some problems in the build process. First, some info about my versions : * I'm using the draft tarballs of the long expected version 1.32 that can be found on http://www.meta-comm.com/engineering/boost/200411020208/boost_1_32_0.zip * I have a pyton 2.4 installed on my computer I'm using bjam --v2 to build boost. First problem I had was that the doc specified to set the PYTHON_ROOT variable to my python installation path, but it looks like the script look for a PYTHON_PATH variable. Either the scripts of the documentation should be corrected. Second problem, even if the doc claims that the variable PYTHON_VERSION can be set to any version at least 2.2, in tha script, I can see what looks to me (I'm totally new to bjam) like an hard-coded value : > # Declare a target for the python interpreter library > lib python : : <name>python22 <search>$(PYTHON_PATH)/libs ; > PYTHON_LIB = python ; Best regards, -- Loïc -- Disclaimer ------------------------------------ Ce message ainsi que les eventuelles pieces jointes constituent une correspondance privee et confidentielle a l'attention exclusive du destinataire designe ci-dessus. Si vous n'etes pas le destinataire du present message ou une personne susceptible de pouvoir le lui delivrer, il vous est signifie que toute divulgation, distribution ou copie de cette transmission est strictement interdite. Si vous avez recu ce message par erreur, nous vous remercions d'en informer l'expediteur par telephone ou de lui retourner le present message, puis d'effacer immediatement ce message de votre systeme. *** This e-mail and any attachments is a confidential correspondence intended only for use of the individual or entity named above. If you are not the intended recipient or the agent responsible for delivering the message to the intended recipient, you are hereby notified that any disclosure, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify the sender by phone or by replying this message, and then delete this message from your system.

3 6

Re: Problem to use boost
by Daniel Lidström 10 Nov '04

10 Nov '04

> > I do the same as before and get the same error. And yes, I am using > > Visual Studio 7.1 in case anyone thought else. What am I > doing wrong? > > No idea, but you can only get the error you are seeing if > __BORLANDC__ is > defined, and it clearly should not be if you are using Visual C++. > You're right. __BORLANDC__ was defined somewhere in this old legacy code base that is now being compiled with .Net 7.1. It didn't cross my mind. Thanks! -- Daniel

1 0

pqs - physical quantities library
by Andy Little 10 Nov '04

10 Nov '04

Hi, I have been continuing with my physical-quantities library over the last year, http://www.servocomm.freeserve.co.uk/Cpp/physical_quantity/index.html and I am now seeking feedback as to whether it is worth putting this forward as a boost library proposal.... *Overview* The physical-quantity type-family provides methods for modeling physical-quantities in C++ programs. The advantages and extra functionality over inbuilt types used in the role include, compile time dimensional-analysis checking, automatic conversion between units and an increase in source code comprehensibility. The type family includes two types, firstly a type where the units are fixed at compile-time referred to in the text as a ct-quantity and secondly a type where the units can be run-time modified, referred to in the text as an rt-quantity. The ct-quantity has many similar features to an inbuilt-type: - concrete type with simple,consistent semantics close to those of inbuilt-types. - aims for speed and code size performance close to that of in-built types. - requires no special framework to use. *Application areas* The application areas are very wide, including scientific-engineering, CAD, 3D games programming among many others. *Future directions* 2D and 3D vector quantities, scene-graphs and scene-modelling, Graphics interface (eg OpenGL), splines and curve analysis, successive approaximation , piecewise differentiation and integration algorithms. finite element analysis, etc etc. Issues from the previous thread on the library and physical quantities in general http://aspn.activestate.com/ASPN/Mail/Message/boost/1926782 issue: Angles. current status: Angles are implemented.There are two types, irrational (ie radians) and rational fractions of revolution ie degrees minutes etc). radians are what you might call a 'weak type'. (Though this behaviour can be modified by a macro switch). They will implicitly decay to (say) double and can be implicitly cast to double. However they also allow implicit conversions to and from degrees etc. hence an implicit conversion from degrees to radians can occur if a function has a radians argument, but not a double argument. They are also useful for output of units. --------------------- issue: Differentiating different but dimensionally equivalent types. current status: This is implemented. --------------------- issue: Implicit conversions between units. current status: Implicit conversions are intrinsic. They are practical instinctive and useful. --------------------- issue: You should be using mpl. current status: Hopefully I will be able to get hold of the metaprogramming book soon, at which point I can decide whether there are advantages. --------------------- regards Andy Little

4 10

Re: Problem to use boost
by Daniel Lidström 10 Nov '04

10 Nov '04

> "Daniel Lidström" <daniel.lidstrom(a)sbg.se> wrote in message > news:E1F34343C3A0804BB3E29ABBFCBBAF0C01BB6F@ADA... > > Hi, > > > > this is what I've done: > > compiled with commandline of > > bjam "-sVC71_ROOT=C:\Program Files\Microsoft Visual Studio .NET > > 2003\Vc7" > > "--prefix=C:\projects\boost" install > > I don't see an -sTOOLS=vc7.1 here telling bjam which tool set > to use, as the > Getting Started page suggests. I'd guess this is confusing > things. Given you > are using the default root for vc7.1 try: > > bjam -sTOOLS=vc7.1 "--prefix=C:\projects\boost" install > > note that vc7.1 is case sensitive. > Ok, I compile like this: bjam "-sTOOLS=vc7.1" "--prefix=C:\projects\boost" install > > Within my project, I've set an additional include path of > > C:\projects\boost\include\boost-1_31. Now when I compile my > project with > > > > one source file containing the line > > > > #include <boost/shared_ptr.hpp> > > > > I get this error: > > > > > c:\projects\boost\include\boost-1_31\boost\config\compiler\bor > land.hpp(1 > > 3) > > : fatal error C1017: invalid integer constant expression > > > > What have I missed? I do the same as before and get the same error. And yes, I am using Visual Studio 7.1 in case anyone thought else. What am I doing wrong? -- Daniel

2 1

[boost][boost-users][random] Open bugs
by Cromwell Enage 10 Nov '04

10 Nov '04

Any chance that any of the following bug reports will be resolved before the release? <http://sourceforge.net/tracker/index.php?func=detail&aid=911758&group_id=75…> <http://sourceforge.net/tracker/index.php?func=detail&aid=715667&group_id=75…> <http://sourceforge.net/tracker/index.php?func=detail&aid=652567&group_id=75…> TIA! Cromwell Enage __________________________________ Do you Yahoo!? Check out the new Yahoo! Front Page. www.yahoo.com

2 1

[serialization] problem with Microsoft VC 7.1 and ADL
by Vyacheslav E. Andrejev 09 Nov '04

09 Nov '04

Hello All, Seriaization library relies on argument dependent lookup (ADL) in calling load and save functions in boost::serialization::free_loader::invoke and boost::serialization::free_saver::invoke accordingly. Library supposes that this feature works well in VC 7.1 (that is macro BOOST_NO_ARGUMENT_DEPENDENT_LOOKUP is undefined). But as I see, first, this supposition is implemented with error, and, second, ADL not always works very well in VC 7.1. Let's look to file /boost/serialization/split_free.hpp: namespace serialization { #if ! BOOST_WORKAROUND(BOOST_MSVC, <= 1300) template<class Archive, class T> void save(Archive &ar, const T & t, const unsigned int); template<class Archive, class T> void load(Archive &ar, T & t, const unsigned int); #endif ... Pay attention to "!" sign before BOOST_WORKAROUND. So, if VC version is 7.1 or higher, compiler expects that save and load would be defined in serialization namespace, if VC version is 7.0 or lower, compiler will search those namespaces from which Archive or T are originated. Very well. But let's take a look now to /boost/serialization/set.hpp for example: #ifdef BOOST_NO_ARGUMENT_DEPENDENT_LOOKUP namespace boost { namespace serialization { #else namespace STD { #endif template<class Archive, class Key, class Compare, class Allocator > inline void save( Archive & ar, const STD::set<Key, Compare, Allocator> &t, const unsigned int /* file_version */ ){ ... } template<class Archive, class Key, class Compare, class Allocator > inline void load( Archive & ar, STD::set<Key, Compare, Allocator> &t, const unsigned int /* file_version */ ){ ... } In this file if BOOST_NO_ARGUMENT_DEPENDENT_LOOKUP is defined save and load will be defined in serialization namespace, otherwise in the std namespace. But BOOST_NO_ARGUMENT_DEPENDENT_LOOKUP is undefined for VC 7.1 (see /boost/config/compiler/visualc.hpp)! So in VC 7.1, accordingly to split_free.hpp, compiler expects save and load from serialization workspace, but they are defind in std accordingly to set.hpp (and all others stanard containers serialization files). By happy concourse of circumstances, this error is bypassed by errors in compiler and in most casses VC 7.1 compiles serialization library very well. But sometimes it accedentally rembers what ADL is and emits error during link stage that serialization::save and serialization::load are undefined. I suggest: 1) define BOOST_NO_ARGUMENT_DEPENDENT_LOOKUP for VC 7.1 since as I can see Koening search technique implementation is unstable; 2) change "#if ! BOOST_WORKAROUND(BOOST_MSVC, <= 1300)" in split_free.hpp to "#if defined(BOOST_NO_ARGUMENT_DEPENDENT_LOOKUP)". -- Vyacheslav E. Andrejev System Architect, Excelsior, LLC

2 1