- Boost - lists.boost.org

[Boost-bugs] [ boost-Bugs-1508243 ] C++ preprocessor stop at GCC include
by SourceForge.net 18 Jun '06

18 Jun '06

Bugs item #1508243, was opened at 2006-06-18 12:13 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1508243&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: wave Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Hartmut Kaiser (hkaiser) Summary: C++ preprocessor stop at GCC include Initial Comment: Hi, C++ preprocessor stop at the middle of include files. All infomation is inside the attached files. If more info is needed, contact me kenhashimoto123(a)yahoo.com ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1508243&group_… _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

[PQS] For Janek
by Andy Little 18 Jun '06

18 Jun '06

Hi Janek, I'm listening :-) No time to reply now though. :-( regards Andy Little

1 0

[Minor] Anyone having the holy Green Hills C++ compiler docs?
by Gennaro Prota 17 Jun '06

17 Jun '06

Hi guys, this is now a matter of principle for me... I'm working on the new compiler identification macros for Boost.Config (see dedicated thread) and spent a whole morning trying to figure out something more detailed than what already is in "boost/config/compiler/greenhills.hpp". Incredibly, not even www.ghs.com has anything useful. The only references (not derived from boost code) that I found used either ghs or __ghs__ to identify the presence of the compiler (without inferring its version). And the only page which attempts to go further is: http://predef.sourceforge.net/precomp.html Does anyone have more info? Thanks. --Gennaro.

2 2

[Boost-bugs] [ boost-Bugs-1507851 ] stop preprocessing
by SourceForge.net 17 Jun '06

17 Jun '06

Bugs item #1507851, was opened at 2006-06-17 10:38 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1507851&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: wave Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Hartmut Kaiser (hkaiser) Summary: stop preprocessing Initial Comment: Hi, I am reporting bug for Boost::Wave library. I have made CPreProcessor out of Boost::Wave::tool directory. When Hello.cpp is preprocessed, output(temp.cpp) is incomplete. Include trace is included at BUG_includelist.txt. GGG.bat is the MSDOS batch file, which I run with the parameter "Hello". GccConfig.txt is configuration file for CPreProcessor. GCC version is listed below. Microsoft Windows XP [Version 5.1.2600] (C) Copyright 1985-2001 Microsoft Corp. C:\CPP_Parser\CPP_parserV3.1\test>gcc --version gcc (GCC) 3.4.4 (cygming special) (gdc 0.12, using dmd 0.125) Copyright (C) 2004 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Boost::Wave version is listed below. C:\CPP_Parser\CPP_parserV3.1 \test>C:\Eclipse.workspace\WaveCPreProcessor\Debug\CPr eProcessor -v 1.2.1.1646 (20050312) BUG_includelist.txt indicates preprocessor stop at C:/cygwin3/usr/include/limits.h When I looked at limits.h and temp.cpp, the following line might cause the trouble. #define __LONG_MAX__ 9223372036854775807L My email is kenhashimoto123(a)yahoo.com ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1507851&group_… _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

Any sunpro experts out there?
by John Maddock 17 Jun '06

17 Jun '06

The sunpro type_traits tests are currently mostly failing because is_enum is broken, this in turn is likely to really be an is_convertible failure. There are a few possible preprocessor branches that could be taken for is_convertible, if some kind soul with access to sunpro would give these a try and see if any fix the errors that would be very welcome. Thanks, John.

5 15

[pool] Problem with ordered_malloc() and ordered_free()
by Boris 17 Jun '06

17 Jun '06

I have a problem with ordered_malloc() and ordered_free() which might be from misunderstanding the documentation. I use these two functions to overload operator new[] and operator delete[]: template <class T> class mem_manager { protected: static boost::pool<my_allocator> mem_pool; public: void *operator new[](std::size_t size) { return mem_pool.ordered_malloc(size / sizeof(T)); } void operator delete[](void *p) { mem_pool.ordered_free(p); } }; I overloaded new and delete with malloc() and free() which works fine. However from what I understand I can't use them for new[] and delete[] - that's why I tried ordered_malloc() and ordered_free(). I haven't really investigated the problem yet because I'm not sure if I implemented these two operators correctly or if I understood ordered_malloc() and ordered_free() wrong. The documentation at http://www.boost.org/libs/pool/doc/interfaces/pool.html says something about merging free lists and preserving order with ordered_malloc(). Is this related to allocating an array? Or how shall I implement new[] and delete[] correctly? Boris

