- Boost - lists.boost.org

install messed up?
by Victor A. Wagner Jr. 12 Aug '04

12 Aug '04

I'm reasonably sure that the install shouldn't copy two _different_ files to the same place/name I'm guessing that one of those shouldn't have the -mt- in the name ================================================================================================= Creating library bin\boost\libs\date_time\build\boost_date_time.dll\vc7.1\debug\threading-multi\boost_date_time-vc71-mt-gd-1_32.lib and object bin\boost\libs\date_time\build\boost_date_time.dll\vc7.1\debug\threading-multi\boost_date_time-vc71-mt-gd-1_32.exp FileClone C:\Boost\lib\boost_date_time-vc71-mt-gd-1_32.dll copy "bin\boost\libs\date_time\build\boost_date_time.dll\vc7.1\debug\boost_date_time-vc71-mt-gd-1_32.dll" "C:\Boost\lib\boost_date_time-vc71-mt-gd-1_32.dll" >NUL: FileClone C:\Boost\lib\boost_date_time-vc71-mt-gd-1_32.dll copy "bin\boost\libs\date_time\build\boost_date_time.dll\vc7.1\debug\threading-multi\boost_date_time-vc71-mt-gd-1_32.dll" "C:\Boost\lib\boost_date_time-vc71-mt-gd-1_32.dll" >NUL: FileClone C:\Boost\lib\boost_date_time-vc71-mt-gd-1_32.lib copy "bin\boost\libs\date_time\build\boost_date_time.dll\vc7.1\debug\boost_date_time-vc71-mt-gd-1_32.lib" "C:\Boost\lib\boost_date_time-vc71-mt-gd-1_32.lib" >NUL: FileClone C:\Boost\lib\boost_date_time-vc71-mt-gd-1_32.lib copy "bin\boost\libs\date_time\build\boost_date_time.dll\vc7.1\debug\threading-multi\boost_date_time-vc71-mt-gd-1_32.lib" "C:\Boost\lib\boost_date_time-vc71-mt-gd-1_32.lib" >NUL: ====================================================================================================== I expect a lot of things are going to fail if my system ever gets around to actually running the tests Victor A. Wagner Jr. http://rudbek.com The five most dangerous words in the English language: "There oughta be a law"

2 3

[thread] wrong name of the thread lib and dll.
by Sven Johannsen 12 Aug '04

12 Aug '04

