- Boost - lists.boost.org

An alternative typeof macro
by Daniel James 03 Sep '04

03 Sep '04

I've come up with an alternative way to invoke the typeof emulations that have been posted. It basically works by defining an iterator over the encoded type. Unfortunately, it can't be used inside a function, and is awkward to use in general, but has the advantage is that it only has to define the call to foo once, which might result in faster compile times. It could possibly also remove the limit on the complexity of the type. Arkadiy's version would require a some changes to do this, but I think Peder's could quite easily. Although I'm not sure as I've only had a brief look at his version. I've implemented it as a sort of typedef, which seems like the easiest way to use it. It's probably easier to understand the code than my explanation, so here it is. It's based on Arkadiy's version in the yahoo groups file section. #define BOOST_TYPEOF_TYPEDEF_ITERATOR_NAME(Name) \ BOOST_PP_CAT(BOOST_TYPEOF_TYPEDEF_ITERATOR_##Name##_, __LINE__) #define BOOST_TYPEOF_TYPEDEF_ITERATOR(Expr, Name) \ struct BOOST_TYPEOF_TYPEDEF_ITERATOR_NAME(Name) { \ template <int pos> \ struct iterator { \ typedef boost::mpl::int_< \ sizeof(boost::type_of::foo<pos>(Expr))> type; \ typedef iterator<pos+1> next; \ }; \ }; #define BOOST_TYPEOF_TYPEDEF(Expr, Name) \ BOOST_TYPEOF_TYPEDEF_ITERATOR(Expr, Name) \ typedef boost::type_of::decode_type< \ BOOST_TYPEOF_TYPEDEF_ITERATOR_NAME(Name)::iterator<0> \ >::type Name; #define BOOST_TYPEOF_TPL_TYPEDEF(Expr, Name) \ BOOST_TYPEOF_TYPEDEF_ITERATOR(Expr, Name) \ typedef typename boost::type_of::decode_type< \ BOOST_TYPEOF_TYPEDEF_ITERATOR_NAME(Name)::iterator<0> \ >::type Name; Here is an example of it's use: template <class Op> struct result_of_nullary_functor { static Op op; BOOST_TYPEOF_TPL_TYPEDEF(op(), type); }; struct g { int operator()(); }; BOOST_MPL_ASSERT_IS_SAME(result_of_nullary_functor<g>::type, int); I've only tested on the intel linux compiler. Daniel

5 38

RE: [boost] Porting to SCO Unix
by Ben Hutchings 03 Sep '04

03 Sep '04

John Maddock <john(a)johnmaddock.co.uk> wrote: > > The following tests in libs/config/configure produce incorrect > > results: > > > > ** checking for pthread_exit in -lpthread... no > > This test tries to compile a C source file that prototypes > > "pthread_exit" as "char pthread_exit();". But my compiler driver > > always adds "-include <...>/pthread.h" to the command line, which > > includes a different, conflicting prototype for this function. I > > think the test ought to include <pthread.h> instead. > > Grrrrr, I used the standard autoconf macros for checking this, if I > get the time I'll try and write my own version that does what you > suggest. > > > ** checking pthread_yield... no > > This is correct, but I do have a pthread_yield_np() function, > > maybe we should look for it, too. > > It's up to the thread lib guys to use it (or not), maybe you could > hassle the authors of the thread lib you are using to provide a > standard function signature? pthread_yield is non-standard; you should use sched_yield instead (if at all). See <http://groups.google.com/groups?selm=3ecbb70c%40usenet01.boi.hp.com>

2 1

Minor preprocessor library documentation typo fixed.
by Jurko Gospodneti� 03 Sep '04

03 Sep '04

