August 2008 - Boost-users - lists.preview.boost.org

link error trying to open file libboost_date-time-vc71-mt-gd-1_36.lib
by Vincent Buonassisi 26 Aug '08

26 Aug '08

hi, i create the multi-threaded and dll versions of the thread and date_time libraries on windows platform using vc++ 7.1: boost_date_time-vc71-mt-gd-1_36.dll/.lib boost_thread-vc71-mt-gd-1_36.dll/.lib when i link my application it wants the static version of the date_time library. is it possible to change boost so that it uses the dll instead of the static version? thanks, vince

2 1

Re: [Boost-users] [Thread] Beginner question regarding threadgroups
by Mike Marchywka 25 Aug '08

25 Aug '08

Hi, I am afraid that once these papers are published, we no longer have the copyright to it (I know it's weird but that is how academic papers work ...). So they are all on IEEE servers or some other journals. The only thing I could find is a link to some slides for a talk at the NUSOD conference but it is short on details. I have not used cite seer in nearly a decade since the advent of Google Scholar ... We do use geometric optics for this with a few exceptions (i.e. anti-reflection coatings used to increase extraction efficiency use a multi-layer plane wave transfer matrix method to get an effective reflection coefficient). But this is getting a bit off-topic so back on to the code ... The only reason I thought the list would tolerate this was general interest in optimization problems and literature sources. Everyone seems to want to use threads and ignore algorithmic issues that may provide ideas for library code. Certainly not boost specific but could develop into something. Considering a few real examples may be interesting by itself. Sent from my Verizon Wireless BlackBerry

1 0

Re: [Boost-users] [Thread] Beginner question regarding thread groups
by Michel Lestrade 25 Aug '08

25 Aug '08

Hi, I am afraid that once these papers are published, we no longer have the copyright to it (I know it's weird but that is how academic papers work ...). So they are all on IEEE servers or some other journals. The only thing I could find is a link to some slides for a talk at the NUSOD conference but it is short on details. I have not used cite seer in nearly a decade since the advent of Google Scholar ... We do use geometric optics for this with a few exceptions (i.e. anti-reflection coatings used to increase extraction efficiency use a multi-layer plane wave transfer matrix method to get an effective reflection coefficient). But this is getting a bit off-topic so back on to the code ... > Are any of the intro papers on google available as free, full text? That is my reason for going > to citeseer ( as it turns out they even seem to allow text format download ) > AFAIK all of the papers are available for free(IEEE is about the worst in terms of > open access, including for searching with scripts or using computer methods,LOL). > > Are these all homogeneous materials with a few planar discontinuities ? > Offhand it seems you could do a lot analytically with classical geometrical > optics. ================================================================================= Thanks for the code sample. It is not what I envisioned originally but I was not aware that threads were that expensive to create/destroy; this is fancier but makes more sense. I guess this will be my starting point, along with most of the Fortran code that I will be keeping. > > Actually, the while loop lives inside the threads, since creating and > destroying threads is relatively expensive, and you don't need to. > > >> > Did I understand you correctly ? It's a good idea and, from the little I >> > know on the subject, it sounds a lot like a "thread pool". >> > >> > > Yes, it's exactly a thread pool. > > Thanks again, Michel Lestrade Crosslight Software

1 0

Xpressive: UTF-8 and diacritics
by Allan Odgaard 25 Aug '08

25 Aug '08

It looks like the traits aspect of Xpressive is geared toward characters, so I assume that Xpressive is not directly usable with UTF-8 encoded text, am I correct? It might work by having the character type be a 32 bit integer and then use iterator adapters which expose the sequence as ucs-4 code points (after all, the sequence is “encoded”), but that leads me to the next question: diacritics. For example something like é in decomposed unicode is two code points (e followed by a combining ´ mark), so even when the sequence is iterated as ucs-4 code points, a regexp of “.” will match just the e, not the actual (rendered) character. Since I was unable to find any discussion of this while searching for Xpressive, I am curious to hear if any thoughts have gone into these issues.

2 1

[Spirit] C++ Parser library
by Florian Goujeon 25 Aug '08

25 Aug '08

Dear boosters, I post in the mailing list for the first time, so I don't know very much about what could have been said concerning any potential Spirit powered C++ parser. I recently started to develop a C++ parsing library. In the future, I would like to develop an UML tool with round-trip engineering capabilities. Such a library would be the cornerstone of that project. Before I started to develop it, I obviously looked for an similar project in the Internet. I've found this page : http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?BoostSpiritC… which was out of date… until recently. Since BoostSpiritCXXParser seems to start again, I though it could be a good idea to talk about my work with the contributors of this project. First of all, here is a place where you could find a snapshot of my source code: https://git.berlios.de/cgi-bin/gitweb.cgi?p=cppparser;a=summary (Note that the most recent revisions are located on my computer, thanks to GIT). The Spirit grammar is located in src/cppparser/grammar.h file. I'd be pleased to have some comments about it. Regards. Florian

1 0

Re: [Boost-users] [Thread] Beginner question regarding thread
by Michel Lestrade 25 Aug '08

25 Aug '08

Hi, So if I understand your suggestion, I should create a container holding rays yet to be processed and then run a while loop until this queue/container is empty. Within that loop, I create a smaller number of threads by popping rays from the queue and let the threads run until they finish before going on to the next iteration. Did I understand you correctly ? It's a good idea and, from the little I know on the subject, it sounds a lot like a "thread pool". Guess I misunderstood the concept behind thread_group since I thought it was doing that already ... There's even a hardware_concurrency() function to determine the number of cores/cpus which I thought was intended to control how many threads were to be running at once. Regards, Michel Lestrade Crosslight Software > ------------------------------ > > Message: 7 > Date: Sun, 24 Aug 2008 21:56:49 -0400 > From: "Scott McMurray" <me22.ca+boost(a)gmail.com> > Subject: Re: [Boost-users] [Thread] Beginner question regarding thread > groups > To: boost-users(a)lists.boost.org > Message-ID: > <fa28b9250808241856l384711bfw658deaa79ae77d96(a)mail.gmail.com> > Content-Type: text/plain; charset=UTF-8 > > On Sun, Aug 24, 2008 at 18:58, Michel Lestrade > <michel.lestrade(a)crosslight.com> wrote: > >> > >> > I am considering rewriting part of our ray tracing code to use the Boost >> > thread library. As many of you might know, ray tracing is a task that lends >> > itself well to a parallel approach since each ray is independent from the >> > other. However, the code right now is in Fortran which doesn't support task >> > level parallelism easily ... The thread_group class seems ideally suited to >> > my needs (one thread == one ray) but there is at least one problem I >> > envision that I would like to solve before embarking on this fairly >> > time-consuming rewrite. >> > >> > > It's worth pointing out that, as I recall, you don't really want more > continually-active threads than, say, twice your number of cores. It > would be nice to run one thread per ray, but the switching and OS > management overhead will kill you if you attempt to run thousands of > threads at once, which I assume you'd need with 1:1. (Erlang, for > example, which is conceptually based on many, many communicating > processes, uses its own implementation, rather than OS threads of > processes.) > > I think you'd be much better off creating a "ray queue" of some sort, > then using a thread_group with cores+1 threads that all continually > poll the ray queue for which one to work on. > > So that's not exactly an answer to the question you asked, but I think > that's the usual wisdom with regards to threads. > > HTH, > ~ Scott > > > ------------------------------

2 1

[System] compile error
by Paul Heil 25 Aug '08

25 Aug '08

I'm trying to compile Boost 1.36.0 with Microsoft Visual Studio 9.0 for Windows Mobile 5. Unfortunately, I'm getting a compile error on the system library (below). Can anybody suggest what I may be doing wrong? The command line I'm using to compile boost is: C:\boost\boost_1_36_0>bjam --without-python --without-mpi msvc-WM5/variant=debug,release/threading=multi/*stdlib*=stlport/link=shared,static/runtime-link=static stage The output from the -d2 flag, as it relates to the System library is: file bin.v2\libs\system\build\msvc-WM5\debug\link-static\runtime-link-static\* stdlib*-stlport\threading-multi\error_code.obj.rsp "libs\system\src\error_code.cpp" -Fo"bin.v2\libs\system\build\msvc-WM5\debug\link-static\runtime-link-static\ *stdlib*-stlport\threading-multi\error_code.obj" -TP /Z7 /Od /Ob0 /W3 /GR /MTd /Zc:forScope /Zc:wchar_t /wd4675 /EHs -D_CRT_SECURE_NO_WARNINGS -D_WIN32_WCE=0x501 -DUNDER_CE=0x501 -DWIN32_WCE_PSPC -D_MSC_VER=1500 -DWINCE -DARM -D_ARM_ -DARMV4I -D_LITTLE_ENDIAN -DUNICODE -D_UNICODE -DPOCKETPC2003_UI_MODEL -c -DBOOST_ALL_NO_LIB=1 -DBOOST_SYSTEM_STATIC_LINK=1 -D_STLP_DEBUG=1 -D_STLP_DEBUG_UNINITIALIZED=1 "-I." "-IC:STLPortSTLport-5.1.5stlport" compile-c-c++ bin.v2\libs\system\build\msvc-WM5\debug\link-static\runtime-link-static\* stdlib*-stlport\threading-multi\error_code.obj cl /Zm800 -nologo @"bin.v2\libs\system\build\msvc-WM5\debug\link-static\runtime-link-static\* stdlib*-stlport\threading-multi\error_code.obj.rsp" error_code.cpp Unknown EVC++ compiler version - please run the configure tests and report the results libs\system\src\error_code.cpp(83) : error C2039: '*strerror*' : is not a member of '*stlpd_std*' libs\system\src\error_code.cpp(83) : error C3861: '*strerror*': identifier not found ...failed compile-c-c++ bin.v2\libs\system\build\msvc-WM5\debug\link-static\runtime-link-static\* stdlib*-stlport\threading-multi\error_code.obj... ...skipped <pbin.v2\libs\system\build\msvc-WM5\debug\link-static\runtime-link-static\* stdlib*-stlport\threading-multi>libboost_system-vc-mt-sgdp-1_36.lib for lack of <pbin.v2\libs\system\build\msvc-WM5\debug\link-static\runtime-link-static\* stdlib*-stlport\threading-multi>error_code.obj... ...skipped <pstage\lib>libboost_system-vc-mt-sgdp-1_36.lib for lack of <pbin.v2\libs\system\build\msvc-WM5\debug\link-static\runtime-link-static\* stdlib*-stlport\threading-multi>libboost_system-vc-mt-sgdp-1_36.lib... For reference, my user-config.jam file: using msvc : WM5 : "cl.exe" : <compileflags>-D_CRT_SECURE_NO_WARNINGS <compileflags>-D_WIN32_WCE=0x501 <compileflags>-DUNDER_CE=0x501 <compileflags>-DWIN32_WCE_PSPC <compileflags>-D_MSC_VER=1500 <compileflags>-DWINCE <compileflags>-DARM <compileflags>-D_ARM_ <compileflags>-DARMV4I <compileflags>-D_LITTLE_ENDIAN <compileflags>-DUNICODE <compileflags>-D_UNICODE <compileflags>-DPOCKETPC2003_UI_MODEL <linkflags>/subsystem:windowsce,5.01 <linkflags>/machine:arm <linkflags>/NODEFAULTLIB:oldnames.lib <linkflags>/STACK:262144,4096 <linkflags>coredll.lib <linkflags>corelibc.lib <linkflags>ole32.lib <linkflags>oleaut32.lib <linkflags>uuid.lib <linkflags>commctrl.lib <architecture>arm <instruction-set>armv4 <interface>wince <assembler>"armasm.exe" ; using stlport : : C:\STLPort\STLport-5.1.5\stlport C:\STLPort\STLport-5.1.5\lib ; Thanks, PaulH

1 0

Re: [Boost-users] [Thread] Beginner question regarding thread groups
by Michel Lestrade 25 Aug '08

25 Aug '08

Hi, Actually, I probably was not clear before: only the refracted ray will be a new ray on the queue: the reflected ray continues on its merry way until it decays. That is probably the same thing as what you are suggesting. The reason I was vague before is that I have two options: follow the reflected ray and spawn new refracted rays (as above) or follow the refracted ray ans spawn the reflected rays. I expect solution #1 is better in terms of locality but #2 might result in a smaller queue since internal reflection coefficients are small (i.e. you often wind up dropping the reflected ray since it no longer carries any significant power). Right now, the code is using #1 but I was considering switching to see what effects it might have... > It may be possible to do fairly well on locality by on a split, rather > than putting both new rays into the queue and doing a new fetch from > the queue, continuing on with the ray most similar to the incident > ray, only adding the other ray(s?) to the queue, so the frame of > reference only jumps when a ray dies. (Not unlike half-tailing > quicksort.) > =========================== We actually almost always develop in Fortran except for the GUI parts. That comes from our company background in physics and the large amount of existing code we have ... But yes, the code is old and mostly written in fixed-form F77. I am at least trying to modernize some parts to use free-form F90/F95 syntax :) I actually have not taken a look recently at these papers since I always worked directly on the code. Hopefully, there is something of interest in there. > Thanks, I always ask people to post links to their work since it makes things more interesting > and I'll look as soon as I can. I thought the code may be a bit old given the language Regards, Michel Lestrade Crosslight Software

2 1

Synchronization support for boost objects
by Zach Turner 25 Aug '08

25 Aug '08

I am wondering if there are any plans, either in the near or distant future, to ever add synchronization support for arbitrary objects. The interface could be simple, every class takes one additional template argument, the class name of a locking object which defaults to some class that provides stub methods so that by default all classes are unsychronized. Then, if I want my object to become synchronized, I can pass it whatever type of lock I deem appropriate. Of course any object can be synchronized currently by making a class that exposes the same interface and acquires a lock before forwarding to the internal boost implementation, but this is inefficient, as the internal details of the object's implementation are not always such that an entire method needs to be locked. Perhaps only a single line of code inside a long method needs to be locked. Has this ever been considered in the past?

2 1

[Thread] Beginner question regarding thread groups
by Michel Lestrade 25 Aug '08

25 Aug '08

Hi, I am considering rewriting part of our ray tracing code to use the Boost thread library. As many of you might know, ray tracing is a task that lends itself well to a parallel approach since each ray is independent from the other. However, the code right now is in Fortran which doesn't support task level parallelism easily ... The thread_group class seems ideally suited to my needs (one thread == one ray) but there is at least one problem I envision that I would like to solve before embarking on this fairly time-consuming rewrite. Just to give you some background, what we are doing is not ray tracing in the visualization/render sense: rather, it is a scientific application used to determine the light emission pattern of certain devices without waveguides (such as LEDs). So keep in mind that not all the conventional ray tracing approaches will work for me. I also come from a physics/engineering background so I am not up to date on all the newer object-oriented techniques and concepts. Now to the heart of the matter: in our approach, each of the initial rays is split into a reflected/refracted ray every time a material interface is reached which generates a secondary ray. Each secondary ray can generate other secondary rays when they hit an interface and so on ... This goes on until the power in each ray has decayed sufficiently (the material is usually absorbing), all rays exit the device or a maximum number of rays has been reached. That means that I do not know ahead of time how many rays (or threads) that I will have. This brings me to my question: can I add new threads to thread group while it is running ? All of the code samples for thread_group seem to call add_thread() on a fixed number of objects before calling join_all(). So it seems that the execution of the thread does not start at the moment it is added to the group but at the moment join_all() is called. In my case, I would have a join_all() first and then periodically add new threads: so this is basically a dynamic queue with new rays being pushed at the end. How can I start these threads automatically if add_thread does not start the execution ? Should I call join() on the new threads before adding them to the thread group instead of using join_all() ? Should I give up on thread_group and store my thread objects in some other container ? Any alternative solutions or a code sample with a dynamically changing thread_group would be appreciated. I am hoping someone has faced a similar problem in another context ... Regards, Michel Lestrade Crosslight Software P.S. Since I am a new user of Boost, I will go ahead and use the latest version (1.36.0). I already built the binaries for my tool set (VS 2008).

3 3