- Boost - lists.boost.org

Intel: uBLAS and range go DR, random still unresolved
by Stefan Slapeta 28 Jul '04

28 Jul '04

I've submitted a Intel 8 DR for two obvious compiler defects: test2 in uBLAS and the iterator_range in iterator (ICE). Is there nobody feeling competent/responsible to give any hint for the random failure? I don't know if I can find it on my own. Stefan

1 2

VC 7.1 warning in linear_congruential.hpp
by Stefan Slapeta 28 Jul '04

28 Jul '04

in rand48::operator () [...]\linear_congruential.hpp(218) : warning C4244: 'return' : conversion from 'boost::uint64_t' to 'boost::int32_t', possible loss of data Patch attached. Stefan RCS file: /cvsroot/boost/boost/boost/random/linear_congruential.hpp,v retrieving revision 1.18 diff -u -r1.18 linear_congruential.hpp --- linear_congruential.hpp 27 Jul 2004 03:43:32 -0000 1.18 +++ linear_congruential.hpp 28 Jul 2004 15:09:10 -0000 @@ -215,7 +215,7 @@ void seed(uint64_t x0) { lcf.seed(x0); } template<class It> void seed(It& first, It last) { lcf.seed(first,last); } - int32_t operator()() { return lcf() >> 17; } + int32_t operator()() { return static_cast<int32_t>(lcf() >> 17); } // by experiment from lrand48() static bool validation(int32_t x) { return x == 1993516219; }

1 0

RE: [boost] Boost Test Library: Bug in floating-point comparison?
by Rozental, Gennadiy 28 Jul '04

28 Jul '04

> Hi, > > I want to use the boost::test floating-point comparison > algorithms (Boost > 1.31.0) and wrote the following simple lines of code: > > double d1 = 0.2; > double d2 = 0.8; > double d3 = d2-d1-d1-d1-d1; // d3 should be zero > > bool b = boost::test_toolbox::check_is_closed( d3, 0., 1e-3 ); > > To my surprise, the return value b is FALSE, although d3 > should be _very_ > close to zero (and is 5.55112e-17 on my machine). > > Am I missing something or is this a bug in the test library? > > Thanks, > Michael > > -- > Michael Kettner > kettner(a)ive.uni-hannover.de Read algorithm description. The algorithm compare "relative errors". In your case it's 1 and infinity. Definitely more then 1e-03. It you want to compare absolute values (which is not recommended in real life applications) you either could write you own predicate or wait a bit, while I am considering adding BOOST_IS_SMALL tool that will be responsible namely for this kind of test. Gennadiy.

2 1

RE: [boost] Re: RE: Re: DLL library (Was: Re: additional boostlibraries?)
by Reece Dunn 28 Jul '04

28 Jul '04

Vladimir Prus wrote: >Bronek Kozicki wrote:mechanism Garland wrote: > >> This isn't really a re-invention of either -- just a very small library >that > >> does someskeletonsilar to what both do -- without all the baggage. COM > >> is a > >> Windows only option, for example. Both are big frameworks with gobs of > >> stuff not needed to load a dll and call a function. > > > > I think that similar motivation drove YAMI project, see > > http://www.msobczak.com/prog/yami/ > >Do you mean "without all the baggage" by "similar motivation"? What I see >on >the page is still very complex -- some network communication and the like. > >I want just portable mechanism to access objects from shared libraries. >This >is much more lightweight than CORBA, which requires IDL, stubs, skeletons, >supports talking to objects on other machines, a lots of other stuff. Frameworks like COM and CORBA are designed to be language independent: this is why they use IDL for describing interfaces. Since what you require is C++-specific, you can skip the IDL language and use abstract base classes and/or virtual functions, which is what Volodya is doing. The frameworks also provide some means of generic exception handling. COM skips this by returning an error code (HRESULT) value because of the issues of dealing with exceptions across language borders (e.g. C++ to C). The C++ exception mechanism is fine for what Volodya wants because there will be no cross-language problems. The frameworks may provide some means of automation. COM uses a discriminant union type (VARIANT) and a dispatch interface to achieve this, as well as providing direct access via the interfaces. I don't think scripting is an important issue in this case, but it should be possible to implement using Boost.Spirit :). The frameworks provide a mechanism for managing object lifetimes. COM does this by the base interface supporting AddRef/Release with the DLL responsible for construction (via exposed object types) and the object responsible for deconstruction (deleting itself once the reference count is 0). As I see it, this is intended to be implemented using shared_ptr's, the issue being *how* to load the objects and DLL's. In COM the object is responsible for keeping the DLL alive (via a reference count on the DLL as has been mentioned in other posts). If there are two objects from the DLL alive, then the DLL's reference count is two (unless it is explicitly locked to keep it alive). The MS documentation on DllMain says: During initial process startup or after a call to LoadLibrary, the system scans the list of loaded DLLs for the process. For each DLL that has not already been called with the DLL_PROCESS_ATTACH value, the system calls the DLL's entry-point function. Thus, if the DLL is already loaded by a process, it will not reload it on successive calls to LoadLibrary. The documentation on FreeLibrary says: The FreeLibrary function decrements the reference count of the loaded dynamic-link library (DLL). When the reference count reaches zero, the module is unmapped from the address space of the calling process and the handle is no longer valid. Thus, there is no easy way to reload a DLL. The best solution would be to release the instance of the plugin you have loaded and let the system unload the DLL. It is best to only be concerned about the DLL when loading the plugin. If you want to alter plugins at run-time (e.g. removing or adding a plugin), just remove all references to the plugin to delete it or load the plugin into the plugin map from the DLL. The frameworks provide other facilities, but I think these are the main (core) facilities. I am not sure how this will map to Linux or MacOS systems. Regards, Reece _________________________________________________________________ Want to block unwanted pop-ups? Download the free MSN Toolbar now! http://toolbar.msn.co.uk/