Hi all. I'm attaching a patch for a minor typo fix in the Boost preprocessor library docs. HTH, Jurko begin 666 enum_binary_params.html.diff.txt M1DE,12!#3TU005))4T].#0I0<F]D=6-E9#H@,RXY+C(P,#0@,3(Z,C0Z-3(- M"@T**BHJ(&5N=6U?8FEN87)Y7W!A<F%M<RYH=&UL(#(P,#(M,3 M,#0@,# Z M,3 Z,C N,# P,# P,# P("LM,#(P, T*+2TM(&5N=6U?8FEN87)Y7W!A<F%M M<RYH=&UL(#(P,#0M,#DM,#,@,3(Z,3@Z,C,N,# P,# P,# P("LM,#(P, T* M*BHJ*BHJ*BHJ*BHJ*BHJ#0HJ*BH@,C$L,S4@*BHJ*@T*(" )"0D\9'0^<#$\ M+V1T/@T*(" )"0D\9&0^#0H@( D)"0E4:&4@=&5X="!O9B!T:&4@9FER<W0@ M<&%R="!O9B!T:&4@<&%R86UE=&5R+B9N8G-P.PT*(" )"0D)/&(^0D]/4U1? M4%!?14Y535]"24Y!4EE?4$%204U3/"]B/B!C;VYC871E;F%T97,@;G5M8F5R M<R!R86YG:6YG(&9R;VT@/&D^,#PO:3X@=&\@/&D^8V]U;G0\+VD^("T@/&D^ M,3PO:3X-"B @"0D)"71O(&=E;F5R871E('!A<F%M971E<G,N#0H@( D)"3PO M9&0^#0H@( D)"3QD=#YP,CPO9'0^#0H@( D)"3QD9#X-"B$@"0D)"51H92!T M97AT(&]F('1H92!F:7)S="!P87)T(&]F('1H92!P87)A;65T97(N)FYB<W [ M#0H@( D)"0D\8CY"3T]35%]04%]%3E5-7T))3D%265]005)!35,\+V(^(&-O M;F-A=&5N871E<R!N=6UB97)S(')A;F=I;F<@9G)O;2 \:3XP/"]I/B!T;R \ M:3YC;W5N=#PO:3X@+2 \:3XQ/"]I/@T*(" )"0D)=&\@9V5N97)A=&4@<&%R M86UE=&5R<RX-"B @"0D)/"]D9#X-"B @"0D\+V1L/@T*(" )/&@T/E)E;6%R M:W,\+V@T/@T*(" )"3QD:78^#0HM+2T@,C$L,S4@+2TM+0T*(" )"0D\9'0^ M<#$\+V1T/@T*(" )"0D\9&0^#0H@( D)"0E4:&4@=&5X="!O9B!T:&4@9FER M<W0@<&%R="!O9B!T:&4@<&%R86UE=&5R+B9N8G-P.PT*(" )"0D)/&(^0D]/ M4U1?4%!?14Y535]"24Y!4EE?4$%204U3/"]B/B!C;VYC871E;F%T97,@;G5M M8F5R<R!R86YG:6YG(&9R;VT@/&D^,#PO:3X@=&\@/&D^8V]U;G0\+VD^("T@ M/&D^,3PO:3X-"B @"0D)"71O(&=E;F5R871E('!A<F%M971E<G,N#0H@( D) M"3PO9&0^#0H@( D)"3QD=#YP,CPO9'0^#0H@( D)"3QD9#X-"B$@"0D)"51H M92!T97AT(&]F('1H92!S96-O;F0@<&%R="!O9B!T:&4@<&%R86UE=&5R+B9N M8G-P.PT*(" )"0D)/&(^0D]/4U1?4%!?14Y535]"24Y!4EE?4$%204U3/"]B M/B!C;VYC871E;F%T97,@;G5M8F5R<R!R86YG:6YG(&9R;VT@/&D^,#PO:3X@ M=&\@/&D^8V]U;G0\+VD^("T@/&D^,3PO:3X-"B @"0D)"71O(&=E;F5R871E M('!A<F%M971E<G,N#0H@( D)"3PO9&0^#0H@( D)/"]D;#X-"B @"3QH-#Y2 896UA<FMS/"]H-#X-"B @"0D\9&EV/@T* ` end

1 0

