- Boost - lists.preview.boost.org

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

RE: [boost] Checking if RTTI is available.
by Stefan Seefeld 02 Sep '04

02 Sep '04

> From: brangdon(a)cix.compulink.co.uk > [mailto:brangdon@cix.compulink.co.uk] > Sent: September 2, 2004 17:05 > 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. Yeah, I noticed, MSVC is full of 'hand-rolled' 'solutions'. One more reason to avoid it. Sorry, couldn't resist. Regards, Stefan

1 0

Re: [boost] Re: [1.32 Release] MPL has been merged into the main trunk
by JOAQUIN LOPEZ MU?Z 02 Sep '04

02 Sep '04

----- Mensaje original ----- De: Eric Niebler <eric(a)boost-consulting.com> Fecha: Jueves, Septiembre 2, 2004 8:11 pm Asunto: [boost] Re: [1.32 Release] MPL has been merged into the main trunk > > > Jonathan Turkanis wrote: > > > "Eric Niebler" <eric(a)boost-consulting.com> wrote in message > > news:41374F88.9010100@boost-consulting.com... > > > >>Aleksey Gurtovoy wrote: > >> > >>>Everything has been tested locally, so the disturbance should > be minimal. > >>>I'll post a detailed changelog later today. Metacomm > regressions have > >>>been restored to run against the main trunk. > >>> > >> > >>Yikes! Where did apply_if go? The docs still talk about > apply_if. Is its > >>absence an oversight or by-design? > > > > > > Can I assume it's now 'eval_if'? > > > > If so, I like it better, since there's no temptation to confuse > apply_if and > > apply. > > > > Jonathan > > > > Oh. How do I make my code work with old versions of MPL and new? > There > is no mpl/version.hpp or a macro I can test for conditional > compilation > AFAICT. I'll have to avoid both mpl::apply_if and mpl::eval_if and > roll > my own. :-( I think you can use BOOST_VERSION in boost/version.hpp for this purpose. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

1 0

RE: [boost] Checking if RTTI is available.
by Stefan Seefeld 02 Sep '04

02 Sep '04

> From: Jurko Gospodnetiæ [mailto:jurko@zse.hr] > Sent: September 2, 2004 04:14 > Hi all. > > I was wondering if boost has any portable way for detecting whether > RTTI is enabled? (For instance a macro expanding to _CPPRTTI in > Visual Studio). If there is, I have not been able to find it. Out of curiosity: why would anybody not use RTTI ? Why shouldn't compilers without RTTI just considered broken ? Being able to switch RTTI support off just introduces binary incompatibilities and makes some code illegal (you can't cast between classes with a virtual inheritance relationship without dynamic_cast, etc.) Regards, Stefan

2 1

RE: [boost] Re: Porting to SCO Unix
by Glen Knowles 02 Sep '04

02 Sep '04

> From: David Abrahams > "Peter Dimov" <pdimov(a)mmltd.net> writes: > > > John Maddock wrote: > >>> ** 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? > > > > There is no pthread_yield in POSIX. Yields are evil anyway. ;-) > > Why evil? There's a lot of backing for this, and the best single comment is probably: ....Similarly, sched_yield() can be used to resolve some problems on a uniprocessor, though such problems can usually be solved more cleanly in other ways. Using sched_yield() will never solve a problem (unless the problem statement is "the performance is too good") on a multiprocessor, and you should never use it there. - Butenhof Glen

1 0