- Boost - lists.boost.org

[1.31 RC2, format] BCB problem
by Pavel Vozenilek 29 Jan '04

29 Jan '04

Borland C++ 6, patch 4, format_implementation.hpp: template< class Ch, class Tr> basic_format<Ch, Tr>& basic_format<Ch, Tr>:: operator= (const basic_format& x) { if(this == &x) return *this; (basic_format(x)).swap(*this); <<<=== here it fails return *this; } [C++ Error] format_implementation.hpp(93): E2102 Cannot use template 'basic_format<Ch,Tr>' without specifying specialization parameters Adding template parameters helped here: (basic_format<Ch, Tr>(x)).swap(*this); /Pavel

3 2

Re: [boost] Re: Re: Boost.Thread : IO multiplexing
by Roland 29 Jan '04

29 Jan '04

(Michael Glassford <glassfordm(a)hotmail.com>) wrote: > Sean Kelly wrote: > > I'm not sure that much if anything would need to be done to provide > > support for IO multiplexing in Boost. ... > That, of course, would be the best solution. Have you looked at the > code in the orignal post to see if such a solution would solve his > problem? > ... > > I guess the question > > becomes, is there a need for such an IO library in Boost? The > nature > > of the project would demand a good bit of custom code for each > > platform, which isn't typical of Boost components. I have been off for a few days now, and I like to see that I have arrived at the very same conclusions than you. 1) I believe now that most likely everything can be done with boost.thread as is (question still is performance) 2) I used an approach as 1 thread / WFMO instead beeing able to directly wait on condvars _and_ IO simulateneously. (Altough this approach isn't easily portable, as it contains a lot of platform dependencies. Also this approach does not scale very well for the multiplexing case since WMFO/select scenarios are limited in the number of waitable things. This is where IO completion should enter the scene.) 3) I agree that the real question should be whether there should be a such an IO library in boost. Personally I would vote for such a thing, perhaps based on already existing "C" async_io libs, much like the pthreads lib. If anyone is interseted I could try to post my files, but I am not sure where I should post them since they are more a bit of example appliaction code than library code. Would the boost files area be adequate? Roland

4 9

Re: [boost] 1.31.0 Release candidate 2 available
by Jeremy Siek 29 Jan '04

29 Jan '04

Hi Beman, On Wed, 28 Jan 2004, Beman Dawes wrote: bdawes> Good catch! adj-matrix-graph2.gif, subgraph.gif, and bdawes> undir-adj-matrix-graph2.gif are checked in a regular rather than binary bdawes> files. bdawes> bdawes> Jeremy? Ok, I think I got those fixed. Also, I fixed the bad figure references in adjacency_list.html and adjacency_matrix.html. Cheers, Jeremy ---------------------------------------------------------------------- Jeremy Siek http://php.indiana.edu/~jsiek/ Ph.D. Student, Indiana Univ. B'ton email: jsiek(a)osl.iu.edu C++ Booster (http://www.boost.org) office phone: (812) 856-1820 ----------------------------------------------------------------------

1 0

RE: [boost] Boost.Thread request: event object
by Hurd, Matthew 29 Jan '04

29 Jan '04

> On Behalf Of Daryle Walker > Subject: Re: [boost] Boost.Thread request: event object > > >> > >> if( lock const& l = lock(guard,t)) > > > > I like this last one, though I suspect I'll end up with > > > > if (lock lk(guard,t)) > > > > in my code as it will be the first thing I'll think of. > [TRUNCATE] > > Did you see my last message in this thread? I said that the rules of C++ > _FORBID_ creation of multiple objects and/or use of the constructor call > syntax when using object creation with the condition of an "if" or > "while". > The single object syntax with "=" is the only one allowed. > > -- > Daryle Walker Quite right. My sloppiness. Thanks Daryle. Matt Hurd. IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.

1 0

The quick_allocator not-a-memory-leak
by Darren Cook 29 Jan '04

29 Jan '04

I've a class using the boost quick_allocator like this: class Chain{ //... void* operator new(std::size_t sz){ return boost::detail::quick_allocator<Chain>::alloc(sz); } void operator delete(void *p,std::size_t sz){ boost::detail::quick_allocator<Chain>::dealloc(p,sz); } //... }; I've started using valgrind ( http://valgrind.kde.org/ ) to look for memory problems in my unit tests and it is complaining that the memory is never released. Now I understand this: // "Listen to me carefully: there is no memory leak" // -- Scott Meyers, Eff C++ 2nd Ed Item 10 But is there some function I can call at the end of my program to: a) confirm I've called dealloc() for every alloc() and that the next pointer is currently at start b) release the memory. Valgrind supports suppressing the complaint but the check of deallocs matches allocs would be a useful test anyway. Darren

2 2

RE: [boost] Re: 1.31.0 Release candidate 2 available - some nitpicks
by Reece Dunn 29 Jan '04

29 Jan '04

Pavel Vozenilek wrote: >2. Spirit 1.8 docs: each line in code snippets is appended > by empty line. Seems as CSS problem (unless its feature). I'm not sure (haven't checked the Spirit source), but if they use <pre> elements, the fix is: <pre style = "margin-bottom: 0px">...</pre> or using CSS: pre{ margin-bottom: 0pc; } Regards, Reece _________________________________________________________________ Express yourself with cool emoticons - download MSN Messenger today! http://www.msn.co.uk/messenger

1 0

Re: impl(ementations) - keeping it simple
by Russell Hind 29 Jan '04

29 Jan '04

David Abrahams wrote: > > 2. We have no control over compiler flags or other settings that > may be neccessary for the library to work, nor that different > libraries are compiled with compatible options > But for this, implementing pre and post fix headers for other compilers as John Maddock has done for Borland and Microsoft compilers can get around this. Without these, if users build the libraries using bjam, they are required to look in the bjam sources to see which options were used, and use them in their project, or as I have done for 1.30.2, create a set of wrapper headers which push the bjam compiler options, include the original boost header, then pop the new options to reset them back to project default. I now only every include the wrapper headers, never the boost headers directly. Cheers Russell

2 1

RE: [boost] Re: Re: BOOST_STD_EXTENSION_NAMESPACE and dinkumware stdlib313
by Richard_Cox＠Dell.com 28 Jan '04

28 Jan '04

On Tuesday, January 27, 2004 12:05 AM, Reece Dunn said: > > I agree. The question is, should the test be BOOST_MSVC >= 1310 or > BOOST_MSVC == 1310, likewise for the _CPPLIB_VER test. I say > this because a > future version of VC may move hash_xxx back into the std > namespace for > future standard library conformance (does TC1 have hash_map, etc.?). Looking at the "Whidbey" technical preview (the next version of Visual Studio... including the next version of VC++), this has not changed (yet). Richard -- All opinions are personal and do not represent the views of my employer.

2 1

Re: [boost] [review] Review Request: "Wave: a Standards conformant C++ preprocessor library"
by Daryle Walker 28 Jan '04

28 Jan '04

On 1/26/04 1:28 AM, "Hartmut Kaiser" <hartmutkaiser(a)t-online.de> wrote: [SNIP] > The main goals for the Wave project are: > > . full conformance with the C++ standard (ISO/IEC 14882:1998) and with the > C99 standard (INCITS/ISO/IEC 9899:1999) [TRUNCATE] You can set these on strict-mode (i.e. no extensions), right? Obviously, the strict C++98 and strict C99 modes have to be distinct. -- Daryle Walker Mac, Internet, and Video Game Junkie darylew AT hotmail DOT com

2 1

A new version of "more_io"
by Daryle Walker 28 Jan '04

28 Jan '04

Besides some tweaks, did the following big changes/additions: * Replaced "multi_deliminator" with its separate input and output parts, "multi_basic_newer" and "multi_basic_skipper". (So "multi_newer" now calls "multi_basic_newer" and "multi_skipper" now calls "multi_basic_skipper".) * Added a 'form'-based manipulator "basic_ios_form". You create a manipulator object, change its stream settings, and those changed settings are applied on a stream for an one-time use on a streamable object. It uses complex C++, so not all systems may accept it. * Added a new stream for constant values "value_stream". A dual to null-streams, it simulates "/dev/zero" by always returning '\0' for input operations, and does nothing but EOF for output operations. (The character returned can be configured at construction time.) It is at <http://groups.yahoo.com/group/boost/files/more_io_3b.zip>. -- Daryle Walker Mac, Internet, and Video Game Junkie darylew AT hotmail DOT com

1 0