[mpl][multi_index][intel-8.0-linux]
by Joaquín Mª López Muñoz 03 Sep '04

03 Sep '04

Newly merged MPL seems to be having problems in Intel 7.x/8.0 under Linux with BOOST_MPL_AUX_ADL_BARRIER_NAMESPACE_OPEN, as shown in http://tinyurl.com/5rj4d Appart from this, the merge is mostly working fine, as far as multi_index is concerned. There's another MPL-related problem, but it's due to a previously masked bug of mine. Congrats and thanks for the staggering effort. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

1 0

UML for templates/conepts/models
by Andreas Fabri 03 Sep '04

03 Sep '04

Hello, do you have any recommendations concerning tools and books for modelling concepts/models with UML. The last time I had a look at such tools there was no support for generic programming, but things might have evolved. Thanks in advance, Andreas

1 0

Re: IOStreams formal review start
by Michel Decima 03 Sep '04

03 Sep '04

>The latest package can be found at the following >> locations: >> >>http://home.comcast.net/~jturkanis/iostreams/ The package avalaible on this page doesn't build with gcc-3.3 on linux and darwin. There are some compilation-time warnings and errors: boost/libs/io/src/file_descriptor.cpp: In member function `void boost::io::file_descriptor_resource::open(const std::string&, std::_Ios_Openmode, std::_Ios_Openmode)': boost/libs/io/src/file_descriptor.cpp:91: error: no matching function for call to `boost::io::file_descriptor_resource::open( const char*, int&, mode_t&)' boost/libs/io/src/file_descriptor.cpp:47: error: candidates are: void boost::io::file_descriptor_resource::open(const std::string&, std::_Ios_Openmode = std::operator|(std::_Ios_Openmode, std::_Ios_Openmode)((std::_Ios_Openmode)8, (std::_Ios_Openmode)16), std::_Ios_Openmode = std::operator|(std::_Ios_Openmode, std::_Ios_Openmode)((std::_Ios_Openmode)8, (std::_Ios_Openmode)16)) boost/libs/io/src/file_descriptor.cpp:68: warning: enumeration value `_M_ios_openmode_end' not handled in switch boost/libs/io/src/file_descriptor.cpp:68: warning: case value `8' not in enumerated type `_Ios_Openmode' /boost/libs/io/src/file_descriptor.cpp:68: warning: case value `16' not in enumerated type `_Ios_Openmode' boost/libs/io/src/file_descriptor.cpp:68: warning: case value `24' not in enumerated type `_Ios_Openmode' ... you may apply the patch file_descriptor-cpp.patch to solve the problem. The link of the shared libraries fails too, because the gzip and bzip2 libraries names are wrong in the file compression.jam (the common names are libz.so and libbz2.so on unix/darwin/solaris...): darwin-Link-DyLib-action bin/boost/libs/io/build/libboost_io.dylib/darwin/debug/shared-linkable-true/libboost_io-d-1_32.dylib ld: can't locate file for: -lzlib ld: can't locate file for: -llibbz2 The patch compression-jam.patch solves the problem, but it may break your build system on other platforms (I'm not a jam file expert yet ;) MD. Vous manquez despace pour stocker vos mails ? Yahoo! Mail vous offre GRATUITEMENT 100 Mo ! Créez votre Yahoo! Mail sur http://fr.benefits.yahoo.com/ Le nouveau Yahoo! Messenger est arrivé ! Découvrez toutes les nouveautés pour dialoguer instantanément avec vos amis. A télécharger gratuitement sur http://fr.messenger.yahoo.com

4 11

RE: [boost] Checking if RTTI is available.
by brangdon＠cix.compulink.co.uk 03 Sep '04

03 Sep '04

