|
|
Boost : |
Subject: Re: [boost] [Boost 1.41: list_of] Boost compliation error, > Sun Studio 11 using standard C++ lib
From: shing fan (shingfan_at_[hidden])
Date: 2010-01-03 22:38:28
>From the sound of this, it is nearly impossible to compile boost using SS11 with stdlib without some sort of complier-hack. I'm not the only user using the environment so hacking the complier would not be a viable solution. And my lib has to work with another third-party lib which specifically mentioned that they do not support the use of stlport. i'm not ready to take the responsibility of causing any problem to a third-party lib if any do arise. So i guess my only choice is to switch to GCC if i need to work on Solaris and use Boost (1.36+)? What is the drawback for using GCC? The only thing that i know of between GCC and SS is that GCC's complier is slower, any other reason why one would prefer SS over GCC?
Many thanks for other useful comments as well and i really appreciate all of them.
> From: boost-request_at_[hidden]
> Subject: Boost Digest, Vol 2780, Issue 2
> To: boost_at_[hidden]
> Date: Sun, 3 Jan 2010 20:33:09 -0500
>
> Send Boost mailing list submissions to
> boost_at_[hidden]
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://lists.boost.org/mailman/listinfo.cgi/boost
> or, via email, send a message with subject or body 'help' to
> boost-request_at_[hidden]
>
> You can reach the person managing the list at
> boost-owner_at_[hidden]
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Boost digest..."
>
>
> The boost archives may be found at: http://lists.boost.org/Archives/boost/
>
> Today's Topics:
>
> 1. Re: [serialization]Memory leak, VS2009, dynamic library
> (Robert Ramey)
> 2. Re: Boost.Atomic request for review/inclusion (Phil Endecott)
> 3. Re: How to create a shallow copy without callingaconstructor?
> (vicente.botet)
> 4. Re: [Boost 1.41: list_of] Boost compliation error, > Sun
> Studio 11 using standard C++ lib (shing fan)
> 5. Re: [Random]Random value from range (Steven Watanabe)
> 6. Re: [Boost 1.41: list_of] Boost compliation error, > Sun
> Studio 11 using standard C++ lib (Stefan Teleman)
> 7. Re: [Boost 1.41: list_of] Boost compliation error, > Sun
> Studio 11 using standard C++ lib (Rob Riggs)
> 8. Re: [Boost 1.41: list_of] Boost compliation error, > Sun
> Studio 11 using standard C++ lib (Stefan Teleman)
> 9. Re: [test] va_copy (Gennadiy Rozental)
> 10. Re: [test] va_copy (Gennadiy Rozental)
> 11. Re: Is floating_point_comparison.hpp general purpose tool?
> (Gennadiy Rozental)
> 12. Re: [Random]Random value from range (Topher Cooper)
> 13. Re: [Boost 1.41: list_of] Boost compliation error, > Sun
> Studio 11 using standard C++ lib (Rob Riggs)
> 14. Re: [test] va_copy (Steven Watanabe)
> 15. Re: [test] va_copy (Bj?rn Roald)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Sun, 3 Jan 2010 09:10:16 -0800
> From: "Robert Ramey" <ramey_at_[hidden]>
> To: boost_at_[hidden]
> Subject: Re: [boost] [serialization]Memory leak, VS2009, dynamic
> library
> Message-ID: <hhqioc$tia$1_at_[hidden]>
>
> I believe this is addressed in 1.42
>
> Robert Ramey
>
> Mariusz Kwiczala wrote:
> > Hello,
> >
> > I have memory leak during initialization of boost.serialization.dll.
> > (I did not call any function from boost.serialization - some static
> > initialization does not free resources)
> > Is it known bug or I missed some library settings?
> >
> > Callstack to memory leak:
>
>
>
>
>
> ------------------------------
>
> Message: 2
> Date: Sun, 03 Jan 2010 17:09:05 +0000
> From: "Phil Endecott" <spam_from_boost_dev_at_[hidden]>
> To: <boost_at_[hidden]>
> Subject: Re: [boost] Boost.Atomic request for review/inclusion
> Message-ID: <1262538545458_at_[hidden]>
> Content-Type: text/plain; format="flowed"
>
> Phil Endecott wrote:
> > There's a new version of my ARM patch here:
> >
> > http://chezphil.org/tmp/boost_atomic_20091220.patch
>
> Another update here:
>
> http://chezphil.org/tmp/boost_atomic_20100103.patch
>
> This adds support for ARM architecture v7. It seems to compile but
> hasn't been properly tested.
>
> I have noticed a few posts here from other people writing iPhone code;
> if you would like to try out a shared_ptr that uses this for its atomic
> reference count, please let me know.
>
> I think it would be great to get Helge's code adopted as Boost.Atomic
> ASAP and to port things like shared_ptr to use it. As usual the
> limiting thing is presumably a review manager...
>
> One thing that seems to be missing is a test that actually tries to
> check for atomicity, i.e. by running multiple threads. Helge, do you
> have something? Does anyone else have something that can be adapted
> for this?
>
>
> Happy New Year,
>
> Phil.
>
>
>
>
>
> ------------------------------
>
> Message: 3
> Date: Sun, 3 Jan 2010 18:59:24 +0100
> From: "vicente.botet" <vicente.botet_at_[hidden]>
> To: <boost_at_[hidden]>
> Subject: Re: [boost] How to create a shallow copy without
> callingaconstructor?
> Message-ID: <8D5ADFEA818544F78596B8A4631296FA_at_viboes1>
> Content-Type: text/plain; charset="iso-8859-1"
>
> Hi Stefan, thanks for your comments
> ----- Original Message -----
> From: "Stefan Strasser" <strasser_at_[hidden]>
> To: <boost_at_[hidden]>
> Sent: Sunday, January 03, 2010 4:55 AM
> Subject: Re: [boost] How to create a shallow copy without callingaconstructor?
>
>
> >
> > Am Saturday 02 January 2010 23:34:51 schrieb vicente.botet:
> >> I want to define a generic mixin that define these function, something
> >> like:
> >>
> >> template <class Derived, typename Base=base_transaction_object>
> >> class shallow_transaction_object : public Base
> >> {
> >> public:
> >> base_transaction_object* shallow_clone() const {
> >> Derived* p = reinterpret_cast<Derived*>( new char[sizeof(Derived)]);
> >> std::memcpy(p, static_cast<Derived const*>(this), sizeof(Derived));
> >> return p;
> >> }
> >>
> >> void cache_deallocate() {
> >> delete[] reinterpret_cast<char*>(this);
> >> }
> >>
> >> void copy_state(base_transaction_object const * const rhs) {
> >> std::memcpy(static_cast<Derived *>(this), static_cast<Derived const *
> >> const>(rhs), sizeof(Derived )); }
> >> };
> >>
> >> So the user can just declare its own class as
> >>
> >> class C : public shallow_transaction_object<C> {
> >> // members concerning the user space
> >> };
> >>
> >> Can this be done in a portable way?
> >
> > depends on if you really mean portable or "defined" (by C++ standard).
>
> I meant portable.
>
> > I doubt memcpy()ing objects with a virtual pointer is defined, but I think
> > it'll work on all implementations I know of if you always copy the most
> > derived type.
>
> This will always be the case. I should rename the template parameter Derived by Final.
>
> template <class Final, typename Base=base_transaction_object>
> class shallow_transaction_object;
>
> > what types can class C : shallow_transaction_object contain? can it contain
> > pointers or is it limited to "shallow types"?
>
> it can contain any non pointer type and pointers to transactional objects, but no pointer to non-transactional objects.
> The pointee transactional objects do not need to be copied since the STM system track any modification to them.
>
> > for the latter, you might want to make the decision if memcpy() can be used
> > based on boost::serialization::is_bitwise_serializable.
>
> is_bitwise_serializable don't goes too far. it is equivalent to is_artithmetic. But it can be specialized.
>
> I have find in Boost.TypeTraits this example
>
> An Optimized Version of std::copy
> Demonstrates a version of std::copy that uses has_trivial_assign to determine whether to use memcpy to optimise the copy operation.
>
> maybe I need something like has_trivial_copy and has_trivial_assign.
>
> > is the object in the cache used or is it only stored to be copied back to the
> > exact same position of the original object, in case the transaction fails?
>
> This depends on the updating policy. With direct updating the cached objects is used as a backup and used to restablish the shared object in case of rollback, so it is never used directly, with deferred updating, the cached object is the object modified by the transaction and used to update the shared object in case of succesfull commit.
>
> For what you and Mathias said, and as I suspected the code is neither portable nor correct and limited to types having trivial copy semantics.
>
> template <class Derived, typename Base=base_transaction_object>
> class trivial_transactional_object : public Base
> {
> typedef Base base_type;
> public:
> base_transaction_object* make_cache() const {
> Derived* p = reinterpret_cast<Derived*>( new char[sizeof(Derived)]);
> std::memcpy(p, static_cast<Derived const*>(this), sizeof(Derived));
> return p;
> }
>
> void remove_cache() {
> delete[] reinterpret_cast<char*>(this);
> }
>
> void copy_cache(base_transaction_object const * const rhs) {
> std::memcpy(static_cast<Derived *>(this), static_cast<Derived const * const>(rhs), sizeof(Derived ));
> }
> };
>
> For shallow copy semantics, I suspect that I will need to relay on whether the user defines these shallow copy constructor and assignement operations following these prototypes
>
> struct shallow_t {};
> const shallow_t shallow = {};
>
> C(C const&, shallow_t);
> C& shallow_assign(C const&);
>
> The new shallow_transactional_object could be defined as
>
> template <class Derived, typename Base=base_transaction_object>
> class shallow_transactional_object : public Base {
> public:
> base_transaction_object* make_cache() const {
> Derived* p = reinterpret_cast<Derived*>( new char[sizeof(Derived)]);
> return new(p) Derived(this, shallow);
> }
>
> void remove_cache() {
> delete[] reinterpret_cast<char*>(this);
> }
>
> void copy_cache(base_transaction_object const * const rhs) {
> this->shallow_assign(static_cast<Derived const * const>(rhs));
> }
> };
>
> Now I can define transactional_object depending on whether has_trivial_copy_semantics<T>::value , has_shallow_copy_semantics<T>::value, or has_deep_copy_semantics<T>::value (TBD)
>
> namespace detail {
> template <class Final, typename Base, bool hasShallowCopySemantics, bool hasTrivialCopySemantics>
> class transactional_object;
> template <class Final, typename Base>
> class transactional_object<Final, Base, true, true>: public shallow_transactional_object<Derived, Base> {};
> template <class Final, typename Base>
> class transactional_object<Final, Base, true, true>: public shallow_transactional_object<Derived, Base> {};
> template <class Final, typename Base>
> class transactional_object<Final, Base, false,true>: public trivial_transactional_object<Derived, Base> {};
> template <class Derived, typename Base>
> class transactional_object<Final, Base, false,false>: public deep_transactional_object<Derived, Base> {};
> }
> template <class Final, typename Base=base_transaction_object>
> class transactional_object
> : public detail::transactional_object<Final, Base, has_shallow_copy_semantics<Derived>::value, has_trivial_copy_semantics<Derived>::value>
> {};
>
> Of course, this force the user to define specific shallow copy semantics operations, but IMO this will have some advantages. What do you think of this approach?
>
> Anyway, I find that it is a shame that the compiler know how to make a shallow copy-constructor and shallow assignement operator, but one the user defines a specific one we are unable to use them. Do you think that its is worth to have the possibility to use the default generated constructors and assignement operators in C++ ? For example we could use these defaulted operators as follows
>
> C a(default); // use the default constructor generated by the compiler
> ...
> C b(a, default); // use the default copy constructor generated by the compiler
>
> C c;
>
> std::assign_default(c, a); // use the default assignement operator generated by the compiler for class C
>
> Best,
> Vicente
>
>
>
>
> ------------------------------
>
> Message: 4
> Date: Sun, 3 Jan 2010 18:45:15 +0000
> From: shing fan <shingfan_at_[hidden]>
> To: <boost_at_[hidden]>
> Subject: Re: [boost] [Boost 1.41: list_of] Boost compliation error, >
> Sun Studio 11 using standard C++ lib
> Message-ID: <SNT124-W25BD216A3B9E9938AAE9B6DD750_at_phx.gbl>
> Content-Type: text/plain; charset="iso-8859-1"
>
>
> So, with limited resources (time, labour, and technical expertise on complier), would it be safe to assume that i should pursue other routes (e.g. boost with gcc or with stlport) and not continue with the beast (compling boost with libCstd?). Your professional opinion is much appreciated.
>
> >
> > Message: 2
> > Date: Sun, 03 Jan 2010 04:10:23 +0000
> > From: Mateusz Loskot <mateusz_at_[hidden]>
> > To: boost_at_[hidden]
> > Subject: Re: [boost] [Boost 1.41: list_of] Boost compliation error,
> > Sun Studio 11 using standard C++ lib
> > Message-ID: <4B4018AF.2020705_at_[hidden]>
> > Content-Type: text/plain; charset=ISO-8859-1
> >
> > Steven Watanabe wrote:
> > > AMDG
> > >
> > > shing fan wrote:
> > >> I'm having trouble building Boost headers (e.g.
> > >> <boost/assign/list_of.hpp> ) with Sun Studio 11 using standard C++
> > >> library. I have no problem when i build the headers using the stlport
> > >> lib. However, due to some restrictions, i have to use the standard
> > >> c++ lib but not the stlport lib. Does anyone know whether it is
> > >> possible to complie the following headers using sun studio 11 with
> > >> ONLY the standard C++ library? I'm okay to use even 1.38 as long as i
> > >> can compile it with Sun Studio 11 using ONLY the C++ standard library.
> > >>
> > >
> > > The default standard library for Sun is not supported because it
> > > is insufficiently standards compliant.
> >
> > I would quote Roman Shaposhnik's workshop [1] from Sun:
> >
> > "BOOST with libCstd.so.1 : Can Happen, but is insane"
> >
> > [1] http://www.osdevcon.org/2008/files/tutorial-roman/
> >
> > Best regards,
> > --
> > Mateusz Loskot, http://mateusz.loskot.net
> > Charter Member of OSGeo, http://osgeo.org
>
>
> _________________________________________________________________
> Windows Live: Keep your friends up to date with what you do online.
> http://go.microsoft.com/?linkid=9691815
>
> ------------------------------
>
> Message: 5
> Date: Sun, 03 Jan 2010 10:59:56 -0800
> From: Steven Watanabe <watanabesj_at_[hidden]>
> To: boost_at_[hidden]
> Subject: Re: [boost] [Random]Random value from range
> Message-ID: <4B40E92C.9080809_at_[hidden]>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> AMDG
>
> Mariusz Kwiczala wrote:
> > After experiments I wrote below function.
> > Could you verify if function is written correctly for random value from
> > range [min,max) and
> > uniform distribution?
> >
> > double RandomGenerator(const double min, const double max)
> > {
> > assert(min<max);
> > static boost::lagged_fibonacci44497 gen(static_cast<unsigned
> > int>(std::time(0)));
> > static boost::uniform_real<> range(min, max);
> > static boost::variate_generator<boost::lagged_fibonacci44497&,
> > boost::uniform_real<> > generator(gen, range);
> > const double value = generator();
> > return value;
> > }
> >
> > I have few question related to random library:
> > 1. Is it possibility to write function which will generate numbers
> > from range [min, max] or (min, max)
> >
>
> (min, max) can be handled by rejection from [min, max).
> [min, max] is a bit trickier. Either way, you'll have to implement
> it yourself.
>
> > 2. Why generator (boost::lagged_fibonacci44497)is not properly
> > initialized in some default constructor. Without static_cast<unsigned
> > int>(std::time(0)) code generated the same values after every application
> > run.
> >
>
> This is a feature.
>
> > 3. Why when I missed reference "&" in line
> > boost::variate_generator<boost::lagged_fibonacci44497&, application crashes.
> >
>
> Probably stack overflow. boost::lagged_fibonacci44497 is
> rather large.
>
> > Is it bug?
> >
>
> In Christ,
> Steven Watanabe
>
>
>
> ------------------------------
>
> Message: 6
> Date: Sun, 3 Jan 2010 14:02:55 -0500
> From: Stefan Teleman <stefan.teleman_at_[hidden]>
> To: boost_at_[hidden]
> Subject: Re: [boost] [Boost 1.41: list_of] Boost compliation error, >
> Sun Studio 11 using standard C++ lib
> Message-ID: <1ccb59a21001031102t3384061m21c45e19d3a877_at_[hidden]>
> Content-Type: text/plain; charset=UTF-8
>
> On Sun, Jan 3, 2010 at 13:45, shing fan <shingfan_at_[hidden]> wrote:
> >
> > So, with limited resources (time, labour, and technical expertise on complier), would it be safe to assume that i should pursue other routes (e.g. boost with gcc or with stlport) and not continue with the beast (compling boost with libCstd?). ?Your professional opinion is much appreciated.
>
> This is what you needed to do for boost 1.33.1 to get it to compile
> with Studio 12:
>
> http://kdesolaris-svn.cvsdude.com/branches/BOOST/1.33.1/Solaris/
>
> see the README.Solaris file.
>
> I haven't tried building more recent boosts with libCstd.so.1 since then.
>
> You can build most of boost 1.40.0 with Studio 12 [ with the latest
> patches ] and the Apache Standard C++ Library 4.2.1, which is
> available in Solaris/Nevada builds, but not in Solaris 10.
>
> There are several boost libraries which do not compile with either
> Studio 12 or Studio 12 Update 1, even with the Apache Standard C++
> Library combination above. One library which pops in my mind right now
> is Boost.Interprocess -- it requires C++0x compiler features [ rvalue
> refs ], and this feature is not yet available with Sun Studio.
>
> You can build recent boosts with GCC 4.3.x on Solaris. Please keep in
> mind that GCC C++ binaries are ABI incompatible with Sun Studio C++
> binaries, and you will not be able to mix and match compilers.
>
> HTH,
>
> --Stefan
>
> --
> Stefan Teleman
> KDE e.V.
> stefan.teleman_at_[hidden]
>
>
> ------------------------------
>
> Message: 7
> Date: Sun, 03 Jan 2010 13:12:29 -0700
> From: Rob Riggs <rob_at_[hidden]>
> To: boost_at_[hidden]
> Subject: Re: [boost] [Boost 1.41: list_of] Boost compliation error, >
> Sun Studio 11 using standard C++ lib
> Message-ID: <4B40FA2D.60403_at_[hidden]>
> Content-Type: text/plain; charset=UTF-8; format=flowed
>
> On 01/03/2010 11:45 AM, shing fan wrote:
> > So, with limited resources (time, labour, and technical expertise on complier), would it be safe to assume that i should pursue other routes (e.g. boost with gcc or with stlport) and not continue with the beast (compling boost with libCstd?). Your professional opinion is much appreciated.
> >
>
> C++ on Solaris is a bit of a lost cause at the moment. The near-term
> route that we have decided to take is to abandon Sun Studio altogether
> and focus on porting to GCC on Solaris using the GCC package from
> Blastwave. I encourage others to consider doing the same.
>
> The issue that you will run into with both Sun Studio & stlport and with
> GCC is that neither has working locale support on Solaris. This is not
> an immediate issue for us so it was a reasonable compromise. My
> understanding is that locale support should be working in the near
> future with "regular" GCC on Solaris using the
> --enable-clocale=ieee_1003.1-2001 option.
>
> Longer term, we do not think Sun Studio is a viable platform for C++
> development. In the near future Sun will have to support Sun Studio
> with 3 C++ standard libraries as they have stated publicly that they
> will be adding Apache's libstdcxx (but not when). This is an untenable
> position for third-party library developers (whether open or
> proprietary). None of the three libraries are binary compatible, so
> every third-party library one uses must be compiled with the same
> library. Additionally, Sun will either have to wait to include the
> Apache libstdcxx until c++1x is ratified and their compiler & library
> supports all its features or it will have to support a 4th C++ standard
> library. However, given Sun's history with C++ support, the option they
> are most likely to choose is to have a broken C++ implementation that
> doesn't support all of c++1x for the next decade.
>
> GCCfss from Sun is another alternative, but it appears to be at a
> crossroads with GCC's recent license change. Sun can no longer modify
> GCC to produce IL code for their compiler back-end without also
> releasing those tools under the GPL. Last I checked, this did have
> working locale support. This is really the only working C++
> implementation on Solaris at this point. But its lifespan appears to be
> rather limited.
>
> Rob
>
>
>
> ------------------------------
>
> Message: 8
> Date: Sun, 3 Jan 2010 15:44:47 -0500
> From: Stefan Teleman <stefan.teleman_at_[hidden]>
> To: boost_at_[hidden]
> Subject: Re: [boost] [Boost 1.41: list_of] Boost compliation error, >
> Sun Studio 11 using standard C++ lib
> Message-ID:
> <1ccb59a21001031244p1bc3740crd4f634b4f45d0059_at_[hidden]>
> Content-Type: text/plain; charset=UTF-8
>
> I do not intend to start a flamewar, but the post below contains
> numerous factually wrong, incomplete, misleading and uninformed
> statements.
>
> It is of great disservice to provide erroneous information, and that
> in response to a mailing list request for accurate information about a
> specific topic. Not only it confuses the original question, but it
> also diminishes the value of the mailing list.
>
> I also realise that this is a Boost mailing list, and it is not a Sun
> compiler complaints list.
>
> I will correct the following false assertions:
>
> - Apache Standard C++ Library 4.2.1 [ libstdcxx ] is already included
> and available in Solaris/Nevada. Sun Studio 12 provides support for
> the Apache Library.
>
> How do I know that libstdcxx is available in Solaris/Nevada ? Because
> I put it there.
>
> It is, therefore, not true, that Sun has not given any indication
> about the availability of the Apache Library: it is already available.
>
> - Sun does not have to wait until C++0x is ratified in order to
> provide libstdcxx, simply because libstdcxx does not yet support
> C++0x. There may exist, in the future, an implementation of the
> Apache Standard C++ Library, providing C++0x. It does not yet exist.
>
> - It is already known that the C++ ABI will break for C++0x.
>
> - GCCFSS has nothing to do with C++, or, for that matter, with C, or
> with std::locale. GCCFSS is simply a compiler backend optimizer for
> the SPARC ISA exclusively.
>
> - The stlport4 library available on Solaris has nothing to do with
> GCC. It is only provided for, and supported with, Sun Studio. GCC
> provides its own implementation of the Standard C++ Library, namely
> libstdc++. The implementation of the GNU Standard C++ Library has
> nothing to do with either GCCFSS, or with the Solaris-provided
> stlport4 library.
>
> Thank you for your time.
>
> --Stefan
>
> ------
>
> On Sun, Jan 3, 2010 at 15:12, Rob Riggs <rob_at_[hidden]> wrote:
>
> > C++ on Solaris is a bit of a lost cause at the moment. ?The near-term route
> > that we have decided to take is to abandon Sun Studio altogether and focus
> > on porting to GCC on Solaris using the GCC package from Blastwave. ?I
> > encourage others to consider doing the same.
> >
> > The issue that you will run into with both Sun Studio & stlport and with GCC
> > is that neither has working locale support on Solaris. ?This is not an
> > immediate issue for us so it was a reasonable compromise. ?My understanding
> > is that locale support should be working in the near future with "regular"
> > GCC on Solaris using the --enable-clocale=ieee_1003.1-2001 option.
> >
> > Longer term, we do not think Sun Studio is a viable platform for C++
> > development. ?In the near future Sun will have to support Sun Studio with 3
> > C++ standard libraries as they have stated publicly that they will be adding
> > Apache's libstdcxx (but not when). ?This is an untenable position for
> > third-party library developers (whether open or proprietary). ?None of the
> > three libraries are binary compatible, so every third-party library one uses
> > must be compiled with the same library. ? Additionally, Sun will either have
> > to wait to include the Apache libstdcxx until c++1x is ratified and their
> > compiler & library supports all its features or it will have to support a
> > 4th C++ standard library. ?However, given Sun's history with C++ support,
> > the option they are most likely to choose is to have a broken C++
> > implementation that doesn't support all of c++1x for the next decade.
> >
> > GCCfss from Sun is another alternative, but it appears to be at a crossroads
> > with GCC's recent license change. ?Sun can no longer modify GCC to produce
> > IL code for their compiler back-end without also releasing those tools under
> > the GPL. ?Last I checked, this did have working locale support. ?This is
> > really the only working C++ implementation on Solaris at this point. ?But
> > its lifespan appears to be rather limited.
> >
> > Rob
> >
> > _______________________________________________
> > Unsubscribe & other changes:
> > http://lists.boost.org/mailman/listinfo.cgi/boost
> >
>
>
>
> --
> Stefan Teleman
> KDE e.V.
> stefan.teleman_at_[hidden]
>
>
> ------------------------------
>
> Message: 9
> Date: Sun, 03 Jan 2010 19:36:45 -0500
> From: Gennadiy Rozental <rogeeff_at_[hidden]>
> To: boost_at_[hidden]
> Subject: Re: [boost] [test] va_copy
> Message-ID: <4B41381D.2010800_at_[hidden]>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> Bj?rn Roald wrote:
> > On Friday 01 January 2010 10:15:29 pm Steven Watanabe wrote:
> >> AMDG
> >>
> >> Boost.Test is still failing on some compilers that don't support
> >> va_copy. Is va_copy always a macro? Would it be possible
> >> to use #ifdef va_copy?
> >
> > If it helps, that is what is done here:
> > http://svn.apache.org/repos/asf/stdcxx/branches/4.1.3/src/exception.cpp
>
> I'd rather stay away from ifdef va_copy. Does it required by standard
> for the va_copy to be a macro? Which compiler are still failing?
>
> > The commit in trunk adding va_copy is also missing the va_end call and
> > possibly one more call of va_copy to be correct according to the manpage.
>
> You mean I need va_end after va_copy? Where is another va_copy?
>
> Gennadiy
>
>
>
>
> ------------------------------
>
> Message: 10
> Date: Sun, 03 Jan 2010 19:36:45 -0500
> From: Gennadiy Rozental <rogeeff_at_[hidden]>
> To: boost_at_[hidden]
> Subject: Re: [boost] [test] va_copy
> Message-ID: <4B41381D.2010800_at_[hidden]>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> Bj?rn Roald wrote:
> > On Friday 01 January 2010 10:15:29 pm Steven Watanabe wrote:
> >> AMDG
> >>
> >> Boost.Test is still failing on some compilers that don't support
> >> va_copy. Is va_copy always a macro? Would it be possible
> >> to use #ifdef va_copy?
> >
> > If it helps, that is what is done here:
> > http://svn.apache.org/repos/asf/stdcxx/branches/4.1.3/src/exception.cpp
>
> I'd rather stay away from ifdef va_copy. Does it required by standard
> for the va_copy to be a macro? Which compiler are still failing?
>
> > The commit in trunk adding va_copy is also missing the va_end call and
> > possibly one more call of va_copy to be correct according to the manpage.
>
> You mean I need va_end after va_copy? Where is another va_copy?
>
> Gennadiy
>
>
>
>
> ------------------------------
>
> Message: 11
> Date: Sun, 03 Jan 2010 19:41:35 -0500
> From: Gennadiy Rozental <rogeeff_at_[hidden]>
> To: boost_at_[hidden]
> Subject: Re: [boost] Is floating_point_comparison.hpp general purpose
> tool?
> Message-ID: <hhrdi9$6cp$2_at_[hidden]>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> Paul A. Bristow wrote:
> > I have, for my own purposes, refactored Gennidy's Boost.Test code - attached -
> > with a demo.
>
> I'd rather have single copy of these inside boost tree. Also If we move
> these under math utils hood, I'd rather keep the same name and
> functionality.
>
>
> Gennadiy
>
>
>
> ------------------------------
>
> Message: 12
> Date: Sun, 3 Jan 2010 19:46:20 -0500
> From: Topher Cooper <topher_at_[hidden]>
> To: boost_at_[hidden]
> Subject: Re: [boost] [Random]Random value from range
> Message-ID: <21D741BA-5FE7-4206-B4BB-302BDB4E38F3_at_[hidden]>
> Content-Type: text/plain; charset=utf-8
>
>
> On Jan 3, 2010, at 1:59 PM, Steven Watanabe wrote:
>
> >>
> >> I have few question related to random library:
> >> 1. Is it possibility to write function which will generate numbers from range [min, max] or (min, max)
> >>
> >
> > (min, max) can be handled by rejection from [min, max).
> > [min, max] is a bit trickier. Either way, you'll have to implement
> > it yourself.
>
> [min, max] isn't that much trickier. It can be handled by rejection from [min, max+?). In fact, for floating types, the float_next function from the boost math toolkit will provide an ? that doesn't require rejection. The float_prior function allows (min, max) to be done without rejection. Equivalent things can be done for any numeric type with finite precision (including discrete numeric types). Indefinite precision, though, will generally require rejection. An ? very much smaller than max-min will rarely take the rejection path.
>
> Topher Cooper
>
> ------------------------------
>
> Message: 13
> Date: Sun, 03 Jan 2010 18:12:43 -0700
> From: Rob Riggs <rob_at_[hidden]>
> To: boost_at_[hidden]
> Subject: Re: [boost] [Boost 1.41: list_of] Boost compliation error, >
> Sun Studio 11 using standard C++ lib
> Message-ID: <4B41408B.7030201_at_[hidden]>
> Content-Type: text/plain; charset=UTF-8; format=flowed
>
> Please do not top post.
>
> On 01/03/2010 01:44 PM, Stefan Teleman wrote:
> > On Sun, Jan 3, 2010 at 15:12, Rob Riggs<rob_at_[hidden]> wrote:
> >
> >
> >> C++ on Solaris is a bit of a lost cause at the moment. The near-term route
> >> that we have decided to take is to abandon Sun Studio altogether and focus
> >> on porting to GCC on Solaris using the GCC package from Blastwave. I
> >> encourage others to consider doing the same.
> >>
> >> [Lots of text elided for brevity.]
> >>
> > the post ... contains
> > numerous factually wrong, incomplete, misleading and uninformed
> > statements.
> >
> Stefan, I believe my post is quite well informed. And your reply seems
> to be intended to confuse the issue by discussing the state of affairs
> of OpenSolaris. My statements do not apply to Nevada. My statements
> apply to Solaris 10. This is the platform most Solaris developers
> target in production environments.
>
> You are using the same tactics that Sun sales staff use to pitch their
> operating system capabilities -- by pointing to features that exist only
> in a development version of the operating system and speak as if that
> were what people use on a daily basis. It is disingenuous at best.
>
> I notice you did not post this from your sun.com account. Do you still
> speak for Sun?
>
> Stefan, I have followed your work on PSARC/2008/549 and am very
> encouraged by the work you are doing. But it is also from the public
> discussions that leave many of us questioning the status of this work.
> The fact is this has not made it into Solaris proper yet and there has
> been no public indication that I can find as to when it will make it
> into Solaris. 12 years after c++98 and 7 years after c++03 was ratified
> and the only compiler shipped by Sun that supports these standards is
> GCC. What is going to happen with c++1x?
>
> > It is of great disservice to provide erroneous information, and that
> > in response to a mailing list request for accurate information about a
> > specific topic. Not only it confuses the original question, but it
> > also diminishes the value of the mailing list.
> >
> There is nothing erroneous in my post. The purpose of my post was to
> aid fellow Solaris developers by providing some of my hard-won
> experience on this platform. I do not see anything that confuses the
> topic beyond what is admittedly a confusing state of affairs for C++ on
> Solaris. You are the one intentionally confusing the issue here.
>
> > - Sun does not have to wait until C++0x is ratified in order to
> > provide libstdcxx, simply because libstdcxx does not yet support
> > C++0x. There may exist, in the future, an implementation of the
> > Apache Standard C++ Library, providing C++0x. It does not yet exist.
> >
> Sun's history with libCstd and with STLport implies that they would
> rather live with a non-standard C++ environment than break the ABI
> again. That this does not address c++1x is clealy pointed our in the
> PSARC opinion paper. I am unfamiliar with Sun's internal workings. But
> my understanding is that libstdcxx is going into the next Solaris
> version to provide c++03 compliance and that another version will need
> to be approved to support c++1x. That sucks for us C++ developers. It
> will be like libCstd and stlport4 all over again.
>
> > - GCCFSS has nothing to do with C++, or, for that matter, with C, or
> > with std::locale. GCCFSS is simply a compiler backend optimizer for
> > the SPARC ISA exclusively.
> >
>
> GCCFSS is relevant to this discussion as it is the only full-featured
> and standards-compliant C++ compiler that supports locales readily
> available on Solaris 10.
> > Thank you for your time.
> >
> > --Stefan
> >
>
> Our decision to switch from Sun Studio to GCC was an economic one. The
> compiler that provides the most economic gain for us wins. In today's
> market, for software that impact our business, the value to us of open
> source software that compiles with GCC (and that does not compile with
> Sun Studio) dwarfs the value of commercially available software packages
> that require Sun Studio. That is true today and the economics are not
> likely to ever swing back in favor of Sun Studio.
>
> Regards,
>
> Rob
>
>
> ------------------------------
>
> Message: 14
> Date: Sun, 03 Jan 2010 17:15:00 -0800
> From: Steven Watanabe <watanabesj_at_[hidden]>
> To: boost_at_[hidden]
> Subject: Re: [boost] [test] va_copy
> Message-ID: <4B414114.3090103_at_[hidden]>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> AMDG
>
> Gennadiy Rozental wrote:
> > Bj?rn Roald wrote:
> >> On Friday 01 January 2010 10:15:29 pm Steven Watanabe wrote:
> >>> AMDG
> >>>
> >>> Boost.Test is still failing on some compilers that don't support
> >>> va_copy. Is va_copy always a macro? Would it be possible
> >>> to use #ifdef va_copy?
> >>
> >> If it helps, that is what is done here:
> >> http://svn.apache.org/repos/asf/stdcxx/branches/4.1.3/src/exception.cpp
> >
> > I'd rather stay away from ifdef va_copy. Does it required by standard
> > for the va_copy to be a macro? Which compiler are still failing?
>
> From the regression tests, msvc-10.0 and intel-vc9-win-11.1.
> It also fails with como-win with a vc9 back end.
>
> >> The commit in trunk adding va_copy is also missing the va_end call
> >> and possibly one more call of va_copy to be correct according to the
> >> manpage.
> >
> > You mean I need va_end after va_copy? Where is another va_copy?
>
> In Christ,
> Steven Watanabe
>
>
>
> ------------------------------
>
> Message: 15
> Date: Mon, 4 Jan 2010 02:32:55 +0100
> From: Bj?rn Roald <bjorn_at_[hidden]>
> To: boost_at_[hidden]
> Subject: Re: [boost] [test] va_copy
> Message-ID: <201001040232.55532.bjorn_at_[hidden]>
> Content-Type: Text/Plain; charset="utf-8"
>
> On Monday 04 January 2010 01:36:45 am Gennadiy Rozental wrote:
> > Bj?rn Roald wrote:
> > > On Friday 01 January 2010 10:15:29 pm Steven Watanabe wrote:
> > >> AMDG
> > >>
> > >> Boost.Test is still failing on some compilers that don't support
> > >> va_copy. Is va_copy always a macro? Would it be possible
> > >> to use #ifdef va_copy?
> > >
> > > If it helps, that is what is done here:
> > > http://svn.apache.org/repos/asf/stdcxx/branches/4.1.3/src/exception.cpp
> >
> > I'd rather stay away from ifdef va_copy. Does it required by standard
> > for the va_copy to be a macro?
>
> Latest C++0x drafts say:
>
> Other runtime support [support.runtime]
>
> Table 21 ? Header <cstdarg> synopsis
> Type Name(s)
> Macros: va_arg va_end va_start va_copy
> Type: va_list
>
> And state that <cstdarg> provide same features as C99 stdarg.h with some C++
> adjustments.
>
> > > The commit in trunk adding va_copy is also missing the va_end call and
> > > possibly one more call of va_copy to be correct according to the manpage.
> >
> > You mean I need va_end after va_copy?
>
> Yes - the Linux manual page says.
>
> va_copy()
> An obvious implementation would have a va_list be a pointer to the
> stack frame of the variadic func?
> tion. In such a setup (by far the most common) there seems nothing
> against an assignment
>
> va_list aq = ap;
>
> Unfortunately, there are also systems that make it an array of
> pointers (of length 1), and there one
> needs
>
> va_list aq;
> *aq = *ap;
>
> Finally, on systems where arguments are passed in registers, it may be
> necessary for va_start() to
> allocate memory, store the arguments there, and also an indication of
> which argument is next, so that
> va_arg() can step through the list. Now va_end() can free the
> allocated memory again. To accommodate
> this situation, C99 adds a macro va_copy(), so that the above
> assignment can be replaced by
>
> va_list aq;
> va_copy(aq, ap);
> ...
> va_end(aq);
>
> Each invocation of va_copy() must be matched by a corresponding
> invocation of va_end() in the same
> function. Some systems that do not supply va_copy() have __va_copy
> instead, since that was the name
> used in the draft proposal.
>
> === end manual quote
>
> > Where is another va_copy?
>
> A bit further down the same function:
>
> if( tl != PASS ) {
> args = args_copy; <=====
>
> Looks a lot like a va_list assignment. But I have no clear understanding of
> the code, or va_list HOWTOs for that sake.
>
> --
> Bj?rn
>
>
> ------------------------------
>
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
>
> End of Boost Digest, Vol 2780, Issue 2
> **************************************
_________________________________________________________________
Windows Live: Friends get your Flickr, Yelp, and Digg updates when they e-mail you.
http://go.microsoft.com/?linkid=9691817
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk