- Boost - lists.boost.org

Re: [boost] alignment problem in proposed any alternative
by felipe 11 Aug '05

11 Aug '05

Nope, this is totally wrong! chars and arrays of type char are generally the least aligned objects. You can demonstrate that this doesn't work with something like this: void blah() { char c[/* some number */]; any<8> a((double)1.0); std::cout << &a << std::endl; } Tweak the size of c[] until you get &a % 8 != 0. Some compilers optimize stack layout, over-aligning data, but this is true only for SOME compilers on SOME processors with SOME optimization settings. (You can also experiment by defining an additional char variable before the buffer in your any. Where does &a.buffer lie?) I think you are misreading 3.9.2: it is talking about pointers, namely that void * and char * have the same storage and alignment requirements. On Wed, 10 Aug 2005 20:27:16 +0200, <boost-request(a)lists.boost.org> wrote: > From: "christopher diggins" <cdiggins(a)videotron.ca> > To: "Boost mailing list" <boost(a)lists.boost.org> > Sent: Wednesday, August 10, 2005 1:30 AM > Subject: [boost] alignment problem in proposed any alternative >> The question I have is whether in practice though are there are any >> compilers which have stricter alignment requirements on small types (<= >> sizeof(void*)) than a void pointer. In other words, is it possible with >> any >> known compiler to actually throw the runtime error ? > Now a moot point, see below. > >> Unfortunately there is another problem, I am not an expert in >> interepreting >> the standard, but AFAICT placement new is guaranteed to return a pointer >> to >> properly aligned memory (3.7.3.1 / 2) which I leverage to check that >> alignment occured. Apparently not every STL implementation does in fact >> do >> that (I believe at least dinkumware is guilty of that). > Apparently I am wrong about this! 18.4.1.3 provides an exception. (I > wonder > why I missed the exception 15 chapters later?) > Anyway it turns out we can guarantee alignment by simply using a char > buffer. According to 3.9/2 the following automatically has no alignment > problems: > template<int buffer_size> > struct any { > char buffer[buffer_size]; > ... > template<typename T> > any(const T& x) { > if (boost::is_pod<T>::value && (sizeof(T) <= buffer_size)) { > memcpy(buffer, &T, N); > } > else { > // new and stuff > } > } > } > Christopher Diggins -- Using Opera's revolutionary e-mail client: http://www.opera.com/m2/

3 2

[1.33.0] Release candidate #2 is available
by Douglas Gregor 11 Aug '05

11 Aug '05

Boost 1.33.0 release candidate #2 is now available at the usual place: http://www.osl.iu.edu/~dgregor/boost-1.33.0/ Please build it, test it, and report back to the mailing list. If no major problems are found before August 9th, this release candidate will become Boost 1.33.0. Doug Gregor 1.33.0 Release Manager

12 19

Compilation error with regex only with -O3 on gcc
by robert kraus 11 Aug '05

11 Aug '05

