- Boost - lists.boost.org

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

Why I couldn't compare optional<int> and optional<long>
by Rozental, Gennadiy 27 Jul '04

27 Jul '04

IMO relational operators in optional implementation should have two template parameters Gennadiy.

1 0

RE: [boost] Re: counting_iterator_test.hpp fails on aC++
by DY, JERRY U (SBCSI) 27 Jul '04

27 Jul '04

Dave, As you suggested, an auxiliary function template is defined (outside of the iterator_adaptor class - aC++ doesn't like it if it's a member function): // workaround for aC++ CR JAGaf33512 template <typename TR1, typename TR2> inline void iterator_adaptor_assert_traversal () { typedef int assertion[sizeof(detail::static_assert_convertible_to<TR2>(TR1()))]; } Then the old static assertion is replaced like so: # define BOOST_ITERATOR_ADAPTOR_ASSERT_TRAVERSAL(cat) \ iterator_adaptor_assert_traversal<my_traversal, random_access_traversal_tag>(); // typedef iterator_adaptor_assert_traversal<my_traversal, cat> assert_traversal_t; I tested this by adapting an ordinary pointer to a forward traversal iterator and if the program calls the operator+= (calling the adaptor's advance member function and triggering the static assertion), the compile fails, the compile succeeds otherwise. There should be no additional overhead incurred due to the workaround because the function itself is inlined and all it does is a typedef. Is this workaround acceptable for check-in? Thanks! -Jerry -----Original Message----- From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of David Abrahams Sent: Saturday, July 24, 2004 8:20 AM To: boost(a)lists.boost.org Subject: [boost] Re: counting_iterator_test.hpp fails on aC++ Probably the right way to fix this is to indirect through an auxilliary function template that does the assertion. I presume _that_ wouldn't be instantiated unless it was actually called.

1 0

Re: [config] seems like VC 8.0 needs BOOST_NO_MEMBER_TEMPLATE_FRIENDS
by Michael Stevens 27 Jul '04

27 Jul '04

On Tuesday 27 July 2004 00:42, JOAQUIN LOPEZ MU?Z <joaquin(a)tid.es> wrote: > error C2888: 'void boost::multi_index::safe_mode::detach_equivalent_iterators(Iterator &)' : symbol cannot be defined within namespace 'detail' The error seems to indicate a namespace problem rather then something specific to member template friends? > > I've searched through the VC 2005 beta docs and, > allegedly, member template friends are supported, so this > particular problem could be a bug rather than complete > lack of support for this feature. Maybe someone with > local access to VC 8.0 can test the above code and > see what happens (I currently don't have the time > and resources to try myself.) Maybe the problem is related to namespace handling in VC 8.0 Boost.numeric.interval library fails when included in uBLAS due to a curious namespace problem. http://www.meta-comm.com/engineering/boost-regression/developer/output/Rudb… The same problem effect VC 7.1 as well. Why the compilers think the 'lower' 'upper' symbols are ambiguous I have no idea! -- Michael ___________________________________ Michael Stevens Systems Engineering Navigation Systems, Estimation and Bayesian Filtering http://bayesclasses.sf.net ___________________________________

6 9