- Boost - lists.boost.org

Re: Singleton
by Dave Handley 19 Jan '05

19 Jan '05

<Jason Hise wrote> > Yay, I finally got the singleton working with allocation and lifetime > policies, in addition to being in CRTP form. I know that threading > policies still remain, however I would like an opinion on what I have so > far. A major difference from Loki is that my lifetime policy needs to > know about the allocation policy in order for dependencies to be > possible to implement. The code is available here: Jason, Great work - I've been away from the list for a couple of days so sorry I didn't get back sooner, but I think you have definitely gone the right way with what you've done up to now. My recommendations for things to look at include: 1) Allocate using malloc as another creation policy 2) Longevity lifetimes 3) Possibly include the ability to turn off phoenix singletons in the dependency lifetime policy. 4) Threading. With all of those, you've almost certainly exceed Loki - especially if you can do them without have to link to any external code. Dave Handley

5 7

RE: [boost] [Gauge for interest] Minimal perfect hashfunctiongenerator
by Hurd, Matthew 19 Jan '05

19 Jan '05

> Behalf Of Hartmut Kaiser <snip> > I've tried to get my hands on the cited papers, but was able to find only > one of them. Could you provide a concrete pointer where to get the Tong > paper from? > The University of Auckland does not have the Uzgalis, Todd technical report "Hashing Myths" online. An overview presentation that is enough to get going is here: http://www.iticse2002.dk/conference/sessionmat/algorithms/1.pdf >From the first slide: The work presented here is almost entirely due to Robert Uzgalas ("Buz"), who single handedly reinvented hashing in the early 1990s. For reasons unknown, Robert never disseminated his work to the wide audience that it deserved. His paper, "Hashing Myths" remains unpublished, and his results are virtually unknown. Here is a snippet related by one of the authors, R. Uzgalis http://www.serve.net/buz/hash.adt/java.000.html Hope that helps, Matt Hurd. IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.

2 1

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