Hi, when you compile the current boost with the following cmd-line the thread-lib has a wrong filename: bjam "-sTOOLS=msvc-stlport" "-sSTLPORT_PATH=D:\Develop" "-sSTLPORT_VERSION=4.5.3" this cmd-should generate "gdpn" files like: boost_thread-vc6-mt-gdpn-1_31.dll but it generate a "gdp" (without "n") file. the "n" stands for native iostreams. (boost_thread-vc6-mt-gdp-1_31.lib) the lib behave like "gdpn"-file, but i have to rename the lib. otherwise i get the following linker error: LINK : fatal error LNK1104: cannot open file "boost_thread-vc6-mt-gdpn-1_31.lib" who can modifier the jam-file. (i don't speak jam) Sven

3 5

[graph] GIF files not marked as binary in CVS.
by Rene Rivera 12 Aug '04

12 Aug '04

In this recent update: U libs/graph/doc/figs/betweenness_centrality.gif U libs/graph/doc/figs/central_point_dominance.gif U libs/graph/doc/figs/relative_betweenness_centrality.gif U libs/graph/doc/figs/sigma_st.gif U libs/graph/doc/figs/sigma_stv.gif U libs/graph/doc/figs/v_star.gif U libs/graph/doc/figs/wheel_graph.gif Those files are not marked as binary in CVS. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com - 102708583/icq

2 1

Re:[boost] Re: serialization and cwpro status
by Robert Ramey 11 Aug '04

11 Aug '04

David Abrahams wrote: "Robert Ramey" <ramey(a)rrsd.com> writes: >> Now that I do, I'm strongly convinced that >> it's a really bad idea. >Give it a chance to sink in. Looks like I don't have much choice. > It's a good idea even if you ignore > export because it reduces the chance that a template's meaning will > change based on definitions that follow it, allows syntax checking > before instantiation, and adds rigor. That's the problem with it in my view. Before, I could keep things in my head by extending the "macro" concept to include types. Now I can't. Now the meaning of something depends upon the order it is included in the program - an incredibly subtle side-effect. Worse, the meaning of a template now can vary quite a bit depending upon the argument used to instantiate it. The whole thing reminds me of trying to write a memo with Microsoft word. It constantly "helps you out" without telling you so you can't really see what's going on without keeping the whole global environment in your head. So it diminishes transparency, verifiability, and opportunity to enforce rigor in coding requires increased dependence on testing to gain confidence on program correctness. Sorry, I know we're going off topic, but I couldn't let the above pass without comment. >> CW < 8 >> >> I believe that these versions will pass 100 % >I wouldn't count on it. CW 7.x couldn't handle the "sizeof() trick", >so *lots* of basic TMP things (like is_convertible) fail there. Of >course, maybe you're sure that none of these things are used...? Good thing you didn't tell me that before - its now passing 100% It feels like I've used everything in mpl (of course I didn't - it just feels like I did). I use is_convertible in many places as well as just about all the type_traits. On the other hand, maybe its just that I don't have enough tests to make it fail. Robert Ramey

3 2

Re:[boost] Re: question re VC 8.0
by Robert Ramey 11 Aug '04

11 Aug '04

Joaquin M Lopez Munoz wrote: > Looks like VC 8.0 does not handle member *qualified* template friends. > The solution I applied is to simply extend the defect macro > BOOST_NO_MEMBER_TEMPLATE_FRIENDS to VC 8.0 (by using a local version of > the macro, namely BOOST_MULTI_INDEX_NO_MEMBER_TEMPLATE_FRIENDS), until > this issue is officially resolved in Boost.Config. Can we not just resolve this issue "officially" right now by amending config/compiler/visualc.hpp ? What is the value of _MSC_VER with VC 8.0 ? Robert Ramey

3 2

Re:[boost] Re: serialization and cwpro status
by Robert Ramey 11 Aug '04

11 Aug '04

Stefan Slapeta wrote: >>Robert Ramey wrote: >> >> CW two-phase lookup threw me for a loop. What I meant was it left me dazed and confused. >This seems _very_ strange to me because two-phase lookup should also be > turned on for Intel 8, so I don't understand why all the tests pass on >this compiler. Please could you mail me a particular test case or code >sequence which you think was failing because of two-phase lookup issues? Is this something that can be turned off/on at will for intel? And/or other compilers? I use boost-build defaults as much as possible. Hmmm - maybe two phase lookup should turned off by default for boost? This experience has convinced me that two phase lookup is a bad idea. A couple of months ago I tested the library with intel 8.0 . After resolving one anomally (related to typeid of const/non-const) things compiled and everything passed. My 30 day license exprired so I haven't been able to test here since. When I went to cw pro version 9, I had the tests for non-intrusive serialization failed. This uses function template overload. This turned out that to be the same problem I had with Commeau. After much effort I came to understand the issue. I made adjustments to address this. This resulted in more changes than I wanted to make at this point. Oh well. It has also resulted in a slightly more complex explanation of how to use non-intrusive serialization portably. This works but it offends my sense of aesthetics. On the other hand, It did force me implement ADL for finding overloads. This was the one feature that had been asked for but hadn't implemented. I didn't see a way to do it without causing a two large ripple effect through the API, docs, etc. Martin Ecker showed me how to fix this so now we have ADL for overloading serialize functions. So I would think that if Intel implements two-phase lookup, things would have failed much sooner. On the other hand, during my 30 test trial of Intel 8.0 I got two?! Notices for updates. It wouldn't surprise me if there are multiple versions named Intel 8.0. In spite of all the pain I've experienced in porting code like this to all such platforms. I've come to appreciate the general high quality of these compilers. They all have quirks and errors. But now having had to delve much deeper into details of C++ than I ever had to before, I have a much better appreciation of how difficult is has to be to write something like this. I think C++ would be much improved if the standards committee would be a little more conservative about "mandating" untested features. Sometimes I wonder if its not just a group of really smart guys sitting around a table thinking up the hardest stuff they can for other people to implement - Sort of like the marketing department. I've had huge difficulties traced to arcane areas of C++ that are really too hard to understand for the normal person. Anyway - one man's two cents. Robert Ramey

2 1

"blank permission" in license_info.html
by Jonathan Wakely 11 Aug '04

11 Aug '04

http://boost.org/more/license_info.html says "blank permission" should be "blanket permission" jon

2 1

Documentation copyright in Boost
by Jonathan Brandmeyer 11 Aug '04

11 Aug '04

John Maddock's prodding with regard to copyright notices in Boost's sources got me thinking about the copyright notices in its documentation. Currently, some docs have a copyright notice using the Boost Software License, some have a permissive license other than the BSL, and some just say "Copyright (c) DATE AUTHOR". I haven't done a detailed survey; that observation is just based on a random browsing of the Boost docs. I generally believe in using the same copyright license for the documentation as the one used for the software, at least in the context of Free/Open Source Software. That may or may not be entirely appropriate considering the BSL's particular language concerning compiled software. Has this issue been raised in the past? Was there a consensus? If not, what do you think about it, now? Thanks, Jonathan Brandmeyer

2 2

[boost.thread] Allowed lifetime of a thread?
by Roland 11 Aug '04

11 Aug '04

While considering various ways to get rid of the remaining intentional memory leak of the tss implementation, I came upon the following question: How long may a thread access it's tss storage anyway? I did not find anything in the documentation about the topic. Looking into the destructor of thread_specific_ptr reveals ~thread_specific_ptr() { reset(); } which in turn implies, that the thread(s) which are using it should have already terminated, when the main thread has exited (called its dtor list). Now when one has control over the lifetime of the threads this poses no problem, since they simply need to be terminated before main() ends. The situation is completely different when writing a piece of code (a library) that has to use tss and shall work with foreign threads too. The library writer in this case has no control over the lifetime of the threads (native or not). So I am wondering if it is possible to refine the inner workings of the thread_specific_ptr without changing the interface to account for these cases? Perhaps only a static pointer should be embedded that points to dynamic memory that will not be touched by destructor calls, but controlled in lifetime be real thread-detachements. (The last one frees everything which is really global.) How is the situation for other libraries, say e.g. pthreads? Are they allowed to run after main ended? Or is this simply considered bad programm behaviour? Any comments? Roland

2 3

Re:[boost] Re: serialization and cwpro status
by Robert Ramey 11 Aug '04

11 Aug '04

David Abrahams wrote: >> This seems _very_ strange to me because two-phase lookup should also >> be turned on for Intel 8, so I don't understand why all the tests pass >> on this compiler. >Intel for windows has the "MSVC bug compatibility" switch turned on. >On linux it actually detects 2-phase problems, except insofar as it's >trying to emulate GCC bugs :( Ahhh - mystery solved - thanks for that. Robert Ramey

1 0