January 2005 - Boost - lists.preview.boost.org

nested lambda question
by Brock Peabody 19 Jan '05

19 Jan '05

Hi, Is there a way to write lambda expressions in the form of: lamba_expression_x < lambda_expression_x without repeating "lambda_expression_x"? I tried this but it didn't work: ( bind(_1, protect(_1)) < bind(_1, protect(_2)) ) (lambda_expression_x) I was trying to sort a vector of objects by a data member: std::sort( v.begin(), b.end(), (&ll::_1 ->* &s::i) < (&ll::_2 ->* &s::i) ); Thanks, Brock

1 0

mail problems
by Vladimir Pozdyayev 19 Jan '05

19 Jan '05

Hello. Seems like boost mailing totally refuses to work with my "ardatur at mail dot ru" address... A couple of months ago I had to resubscribe as <the "from" address> because of this (http://lists.boost.org/mailman/options.cgi/boost/@@@ reported bounces from the destination address), and now I can't register at the vault using the "ardatur at mail dot ru" address (no activation mail). Is that fixable? -- Best regards, Vladimir Pozdyayev.

4 4

[signals] performance
by Neal Coombes 19 Jan '05

19 Jan '05

I just wanted to ping Doug to see if there are any updates on the performance of signals. I also noticed pretty drastic memory performance. Although I haven't benchmarked it thoroughly, I decided to rip out our systems current observer pattern and replace it with signals. For our more ubiquitous app, the memory consuption rose from 110 MB to 350 MB. Even after lazily instantiating Signals through scoped_ptr so they only exist if their specifically connected to, the memory consuption was still at 240MB. (This is all using boost-1.31, gcc-3.3.2, Solaris 9). While I try to figure out where all this memory is being used: Has anyone had any experience with using numerous signals in a large system and found any technique for reducing the impact on memory? Thanks, Neal

1 1

[Boost-bugs] [ boost-Bugs-1105342 ] can't compile with intel-linux (icc 8)
by SourceForge.net 19 Jan '05

19 Jan '05

Bugs item #1105342, was opened at 2005-01-19 17:07 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1105342&group_… Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Akos Maroy (darkeye) Assigned to: Nobody/Anonymous (nobody) Summary: can't compile with intel-linux (icc 8) Initial Comment: I just tried to compile boost (1.31 and 1.32) with intel's icc 8 for Linux, but I can't even get the jam tool to compile. here's what I get, in boost_1_32_0/tools/build/jam_src: $ sh build.sh intel-linux ### ### Using 'intel-linux' toolset. ### rm -rf bootstrap.intel-linux mkdir bootstrap.intel-linux icc -o bootstrap.intel-linux/jam0 command.c compile.c execnt.c execunix.c execvms.c expand.c filent.c fileos2.c fileunix.c filevms.c glob.c hash.c hdrmacro.c headers.c jam.c jambase.c jamgram.c lists.c make.c make1.c newstr.c option.c parse.c pathunix.c pathvms.c regexp.c rules.c scan.c search.c subst.c timestamp.c variable.c modules.c strings.c filesys.c builtins.c pwd.c class.c native.c modules/set.c modules/path.c modules/regex.c modules/property-set.c modules/sequence.c modules/order.c execunix.c(225): warning #266: function declared implicitly if ((pid = vfork()) == 0) ^ execunix.c(227): warning #266: function declared implicitly execvp( argv[0], argv ); ^ execunix.c(228): warning #266: function declared implicitly _exit(127); ^ execunix.c(269): warning #266: function declared implicitly while( ( w = wait( &status ) ) == -1 && errno == EINTR ) ^ fileunix.c(270): warning #266: function declared implicitly lseek(fd, offset + SARHDR, 0); ^ fileunix.c(302): warning #266: function declared implicitly lseek( fd, offset, 0 ); ^ builtins.c(275): warning #266: function declared implicitly init_set(); ^ builtins.c(276): warning #266: function declared implicitly init_path(); ^ builtins.c(277): warning #266: function declared implicitly init_regex(); ^ builtins.c(278): warning #266: function declared implicitly init_property_set(); ^ builtins.c(279): warning #266: function declared implicitly init_sequence(); ^ builtins.c(280): warning #266: function declared implicitly init_order(); ^ native.c(27): warning #266: function declared implicitly lol_build( n.arguments->data, args ); ^ /opt/intel/compiler80/lib/libunwind.a(unwind.o)(.text+0x4e8): In function `_Unwind_Context_copy': : undefined reference to `_intel_fast_memcpy' /opt/intel/compiler80/lib/libunwind.a(unwind32.o)(.text+0x175): In function `VirtualUnwindOneFrame32': : undefined reference to `_intel_fast_memset' /opt/intel/compiler80/lib/libunwind.a(unwind32.o)(.text+0x2c2): In function `VirtualUnwindForArgSize': : undefined reference to `_intel_fast_memset' /opt/intel/compiler80/lib/libunwind.a(dw2-interface.o)(.text+0xbf4): In function `_dw2_execute_cfa_instructions': : undefined reference to `_intel_fast_memcpy' /opt/intel/compiler80/lib/libunwind.a(dw2-interface.o)(.text+0xc42): In function `_dw2_execute_cfa_instructions': : undefined reference to `_intel_fast_memcpy' /opt/intel/compiler80/lib/libunwind.a(dw2-interface.o)(.text+0xd31): In function `_dw2_execute_cfa_instructions': : undefined reference to `_intel_fast_memcpy' /opt/intel/compiler80/lib/libcxa.so.5: undefined reference to `__ashldi3' /opt/intel/compiler80/lib/libcxa.so.5: undefined reference to `__ashrdi3' /opt/intel/compiler80/lib/libcxa.so.5: undefined reference to `__muldi3' ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1105342&group_… ------------------------------------------------------- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

2 1

[string_algo, regex] Fix for reg_expression errors?
by Daniel Schlyder 19 Jan '05

19 Jan '05

The attached patch fixes errors in the Boost String Algorithms library caused by recent changes to Boost.Regex. I'm a newbie when it comes to using templates, therefore I'm not sure whether the patch fixes the problem properly, although it seems to work with my (trivial) code. If it is the correct fix, could someone please apply it. Otherwise, what is the proper way to fix this? Thanks in advance, -- Daniel Schlyder http://bitblaze.com/

2 1

containers
by Jason Hise 19 Jan '05

19 Jan '05

I was thinking about the simpler standard containers... specifically vector, deque, and list, and wondering... would there be any value in making a generic linear_container class which uses policies to define the allocation and iteration methods? Specifically, I imagine something like this: typedef linear_container < contiguous_iterator, alloc_using_new > vector; typedef linear_container < double_linked_iterator, alloc_using_new > list; // etc... The iterator itself could probably be broken down into smaller traits, but the idea is that this would make it much easier to add new types of containers or mix and match existing functionality. Through the linear_container it would be easy to ensure that all types of containers had the same interface (push_back, pop_back, etc...) Thoughts/opinion? -Jason

4 5

Re: Bug#290782: multi_array.hpp: rebasing via range causes a crash while reindex works
by Vassilii Khachaturov 19 Jan '05

19 Jan '05

> > arr a(boost::extents[ arr::extent_range(1, 1) ]); > > I'm not a multi.array user, but this is an invalid range. See > Table 4 [1] Invariants: > o Valid range [a.begin(),a.end()) is a valid range. Thanks. It looks like I have misunderstood the extent_range ctor semantics. Upon re-reading the multi_array reference page in its extent_range section, I see extent_range(index start, index finish) This constructor defines the half open interval [start,finish). The expression finish must be greater than start. (I assumed that finish is included in the interval, hence the snippet.) Vassilii

1 0

Bug#290782: multi_array.hpp: rebasing via range causes a crash while reindex works
by Domenico Andreoli 19 Jan '05

19 Jan '05

hi all, boost debian package version 1.32.0-2 has been reported the following bug. i didn't find anything in the archive. is it a new entry? cheers domenico ----- Forwarded message from Vassilii Khachaturov <vassilii(a)tarunz.org> ----- Date: Sun, 16 Jan 2005 19:06:00 +0200 From: Vassilii Khachaturov <vassilii(a)tarunz.org> Subject: Bug#290782: multi_array.hpp: rebasing via range causes a crash while reindex works When a multi_array rebasing to 1 is attempted via extent_range, a segmentation fault happens on accessing the boundary element. Workaround: use reindex. See the snippet below. The 1.32.0-2 was built locally from the source package. -- Transcript of a crash: vassilii@ilmarinen:$ make t-boost-multiarray-reindex1 g++ -Wall -O3 -g -ansi -pedantic-errors -MMD t-boost-multiarray-reindex1.cpp -o t-boost-multiarray-reindex1 vassilii@ilmarinen:$ ./t-boost-multiarray-reindex1 Segmentation fault -- Test that causes the crash (t-boost-multiarray-reindex1.cpp): #include <boost/multi_array.hpp> int main() { typedef boost::multi_array<float, 1> arr; float pi = 3.14; #ifdef WORKAROUND arr a(boost::extents[ 1 ]); a.reindex(1); #else arr a(boost::extents[ arr::extent_range(1, 1) ]); #endif a[1] = pi; return 0; } ----- End forwarded message ----- -----[ Domenico Andreoli, aka cavok --[ http://people.debian.org/~cavok/gpgkey.asc ---[ 3A0F 2F80 F79C 678A 8936 4FEE 0677 9033 A20E BC50

2 1

RE: [boost] Re: Functions as Filters (was Program Reuse...)
by Brian Braatz 18 Jan '05

18 Jan '05

[christopher diggings ] Reading and writing to cin and cout, is a long established effective practice which results in generic and easily reused code. I am not simply advocating for needs of novice programmers. I am not a novice, but I always want my code to be written as if for novices whereever possible. It is my experience that when writing as if for novices usually results in code which is more easy to maintain, reuse and document. [Jonathan Turkanis] > I was going to mention the global variables, but in fairness I think the > four > global streams have special status. If I could redesign the standard > iostreams > library without concern for backward compatibility, I'd change a number of > things but I'm not sure I'd require users to write > > std::cout::instance() << "Hello World!\n"; > > I'm interested to know exactly what Christopher thinks is too complex > about the > filter concepts, since I'm sure others will share his view. [christopher diggings] I don't think they are too complicated! They do precisely what they should do, the way they should do it. [And now for Brian Braatz's 2 cents] I have been watching this thread with interest. And I find it odd. Yes Odd... I agree that a simple interface is always good to have for novices. And I prefer to provide a "advanced" interface where I can. This is, in general, why I like modern techniques of C++. As with template based techniques, I am more enabled to give the users something easy to get their head around, yet, also provide for the ability to use my concept generically or even alter some key functionality of my concept. (i.e. std::allocator and its usage in STL is a simple example). At the end of the day, I am willing to make my interface "a tad weird for newbies", but exponentially increase the things that can do with my component. What I see though, is Christopher making an argument for dumbed down C++ because many of the developers out there have not yet learned the modern techniques. This is a philosophical discussion at some level. And at that level I partly agree with you in principle. From a boost level though, to me at least, boost is not about "purposely dumbed down so you can use it without having to learn anything new". That would be the opposite of what boost is. At least to me personally, Boost is about the power of generic programming, not purposely making global variables so things are easier for newbies. Learning and using boost requires commitment. (indeed). But the payoff of skills and abilities more than pays for itself. Chris, I suggest to you that you get a copy of the book Modern C++ and really give it a good read. It covers a lot of the new techniques now available to us because our compilers are now more compliant. We don't have to live in the stone ages anymore (applause!). I really get the sense, that if you were to take the time to understand some of the newer ideas on how to write code, you might not feel like everyone is disagreeing with you on this list. There are a number of mind blowing things that can be done with Generic Programming, but you first have to get your head into it and you have to be willing to accept new ideas. > -----Original Message----- > From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] > On Behalf Of christopher diggins > ----- Original Message ----- > From: "Jonathan Turkanis" <technews(a)kangaroologic.com> > > I don't see why this is better than > > > > struct toupper_filter : input_filter { > > template<typename Source> > > int get(Source& src) { return toupper(boost::io::get(src)); } > > }; > > > > and its cousins. > > Then that pretty much closes the discussion. If you do not see the > benefits > of the lower complexity, then there really is little more I can do to > convince you otherwise. > > >> int main() { > >> fstream("input.txt") > Filter(ToUpper); > >> } > > > > This won't work, since fstream("input.txt") produces a temporary object > > which > > cannot be used to initialize a non-const reference. Therefore operator< > > would > > have to be declared to take a const reference, and the non-const > > extraction > > functions would not be usable. > > I already made it work by creating temporary helper objects which take the > address of the temporary objects. > > > I have to go no, but I'll continue this discussion later. > > CD

4 3

[Gauge for interest] Minimal perfect hash function generator
by Hartmut Kaiser 18 Jan '05

18 Jan '05

Hi all, recently I've written a minimal perfect hash function generator, which generates very efficient hashing functions for arbitrary (reasonable large) key sets containing strictly positive integers to achieve a minimal and perfect mapping of these keys to hash values in the range [0..N), where N is the size of the key set (minimality requirement) and the hash values are unique (perfection requirement). IOW, given a set of N arbitrary positve integers (xi > 0) this hash function generator allows to map the integers to another set of integers, the values of which are in between and including 0 and N-1. No duplicate mappings are generated. Generally the developed MPH (minimal perfect hash) generates the coefficients for the following hash functions: h(x) = (C / (D*x + E) mod N or h(x) = (C / x) mod N (D == 1, E == 0) where the second one is choosen almost all the time (generally C, D and E are integers). Especially the second one requires only a couple of instructions to be executed, which makes it a very effective selection alternative for table oriented algorithms. The requirement, that the input keys should be strictly positive isn't a big limitation, because it is always possible to accordingly transform key sets containing possibly negative numbers, or to derive the keys from strings to match. Sounds really perfect! But there are some drawbacks: - the keys (obviously) must be known in advance, so a corresponding hash function may be generated. - some initial computation is required to find the coefficients C, D and E (which is obvious as well :-). The initial overhead is tolerable, though, here are some timings on my machine - Pentium M, 1.6GHz, 1GByte: 20 keys: 0.005 [s], 200 keys: 0.03 [s], 2000 keys: 0.15 [s], 20000 keys: 4.45[s] where the time is raising slightly more worse than linear (actually it has a linear and an exponential component, but the exponential component kicks in for larger key sets only), depending on the number of keys. The memory requirement for the MPH generator is raising linearily with the number of keys: roughly N/3 * sizeof(int), where N is the number of keys. This hash function generator is usable for a wide range of applications, where efficient data lookup is a major goal and where sparse data sets have to be treated efficiently. Is there anybody interested in such a thing? Regards Hartmut

6 12