In-Reply-To: <20DCDD8F0FCED411AC4D001083CF504501AA9741@MTL-EXCHANGE> sseefeld(a)art.ca (Stefan Seefeld) wrote (abridged): > Out of curiosity: why would anybody not use RTTI ? Why shouldn't > compilers without RTTI just considered broken ? It's generally more expensive than hand-rolled solutions, at least ones that don't have to cope with multiple virtual inheritance. (And I've yet to find a problem for which multiple virtual inheritance seemed like the best solution in C++.) In particular, VC++ ships with MFC, which has its own hand-rolled solution. If you use that, you may not want the overhead of RTTI. -- Dave Harris, Nottingham, UK

2 1

RE: [boost] Re: New design proposal for boost::filesystem
by Bennett, Patrick 03 Sep '04

03 Sep '04

Er, sorry, I mean Dave (I'm sure people knew who I meant). You. :) Anyway, hopefully I didn't misrepresent a statement of yours. I was referring to your message to Carlo Wood where you stated: "...I'm among them. However, I have a hard time articulating what I found difficult about the library, other than that the path portability checks seemed to get in my way. If there's something deeper going on, I'd like to hear your opinion of what it is..." It was this message that I believe I originally replied to stating that internationalization support was an issue (for my company at least). Cheers... > -----Original Message----- > From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] > On Behalf Of David Abrahams > Sent: Tuesday, August 24, 2004 5:00 PM > To: boost(a)lists.boost.org > Subject: [boost] Re: New design proposal for boost::filesystem > > "Bennett, Patrick" <Patrick.Bennett(a)inin.com> writes: > > > My real issue with boost::filesystem is that as currently defined, it's > > unusable in an application that will be used around the world. My > > initial response to this whole thread was just to point out to David > > that there *are* issues preventing people from using the library. He > > didn't think there were any, so I was compelled to point out what one of > > the issues was for me at least. > > David who? > > -- > Dave Abrahams > Boost Consulting > http://www.boost-consulting.com > > _______________________________________________ > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost

6 21

FC++ help!
by David Abrahams 03 Sep '04

03 Sep '04

Did anyone get familiar enough with FC++ during the review period to help me with a few simple examples? I have them in the TMP book and I can't get anything to compile! Thanks in advance, -- Dave Abrahams Boost Consulting http://www.boost-consulting.com

1 0

Re: IOStream mmap too restrictive?
by Jonathan Graehl 02 Sep '04

02 Sep '04

> > >After reviewing this, I think I spoke too soon. The above restrictions are >consistent with Posix. I had thought that mmap would allow mapping beyond >the file current size, but it seems not. One should use ftruncate to set >the size before mmap instead. > Since ftruncate isn't portable, it seems something like this (warning: untested) would be appropriate for boost::filesystem (perhaps taking a path object as an argument instead of a string - and shouldn't the Boost IO library do the same?) #ifdef _WIN32 #include <io.h> #else #include <unistd.h> #endif bool create_file(const std::string& path,std::size_t size) { #ifdef _WIN32 int fh=::_open(path.c_str(),_O_CREAT|_O_SHORT_LIVED); if (fh == -1) return false; if (::_chsize(fh,size) == -1) return false; return ::_close(fh) != -1; #else return ::truncate(path.c_str(),size) != -1; #endif } I don't see how, in Windows, to atomically keep the file open before it's mmapped, because chsize takes an int fh and the (equivalent of) mmap takes a HANDLE (maybe there is some Win32 call to get the HANDLE from the int fh?). The abstraction/interface that seems to be missing here is a low level (operating system level) file descriptor that can be passed to platform specific functions like ftruncate or _chsize, which weren't anticipated and wrapped by the higher-level libraries. I'd also like to see a constructor for mapped_file that creates a new file of exactly the required size (this might be a reasonable request for mapped_file_sink as well). It might also be nice to be able to set MAP_SHARED vs MAP_PRIVATE, or to be allowed to atomically deactivate an existing mapped_file (substituting a new backing file), guaranteeing the same address space (this is, I think, feasible if you do no allocation between munmap and mmap, and you can always detect failure by setting MAP_FIXED). I guess there's enough work left to be done for a "proper" Windows/POSIX mmap wrapper that the IO library shouldn't attempt to promote it yet.

2 4