Hi, when I compile with: -O0 to -O2 my programs compile and work fine, but when I switch to -O3 I get compilation errors (shortened, see below). Is this my fault (maybe I shouldnt use optimizations? thank you very much for your answers ido fedora core 4,gcc version: Target: i386-redhat-linux Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-libgcj-multifile --enable-languages=c,c++,objc,java,f95,ada --enable-java-awt=gtk --with-java-home=/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre --host=i386-redhat-linux Thread model: posix gcc version 4.0.1 20050727 (Red Hat 4.0.1-5) boost: boost-devel-1.32.0-6 Errors: Building file: ../src/Parser.cpp Invoking: GCC C++ Compiler g++ -DDEBUG -O3 -g3 -pedantic -Wall -c -fmessage-length=0 -osrc/Parser.o ../src/Parser.cpp /usr/include/boost/regex/v4/regex_compile.hpp: In member function ‘boost::re_detail::re_syntax_base* boost::reg_expression<charT, traits, Allocator>::compile_set_simple(boost::re_detail::re_syntax_base*, long unsigned int, bool) [with charT = char, traits = boost::regex_traits<char>, Allocator = std::allocator<char>]’: /usr/include/boost/regex/v4/regex_compile.hpp:1635: instantiated from ‘unsigned int boost::reg_expression<charT, traits, Allocator>::set_expression(const charT*, const charT*, boost::regex_constants::syntax_option_type) [with charT = char, traits = boost::regex_traits<char>, Allocator = std::allocator<char>]’ /usr/include/boost/regex/v4/basic_regex.hpp:238: instantiated from ‘unsigned int boost::reg_expression<charT, traits, Allocator>::set_expression(const charT*, boost::regex_constants::syntax_option_type) [with charT = char, traits = boost::regex_traits<char>, Allocator = std::allocator<char>]’ /usr/include/boost/regex/v4/regex_compile.hpp:110: instantiated from ‘boost::reg_expression<charT, traits, Allocator>::reg_expression(const charT*, boost::regex_constants::syntax_option_type, const Allocator&) [with charT = char, traits = boost::regex_traits<char>, Allocator = std::allocator<char>]’ /usr/include/boost/regex/v4/basic_regex.hpp:340: instantiated from ‘boost::basic_regex<charT, traits, Allocator>::basic_regex(const charT*, typename boost::reg_expression<charT, traits, Allocator>::flag_type, const Allocator&) [with charT = char, traits = boost::regex_traits<char>, Allocator = std::allocator<char>]’ ../src/Parser.cpp:16: instantiated from here __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

3 2

Re: [boost] [format] Inconsistency with printf
by martin.ecker＠tab.at 11 Aug '05

11 Aug '05

Sorry about the previous, empty e-mail. We were having mail server problems at my company. Below is the content of my original mail: Hello, The following sample program: #include <cstdio> #include <iostream> #include <limits> #include <boost/format.hpp> int main(int argc, char* argv[]) { std::cout << boost::format("%f") % std::numeric_limits<float >::infinity() << std::endl; std::printf("%f", std::numeric_limits<float>::infinity()); return 0; } produces 1.00000000000000000000000000....00000000000000000.#INF00 with Boost.Format, but 1.#INF00 with printf. Is this a bug or shouldn't I expect the same behavior from Boost.Format for special floating point values such as NaN and infinity? Note that using %g instead of %f, that is: std::cout << boost::format("%g") % std::numeric_limits<float>::infinity() << std::endl; prints the same thing as printf, i.e. 1.#INF00 This is using Boost 1.32.0 with MSVC 7.1 on Windows. Best Regards, Martin TAB Austria Haiderstraße 40 4052 Ansfelden Austria Phone: +43 7229 78040-218 Fax: +43 7229 78040-209 E-mail: martin.ecker(a)tab.at http://www.tab.at

1 0

Re: [boost] surveying async network io libraries
by Matthew Nourse 11 Aug '05

11 Aug '05

>On 8/10/05, Jose <jmalv04_at_[hidden]> wrote: > >The asio library really looks quite nice. It appears simple to use, >is 100% header-based, doesn't require the use of threads, and uses the >most scalable event demultiplexor supplied by the OS (epoll on Linux >in the 0.3x version and IOCP on Windows). Its a very nice little >library! Thanks for linking to it. I think I'm in love :-) I've been writing asio apps for a closed-source software company for the last 16 months. With asio, I've written: * a custom HTTP proxy that has been running in production non-stop since October last year * an HTTP<->XMPP gateway * a simple asio-based HTTP load test tool (so I can simulate 20,000 simultaneous HTTP "clients" from a single process) * a publish/subscribe server with a simple binary protocol- am still trying to performance tune other code so I can find the limits of this, so far 500 messages/sec doesn't cause any detectable CPU usage on a 3GHz P4. * A second custom HTTP proxy- this one does some authentication as well. The first application runs on Windows and the rest run on Debian Linux. They all share HTTP/networking code where applicable. All applications use boost::bind and boost::shared_ptr extensively and the publish/subscribe server uses boost::regex to figure out how to route requests. I am addicted to asio. I can't stop using it ;-). Matt

1 0

Interest for a perl6-like-junctions-class?
by FlSt＠gmx.de 11 Aug '05

11 Aug '05

Hi! The new Perl 6 has a nice feature called junctions. See http://www.perl.com/pub/a/2003/07/29/exegesis6.html?page=4 and http://www.metaperl.com/talks/p6-junctions/ for more information. I think this is a interesting way to save the time for writing loops in some situations. I've tried to implement this for C++ and uploaded a version with two examples into the Boost Sandbox File Vault (flos_super_position.zip). This version works for my purposes, but if you interested i would rework it and submit it to the boost library. Sincerely, Florian S.

13 95

shared_ptr and threads
by Timothy Ritchey 11 Aug '05

11 Aug '05

