- Boost - lists.boost.org

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

[test, others..] EOLs and such.
by Rene Rivera 18 Jan '05

18 Jan '05

I was looking at Boost.Test.. did an update.. and noticed the EOLs got messed up recently. So I ran the inspection tools and it found a variety of errors: http://www.boost.org/regression-logs/inspection_report.html -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com - 102708583/icq

2 5

Published books on Boost
by Dave 18 Jan '05

18 Jan '05

Dear Boost Community, I am aware of the books on the graph and template metaprogramming libraries. Are any other books available, or in the works, on Boost libraries? Thank you, Dave

2 1

linker problems, mingw, win2k
by Jacek Pakulski 18 Jan '05

18 Jan '05

Hi; This is my first attempt at using Boost. Thought I'd start with the unit test lib. I tried to make unit_test_framework1.cpp, which compiled but failed to link, producing several errors like the one below: C:/Boost/lib/libboost_unit_test_framework-mgw-s-1_32.lib(test_tools.obj)(.rdata$_ZTISt9exception+0x0):test_tools.cpp: first defined here /mingw/lib/libstdc++.a(vterminate.o)(.text$_ZTSSt9exception+0x0): multiple definition of `typeinfo name for std::exception' I compiled the Boost library using bjam with following options: bjam "-sMINGW_ROOT_DIRECTORY=C:\Dev-Cpp\bin" "-sTOOLS=mingw" "-sBUILD=release <runtime-link>static <threading>single" install Result: ...failed updating 10 targets... ...skipped 3 targets... ...updated 3164 targets... My cmd. to make unit_test_framework1.cpp is: g++ -I"C:\Boost\include\boost-1_32" -L"C:\Boost\lib" C:\Boost\lib\libboost_unit_test_framework-mgw-s-1_32.lib -o boost_test.exe boost_test.o Thank You for Your patience and help Jacek <http://www.boost.org/libs/test/example/unit_test_example1.cpp>

1 1

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

18 Jan '05

> -----Original Message----- > From: christopher diggins [mailto:cdiggins@videotron.ca] > Cc: Brian Braatz > Subject: Re: [boost] Re: Functions as Filters (was Program Reuse...) > > ----- Original Message ----- > From: "Brian Braatz" <brianb(a)rmtg.com> > > 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. > > It is hard to not be insulted by your suggestions that I don't understand > the topics, that I am unwilling to accept new ideas, and that I need to > read > more books. I have said it before on this list, and I will say it to you: > I > would suggest that you do not jump to conclusions about my (or anyone > else's) lack of knowledge on a subject. I am far more familiar with > generic > programming than you probably realize. This kind of innuendo accomplishes > little, except aggravation. It also makes the Boost mailing list a very > inhospitable place. > [Brian Braatz] Chris, I was not trying to insult you. From my perspective: You had suggested using a global variable for something that someone else suggested making a template. You had repeatedly said things along the lines of "I Don't understand, why not make it a global". What I saw was a good argument for making things easy, but I did not get the sense that they power of the template was clear. I then suggested the book that I did. Not because I was jumping to conclusions. I suggested it based on the context of the conversation. I believe if you read Andrei's book (Modern C++ design), it will make the perspective of the people who were disagreeing with you more clear. That was neither an insult, or a jump to a conclusion. It was merely a suggestion from someone trying to help you NOT feel like this list is an inhospitable place.

1 0

[config] Single threaded builds with g++ >= 3.4: No longer possible?
by Andreas Huber 18 Jan '05

18 Jan '05

Hi there >From boost/config/stdlib/libstdcpp3.hpp: <quote> #ifdef __GLIBCXX__ // gcc 3.4 and greater: # ifdef _GLIBCXX_HAVE_GTHR_DEFAULT // // If the std lib has thread support turned on, then turn it on in Boost // as well. We do this because some gcc-3.4 std lib headers define _REENTANT // while others do not... // # define BOOST_HAS_THREADS # else # define BOOST_DISABLE_THREADS # endif #endif </quote> I suspect this means that ST builds are no longer possible on some GCC platforms (I'm using MinGW). Could someone please confirm or deny this? Thanks & Regards, -- Andreas Huber When replying by private email, please remove the words spam and trap from the address shown in the header.

2 2

ill-formed XML in boost::unit_test logger
by Mikhail Gusarov 18 Jan '05

18 Jan '05

Unit testing library creates invalid XML when asked about XML logging output, like this: --------------------------------------- <TestSuite name="TaskQueue tests"> </TestSuite="TaskQueue tests"> --------------------------------------- This is a trivial 'missing braces' bug which can be fixed by the patching libs/test/src/supplied_log_formatters.cpp. Patch is attached. -- Mikhail Gusarov ICQ UIN: 111575219 JID dottedmag(a)jabber.ru --- supplied_log_formatters.cpp.old 2005-01-17 17:29:51.000000000 +0600 +++ supplied_log_formatters.cpp 2005-01-17 17:31:13.000000000 +0600 @@ -203,8 +203,9 @@ output << (in_out ? "<" : "</") << ( tc.p_type ? "TestCase" : "TestSuite" ); - if( in_out ) + if( in_out ) { output << " name"; print_attr_value( output, tc.p_name ); + } output << ">";

2 1

RE: [boost] [Gauge for interest] Minimal perfect hash functiongenerator
by Hurd, Matthew 18 Jan '05

18 Jan '05

> Behalf Of Beman Dawes > >At 04:51 AM 1/17/2005, Matt Hurd wrote: > > >Perfect hashing and statistically reasonable hashing are quite > >different but practically the same ;-) > > Isn't that stretching it a bit? Collision handling code can be eliminated > if you know the hashing is perfect, for example. Although I do understand > your point that for many practical applications, perfect hashing and > statistically reasonable hashing would yield very similar performance. My apologies if I caused confusion. I was being a little facetious and assumed the points you make. > Seems like both could have a place in Boost. Yup. And perhaps a third that maps longer "key" sequence types into unique ids suitable for perfect hashing in an efficient way. For example, finding a minimum set of bytes to rotate and xor into a std::size_t that is unique for all keys via a simple decision tree. The size_t is then used for perfect hashing via a generator such as the MPH. This would efficiently meet the needs of a user with a fixed pool of strings or UUIDs, mentioned elsewhere, looking to map to a suitable index. > Statistically reasonable hashing of particular sets of strings has been a > need that I've often run into. Please feel free to take my hash.hpp code into the BSL as the basis for a real implementation that meets your needs w.r.t. a statistically robust but non-perfect hash. It is based on the solution outlined in Java in the articles previously cited. Regards, Matt Hurd matthurd(a)acm.org 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.

3 2