- Boost-users - lists.boost.org

[BGL] Neighbourhood as a subgraph.
by Seweryn Habdank-Wojewódzki 03 Apr '06

03 Apr '06

Hi! Did any one check how to get neighbourhood of the node from given graph with respect to the properties or connections? Like in example below: V = { 1, 2, 3, 4, 5 }; E = { (1,2), (2,5), (5,4), (2,4), (1,4), (1,3), (3,4) }; So if there is no property, let assume that we are interesting in searching neighbourhood level 1 of point 1 we will have {1,2,3,4} level 2 {1,2,3,4,5}, but neighbourhood level 1 of point 4 is {1,2,3,4,5}. Of course I am interesting in copying proper edges too. If we have numerical properties on edges we could define (as on all problems with paths) that distance between node A and B is a sum of properties between them. And if we set adjacent matrix as 0 1 3 2 0 1 0 0 1 1 3 0 0 2 0 2 1 2 0 2 0 1 0 2 0 Than neighbourhood of level (or in that case "distance") 1 of point 1 is {1,2} level 2 {1,2,4,5}, and for point 4 level 1 {2,4}. The question is. If algorithms "breadth_first_*" will give me all functionality for that or not? Regards. -- |\/\/| Seweryn Habdank-Wojewódzki `\/\/

1 0

How to meet these cross-platform project goals?
by Matt England 03 Apr '06

03 Apr '06

Summary: I'm managing a newly-open-sourced project, and I'm looking to accomplish these goals: 1) Ensure the source packages can build on all systems 2) Ensure the application (binary) packages run on all supported systems 3) Ensure libraries we deliver integrate properly with other software projects Any feedback or guidance from this community would be greatly appreciated. I provide further details, as well as more-specific questions, below. Details: I manage a significant, C++ based software project that is on the verge of presenting an open-source format. Up until now, my group had tight control on the systems/environments (mostly Windows-MinGW, RHEL, Fedora, and Debian to this point) for which we built and tested our software. No longer; we now believe we have to support most of the worlds' systems, representing a set of very heterogeneous environments, and that's not trivial. I'm looking for feedback and guidance on what tools and paradigms are available to my C++ based, open-source project to best ensure consistent cross-platform build and execution capability. I provide my research findings and general understanding of the issues below. Thanks in advance for any help. (I plan on posting this note in a couple different email lists, forums, and newsgroups. Please forgive me if my post is not appropriate for your community. For what it's worth, I have found it difficult reaching a conclusion for this cross-platform-software-distribution issue, and I think it best to query several different communities involved with this stuff and get their combined take on the matter.) I break this issue down into these goals: 1) Ensure the source packages can build on all systems 2) Ensure the application (binary) packages run on all supported systems 3) Ensure libraries we deliver integrate properly with other software projects I write more details, including associated questions, for each one of these goals in 3 different sections of my note below. I'm looking for the best and/or most-accepted ways to solve these problems. I've done a little research (coupled with my many years of user/developer experience with similar systems facing the same problems), and the following notes reflect what I've come up with thus far. For what it's worth: our project has taken extreme care to create portable and modular C++ code and to use only the most-common and highly-portable libraries. We feel that our problem lies not in making our code more portable, but rather making our build process and our binary-distribution systems more portable. ------------------------------------------------------------------ ---- 1) Ensure the source packages can build on all systems ------ ------------------------------------------------------------------ The target stakeholder for this problem seems to be one of: a) user looking to build binaries from source, or b) a developer looking to modify the source for some reason, or c) some combination thereof. While this stakeholder set may be more knowledgeable and experienced then a general "binary-only" user, I still believe an automated system needs to check the build environment to make sure it's suitable to build my software package. This task appears to be centered on 2 basic issues: * Check that a proper compiler-and-linker system exists with all the appropriate system headers and libraries * Check availability and compatibility of "external" libraries and their headers Am I missing anything here? For what it's worth: the external libraries (besides "standard" system libraries) that we currently use include but may not be limited to the following: various Boost-C++ libraries, OpenSSL, BZip2, libpqxx, Xerces-c, and optionally ACE (<http://www.cs.wustl.edu/~schmidt/ACE.html>), libcurl, and xmlrpc-c. Up until now, we were including each library (and its associated header files) from the above toolset in a Subversion-controlled "external" directory for each platform (eg, one for MinGW, Fedora, RHEL, Debian, etc). However, we're finding that some boost libs don't work for all debian3.1 systems, etc. I suspect we are going to run into this problem more and more over time, and as such we need to let system in question provide the library that's compatible with said system (in the aforementioned case: let Debian's apt download/build the right boost library). Is my understanding correct? My project also uses an extensive and modular GNU-make Makefile system based on a core Makefile we authored that builds rules dynamically (by heavily leveraging the $(eval) function in make) based up on per-application "input" Makefiles. Further, we do not hard-code lists of source files in our Makefiles, for we auto-find the source files in each application or library subdirectory on the fly; therefore, when one adds or removes source-code files to our repos (we use Subversion, although it may not matter that much), we require no changes to the Makefiles. This system has served us well, and we're not inclined to move away from this system unless absolutely necessary. (And if we want to support single-source control of all build processes, even with non-MinGW Windows systems, we might have to move away from this to something like bakefile or CMake...but more on this in a minute.) However, I doubt the Makefile system will be robust enough to handle the nuances of truly cross-platform builds; maybe that's an understatement. The tried-and-true tool to address this seems to be autoconf, and I'm currently gearing myself up to author some autoconf-based control files. However, autoconf does not appear to address non-MinGW Windows environments. For that reason, my project is currently supporting only MinGW in Windows environments. However, I'd like to be able to "single-source control" the build process for non-autoconf-supported systems like VisualStudio systems (and to a lesser extent CodeBlocks, Dev-C++, etc...although they are a safer bet to read GNUmake Makefiles) in the future. bakefile is the only thing that I've seen that yet supports this approach. CMake (CMake?) might, but I'm not sure about VStudio; further, CMake requires that all my developer-users change their usage patterns (from './configure && make && make install') and to build and use CMake...and I'm not yet inclined to change this paradigm. A note about autoconf: I'm hoping it provides a *supplement* to my existing Makefile system, instead of replacing such system with new, auto-generated makefiles, etc. (For this and possibly other reasons I'm steering clear of using automake, as per experiences like these: <http://subversion.tigris.org/hacking.html#configury>). I'm a control freak about my build-control process, and I don't want some automated tool specifying what my build rules and dependencies are. Rather, I want autoconf (or some tool that replaces it) to simply make sure that the build environment (on said machine) is sufficient and then set the make variables accordingly as inputs to my existing make/Makefile process. Is this the way it works...or at least can work...with autoconf? Another way to ask this: can autoconf essentially be made a "slave" to the Makefile.in file? ------------------------------------------------------------------ ------ 2) Ensure the app packages run on all supported systems --- ------------------------------------------------------------------ The target stakeholder here seems to be: A "binary-only" user that simply needs to install the package and have it run, no fuss, no muss. This seems to boil down address this problem (or set of problems): making sure that all the shared-object/DLL library and other binary dependencies (like having a PostgreSQL or MySQL system installed if the system stores data in a database like ours does) are satisfied for the target operating system (and can be referenced in the appropriate binary/library "lookup" paths). And if said libraries/binaries/software can not be found, auto-downloading and installing them if necessary. Mechanisms like Fedora's yum, RHEL's up2date (hopefully I didn't get those mixed up), Debian's apt, *BSD's pkg, Solaris' pkg, etc, all seem to handle this with more or less sufficient capability. (Eg, an .rpm ".spec" file will map out the necessary rpm dependencies on a fedora/reel system.) Assuming they do, a couple questions: * Is there ever a time when I should package the binary libraries or binaries for external products (eg, OpenSSL, PostgreSQL) for my project's binary distribution? * Do tools exist where I can write one "control spec" for all the above auto-package toolsets instead of having to write a different spec for each of .rpm, .deb, BSD-pkg, etc? Separately: what does one do about Windows? What about other "non-Unix" operating systems like VMS? Do .msi-like installation packages do the work that of Debian's apt in that said system will automatically download missing library dependencies? I highly doubt it. Must my project include all the binary packages for my external libs/bins (eg, OpenSSL, PostgreSQL) in these distributions? (For what it's worth, our project currently supports MinGW-based Windows distributions of our stuff.) An additional note/question about "common" Linux binaries: For Linux flavors of my binary distribution, I'd like to be able to support a "build once, support many" paradigm. ie, if I could make one binary to support many different Linux distributions (Fedora, Debian, RHEL, SuSE, Mandiva/Mandrake, etc) and many different versions of each distribution (FC 1, 2, 3, 4, 5), I feel like I could save myself a lot of headache running different builds on all these platforms. At the very least, I'd like to not have to make a different build for every single Fedora flavor. Alas, I suspect this boils down to which "native, Linux-system" libraries does my app/apps/libraries depend on? Is there implicit kernel-level dependence in this scenario? Is it more then libc/libc++/etc? Where can I read more about this? This is the area for which I'm least experienced and knowledgeable. To be clear: I still want to make separate, "native," .rpm and .deb packages (and any other packages I need to support for Linux distros), but if they could all use the same underlying binary...and we could do this reliably and consistently with no problems...it would seem to make our life a lot easier. I see mature projects (like CMake) use one binary tarball (again, I'm not saying I'm going to distribute in a tarball-only fashion) for all Linux distros, so I'm hopeful this can be done. ------------------------------------------------------------------ -- 3) Ensure our libraries integrate w/ other software projects -- ------------------------------------------------------------------ We want to provide the core functionality of our project's technology as an "embed-able" library (either in static or dynamic-shared-object/dll fashion). The libtool section of the autoconf manual (<http://www.gnu.org/software/autoconf/manual/index.html>), quoted below, appears to sum up the issues surrounding this...I guess. I have to take libtool's word for it, for I have to experience the library distribution problems in our project that libtool says will happen. But if this helps, then we'll do it. Do any alternatives exist? But what do we do in non-MinGW Windows environments (assuming libtool works with MinGW-based systems at all)? Is there where the Windows' dlltool and similar tools come in? Can anyone point me to good reading for this on the web or elsewhere? The libtool quote as promised: "2.2 Libtool Very often, one wants to build not only programs, but libraries, so that other programs can benefit from the fruits of your labor. Ideally, one would like to produce shared (dynamically linked) libraries, which can be used by multiple programs without duplication on disk or in memory and can be updated independently of the linked programs. Producing shared libraries portably, however, is the stuff of nightmares; each system has its own incompatible tools, compiler flags, and magic incantations. Fortunately, gnu provides a solution: Libtool. Libtool handles all the requirements of building shared libraries for you, and at this time seems to be the only way to do so with any portability. It also handles many other headaches, such as: the interaction of Makefile rules with the variable suffixes of shared libraries, linking reliably with shared libraries before they are installed by the superuser, and supplying a consistent versioning system (so that different versions of a library can be installed or upgraded without breaking binary compatibility)." -Matt --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscribe(a)subversion.tigris.org For additional commands, e-mail: users-help(a)subversion.tigris.org

2 1

multi index sidx.relocate(sidx.end(), si) performance, legality
by bert hubert 03 Apr '06

03 Apr '06

Hi People, Does anybody know if the code below, which relocates an interator to the end() of an index, is legal? I tried delving into the multi_index code but it is over my head. I ask this because begin() is typically valid as an iterator, but end() never is. The code does appear to work. Also, would it be expensive? I think relocating in a sequenced index is about as expensive as swapping pointers, but I'm not sure. The code: typedef multi_index_container< CacheEntry, indexed_by < ordered_unique< composite_key< CacheEntry, member<CacheEntry,string,&CacheEntry::d_qname>, member<CacheEntry,uint16_t,&CacheEntry::d_qtype> > >, ordered_non_unique<const_mem_fun<CacheEntry,uint32_t,&CacheEntry::getTTD> >, sequenced<> > > cache_t; cache_t d_cache; // i is given and a valid iterator to the composite key typedef cache_t::nth_index<2>::type sequence_t; sequence_t& sidx=d_cache.get<2>(); sequence_t::iterator si=d_cache.project<2>(i); sidx.relocate(sidx.end(), si); // does this work? -- http://www.PowerDNS.com Open source, database driven DNS Software http://netherlabs.nl Open and Closed source services

2 1

boost::bind to member variables
by Nico Galoppo 03 Apr '06

03 Apr '06

Hi, what kind of object does boost::bind return when binding to a class member variable ? (as opposed to a member method). Is it a function object too? More in particular, I would like to write a generic free function that applies an operation on a particular member variable, passed in with boost::bind. Something like this: struct A { int value; }; void f(bind_return_type& membervar) { membervar = 3; } A a; f(bind(&A::value, a)); Thanks. --nico -- nico galoppo von borries | address: 105 creel st., chapel hill comp. graphics phd. student | north carolina, 27516 USA UNC, chapel hill | phone: +1 (919) 962-1898 (office) | +1 (919) 942-7609 (home) | email: nico at cs dot unc dot edu | homepage: http://www.ngaloppo.org

4 9

dereferencing cursors
by Louis Lavery 03 Apr '06

03 Apr '06

Hello, I've been reading "The Cursor/Property Map Abstraction" Doc.No: N1873=05-0133 by Dietmar Kühl and David Abrahams. I like the idea of cursors, they're so much simpler than C++ iterators, but I am concerned regarding dereferencing a cursor. Here's the relevant paragraph... "The presence of a dereference operator on cursors might seem strange, since since the goal is to separate access from traversal. For instance, the values of a property map could be read as pm(c) instead of pm(*c). It turns out that the dereference operation is required in order to reasonably support traversal adapters. If you have a property map that accepts foo_cursor arguments, it may not be designed to accept a reverse_cursor<foo_cursor> directly. Like so many others, this problem is solved by adding a level of indirection: dereferencing a cursor yields an intermediate key, and the key type of a traversal adapter is the same as that of its underlying iterator." ...and my concern is that if all cursors yield the same key type then this could lead to hard to find bugs. EG. Suppose we have a property map (pm) of Ts and that it's useful to reverse it but that reversing it requires reversing the Ts[1], not just applying a reverse cursor. I guess we'd wrap pm in a reversed property map (rpm) that supplies its own cursors (rc), some thing like... t = pm(*c); // forward access t = rpm(*rc); // reversed access - returns reversed t ...but, of course, there's nothing to stop... t = pm(*rc); t = rpm(*c); But may be there are other advantages that outweight this drawback? I'd be interested to know. Also, has there been any further work on the proposal? Thanks, Louis. [1] EG. Reversing a 2D curve made from arcs of circles could well require reversing the direction of the returned arcs.

2 1

[format][patch][1.33.1][SunPro11] missing static_cast from void* to char*
by Marc Mutz 03 Apr '06

03 Apr '06

Hi, SunPro (tested: v11, with current patches), needs the attached patch to compile the following code: --code-- using boost::format; using boost::str; void foo( const std::string & ); format fmt( "host=%1%,port=%2%" ); const std::string host = ...; const unsigned short port = ...; foo( str( fmt % host % port ) ); --/code-- --- /opt/boost/cc/1.33.1/include/boost-1_33_1/boost/format/alt_sstream_impl.hpp~ Sun Feb 27 03:06:57 2005 +++ /opt/boost/cc/1.33.1/include/boost-1_33_1/boost/format/alt_sstream_impl.hpp Mon Apr 24 18:07:09 2006 @@ -245,7 +245,7 @@ add_size /= 2; if(0 < add_size) { new_size += add_size; - newptr = alloc_.allocate(new_size, is_allocated_? oldptr : 0); + newptr = static_cast<Ch*>(alloc_.allocate(new_size, is_allocated_? oldptr : 0)); } if(0 < prev_size) Thanks, Marc PS: Regarding the API: I don't much like the fact that format::operator% changes the format instance. I would have liked to write "static const format" in the code snippet above. Feels more natural ("do as the ints do"). I see where the design comes from (speed optimization), but speed shouldn't dictate design. Expression templates could be used to speed up the process. -- Marc Mutz -- marc(a)klaralvdalens-datakonsult.se, mutz(a)kde.org Klarälvdalens Datakonsult AB, Platform-independent software solutions

1 0

Re: [Boost-users] Serialization--a peculiar observation regardingoperator<<
by David Klein 03 Apr '06

03 Apr '06

boost-users-bounces(a)lists.boost.org wrote: > The test program below (under boost 1_33, vc71) compiles fine, unless > I change the "#if 1" to "#if 0", in which case it produces this: > error C2679: binary '<<': no operator found which takes a right-hand > operand of type 'double' (or there is no acceptable conversion) > > Can anyone explain why that should happen? A double is a double--why > should '<<' care whether the rhs comes from funcall a variable? > > Note: The test program is clearly a nonsense program (in real life > the role of foo() is played by some public (get-accessor) on klass--a > very common pattern when doing a non-intrusive serialization). But I > did not want to cloud the issue--I wanted to emphasize that the bug, > if it is a bug, seems to have nothing to with klass. > > Thank you. > > Michael Drumheller > -----------------------------------------------------------------begin-- > ------------------------------------------------------------- > #include <fstream> > #include <boost/archive/text_oarchive.hpp> > #include <boost/serialization/split_free.hpp> > class klass {}; > double foo() { return 3.1416; } > namespace boost { namespace serialization { > template<class Archive> > void save(Archive &ar, const klass & b, const unsigned int > ver) > { > #if 1 > double x=foo(); > ar << x; > #else > ar << foo(); > #endif > } > template<class Archive> > void load(Archive &ar, klass & b, const unsigned int > ver){}//N/A for this demo > }} > BOOST_SERIALIZATION_SPLIT_FREE(klass); > void out(const char *testfile, const klass & c) > { > std::ofstream ofs(testfile); > boost::archive::text_oarchive oa(ofs); > oa << c; > } > ----------------------------------------------------------------end----- > ----------------------------------------------------------------- > Michael Drumheller > Boeing Phantom Works > Mathematics and Engineering Analysis > 425.865.3520 michael.drumheller(a)boeing.com > > _______________________________________________ > Boost-users mailing list > Boost-users(a)lists.boost.org > http://lists.boost.org/mailman/listinfo.cgi/boost-users hi michael, try changing: double foo() { return 3.1416; } to const double foo() { return 3.1416; } HTH dave

1 0

Regex question
by Kyle Alons 03 Apr '06

03 Apr '06

std::string in("hello"); std::string exprStr("(.*)"); std::string replStr("goodbye$1"); boost::regex expr(exprStr); std::string out(boost::regex_replace(in, expr, replStr)); printf("%s", out.c_str()); In Boost 1.31, this outputs "goodbyehello". In 1.32+, it outputs "goodbyehellogoodbye". Is it a bug, a by-design breaking change, or? Thanks. -- --------------------- Kyle Alons http://www.kinook.com

2 1

Minimal installation with smart pointers only
by Mateusz Łoskot 02 Apr '06

02 Apr '06

Hi, Today, I tried to extract smart pointers library from Boost tree using bcp tool. Everything seems to work well: 1. I checkouted latest Boost CVS 2. I build bcp without any problems, using VC++ 8.0 3. I run bcp --cvs --list to see how many files are related to smart_ptr.hpp (and shared_ptr.hpp too). 4. Finally, I extracted smart pointers library: d:\boost_cvs> bcp --cvs smart_ptr.hpp d:\tmp\boost-smart_ptr Next, I compiled some examples using this extraction and everything works well. My only question is if this is normal that smart_ptr extraction weight is about 2.8MB ? Are there any options that can be used to make this package smaller? Here is a linsg (looong) of files that I got copied during the extraction process. Could anyone take a look at it and see if there are some files not used which can be safely removed? //////////////////////////////////////////////////////// // START OF THE LIST ./boost/assert.hpp ./boost/checked_delete.hpp ./boost/config ./boost/config/abi ./boost/config/abi/borland_prefix.hpp ./boost/config/abi/borland_suffix.hpp ./boost/config/abi/msvc_prefix.hpp ./boost/config/abi/msvc_suffix.hpp ./boost/config/abi_prefix.hpp ./boost/config/abi_suffix.hpp ./boost/config/auto_link.hpp ./boost/config/compiler ./boost/config/compiler/borland.hpp ./boost/config/compiler/comeau.hpp ./boost/config/compiler/common_edg.hpp ./boost/config/compiler/compaq_cxx.hpp ./boost/config/compiler/digitalmars.hpp ./boost/config/compiler/gcc.hpp ./boost/config/compiler/gcc_xml.hpp ./boost/config/compiler/greenhills.hpp ./boost/config/compiler/hp_acc.hpp ./boost/config/compiler/intel.hpp ./boost/config/compiler/kai.hpp ./boost/config/compiler/metrowerks.hpp ./boost/config/compiler/mpw.hpp ./boost/config/compiler/sgi_mipspro.hpp ./boost/config/compiler/sunpro_cc.hpp ./boost/config/compiler/vacpp.hpp ./boost/config/compiler/visualc.hpp ./boost/config/no_tr1 ./boost/config/no_tr1/complex.hpp ./boost/config/no_tr1/functional.hpp ./boost/config/no_tr1/memory.hpp ./boost/config/no_tr1/utility.hpp ./boost/config/platform ./boost/config/platform/aix.hpp ./boost/config/platform/amigaos.hpp ./boost/config/platform/beos.hpp ./boost/config/platform/bsd.hpp ./boost/config/platform/cygwin.hpp ./boost/config/platform/hpux.hpp ./boost/config/platform/irix.hpp ./boost/config/platform/linux.hpp ./boost/config/platform/macos.hpp ./boost/config/platform/qnxnto.hpp ./boost/config/platform/solaris.hpp ./boost/config/platform/win32.hpp ./boost/config/posix_features.hpp ./boost/config/requires_threads.hpp ./boost/config/select_compiler_config.hpp ./boost/config/select_platform_config.hpp ./boost/config/select_stdlib_config.hpp ./boost/config/stdlib ./boost/config/stdlib/dinkumware.hpp ./boost/config/stdlib/libcomo.hpp ./boost/config/stdlib/libstdcpp3.hpp ./boost/config/stdlib/modena.hpp ./boost/config/stdlib/msl.hpp ./boost/config/stdlib/roguewave.hpp ./boost/config/stdlib/sgi.hpp ./boost/config/stdlib/stlport.hpp ./boost/config/stdlib/vacpp.hpp ./boost/config/suffix.hpp ./boost/config/user.hpp ./boost/config.hpp ./boost/current_function.hpp ./boost/detail ./boost/detail/atomic_count.hpp ./boost/detail/atomic_count_gcc.hpp ./boost/detail/atomic_count_pthreads.hpp ./boost/detail/atomic_count_win32.hpp ./boost/detail/bad_weak_ptr.hpp ./boost/detail/interlocked.hpp ./boost/detail/lightweight_mutex.hpp ./boost/detail/lwm_nop.hpp ./boost/detail/lwm_pthreads.hpp ./boost/detail/lwm_win32_cs.hpp ./boost/detail/quick_allocator.hpp ./boost/detail/shared_array_nmt.hpp ./boost/detail/shared_count.hpp ./boost/detail/shared_ptr_nmt.hpp ./boost/detail/sp_counted_base.hpp ./boost/detail/sp_counted_base_cw_ppc.hpp ./boost/detail/sp_counted_base_gcc_ia64.hpp ./boost/detail/sp_counted_base_gcc_ppc.hpp ./boost/detail/sp_counted_base_gcc_x86.hpp ./boost/detail/sp_counted_base_nt.hpp ./boost/detail/sp_counted_base_pt.hpp ./boost/detail/sp_counted_base_w32.hpp ./boost/detail/sp_counted_impl.hpp ./boost/detail/workaround.hpp ./boost/enable_shared_from_this.hpp ./boost/intrusive_ptr.hpp ./boost/mpl ./boost/mpl/aux_ ./boost/mpl/aux_/adl_barrier.hpp ./boost/mpl/aux_/arity.hpp ./boost/mpl/aux_/config ./boost/mpl/aux_/config/adl.hpp ./boost/mpl/aux_/config/arrays.hpp ./boost/mpl/aux_/config/ctps.hpp ./boost/mpl/aux_/config/dtp.hpp ./boost/mpl/aux_/config/eti.hpp ./boost/mpl/aux_/config/gcc.hpp ./boost/mpl/aux_/config/integral.hpp ./boost/mpl/aux_/config/intel.hpp ./boost/mpl/aux_/config/lambda.hpp ./boost/mpl/aux_/config/msvc.hpp ./boost/mpl/aux_/config/nttp.hpp ./boost/mpl/aux_/config/overload_resolution.hpp ./boost/mpl/aux_/config/preprocessor.hpp ./boost/mpl/aux_/config/static_constant.hpp ./boost/mpl/aux_/config/ttp.hpp ./boost/mpl/aux_/config/workaround.hpp ./boost/mpl/aux_/integral_wrapper.hpp ./boost/mpl/aux_/lambda_arity_param.hpp ./boost/mpl/aux_/lambda_support.hpp ./boost/mpl/aux_/na.hpp ./boost/mpl/aux_/na_fwd.hpp ./boost/mpl/aux_/na_spec.hpp ./boost/mpl/aux_/nttp_decl.hpp ./boost/mpl/aux_/preprocessor ./boost/mpl/aux_/preprocessor/def_params_tail.hpp ./boost/mpl/aux_/preprocessor/enum.hpp ./boost/mpl/aux_/preprocessor/filter_params.hpp ./boost/mpl/aux_/preprocessor/params.hpp ./boost/mpl/aux_/preprocessor/sub.hpp ./boost/mpl/aux_/preprocessor/tuple.hpp ./boost/mpl/aux_/static_cast.hpp ./boost/mpl/aux_/template_arity_fwd.hpp ./boost/mpl/aux_/value_wknd.hpp ./boost/mpl/aux_/yes_no.hpp ./boost/mpl/bool.hpp ./boost/mpl/bool_fwd.hpp ./boost/mpl/if.hpp ./boost/mpl/int.hpp ./boost/mpl/integral_c.hpp ./boost/mpl/integral_c_fwd.hpp ./boost/mpl/integral_c_tag.hpp ./boost/mpl/int_fwd.hpp ./boost/mpl/lambda_fwd.hpp ./boost/mpl/limits ./boost/mpl/limits/arity.hpp ./boost/mpl/size_t.hpp ./boost/mpl/size_t_fwd.hpp ./boost/mpl/void_fwd.hpp ./boost/non_type.hpp ./boost/preprocessor ./boost/preprocessor/arithmetic ./boost/preprocessor/arithmetic/add.hpp ./boost/preprocessor/arithmetic/dec.hpp ./boost/preprocessor/arithmetic/inc.hpp ./boost/preprocessor/arithmetic/sub.hpp ./boost/preprocessor/array ./boost/preprocessor/array/data.hpp ./boost/preprocessor/array/elem.hpp ./boost/preprocessor/array/size.hpp ./boost/preprocessor/cat.hpp ./boost/preprocessor/comma_if.hpp ./boost/preprocessor/config ./boost/preprocessor/config/config.hpp ./boost/preprocessor/control ./boost/preprocessor/control/detail ./boost/preprocessor/control/detail/dmc ./boost/preprocessor/control/detail/dmc/while.hpp ./boost/preprocessor/control/detail/edg ./boost/preprocessor/control/detail/edg/while.hpp ./boost/preprocessor/control/detail/msvc ./boost/preprocessor/control/detail/msvc/while.hpp ./boost/preprocessor/control/detail/while.hpp ./boost/preprocessor/control/expr_iif.hpp ./boost/preprocessor/control/if.hpp ./boost/preprocessor/control/iif.hpp ./boost/preprocessor/control/while.hpp ./boost/preprocessor/debug ./boost/preprocessor/debug/error.hpp ./boost/preprocessor/detail ./boost/preprocessor/detail/auto_rec.hpp ./boost/preprocessor/detail/check.hpp ./boost/preprocessor/detail/dmc ./boost/preprocessor/detail/dmc/auto_rec.hpp ./boost/preprocessor/detail/is_binary.hpp ./boost/preprocessor/empty.hpp ./boost/preprocessor/enum_params.hpp ./boost/preprocessor/facilities ./boost/preprocessor/facilities/empty.hpp ./boost/preprocessor/facilities/identity.hpp ./boost/preprocessor/identity.hpp ./boost/preprocessor/inc.hpp ./boost/preprocessor/iterate.hpp ./boost/preprocessor/iteration ./boost/preprocessor/iteration/detail ./boost/preprocessor/iteration/detail/bounds ./boost/preprocessor/iteration/detail/bounds/lower1.hpp ./boost/preprocessor/iteration/detail/bounds/lower2.hpp ./boost/preprocessor/iteration/detail/bounds/lower3.hpp ./boost/preprocessor/iteration/detail/bounds/lower4.hpp ./boost/preprocessor/iteration/detail/bounds/lower5.hpp ./boost/preprocessor/iteration/detail/bounds/upper1.hpp ./boost/preprocessor/iteration/detail/bounds/upper2.hpp ./boost/preprocessor/iteration/detail/bounds/upper3.hpp ./boost/preprocessor/iteration/detail/bounds/upper4.hpp ./boost/preprocessor/iteration/detail/bounds/upper5.hpp ./boost/preprocessor/iteration/detail/finish.hpp ./boost/preprocessor/iteration/detail/iter ./boost/preprocessor/iteration/detail/iter/forward1.hpp ./boost/preprocessor/iteration/detail/iter/forward2.hpp ./boost/preprocessor/iteration/detail/iter/forward3.hpp ./boost/preprocessor/iteration/detail/iter/forward4.hpp ./boost/preprocessor/iteration/detail/iter/forward5.hpp ./boost/preprocessor/iteration/detail/iter/reverse1.hpp ./boost/preprocessor/iteration/detail/iter/reverse2.hpp ./boost/preprocessor/iteration/detail/iter/reverse3.hpp ./boost/preprocessor/iteration/detail/iter/reverse4.hpp ./boost/preprocessor/iteration/detail/iter/reverse5.hpp ./boost/preprocessor/iteration/detail/local.hpp ./boost/preprocessor/iteration/detail/rlocal.hpp ./boost/preprocessor/iteration/detail/self.hpp ./boost/preprocessor/iteration/detail/start.hpp ./boost/preprocessor/iteration/iterate.hpp ./boost/preprocessor/iteration/local.hpp ./boost/preprocessor/iteration/self.hpp ./boost/preprocessor/list ./boost/preprocessor/list/adt.hpp ./boost/preprocessor/list/append.hpp ./boost/preprocessor/list/detail ./boost/preprocessor/list/detail/dmc ./boost/preprocessor/list/detail/dmc/fold_left.hpp ./boost/preprocessor/list/detail/edg ./boost/preprocessor/list/detail/edg/fold_left.hpp ./boost/preprocessor/list/detail/edg/fold_right.hpp ./boost/preprocessor/list/detail/fold_left.hpp ./boost/preprocessor/list/detail/fold_right.hpp ./boost/preprocessor/list/fold_left.hpp ./boost/preprocessor/list/fold_right.hpp ./boost/preprocessor/list/for_each_i.hpp ./boost/preprocessor/list/reverse.hpp ./boost/preprocessor/list/transform.hpp ./boost/preprocessor/logical ./boost/preprocessor/logical/and.hpp ./boost/preprocessor/logical/bitand.hpp ./boost/preprocessor/logical/bool.hpp ./boost/preprocessor/logical/compl.hpp ./boost/preprocessor/punctuation ./boost/preprocessor/punctuation/comma.hpp ./boost/preprocessor/punctuation/comma_if.hpp ./boost/preprocessor/repeat.hpp ./boost/preprocessor/repetition ./boost/preprocessor/repetition/detail ./boost/preprocessor/repetition/detail/dmc ./boost/preprocessor/repetition/detail/dmc/for.hpp ./boost/preprocessor/repetition/detail/edg ./boost/preprocessor/repetition/detail/edg/for.hpp ./boost/preprocessor/repetition/detail/for.hpp ./boost/preprocessor/repetition/detail/msvc ./boost/preprocessor/repetition/detail/msvc/for.hpp ./boost/preprocessor/repetition/enum_params.hpp ./boost/preprocessor/repetition/for.hpp ./boost/preprocessor/repetition/repeat.hpp ./boost/preprocessor/slot ./boost/preprocessor/slot/detail ./boost/preprocessor/slot/detail/counter.hpp ./boost/preprocessor/slot/detail/def.hpp ./boost/preprocessor/slot/detail/shared.hpp ./boost/preprocessor/slot/detail/slot1.hpp ./boost/preprocessor/slot/detail/slot2.hpp ./boost/preprocessor/slot/detail/slot3.hpp ./boost/preprocessor/slot/detail/slot4.hpp ./boost/preprocessor/slot/detail/slot5.hpp ./boost/preprocessor/slot/slot.hpp ./boost/preprocessor/tuple ./boost/preprocessor/tuple/eat.hpp ./boost/preprocessor/tuple/elem.hpp ./boost/preprocessor/tuple/rem.hpp ./boost/preprocessor/tuple/to_list.hpp ./boost/scoped_array.hpp ./boost/scoped_ptr.hpp ./boost/shared_array.hpp ./boost/shared_ptr.hpp ./boost/smart_ptr.hpp ./boost/static_assert.hpp ./boost/throw_exception.hpp ./boost/type.hpp ./boost/type_traits ./boost/type_traits/add_reference.hpp ./boost/type_traits/alignment_of.hpp ./boost/type_traits/broken_compiler_spec.hpp ./boost/type_traits/config.hpp ./boost/type_traits/detail ./boost/type_traits/detail/bool_trait_def.hpp ./boost/type_traits/detail/bool_trait_undef.hpp ./boost/type_traits/detail/cv_traits_impl.hpp ./boost/type_traits/detail/false_result.hpp ./boost/type_traits/detail/ice_and.hpp ./boost/type_traits/detail/ice_eq.hpp ./boost/type_traits/detail/ice_not.hpp ./boost/type_traits/detail/ice_or.hpp ./boost/type_traits/detail/is_function_ptr_helper.hpp ./boost/type_traits/detail/is_function_ptr_tester.hpp ./boost/type_traits/detail/is_mem_fun_pointer_impl.hpp ./boost/type_traits/detail/is_mem_fun_pointer_tester.hpp ./boost/type_traits/detail/size_t_trait_def.hpp ./boost/type_traits/detail/size_t_trait_undef.hpp ./boost/type_traits/detail/template_arity_spec.hpp ./boost/type_traits/detail/type_trait_def.hpp ./boost/type_traits/detail/type_trait_undef.hpp ./boost/type_traits/detail/wrap.hpp ./boost/type_traits/detail/yes_no_type.hpp ./boost/type_traits/ice.hpp ./boost/type_traits/integral_constant.hpp ./boost/type_traits/intrinsics.hpp ./boost/type_traits/is_abstract.hpp ./boost/type_traits/is_arithmetic.hpp ./boost/type_traits/is_array.hpp ./boost/type_traits/is_class.hpp ./boost/type_traits/is_convertible.hpp ./boost/type_traits/is_enum.hpp ./boost/type_traits/is_float.hpp ./boost/type_traits/is_function.hpp ./boost/type_traits/is_integral.hpp ./boost/type_traits/is_member_function_pointer.hpp ./boost/type_traits/is_member_pointer.hpp ./boost/type_traits/is_pod.hpp ./boost/type_traits/is_pointer.hpp ./boost/type_traits/is_polymorphic.hpp ./boost/type_traits/is_reference.hpp ./boost/type_traits/is_same.hpp ./boost/type_traits/is_scalar.hpp ./boost/type_traits/is_union.hpp ./boost/type_traits/is_void.hpp ./boost/type_traits/remove_cv.hpp ./boost/type_traits/remove_reference.hpp ./boost/type_traits/type_with_alignment.hpp ./boost/version.hpp ./boost/weak_ptr.hpp ./libs/smart_ptr ./libs/smart_ptr/src ./libs/smart_ptr/src/sp_collector.cpp ./libs/smart_ptr/src/sp_debug_hooks.cpp // END OF THE LIST //////////////////////////////////////////////////////// Thanks in advance -- Mateusz Łoskot http://mateusz.loskot.net

3 4

multi_array operations.
by chun ping wang 01 Apr '06

01 Apr '06

2 question: Hi, i would like to know are there any easy way to do multi_array math operation on ones of same dimension and size.. #include <boost/multi_array.hpp> template <class T, int N> typename DimArray<T, N>::ndimarr array_minus(const typename DimArray<T, N>::ndimarr& A, const typename DimArray<T, N>::ndimarr& B) { typename DimArray<T, N>::ndimarr temp(A); typedef typename DimArray<T, N>::size TDS; const TDS outer_sz(A.size()); const TDS inner_sz(A[0].size()); for (TDS i = 0; i < outer_sz; ++i) { for (TDS j = 0; j < inner_sz; ++j) { temp[i][j] -= B[i][j]; } } return temp; } question 2: How do you find a index of an item where a specify condition is true. given this... template <class T> bool isSafe(const typename DimArray<T, 2>::ndimarr& MAX, const typename DimArray<T, 2>::ndimarr& Alloc, const typename DimArray<T, 2>::ndimarr& Need, const typename DimArray<T, 1>::ndimarr& Available) { typename DimArray<T, 1>::ndimarr Work(Available); typename DimArray<bool, 1>::ndimarr Finish(boost::extents[Need[0].size()]); typedef typename DimArray<T, 2>::size TDS; const TDS outer_sz(MAX.size()); const TDS inner_sz(MAX[0].size()); for(TDS i = 0; i < inner_sz; ++i) Finish[i] = false; } Is there a effective and safe way to find i such that Need[i] <= Work other than a loop. Thanks for the help.

1 0