Given boost uses version numbers x.y.z such as
1.30.2
1.31.0
The build system generated libs and stuff with -1_31 appended. I have a
few questions about this:
How is this generated? We wish to build our own version of boost (based
on one of the above releases, but with patches) so wanted to version it
accordingly. The obvious way would be for us to version it 1.31.0.1 so
it is differentiated from the official 1.31 release. Unfortunately,
boost only appears to support the x.y.z …
[View More]format.
So we could number it 1.31.1 and hope boost doesn't release a 1.31.1.
But I've edited boost/version.hpp to be 103101 and 1_31_1 and also the
jamrules file to be 1.31.1 but the build-generated libs are still only
post-fixed with -1_31. Where does the bulid system pick up the version
number so I can modify it for the build and would it be easy to modify
it to support w.x.y.z format so we don't run a risk of coliding with
boost versions?
Thanks
Russell
[View Less]
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\…
[View More]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"
[View Less]
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:
…
[View More]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
[View Less]
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
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.…
[View More] 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
[View Less]
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 …
[View More]value of _MSC_VER with VC 8.0 ?
Robert Ramey
[View Less]
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 …
[View More]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
[View Less]
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
…
[View More]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
[View Less]
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 …
[View More]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
[View Less]