We are using shared_ptr extensively in our application, and seem to be having some threading issues. In particular, we have an Envelope class that is used to hold messages received over the network. We use Spirit to parse the message string and construct the Envelope object, then we pass is on to the EnvelopeController, which holds a thread pool to handle all of the Envelopes. These Envelopes are passed around as shared_ptr<Envelope> between these different components. In essense, we have one thread that is receiving the message from the network stack, parsing it, and passing it to the thread_pool, which is then using one (or more) additional threads to actually deal with the contents of the envelope. On a Uni-processor box, everything works great. All of our envelopes are being destroyed properly. On a multi-processor machine, none of the envelopes are getting destroyed. We are in a situation where two shared_ptrs to the same underlying object may go out of scope and need to decrement the ref count at the same time. Is the in the realm of "undefined behavior?" Am I using the shared_ptr incorrectly? Thanks for any advice. Thread 1 --------- { shared_ptr<Envelope> envelope(new Envelope(...)); ... [pass envelope to Thread 2] ... [envelope goes out of scope] } Thread 2 -------- void process(shared_ptr<Envelope> envelope) { [do work on envelope] [envelope goes out of scope] }

2 2

[Boost-bugs] [ boost-Bugs-1256121 ] 1.33 R1/R2's shared_ptr crashes due to inlining in CW PPC
by SourceForge.net 10 Aug '05

10 Aug '05

Bugs item #1256121, was opened at 2005-08-10 12:29 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=1256121&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: smart_ptr Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Peter Dimov (pdimov) Summary: 1.33 R1/R2's shared_ptr crashes due to inlining in CW PPC Initial Comment: Hello. My name is John Daub, email: hsoi(a)hsoi.com. I am using CodeWarrior Pro 9.5 on a dual G5/2GHz PowerMac (PPC). I believe the version of boost that I am using is 1.33 R1 as version.hpp says 1.33 and since 1.33 R2 was released only 2 days ago, I figure I must be using R1 (I didn't put boost into our CVS repository... someone else did that so I can't say what version of boost I have any more than that). However, I did check the 1.33 R2 and it seems to have the same problem. Going back to 1.32 however, I do not have the problem. It appears to be something introduced in 1.33. The problem stems from my use of the boost::shared_ptr class, and then ultimately how shared_ptr uses sp_counted_base to track the useCount. It seems boost 1.33 has introduced compiler and processor specific implementations of sp_counted_base. In the CodeWarrior PPC version (boost/detail/ sp_counted_base_cw_ppc.hpp) there are 3 inline functions: atomic_increment, atomic_decrement, atomic_conditional_increment. These 3 inline functions use inline assembly to do their work. That's fine. However, if you set the CW compiler to build with "don't inline", things work out fine. You can run and play and no problems. If however you set the CW compiler to "smart" inlining, then you will crash because these atomic functions don't work for some reason. FWIW, the other inlining options are set as follows: auto-inline is off, deferred inling is off, bottom-up inlining is on. You should be able to reproduce this yourself. I used my CW Pro 9.5 install and created a new project based upon the Mac OS C++ Stationery (the Mac OS Carbon, Standard Console, C++ Console Carbon, stationery). I added an access path to my boost library folder, and I added your own test file from boost-distro/libs/ smart_ptr/shared_ptr_test.cpp to the project. I changed nothing else about the project... just stock CodeWarrior stationery. If you ensure inlining is set to "don't inline", build, and it runs fine. If you then go back, change the setting to "smart" inlining, rebuild, and then run, you should see the console window comes up, some stuff appears in the window but quickly things crash. The problem is the useCount doesn't seem to increment, so when it later decrements, the count is off and things go wrong. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1256121&group_… ------------------------------------------------------- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

Improved boost::any
by christopher diggins 10 Aug '05

10 Aug '05

I have developed a type very similar to boost::any which requires less memory and significantly reduces the number of allocations / deallocations. If anyone is interested I have posted a brief article about it at CodeProject http://www.codeproject.com/useritems/dynamic_typing.asp and I have uploaded the source to the vault ( http://boost-sandbox.sourceforge.net/vault/index.php ). Is there any interest? Christopher Diggins http://www.cdiggins.com

7 14

[Boost-bugs] [ boost-Bugs-1256069 ] 1.32.0 signals and shared_ptr mem-leak bug
by SourceForge.net 10 Aug '05

10 Aug '05

Bugs item #1256069, was opened at 2005-08-10 11: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=1256069&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: smart_ptr Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Peter Dimov (pdimov) Summary: 1.32.0 signals and shared_ptr mem-leak bug Initial Comment: The attached file shows a discrepancy with boost 1.31 and 1.32 when dealing with shared_ptr's and signals. The 1.32 behavior can cause memory leaks in certain conditions. camior(a)gmail.com David J. Sankel ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1256069&group_… ------------------------------------------------------- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0