Re: [boost] Build help for OS X
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 Boost.Python library. Somehow I got it to work after hours of trial-and-error. See boost/libs/python/src/converter/registry.cpp, BOOST_PYTHON_CONVERTER_REGISTRY_APPLE_MACH_WORKAROUND. It could be that the std::cout << std::flush trick is the main trick, I am not sure, I only know it works the way you see it. --- Paul Hamilton <[EMAIL PROTECTED]> wrote: > > I managed to get my stuff built using all shared libraries on OS X, but > I came across the following problems: > > - I had to hack "boost/format/feedargs.hpp" to remove the static > variable (I have explained in other posts why). > > - I am going to work around this by only having a single include point > for "format.hpp", but it will limit my further use of this. > - I sent a message earlier about changing this code so that is does > something a lot simpler than it does, and it fixes my problem. Any > thoughts about that? > > - I had to turn off optimization and inlines for the release build > because I was getting a bunch of "non-virtual thunk" errors in the link. > > - I will test with the latest build from Apple to see if this goes > away, since when I googled I received lot's of "this is a compiler bug, > turn off optimization" messages. > > But in the meantime, rather than needing to hack "darwin-tools.jam" to > turn off inlining/optimization, how do you change these for the default > build? > > I tried this in my Jamfile: > > dll cppxmlobjlib : $(XMLOBJ_PATH)/$(CPP_SOURCES).cpp > ../libs/cpppersistxmllib > ../libs/cpppersistlib > ../libs/cppreflectlib > : $(BOOST_ROOT) expat off > off > : debug release > ; > > But it gives me a warning saying that "off" is not > compatible with full. > > How do you override those defaults? > > Paul. > > - > Paul Hamilton > pHamtec P/L - Software Makers > http://www.phamtec.com/ > mailto:[EMAIL PROTECTED] > > The information transmitted is intended only for the person or entity > to which it is addressed and may contain confidential and/or privileged > material. Any review, retransmission, dissemination or other use of, or > taking of any action in reliance upon, this information by persons or > entities other than the intended recipient is prohibited. If you > received this in error, please contact the sender and delete the > material from any computer. > - > > ___ > Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Package for Cygwin distribution
--- Reed Hedges <[EMAIL PROTECTED]> wrote: > Quoting David Abrahams <[EMAIL PROTECTED]>: > > > However, in my experience GCC 3.3 is a lot worse than 3.2, so if That's my experience, too, but I don't use cygwin. General observations: - we had to add a couple of gcc 3.3 specific workarounds to Boost.Python - under Redhat 8.0 the optimizer is broken for several of our modules - under Mac OS 10 I had a very hard time working around internal compiler errors and the optimizer is broken for virtually everything On the other hand, gcc 3.2 under Redhat 8.0 works like charm. I cannot remember any significant issues. But again, I don't know how this is related to gcc under cygwin. Ralf __ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Mac OS 10 & type_traits/type_with_alignment.hpp
--- 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 value in an error message, e.g.,
Thanks a lot for your message!
> // somewhere
> template struct maybe_print_align {
> typedef void type; }
> template struct maybe_print_align {};
>
> // instead of the static asserts:
> typedef typename maybe_print_align<(found >= Align), Align>::type foobar;
>
> Note that when those static asserts fail, it means that you aren't getting
> back a type with the right alignment.
That's a cool trick and it works great. I've expanded your templates
to also print the value of the "found" constant:
template struct
maybe_print_align { typedef void type; };
template struct maybe_print_align {};
typedef typename maybe_print_align<(found >= Align), Align, found>::type
foobar;
Here is the error:
/var/tmp/mac/boost/boost/type_traits/type_with_alignment.hpp:120:
error: no type named `type' in `boost::maybe_print_align'
The full error message is here:
http://cci.lbl.gov/~rwgk/tmp/mac_os_10_alignment_problem
FYI: In the meantime we've found out that the PowerPC doesn't have
strict alignment requirements (but unaligned access may be associated
with performance penalties). After a discussion with David Abrahams
I've disabled the static assertions in type_with_alignment.hpp:
#if !(defined(__APPLE__) && defined(__MACH__) && defined(__GNUC__))
BOOST_STATIC_ASSERT(found >= Align);
BOOST_STATIC_ASSERT(found % Align == 0);
#endif
Ralf
__
Do you Yahoo!?
Yahoo! Calendar - Free online calendar with sync to Outlook(TM).
http://calendar.yahoo.com
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] patch for boost/mpl/joint_view.hpp
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 === RCS file: /cvsroot/boost/boost/boost/mpl/joint_view.hpp,v retrieving revision 1.3 diff -u -r1.3 joint_view.hpp --- joint_view.hpp 21 May 2003 13:39:09 - 1.3 +++ joint_view.hpp 26 May 2003 03:02:56 - @@ -58,8 +58,6 @@ friend struct size_traits< aux::joint_view_tag >::algorithm; # endif #endif -typedef Sequence1_ sequence1; -typedef Sequence2_ sequence2; typedef typename begin::type first1_; typedef typename end::type last1_; @@ -67,6 +65,8 @@ typedef typename end::type last2_; public: +typedef Sequence1_ sequence1; +typedef Sequence2_ sequence2; typedef aux::joint_view_tag tag; typedef typename aux::joint_iter begin; typedef typename aux::joint_iter end; __ Do you Yahoo!? The New Yahoo! Search - Faster. Easier. Bingo. http://search.yahoo.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Boost proposals accepted by C++ committee
--- 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 Yahoo! Search - Faster. Easier. Bingo http://search.yahoo.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] RC_1_30_0: gcc 2.96 boost/libs/python/test/opaque.cppfailure
--- 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 BOOST_WORKAROUND(__GNUC__, < 3)
Full patch attached. Tested with gcc 2.96 and cxx 6.5.1.
Ralf
Index: opaque_pointer_converter.hpp
===
RCS file: /cvsroot/boost/boost/boost/python/opaque_pointer_converter.hpp,v
retrieving revision 1.2.2.4
diff -u -r1.2.2.4 opaque_pointer_converter.hpp
--- opaque_pointer_converter.hpp18 Mar 2003 22:31:12 - 1.2.2.4
+++ opaque_pointer_converter.hpp19 Mar 2003 02:39:19 -
@@ -116,7 +116,7 @@
// MSC works without this workaround, but needs another one ...
# define BOOST_PYTHON_OPAQUE_SPECIALIZED_TYPE_ID(Pointee) \
BOOST_BROKEN_COMPILER_TYPE_TRAITS_SPECIALIZATION(Pointee)
-# else
+# elif BOOST_WORKAROUND(__GNUC__, < 3)
# define BOOST_PYTHON_OPAQUE_SPECIALIZED_TYPE_ID(Pointee) \
namespace boost { namespace python { \
template<> \
@@ -127,6 +127,19 @@
inline type_info type_id() { \
return type_info (typeid (Pointee *)); \
} \
+}}
+# else
+# define BOOST_PYTHON_OPAQUE_SPECIALIZED_TYPE_ID(Pointee) \
+namespace boost { namespace python { \
+template<>\
+inline type_info type_id(boost::type*) { \
+return type_info (typeid (Pointee *));\
+} \
+template<>\
+inline type_info type_id( \
+boost::type*) { \
+return type_info (typeid (Pointee *));\
+} \
}}
# endif
# endif// OPAQUE_POINTER_CONVERTER_HPP_
__
Do you Yahoo!?
Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop!
http://platinum.yahoo.com
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] RC_1_30_0: gcc 2.96 boost/libs/python/test/opaque.cppfailure
--- "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/opaque_ext.so/tru64cxx651/debug/opaque.o cxx: Error: opaque.cpp, line 55: #493 no instance of function template "boost::python::type_id" matches the specified type BOOST_PYTHON_OPAQUE_SPECIALIZED_TYPE_ID(opaque_) ^ cxx: Error: opaque.cpp, line 56: #493 no instance of function template "boost::python::type_id" matches the specified type The full logs are here: http://cci.lbl.gov/boost/results/1048021397/dailylog_tru64_cxx_test http://cci.lbl.gov/boost/results/1048021397/dailylog_irix_CC_test I think we have to put in an #ifdef to do what was done before in some cases and what is done now in others. I will try this now. Please let me know if there are better ideas. We will have to decide what to test for: #ifdef gcc or #ifdef EDG? Ralf __ Do you Yahoo!? Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop! http://platinum.yahoo.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] RC_1_30_0: gcc 2.96 boost/libs/python/test/opaque.cppfailure
--- David Abrahams <[EMAIL PROTECTED]> wrote: > should be: > > > # if BOOST_WORKAROUND(BOOST_MSVC, <= 1300) > // MSC works without this workaround, but needs another one ... > -# define BOOST_PYTHON_OPAQUE_SPECIALIZED_TYPE_ID(Pointee) \ > +# define BOOST_PYTHON_OPAQUE_SPECIALIZED_TYPE_ID(Pointee) \ > BOOST_BROKEN_COMPILER_TYPE_TRAITS_SPECIALIZATION(Pointee) > # else > > > Otherwise, it will break vc7.1 I'm fairly certain. OK, checked into RC_1_30_0. I don't have vc7.1. Could someone please try it out? Ralf __ Do you Yahoo!? Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop! http://platinum.yahoo.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] RC_1_30_0: gcc 2.96 boost/libs/python/test/opaque.cppfailure
--- 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 have. > > You should do that. Beman has retired for the day due to a cold. > Let me know how the tests go. I've checked in the patch and we will restart the tests as soon as the Sourceforge server is cooperating. Ralf __ Do you Yahoo!? Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop! http://platinum.yahoo.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] RC_1_30_0: gcc 2.96 boost/libs/python/test/opaque.cppfailure
--- 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:
> >>>
> >>> template <>
> >>> inline type_info type_id(boost::type*) {
> >>> return type_info(typeid(Pointee*));
> >>> }
> >>>
> >>> template <>
> >>> inline type_info type_id(
> >>> boost::type*) {
> >>> return type_info(typeid(Pointee*));
> >>> }
> >>>
> >> You're probably right, but the other compilers didn't
> >> complain... Anyway, that wasn't the cause of the problem; the
> >> problem seems to be that gcc-2.9x doesn't recognize the defaulted
> >> argument but insists on having an argument anyway. Now i have
> >> changed my specializations such that these have *no* arguments and
> >> now it works on all my compilers (MSVC6, VC7.1ß, gcc-2.95.3,
> >> gcc-3.2).
> >
> >I think we need to keep the argument for VC6 at least; the problem is
> >one that shows up at link time because VC6 seems to distinguish
> >function template instantiations only by the types of the arguments
> >and not the template parameters. If you amend the patch so that it
> >still uses the default argument for VC6, I will be happy for Ralf to
> >apply it.
> >
> >Beman, can we get this in under the wire? It only affects
> >Boost.Python and then only a new feature of Boost.Python.
>
> Yes, if it is ready in the next couple of hours. Please let me know when it
> is committed.
I have the patch ready to go and it fixes the gcc 2.96 problem. However, I am
in limbo because I am waiting for a word from David. I don't think his concern
above is valid, but I am not certain.
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 have.
Ralf
__
Do you Yahoo!?
Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop!
http://platinum.yahoo.com
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: RC_1_30_0: minor patch:boost/test/detail/wrap_stringstream.hpp
--- "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 inline is ignored, and our multi-platform builds show that all other compilers are quite happy with it. I'd highly appreciate if the patch could stay in RC_1_30_0. Ralf __ Do you Yahoo!? Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop! http://platinum.yahoo.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] RC_1_30_0: gcc 2.96 boost/libs/python/test/opaque.cppfailure
--- 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: opaque_pointer_converter.hpp
===
RCS file: /cvsroot/boost/boost/boost/python/opaque_pointer_converter.hpp,v
retrieving revision 1.2.2.2
diff -u -r1.2.2.2 opaque_pointer_converter.hpp
--- opaque_pointer_converter.hpp12 Mar 2003 22:58:52 - 1.2.2.2
+++ opaque_pointer_converter.hpp18 Mar 2003 14:18:27 -
@@ -118,12 +118,12 @@
# define BOOST_PYTHON_OPAQUE_SPECIALIZED_TYPE_ID(Pointee) \
namespace boost { namespace python { \
template<>\
-inline type_info type_id(boost::type*) { \
+inline type_info type_id(boost::type* = 0) { \
return type_info (typeid (Pointee *));\
} \
template<>\
inline type_info type_id( \
-boost::type*) { \
+boost::type* = 0) { \
return type_info (typeid (Pointee *));\
} \
}}
Here is the result:
gcc-C++-action
/net/taipan/scratch1/rwgk/bjam/libs/python/test/bin/opaque_ext.so/gcc/debug/runtime-link-dynamic/shared-linkable-true/opaque.o
opaque.cpp:55: default argument specified in explicit specialization
opaque.cpp:55: default argument specified in explicit specialization
opaque.cpp:56: default argument specified in explicit specialization
opaque.cpp:56: default argument specified in explicit specialization
g++ -c -Wall -ftemplate-depth-100 -DBOOST_PYTHON_DYNAMIC_LIB -g -O0
-fno-inline -fPIC -I"/net/taipan/scratch1/rwgk/bjam/libs/python/test" -I
"/usr/local_cci/Python-2.2.1/include/python2.2" -I
"/net/boa/home1/rwgk/rc_1_30_0/boost" -o
"/net/taipan/scratch1/rwgk/bjam/libs/python/test/bin/opaque_ext.so/gcc/debug/runtime-link-dynamic/shared-linkable-true/opaque.o"
"opaque.cpp"
...failed gcc-C++-action
/net/taipan/scratch1/rwgk/bjam/libs/python/test/bin/opaque_ext
__
Do you Yahoo!?
Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop!
http://platinum.yahoo.com
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] RC_1_30_0: gcc 2.96 boost/libs/python/test/opaque.cppfailure
--- 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 this problem.
> > I am not sure this is important enough to delay the release any further.
> > David?
> >
> > Ralf
>
> Hmm, looking at:
>
> # define BOOST_PYTHON_OPAQUE_SPECIALIZED_TYPE_ID(Pointee) \
> namespace boost { namespace python { \
> template<>\
> inline type_info type_id(boost::type*) { \
> return type_info (typeid (Pointee *));\
> } \
> template<>\
> inline type_info type_id( \
> boost::type*) { \
> return type_info (typeid (Pointee *));\
> } \
> }}
>
> 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:
>
> template <>
> inline type_info type_id(boost::type*) {
> return type_info(typeid(Pointee*));
> }
>
> template <>
> inline type_info type_id(
> boost::type*) {
> return type_info(typeid(Pointee*));
> }
>
> ??
That change does not seem to make a difference. The compiler errors are still
exactly the same.
Ralf
__
Do you Yahoo!?
Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop!
http://platinum.yahoo.com
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] RC_1_30_0: gcc 2.96 boost/libs/python/test/opaque.cpp failure
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 __ Do you Yahoo!? Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop! http://platinum.yahoo.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] RC_1_30_0: minor patch:boost/test/detail/wrap_stringstream.hpp
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() ^ Here is the patch: Index: wrap_stringstream.hpp === RCS file: /cvsroot/boost/boost/boost/test/detail/wrap_stringstream.hpp,v retrieving revision 1.2 diff -r1.2 wrap_stringstream.hpp 42,44c42,44 < wrap_stringstream& ref(); < wrapped_stream& stream(); < std::string const& str(); --- > inline wrap_stringstream& ref(); > inline wrapped_stream& stream(); > inline std::string const& str(); I've tested with gcc 2.69, Tru64/cxx and IRIX/CC (MIPSpro). I'll monitor our auto-builds (next run in about 2 hours) to check that this doesn't unexpectedly cause any problems somewhere else. Ralf __ Do you Yahoo!? Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop! http://platinum.yahoo.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] RC_1_30_0 still broken
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 __ Do you Yahoo!? Yahoo! Web Hosting - establish your business online http://webhosting.yahoo.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Update: Outstanding patches and fixes
--- 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 stability. If you miss the train do you expect it to come back just for you? Would that make sense in the grand scheme of things? Ralf __ Do you Yahoo!? Yahoo! Web Hosting - establish your business online http://webhosting.yahoo.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Update: Outstanding patches and fixes
--- 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 chance to check that the candidate is healthy on all platforms. IFO stronlgy favor undoing the changes to lexical_cast.hpp. Waiting with the actual release until Sunday sounds good to me. But I very much hope that everybody refrains from experimenting on the RC_1_30_0 branch. Ralf __ Do you Yahoo!? Yahoo! Web Hosting - establish your business online http://webhosting.yahoo.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] RC_1_30_0: lexical_cast.hpp broken under Mac OS X/gcc 3.2.2
The recent patch to lexical_cast.hpp causes problems under Mac OS X/gcc 3.2.2. The error message appears at the top of: http://cci.lbl.gov/boost/results/1047512220/dailylog_coral_test .../boost/boost/lexical_cast.hpp:92: `wstring' undeclared in namespace `std' This worked before: http://cci.lbl.gov/boost/results/1047490620/dailylog_coral_test (There are some other unrelated problems on this platform.) Ralf __ Do you Yahoo!? Yahoo! Web Hosting - establish your business online http://webhosting.yahoo.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Outstanding patches and fixes
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 significant investment? I wish the rules for release candidates are much stricter: NO new features after branching, only bug fixes and portability fixes should be allowed. If everybody keeps squeezing in new features at the last minute the whole idea of having a release candidate is obsolete. Ralf --- Beman Dawes <[EMAIL PROTECTED]> wrote: > Here is my list of outstanding patches and fixes. It would be great if we > could resolve the bulk of these for 1.30.0. > > If you resolve any of these issues, please let me know so I can clear it > off the list. > > Thanks, > > --Beman > > * lexical_cast changes >Kevlin and Terje doing final tests on changes. > > * Boost.Python private email >Final changes promised for Wednesday night. > > * Possible addition to operators library from Sam Partington >Daniel Frey and Sam discussing changes. > > * Regex "make boost work better" patch from Lars Gullik Bjønnes >John Maddock will investigate once new machine working > > * Multi-array constructor patch >Has been applied, but caused Win32 Metrowerks "constructors" >test failure. > > * [bgl] pass by value >Awaiting response from Jeremy > > * PRB with type_traits::is_member_function_pointer >Would prefer John Maddock or someone else more familiar with type >traits regeneration make this change. > > * Does this compiler need configuring >Howard has provided patch, but need Mac person to apply and test. > > * [config] BOOST_DEDUCED_TYPENAME >Status currently unknown. John? Aleksey? > > * [Boost.Python] rpms and small fix for RedHat >Awaiting reply. Dave? > > * [status/Jamfile] Jamfile patches for Borland >Need a decision. Dave? > > * [Boost.Regex] [PATCH] Fix GCC 3.3 warnings from Lars Gullik Bjønnes >Awaiting response from John. > > * tuples::apply >Did this every get resolved? Aleksey? Jaakko? > > * [Boost.Test] Request for const fix in unit_test_suite.hpp >Posted 12 Feb 2003. Did this ever get resolved? Gennadiy? > > --- end --- __ Do you Yahoo!? Yahoo! Web Hosting - establish your business online http://webhosting.yahoo.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] boost/limits.hpp & Itanium2 & RC_1_30_0
--- 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 permission to make stuff work. > (it's nice to notify the list when you do, though) OK, done, both in the RC_1_30_0 branch and in the trunk. Ralf __ Do you Yahoo!? Yahoo! Tax Center - forms, calculators, tips, more http://taxes.yahoo.com/ ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] boost/limits.hpp & Itanium2 & RC_1_30_0
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 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?
Thanks,
Ralf
#include
int main()
{
double x = 1.23456789e12;
unsigned char* c = (unsigned char*) &x;
for (int i=0;i #elif defined(__i386__) || defined(__alpha__) || defined(__ia64) ||
defined(__ia64__)
__
Do you Yahoo!?
Yahoo! Tax Center - forms, calculators, tips, more
http://taxes.yahoo.com/
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] boost/limits.hpp & Itanium2 & RC_1_30_0
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 quick-and-easy way to find out for sure? Finally, if my experiments are successful it would be very useful to include this tiny patch in 1.30.0. Ralf --- limits.hpp Wed Jul 24 09:07:41 2002 +++ /net/cci/rwgk/limits.hppMon Mar 10 15:14:47 2003 @@ -49,7 +49,7 @@ // The macros are not named appropriately. We don't care about integer // bit layout, but about floating-point NaN (etc.) bit patterns. -#if defined(__sparc) || defined(__sparc__) || defined(__powerpc__) || defined(__ppc__) || defined(__hppa) || defined(_MIPSEB) || defined(_POWER) +#if defined(__sparc) || defined(__sparc__) || defined(__powerpc__) || defined(__ppc__) || defined(__hppa) || defined(_MIPSEB) || defined(_POWER) || defined(__ia64__) #define BOOST_BIG_ENDIAN #elif defined(__i386__) || defined(__alpha__) #define BOOST_LITTLE_ENDIAN __ Do you Yahoo!? Yahoo! Tax Center - forms, calculators, tips, more http://taxes.yahoo.com/ ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] 1.30.0 Schedule [was: RC_1_30_0 compile error with SGIMIPSpro Compilers]
--- 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, > >> > >> Thanks for being alert to that. Please post a brief note once you have > >> finished all commits. I've checked in all my patches. I couldn't fully test the RC_1_30_0 branch because Aleksey's recent fixes are not there yet. Aleksey, please let me know when the fixes are available on the branch. I will re-run my tests as soon as possible. Until the 1.30.0 release is finished our multi-platform Boost.Python auto-build procedure will use the RC_1_30_0 branch. The results are available at http://cci.lbl.gov/boost/ The last run started before I checked in my patches. The pages are updated approx. every 6 hours (if the Sourceforge CVS server is cooperating). Ralf __ Do you Yahoo!? Yahoo! Tax Center - forms, calculators, tips, more http://taxes.yahoo.com/ ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] RC_1_30_0 compile error with SGI MIPSpro Compilers
--- 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 currently known which EDG version > // exactly fixes the problem. Sigh. Trying this out right now. If only compilation wouldn't take so long... Ralf __ Do you Yahoo!? Yahoo! Tax Center - forms, calculators, tips, more http://taxes.yahoo.com/ ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] RC_1_30_0 compile error with SGI MIPSpro Compilers
--- "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 the failure on our auto-built "test" pages. I take all that back. The messages are printed if I don't specify -d0. And the as_to_python_function.cpp test behaves just like the others. Sorry for the confusion. Ralf __ Do you Yahoo!? Yahoo! Tax Center - forms, calculators, tips, more http://taxes.yahoo.com/ ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] RC_1_30_0 compile error with SGI MIPSpro Compilers
--- 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 === RCS file: /cvsroot/boost/boost/boost/type_traits/is_base_and_derived.hpp,v retrieving revision 1.4 diff -r1.4 is_base_and_derived.hpp 27c27,31 < #if !defined(__BORLANDC__) --- > #if !defined(__BORLANDC__) \ > && !(defined(__EDG_VERSION__) && __EDG_VERSION__ <= 238) > // The EDG version number is a lower estimate. > // It is not currently known which EDG version > // exactly fixes the problem. > (failed-as-expected) ... > **passed** ... > > unless -d0 caused that to be suppressed, in which case we should > remove the -d0 I guess. 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 the failure on our auto-built "test" pages. Ralf __ Do you Yahoo!? Yahoo! Tax Center - forms, calculators, tips, more http://taxes.yahoo.com/ ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] RC_1_30_0 compile error with SGI MIPSpro Compilers
--- 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 auto-generated? Are there master files that should be > > patched instead? > > Well, in addition, I believe: > /boost/boost/mpl/aux_/lambda_no_ctps.hpp. OK, here are the two additional patches: Index: lambda_no_ctps.hpp === RCS file: /cvsroot/boost/boost/boost/mpl/aux_/lambda_no_ctps.hpp,v retrieving revision 1.7 diff -r1.7 lambda_no_ctps.hpp 127c127 < typedef protect< BOOST_PP_CAT(bind,i)< --- > typedef mpl::protect< BOOST_PP_CAT(bind,i)< Index: iter_fold_if_impl.hpp === RCS file: /cvsroot/boost/boost/boost/mpl/aux_/iter_fold_if_impl.hpp,v retrieving revision 1.5 diff -r1.5 iter_fold_if_impl.hpp 104c104 < >::template result_< Iterator,State,ForwardOp,next > impl_; --- > >::template result_< Iterator,State,ForwardOp,mpl::next > impl_; > The patch that worries me > the most is the one in is_base_and_derived.hpp, but not seriously: > it's just that it should probably be checking __EDG_VERSION instead of > looking for the sgi compiler. I don't know what EDG version to use in the #ifdef. I'll leave this as is for now. If someone else has the same problem on a different platform we can generalize. > Otherwise, they all look fine to me. OK, I'll wait for a word from Aleksey. If he is happy I'll check in the eight patches, both into the trunk and the RC_1_30_0 branch. BTW: David, compilation of as_to_python_function.cpp fails on all platforms. "hopefully_illegal" suggests that this is expected, but then again the test is not called xxx_fail.cpp like the other tests that are expected to fail. Is everything all right here? Don't you want to rename the test? Ralf __ Do you Yahoo!? Yahoo! Tax Center - forms, calculators, tips, more http://taxes.yahoo.com/ ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] RC_1_30_0 compile error with SGI MIPSpro Compilers
--- 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 is gone. This is very helpful and highly appreciated. I spent the better part of today figuring out the six additional patches shown below. I believe all Boost.Python tests build as expected with these patches using the mipspro toolset, but the final re-compilation from scratch is still going. 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 auto-generated? Are there master files that should be patched instead? Thank you in advance! Ralf Index: mpl/protect.hpp === RCS file: /cvsroot/boost/boost/boost/mpl/protect.hpp,v retrieving revision 1.5 diff -r1.5 protect.hpp 32c32 < typedef protect type; --- > typedef struct protect type; Index: mpl/aux_/integral_wrapper.hpp === RCS file: /cvsroot/boost/boost/boost/mpl/aux_/integral_wrapper.hpp,v retrieving revision 1.1 diff -r1.1 integral_wrapper.hpp 30c30 < # define AUX_WRAPPER_INST(value) AUX_WRAPPER_NAME< value > --- > # define AUX_WRAPPER_INST(value) mpl::AUX_WRAPPER_NAME< value > 39c39 < typedef AUX_WRAPPER_NAME type; --- > typedef struct AUX_WRAPPER_NAME type; Index: mpl/aux_/preprocessed/no_ttp/iter_fold_if_impl.hpp === RCS file: /cvsroot/boost/boost/boost/mpl/aux_/preprocessed/no_ttp/iter_fold_if_impl.hpp,v retrieving revision 1.1 diff -r1.1 iter_fold_if_impl.hpp 58c58 < >::template result_< Iterator,State,ForwardOp,next > impl_; --- > >::template result_< Iterator,State,ForwardOp,mpl::next > impl_; Index: mpl/aux_/preprocessed/no_ttp/lambda_no_ctps.hpp === RCS file: /cvsroot/boost/boost/boost/mpl/aux_/preprocessed/no_ttp/lambda_no_ctps.hpp,v retrieving revision 1.1 diff -r1.1 lambda_no_ctps.hpp 34c34 < typedef protect< bind1< --- > typedef mpl::protect< bind1< 59c59 < typedef protect< bind2< --- > typedef mpl::protect< bind2< 85c85 < typedef protect< bind3< --- > typedef mpl::protect< bind3< 111c111 < typedef protect< bind4< --- > typedef mpl::protect< bind4< 137c137 < typedef protect< bind5< --- > typedef mpl::protect< bind5< Index: python/enum.hpp === RCS file: /cvsroot/boost/boost/boost/python/enum.hpp,v retrieving revision 1.6 diff -r1.6 enum.hpp 95c95 < this->enum_base::export_values(); --- > this->base::export_values(); Index: type_traits/is_base_and_derived.hpp === RCS file: /cvsroot/boost/boost/boost/type_traits/is_base_and_derived.hpp,v retrieving revision 1.4 diff -r1.4 is_base_and_derived.hpp 27c27,28 < #if !defined(__BORLANDC__) --- > #if !defined(__BORLANDC__) \ > && !(defined(__sgi) && defined(_COMPILER_VERSION) && _COMPILER_VERSION <= 730) __ Do you Yahoo!? Yahoo! Tax Center - forms, calculators, tips, more http://taxes.yahoo.com/ ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] RC_1_30_0 compile error with SGI MIPSpro Compilers
--- David Abrahams <[EMAIL PROTECTED]> wrote:
> I think it would be better to make the trunk work,
This requires active participation by the developers. We've spent a lot of time
setting up the auto-builds to enable developers to see immediately when their
changes break portability. We've also made a major effort cleaning up 1.29.0.
That seemed like a good start to me, but it didn't work out for lack of
participation from the developer's side. So now I am stuck with messages like
the one posted before:
cc-3192 CC: ERROR File = zzstrip.cpp, Line = 71667
The nontype "boost::mpl::fold_backward>::rebind"
is not a class template.
static const int arity = 3; typedef Sequence arg1; typedef State arg2;
typedef BackwardOp arg3; struct rebind; }; template< typename T1,typename
T2,typename T3 > struct fold_backward ::rebind { template< typename
U1,typename U2,typename U3 > struct apply : fold_backward< U1,U2,U3 > { };
^
If one of the developers could at least comment on this I might give it another
try. Otherwise I estimate it would take me weeks to reverse-engineer what is
happening here.
Ralf
__
Do you Yahoo!?
Yahoo! Tax Center - forms, calculators, tips, more
http://taxes.yahoo.com/
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] RC_1_30_0 compile error with SGI MIPSpro Compilers
--- 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. If nobody else cares about MIPSpro compatibility we will just keep using 1.29.0. I'd like to suggest opening a 1.29 maintenance branch. I've accumulated a few minor patches that make Boost.Python 1.29.0 compatible with Python 2.3. If I could check these patches in they would be available to everybody. Ralf __ Do you Yahoo!? Yahoo! Tax Center - forms, calculators, tips, more http://taxes.yahoo.com/ ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] RC_1_30_0 compile error with SGI MIPSpro Compilers
--- 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
> static type_traits::yes_type bd_helper(D const volatile *, T);
>
> template
> static type_traits::no_type bd_helper(B const volatile *, int);
That doesn't work because older EDG's don't support the bd_helper syntax.
To be sure I just tried it again and it failed.
Using the __BORLANDC__ branch got me a little further. Some Boost.Python tests
compile and run.
Is the __BORLANDC__ branch different from (not as good as) the
is_base_and_derived implementation in 1.29.0?
There are many new errors when compiling the Boost.Python tests, but most of
them are identical:
mipspro-C++-action
/var/tmp/rwgk/bjam/libs/python/test/bin/embedding.test/mipspro/debug/embedding.o
cc-3192 CC: ERROR File =
/u1/rwgrosse/rc_1_30_0/boost/boost/mpl/fold_backward.hpp, Line = 47
The nontype "boost::mpl::fold_backward>::rebind"
is not a class template.
BOOST_MPL_AUX_LAMBDA_SUPPORT(3,fold_backward,(Sequence,State,BackwardOp))
^
I've preprocessed the source of test/embedding.cpp and stripped out all #line
directives. The error message then becomes:
cc-3192 CC: ERROR File = zzstrip.cpp, Line = 71667
The nontype "boost::mpl::fold_backward>::rebind"
is not a class template.
static const int arity = 3; typedef Sequence arg1; typedef State arg2;
typedef BackwardOp arg3; struct rebind; }; template< typename T1,typename
T2,typename T3 > struct fold_backward ::rebind { template< typename
U1,typename U2,typename U3 > struct apply : fold_backward< U1,U2,U3 > { };
^
With the ^ pointing to the beginning of ::rebind.
The full prepocessed, stripped file is here:
http://cci.lbl.gov/~rwgk/tmp/zzstrip.cpp
Are there any insights what the compiler is choking on here?
Thanks,
Ralf
__
Do you Yahoo!?
Yahoo! Tax Center - forms, calculators, tips, more
http://taxes.yahoo.com/
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] RC_1_30_0 compile error with SGI MIPSpro Compilers
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 = sizeof(bdhelper_t::check());
^
1 error detected in the compilation of "zminmin.cpp".
The same code works correctly with gcc 2.96 and an EDG245-based compiler
(Compaq cxx). However, here is an interesting observation:
% cxx -std strict_ansi zminmin.cpp
% a.out
4
No problem with "strict_ansi." But:
% cxx -std ansi -D__USE_STD_IOSTREAM zminmin.cpp
cxx: Error: zminmin.cpp, line 13: operand of sizeof may not be a function
static const unsigned long value = sizeof(bdhelper_t::check());
--^
cxx: Info: 1 error detected in the compilation of "zminmin.cpp".
I am jumping to the conclusion that older EDG's don't support
sizeof(some_function()). Does that sound plausible? What could be done to make
the is_base_and_derived test work with MIPSpro?
Is the test actually used in Boost.Python? -- I noticed that MIPSpro chokes
even if is_base_and_derived_impl2 is not instantiated.
Thanks!
Ralf
#include
template
struct bd_helper
{
static int check();
};
template
struct is_base_and_derived_impl2
{
typedef bd_helper bdhelper_t;
static const unsigned long value = sizeof(bdhelper_t::check());
};
int main()
{
unsigned long n = is_base_and_derived_impl2::value;
std::cout << n << std::endl;
}
__
Do you Yahoo!?
Yahoo! Tax Center - forms, calculators, tips, more
http://taxes.yahoo.com/
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] RC_1_30_0 compile error with SGI MIPSpro Compilers
The MIPSpro problems are due to a hickup in is_base_and_derived.hpp.
Here is the relevant *preprocessed* piece of code:
template
struct bd_helper
{
template
static type_traits::yes_type check(D const volatile *, T);
static type_traits::no_type check(B const volatile *, int);
};
template
struct is_base_and_derived_impl2
{
struct Host
{
operator B const volatile *() const;
operator D const volatile *();
};
static const bool value = sizeof(bd_helper:: check(Host(), 0)) ==
sizeof(type_traits::yes_type);
};
And here is the error:
cc-1108 CC: ERROR File =
/u1/rwgrosse/rc_1_30_0/boost/boost/type_traits/is_base_and_derived.hpp, Line =
106
The indicated expression must have pointer-to-function type.
static const bool value = sizeof(bd_helper ::check(Host(), 0)) ==
sizeof(type_traits::yes_type);
^
Findings:
- Replacing "sizeof(bd_helper ::check(Host(), 0))" by "sizeof(int)"
leads to successful compilation.
- Removing the space before ::check doesn't make a difference.
MIPSpro is based on EDG 238. Are there known issues with "operator T"?
Ideas for a workaround are highly appreciated.
Thanks,
Ralf
__
Do you Yahoo!?
Yahoo! Tax Center - forms, calculators, tips, more
http://taxes.yahoo.com/
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Array support [was SmartPtr (Loki)-auto_ptr/movec'torissue]
--- David Abrahams <[EMAIL PROTECTED]> wrote: > > I did not use boost::shared_array to implement the shared_plain > > 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 could well be. However: - I don't think this was an option a year ago when I started the array family (weak excuse). - The reference counting object is implemented in exactly 44 lines of code. I am afraid a policy based approach could easily involve typedef expressions twice the size (I know I am a bit vicious here). Having said that, a little overhead could be more than justified if the boost smart pointer is thread-safe, as I believe it is now. My shared_plain type does not include any code to specifically support threaded applications (I am counting on Python to get this right for me). Ralf __ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Array support [was SmartPtr (Loki)-auto_ptr/movec'torissue]
--- 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: http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/cctbx/scitbx/include/scitbx/array_family/ Ralf P.S.: If you look around some more and find more missing header files: these are automatically generated by a set of Python scripts under the control of SCons. -- My high-tech replacement for the pre-processor library. __ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Array support [was SmartPtr (Loki)-auto_ptr/movec'torissue]
--- David Abrahams <[EMAIL PROTECTED]> wrote: > [EMAIL PROTECTED] (Joerg Walter) writes: > > > I needed something with exactly boost::shared_array's interface to add > > reference counting to ublas. With shared_array I'm able to run the CLAPACK > > test suite on ublas containers. > > I think Ralf Grosse-Kunstleve did something similar in scitbx > (http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/cctbx/scitbx/array_family/) The type implemented in shared_plain.h (in the directory above) is a reference counted array type. The code is derived from the std::vector implementation in STLport (see copyright statement). Naming is according to Boost conventions. I did not use boost::shared_array to implement the shared_plain type because one of our requirements is that one reference count can be used to manage multiple types. This is required in the context of in-place fast Fourier transforms. I.e. an array that starts out as shared_plain > ends up as shared after the Fourier transformation or vice versa. Of course, constructing an array with type T and destructing it while thinking of it as containing element types U could potentially lead to disasters. To provide a certain degree of protection type casts are therefore only allowed for element types with trivial destructors. This is managed through type traits that can be specialized by the user. The source code comes with a comprehensive set of regression tests. It is also extensively tested as part of our application and has not changed significantly for about 10 months now. I.e. I consider it "stable." I am planning to write documentation "real soon." The license is also compatible with Boost, I believe. Ralf __ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] STL extensions
--- 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. > > That sort of surprises me. I think they should go in boost, for sure, > but I thought the compatibility library was about fixing broken > std library implementations. This is really Ralf's bailiwick, though. > Ralf? My contribution to the compatibility library focuses completely on providing the C++ C headers (such as ) on a couple of platforms. The intent was to make a compiler/library appear as std-conformant as possible, but in a lightweight fashion (I had some difficulties using STLport). I don't really have an opinion regarding Toon's proposal, but my gut feeling is that compatibility with the ISO standard is very different from compatibility with someone's extensions. Maybe something like "extension adaptor" library is more appropriate? Ralf __ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