1 0

[filesystem] multiple definition errors patch
by Daniel Schlyder 17 Jun '06

17 Jun '06

I had to apply the attached patch to use Boost.Filesystem CVS HEAD with MinGW (GCC 3.4.5). Index: boost/filesystem/convenience.hpp =================================================================== RCS file: /cvsroot/boost/boost/boost/filesystem/convenience.hpp,v retrieving revision 1.12 diff -u -p -r1.12 convenience.hpp --- boost/filesystem/convenience.hpp 9 Mar 2006 22:14:08 -0000 1.12 +++ boost/filesystem/convenience.hpp 17 Jun 2006 14:54:11 -0000 @@ -28,7 +28,7 @@ # else # define BOOST_FS_FUNC(BOOST_FS_TYPE) inline BOOST_FS_TYPE typedef boost::filesystem::path Path; -# define BOOST_FS_FUNC_STRING std::string +# define BOOST_FS_FUNC_STRING inline std::string # define BOOST_FS_TYPENAME # endif

1 0

[smart_ptr/static_pointer_cast] Trying to make ADL useful in my boost libraries
by Ion Gaztañaga 17 Jun '06

17 Jun '06

Hi to all, There were some recent Shmem/Interprocess bug reports concerning header ordering issues. I've investigated it a bit and I've come up with a reduced test case that reproduces the problem that happens with the static_pointer_cast() expression. Now that I have reduced the problem, I don't know how to solve it so I need some expert ADL recommendation to implement a "best practices" approach in my boost code. Imagine a container that can store raw pointers or smart pointers pointer to a polymorphic class (or a container using an allocator that defines its own "pointer" type). To avoid instantiations, it uses static_pointer_cast to work only with base classes and avoid code bloat. This is typical in node based containers like lists and trees. Then suppose a container factory that creates containers based on a configuration. Here is the code: //////////////////////////////////////// //containers.hpp header: //////////////////////////////////////// namespace boost { namespace dummy { template<class Pointer> class container { Pointer ptr; public: void func() { static_pointer_cast<int>(Pointer()); } }; } //namespace dummy { } //namespace boost { //////////////////////////////////////// //smart_ptr.hpp header: //////////////////////////////////////// namespace boost { namespace dummy { template<class T> class smart_ptr { }; template<class T, class U> smart_ptr<T> static_pointer_cast(const smart_ptr<U> &u) { return smart_ptr<T>(); } } //namespace dummy { } //namespace boost { //////////////////////////////////////// //container_factory.hpp header: //////////////////////////////////////// namespace boost { namespace dummy { class container_factory { public: template<class Container> static Container *create() { return new Container; } }; } //namespace dummy { } //namespace boost { //////////////////////////////////////// //main.cpp: //////////////////////////////////////// #include "container.h" #include "smart_ptr.h" #include "container_factory.h" int main() { using namespace boost::dummy; typedef container<smart_ptr<int> > my_container; my_container *cont = container_factory::create<my_container>(); cont->func(); return 0; } This code compiles in VC 7.1 and VC 8 but fails with gcc, complaining the "there is no declaration for static_pointer_cast". If we change the header order to: #include "smart_ptr.h" #include "container.h" #include "container_factory.h" This compiles fine because the static_pointer_cast definition is found before the call. My first question is: * Is this gcc error correct? Revising a bit ADL + template issues (a fairly complicated logic that should be removed from C++, in my opinion) I think that gcc is right. * If gcc is correct, what is the implementor supposed to do? Every templatized class header shouldn't include smart_ptr.h because smart_ptr is unknown and it can even be a user-defined class. * If this is correct, that is the user supposed to do? The user has included all the headers, and he shouldn't know about the implementation and internal dependency issues. It's really a mess for a user to start guessing the correct header order. And this is only a simple dependency, imagine a fairly more complicated approach, it would be really a nightmare. So the question is, how should I write my library to take advantage of ADL without creating such header dependency problems? Should I avoid ADL and require static_pointer_cast overloads in boost namespace for a user class defined in a different namespace? I must have missed something, because otherwise, I would find ADL really useless as a robust customization point. Any expert willing to help? Regards, Ion

5 16

[Boost-bugs] [ boost-Support Requests-1507697 ] Mail Delivery failure when committing to Boost CVS
by SourceForge.net 17 Jun '06

