FWIW: I am using gcc 3.3.1 compiled from scratch with sources from gcc.gnu.org
under OS X. This works with full optimization (gcc 3.3 did not).
I didn't see your other messages, but I hope this is relevant: I had serious
trouble with multiple initializations of a static variable in the
--- Douglas Gregor [EMAIL PROTECTED] wrote:
Hi Doug,
If you could figure out what alignment value you're trying to get a type for
it would help greatly. One way you could do it would be to replace the
static assertion lines with something that will halt the compile and give
back the Align
While compiling certain Boost.Python regression tests (e.g. args.cpp) gcc 3.3
complains about some typedefs being private. Attached is a trivial patch which
fixes the problem. OK to commit to CVS?
Thanks,
Ralf
Index: joint_view.hpp
--- Daniel Spangenberg [EMAIL PROTECTED] wrote:
These news are very good, but what about the thread library?
I cannot find the beginning of this thread. Where could I read the very good
news?
Thanks,
Ralf
__
Do you Yahoo!?
The New
--- David Abrahams [EMAIL PROTECTED] wrote:
Ralf W. Grosse-Kunstleve [EMAIL PROTECTED] writes:
There are gcc 2.96 (Redhat 7.3) compilation error for
boost/libs/python/test/opaque.cpp:
http://cci.lbl.gov/~rwgk/tmp/rc_1_30_0_opaque_fail.txt
More recent gcc's don't seems to suffer from
--- David Abrahams [EMAIL PROTECTED] wrote:
Ralf W. Grosse-Kunstleve [EMAIL PROTECTED] writes:
That change does not seem to make a difference. The compiler errors are
still
exactly the same.
Does 2.96 want the default argument (=0) to be repeated?
Is this what you mean?
Index
--- Rozental, Gennadiy [EMAIL PROTECTED] wrote:
Not all^H^H^H^H^H^H^H^HNo compilers are perfectly standard-compliant.
Ih this case I would not want to make this change. After all it's only
warning.
The patch is only in RC_1_30_0.
The warnings are creating a lot of noise. As you said the
--- Beman Dawes [EMAIL PROTECTED] wrote:
At 09:48 AM 3/18/2003, David Abrahams wrote:
[EMAIL PROTECTED] writes:
it seems to me that these aren't actually legal specializations
(though I've never specialized functions before so I could be wrong).
Shouldn't that be:
--- David Abrahams [EMAIL PROTECTED] wrote:
Beman, here is an idea: I could check in the patch now and restart our
multi-platform Boost.Python regression tests. When we hear back from David
we
have the results already. Then we can decide what to do based on all the
information that we
--- Ralf W. Grosse-Kunstleve [EMAIL PROTECTED] wrote:
I've checked in the patch and we will restart the tests as soon as the
Sourceforge server is cooperating.
This patch breaks the Tru64/cxx and IRIX/CC (MIPSpro) compilations :-(
tru64cxx65-C++-action
../../../libs/python/test/bin
--- David Abrahams [EMAIL PROTECTED] wrote:
Seems to me a special version of the code for
BOOST_WORKAROUND(__GNUC__, == 2 __GNUC_MINOR__ == 96)
is in order.
We know that the special code works with 2.95.3 (according to Gottfried), so
I've made this:
# elif
I've just checked in a small patch to address this warning:
cc-1460 CC: WARNING File = boost/boost/test/detail/wrap_stringstream.hpp, Line
= 90
Function function boost::wrap_stringstream::str is redeclared inline
after
being called.
wrap_stringstream::str()
^
There are gcc 2.96 (Redhat 7.3) compilation error for
boost/libs/python/test/opaque.cpp:
http://cci.lbl.gov/~rwgk/tmp/rc_1_30_0_opaque_fail.txt
More recent gcc's don't seems to suffer from this problem.
I am not sure this is important enough to delay the release any further.
David?
Ralf
As of about 3pm PST today the RC_1_30_0 branch is still broken under VC6 and
7.0:
http://cci.lbl.gov/boost/results/1047771420/dailylog_win32_vc60_test
http://cci.lbl.gov/boost/results/1047771420/dailylog_win32_vc70_test
Is this on the radar of someone who could fix the failures?
Ralf
--- Beman Dawes [EMAIL PROTECTED] wrote:
OTOH, it's very tiresome waiting for these last minute fixes, which don't
seem particularly critical anyhow. Assuming lexical_cast is reverted, maybe
we should just go ahead with the release now.
Whatever you do, please give me (another...) realistic
--- David Abrahams [EMAIL PROTECTED] wrote:
My only concern about this is that IIUC Bjorn has been making lots of
promises that the new lexical_cast was going to be in 1.30.0. I
don't want to break promises without due consideration.
To me branching for release also is a promise: relative
I see new features being added to RC_1_30_0.
Is this the right balance of innovation and stability?
I've spent several days cleaning up RC_1_30_0 for a large number of platforms.
It takes a long time to do all the compilations and tests. Do I have to do this
all over again to salvage my
Hi,
We got access to a brand-new HP Itanium2 machine. Compiling with the
pre-installed gcc 2.96 seems to go fine, but I had to patch
boost/detail/limits.hpp. See below. I am just guessing that BOOST_BIG_ENDIAN is
correct for the Itanium2. Does anybody here know if this is correct? Is there a
If evaluating the output of the code below counts as a
quick-and-easy-and-conclusive test the result is that the Itanium2 must be
BOOST_LITTLE_ENDIAN like the i386 and Alpha lines. I.e. my patch needs to be
revised (see below).
I am happy to report that Boost.Python works both with gcc 2.96 and
--- David Abrahams [EMAIL PROTECTED] wrote:
I am happy to report that Boost.Python works both with gcc 2.96 and Intel
7.0
on the Itanium2. The patch below is the only modification required. Would
it be
OK to check this into the RC_1_30_0 branch?
Go for it! You don't need to ask
--- Aleksey Gurtovoy [EMAIL PROTECTED] wrote:
OK, I've checked in a fix into the main trunk (see
boost/mpl/aux_/lambda_support.hpp). If you could check if it makes the
problem go away, I'll integrate the new version into the release branch.
Thank you very much Aleksey! The error posted before
--- David Abrahams [EMAIL PROTECTED] wrote:
Ralf W. Grosse-Kunstleve [EMAIL PROTECTED] writes:
David and Aleksey, could you please review the patches and tell
me which are OK to check in? -- I am a bit worried about the
two patches in the mpl/aux_/preprocessed directory. Are these
files
--- David Abrahams [EMAIL PROTECTED] wrote:
It's easy enough to test it with a little program that prints the
value you have.
OK, OK, OK, David. I know that MIPSpro == EDG 238, what I don't know is which
EDG version fixes the problem. Is this better?
Index: is_base_and_derived.hpp
--- Ralf W. Grosse-Kunstleve [EMAIL PROTECTED] wrote:
I don't use -d0, but I don't see that **passed** message anywhere.
Something else is not right: The other fail tests are only built once, but
the as_to_python_function.cpp test is built each time I enter bjam again.
That's why you see
--- David Abrahams [EMAIL PROTECTED] wrote:
Should be:
#if !BOOST_WORKAROUND(__BORLANDC__, BOOST_TESTED_AT(0x570)) \
!BOOST_WORKAROUND(__EDG_VERSION__, = 238)
// The EDG version number is a lower estimate.
// It is not
--- Beman Dawes [EMAIL PROTECTED] wrote:
At 07:59 PM 3/7/2003, David Abrahams wrote:
Beman Dawes [EMAIL PROTECTED] writes:
At 05:38 PM 3/7/2003, Ralf W. Grosse-Kunstleve wrote:
... I'll check in the eight patches, both into the trunk and the
RC_1_30_0 branch.
Ralf
--- David Abrahams [EMAIL PROTECTED] wrote:
There are any number of ways you could try reformulating this to make
the error go away. At worst you could try the __BORLANDC__ branch in
is_base_and_derived.hpp.
Another approach:
template typename B, typename D, typename T
static
--- David Abrahams [EMAIL PROTECTED] wrote:
Ralf W. Grosse-Kunstleve [EMAIL PROTECTED] writes:
Is the __BORLANDC__ branch different from (not as good as) the
is_base_and_derived implementation in 1.29.0?
cvs diff knows for sure.
Sure, but this chasing tails game is impractical
The MIPSpro problems are due to a hickup in is_base_and_derived.hpp.
Here is the relevant *preprocessed* piece of code:
template typename B, typename D
struct bd_helper
{
template typename T
static type_traits::yes_type check(D const volatile *, T);
static type_traits::no_type
Below is a stand-alone minimal test that still produces the same error message
with MIPSpro:
% CC -LANG:std zminmin.cpp
cc-1108 CC: ERROR File = zminmin.cpp, Line = 13
The indicated expression must have pointer-to-function type.
static const unsigned long value =
--- Larry Evans [EMAIL PROTECTED] wrote:
The type implemented in shared_plain.h (in the directory above) is a
reference
All I see there doesn't include shared_plain.h unless it's in a subdirectory.
Is it some other place?
Sorry, this is the correct link:
--- David Abrahams [EMAIL PROTECTED] wrote:
I did not use boost::shared_array to implement the shared_plainT
type because one of our requirements is that one reference count can
be used to manage multiple types.
Sounds like a job for a policy-based smart pointer to array to me ;-)
This
--- David Abrahams [EMAIL PROTECTED] wrote:
Toon Knapen [EMAIL PROTECTED] writes:
Long time ago I inquired if it would be a good idea to provide STL
extensions
in boost that are not implemented by all STL's. IIRC David A responded that
boost/compatibility was intended for this.
33 matches
Mail list logo