2 1

Building Libraries in Boost
by Jody Hagins 28 Jul '04

28 Jul '04

Most of boost is implemented in header files (as most is based on templates). However, what are the guidelines for splitting code into compilable units? For example, if a library is not a template library, should the author strive to implement it entirely in headers as inline functions, or should it be implemented as part inline functions and part a compiled library? A fair amount of code uses the PIMPL pattern to reduce header complexity, reduce interface and implementation exposure, and to reduce compile times. However, this requires, in large part, separate compiled libraries. What is the Boost position in this regard? Thanks!

2 1

sporadic bjam crashes on WinXP box
by Gennadiy Rozental 28 Jul '04

28 Jul '04

When I run Boost.Test unit test for 10 compilers in crashes sometimes (but quite regularly). How could I track the issue? Looks like it depend on amount target it actually need to update with current run. Gennadiy.

4 5

Re: [boost] RE: Re: DLL library (Was: Re: additional boost libraries?)
by Robert Ramey 28 Jul '04

28 Jul '04

Vladimir Prus wrote: >I know next to nothing about COM, so can't on this idea. In all cases, I >think it's a bit beyond the scope. I have some experience writing applications that use COM. Reading through this discussion makes me wonder if this isn't a re-invention of the COM wheel. I don't know anything about CORBA. I has always presumed it was similar to COM. COM starts out as simple in principle and ends up being very complex. It seems that Microsoft has now rolled up that functionality into Dot Net and no longer promotes COM. I would think a careful study of COM/CORBA would be key to pursuing this line of inquiry. Robert Ramey

4 3

Re: Threads Rewrite?
by Tonko Juricic 28 Jul '04

28 Jul '04

Michael Glassford wrote: > The next release will clean up TLS right after the > thread function exits, but that doesn't work for > threads that aren't created by Boost.Threads. If > that's good enough for you, good! However, if you > need TLS cleanup for threads not created by > Boost.Threads, the DLL_THREAD_DETACH or some other > approach is still necessary. I see your point! I guess this is more of a taste/philosophy issue. Leaning toward "less code is better" philosophy I would tend to take a position : you are not using boost threads? Then it's yours, rather than boost code responsibility, to clean up TLS. I don't see anything particularly productive coming out of discussing such issues here so let's put it in IMHO folder. Regards, Tony __________________________________ Do you Yahoo!? Yahoo! Mail - 50x more storage than other providers! http://promotions.yahoo.com/new_mail

2 1

BOOST_BIG_ENDIAN
by Jody Hagins 28 Jul '04

28 Jul '04

This macro (and its friend BOOST_LITTLE_ENDIAN) definition appears in boost/detail/limits.hpp. However, that file is included only if boost/limits.hpp does not detect the standard <limits>. Thus, it does not get defined for more standard compilers. The serialization library makes use of this macro (in a test), so I wonder how it works on standard compilers. I could use the ENDIAN macros in some of my code to provide compile time performance options (linux provides something similar). Is it possible to move the ENDIAN macros into some other header so that they are more easily obtained, and also do not force including a limits workaround? I also imagine if they were actually included in more compilations, that they could get checked for correctness and the maintenance of newer platforms would increase. Thanks!

6 8

RE: [boost] Building Libraries in Boost
by Reece Dunn 27 Jul '04

27 Jul '04

Jody Hagins wrote: >Most of boost is implemented in header files (as most is based on >templates). However, what are the guidelines for splitting code into >compilable units? As far as I know, anything sensible. >For example, if a library is not a template library, should the author >strive to implement it entirely in headers as inline functions, or >should it be implemented as part inline functions and part a compiled >library? If the code is non-template and is non-trivial, it should really be a part of a compiled library. For trivial functions (e.g. returning data information), these should be inlined. Boost uses the Boost.Build system to compile the libraries (see the installation docs for information on how to setup and configure either V1 or V2). You will need to create a Jamfile that describes the library so that it can be built (this will normally be in libs/<library>/build), with the source in libs/<library>/src. I suggest that you take a look at the existing libraries that have built components: Boost.DateTime; Boost.RegEx; Boost.Signals; Boost.Graph; Boost.Thread; Boost.FileSystem and Boost.ProgramOptions. If you get stuck with Boost.Build you can contact the Boost.Build mailinglist. >A fair amount of code uses the PIMPL pattern to reduce header >complexity, reduce interface and implementation exposure, and to reduce >compile times. However, this requires, in large part, separate compiled >libraries. Whether or not to use PIMPL should be a design decision based on the library requirements. There are also non-class functions that may be a part of a library that exist in a compiled unit (see Boost.FileSystem). Regards, Reece _________________________________________________________________ Want to block unwanted pop-ups? Download the free MSN Toolbar now! http://toolbar.msn.co.uk/

1 0