17 Jun '06

Support Requests item #1507697, was opened at 2006-06-17 10:00 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=207586&aid=1507697&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Reece H Dunn (msclrhd) Assigned to: Nobody/Anonymous (nobody) Summary: Mail Delivery failure when committing to Boost CVS Initial Comment: When making changes to the main Boost CVS repository (the Boost.Build V2 HEAD revision to be precise) on Windows XP SP2 with cvsnt + TortoiseCVS 1.8.26 + Putty/PAgent 0.53b I am getting the following Mail Delivery error when CVS is sending the change history: Mail Delivery System (Mailer-Daemon(a)sshgate.sourceforge.net) +Add contact To: msclrhd(a)users.sourceforge.net Subject: Mail delivery failed: returning message to sender This message was created automatically by mail delivery software. A message that you sent could not be delivered to one or more of its recipients. This is a permanent error. The following address(es) failed: boost-build(a)lists.sourceforge.net SMTP error from remote mailer after RCPT TO:<boost-build(a)lists.sourceforge.net>: host sc8-sf-mx-b.sourceforge.net [10.3.1.91]: 550-Verification failed for <msclrhd(a)users.sourceforge.net> 550-(result of earlier verification reused). 550 Sender verify failed ------ This is a copy of the message, including all the headers. ------ Return-path: <msclrhd(a)users.sourceforge.net> Received: from sc8-pr-cvs3-b.sourceforge.net ([10.5.1.173] helo=sc8-pr-cvs3.sourceforge.net) by sc8-sf-sshgate.sourceforge.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.43) id 1Fqpme-0007Wt-Sn for boost-build(a)lists.sourceforge.net; Thu, 15 Jun 2006 04:13:09 -0700 Received: from msclrhd by sc8-pr-cvs3.sourceforge.net with local (Exim 4.43) id 1Fqpme-0003dp-AV for boost-build(a)lists.sourceforge.net; Thu, 15 Jun 2006 04:13:08 -0700 To: boost-build(a)lists.sourceforge.net Subject: CVS: boost/tools/build/v2/tools msvc.jam,1.81,1.82 Message-Id: <E1Fqpme-0003dp-AV(a)sc8-pr-cvs3.sourceforge.net> From: Reece H Dunn <msclrhd(a)users.sourceforge.net> Date: Thu, 15 Jun 2006 04:13:08 -0700 ... NOTE: In my SF user area, it says that msclrhd(a)users.sourceforge.net is aliased to my Hotmail address (which I use for the lists). I did try signing up to the Boost.Biuld list using my SF e-mail which worked, but I still got a mail delivery failure. - Reece ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=207586&aid=1507697&group_… _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

try/catch(...) in thread_proxy()
by Kim Barrett 16 Jun '06

16 Jun '06

Back in August 2005 there was a discussion on this list of the pros and cons of the existance of the try/catch(...) in thread_proxy(), which seemed to me to end with a pretty clear consensus that it should be removed. There was also a bug report filed around that time about this: 1274707. Having spent about a couple of days in the past week helping coworkers track down problems that ultimately proved to be obvious mistakes that were hidden by that catch clause, I've patched our local copy of boost 1.33.1 to remove that "feature". (I'd rather not think about how much time the affected coworkers lost to this.) I also checked boost CVS and found that this change hasn't been made there yet, so I'm attaching the patch below. ----------------------------------- --- thread.cpp.orig 2005-07-14 11:46:50.000000000 -0400 +++ thread.cpp 2006-06-16 18:17:33.000000000 -0400 @@ -105,22 +105,13 @@ static OSStatus thread_proxy(void* param) #endif { - try - { - thread_param* p = static_cast<thread_param*>(param); - boost::function0<void> threadfunc = p->m_threadfunc; - p->started(); - threadfunc(); + thread_param* p = static_cast<thread_param*>(param); + boost::function0<void> threadfunc = p->m_threadfunc; + p->started(); + threadfunc(); #if defined(BOOST_HAS_WINTHREADS) - on_thread_exit(); + on_thread_exit(); #endif - } - catch (...) - { -#if defined(BOOST_HAS_WINTHREADS) - on_thread_exit(); -#endif - } #if defined(BOOST_HAS_MPTASKS) ::boost::detail::thread_cleanup(); #endif

1 0