- Boost - lists.boost.org

Re: [boost] Re: What I Hate About How We Abstract System Dependence
by brangdon＠cix.compulink.co.uk 08 Mar '05

08 Mar '05

In-Reply-To: <loom.20050308T013051-569(a)post.gmane.org> belvis(a)pacbell.net (Bob Bell) wrote (abridged): > Another possibility is to provide another level of indirection. For > example, boost::thread can have an accessor which returns a > boost::platform_thread, which has the OS thread ID, plus member > functions which mimic OS operations not reflected in the portable > (boost::thread) API. The advantage of this approach is that > boost::platform_thread member functions may be able to preserve > invariants that otherwise might be broken if the user was allowed > to manipulate the underlying OS thread ID itself, and if the coverage > of the boost::platform_thread member functions is large enough, it > might not even be necessary to expose the OS thread ID at all. I don't think the coverage could never be large enough. We should always allow for 3rd parties which are not boost-aware, and which need to be passed low-level OS handles. -- Dave Harris, Nottingham, UK

1 0

Re: [boost] Re: What I Hate About How We Abstract System Dependence
by brangdon＠cix.compulink.co.uk 08 Mar '05

08 Mar '05

In-Reply-To: <422D79A6.4050502(a)aaronwl.com> aaronrabiddog51(a)aaronwl.com (Aaron W. LaFramboise) wrote (abridged): > > I have always thought that concrete implementations of portable > > libraries should supply users a way to get at the OS-specific data so > > they can use platform-specific facilities on them if neccessary. > [...] > It seems to me that, by doing this, we are throwing away so many > correctness guarantees. To me, this seems sort of like taking > shared_ptr, and making it implicitly convertable to a pointer. Surely it's more like taking shared_ptr and giving it an explicit get() function? You can break invariants by doing stuff like: delete p.get(); but people are unlikely to do that by accident. Access to the underlying raw pointer is essential for inter-operating with software which isn't smart-pointer aware. So it is with OS handles. -- Dave Harris, Nottingham, UK

1 0

[iostreams] names for non-blocking character properties
by Jonathan Turkanis 08 Mar '05

08 Mar '05

Hi All, Everybody likes naming questions, right? The thread "[iostreams] Major interface changes planned" discussed having the get() function return a type (basic_character, character or wcharacter) which can hold either a character, an EOF indication or an EAGAIN indication. My question is what I should call the functions which query the state of a basic_character. My first idea was to use bool good(character c) - returns true if c represents a character rather than EOF or EAGAIN bool eof(chacrater c) - returns true if c represent EOF bool fail(character c) - returns true if c represents EAGAIN. These functions have the same names as member functions of basic_ios. However, since fail() above doesn't mean exactly the same thing as basic_ios::fail(), I now think this is a bad idea. Here are the names I've thought of: good: good, is_good eof: eof, is_eof fail: fail, eagain, is_eagain, would_block, should_retry I also need names for the two functions called by implementations of get() to return characters representing EOF and EAGAIN. E.g., template<typename Source> character get(Source& src) { ... if ( ... ) return eof(); else return eagain(); } (They will actually return instances of types convertible to basic_character.) What do you think? Jonathan

3 7

[shmem] New Shmem snapshot ready in Boost Files section
by Ion Gaztañaga 08 Mar '05

08 Mar '05

Hello to all, I've just uploaded a new version of Shmem library (removed Boost from name because of the new naming policy) to Boost Files (http://groups.yahoo.com/group/boost/files/) which includes built html help files. Snapshot file: Shmem.2005-03-06.tar.bz2. Changes and features from last version: -> Name changes. -> Improved compatibility with unordered_map/set family. Soon we will be able to place unordered containers in shared memory. Thanks, Daniel. -> Templatized index types for named shared memory object allocator -> New private segregated storage STL allocator for shared memory. -> Bug fixes -> Improved documentation and code comments. For the next version I plan to improve code comments, documentation and tests. Please, if there is any comment or suggestion, let me know. Regards, /Ion

2 1

Is (void) still means ()? Is that syntax deprecated?
by Pavel Chikulaev 08 Mar '05

08 Mar '05

ISO/IEC 14882:1998(E) 8.3.5 (2) says: The parameter list (void) is equivalent to the empty parameter list. Is there any paper that shows that syntax (void) deprecated? I am asking about it because I'm trying to remove (void) syntax in Visual Studio's 2005 IDE Class View and Add Member Wizard. Is there any ideas how to remove it? P.S. As for me, It is really annoying.

1 0

[Boost.Regex] Not compiling without exceptions.
by larsbj＠gullik.net 08 Mar '05

08 Mar '05

In cpp_regex_traits.cpp line 76 there is a re-throw. This does not work when compiling without exceptions. I see that gcc have a #ifndef __EXCEPTIONS # define __throw_exception_again #else # define __throw_exception_again throw #endif for this case. Something similar should work for boost as well. To allow compiling I did this: --- ../../boost/boost/throw_exception.hpp 2004-08-05 17:24:43.000000000 +0200 +++ boost/throw_exception.hpp 2005-03-08 03:04:27.066704153 +0100 @@ -32,6 +32,8 @@ void throw_exception(std::exception const & e); // user defined +#define BOOST_THROW_EXCEPTION_AGAIN + #else template<class E> inline void throw_exception(E const & e) @@ -39,6 +41,8 @@ throw e; } +#define BOOST_THROW_EXCEPTION_AGAIN throw + #endif } // namespace boost -- Lgb

3 3

Incredible Logos
by John Maddock 08 Mar '05

08 Mar '05

As someone who hasn't paid that much attention to the logos during their development, I have to say going to vote was a revelation - there were so many exceptionally high quality logos to choose from - all I can say is there's some really talented people on this list and whatever the result I think we're going to end up with an excellent new logo. Well done everyone! John.

1 0

Re: What I Hate About How We Abstract System Dependence
by Chris Just 08 Mar '05

08 Mar '05

Rob Stewart wrote: > Another possibility is to provide another level of indirection. For > example, boost::thread can have an accessor which returns a > boost::platform_thread, which has the OS thread ID, plus member functions > which mimic OS operations not reflected in the portable (boost::thread) API. > The advantage of this approach is that boost::platform_thread member > functions may be able to preserve invariants that otherwise might be broken > if the user was allowed to manipulate the underlying OS thread ID itself, and > if the coverage of the boost::platform_thread member functions is large > enough, it might not even be necessary to expose the OS thread ID at all. This is exactly what I would like to see. Boost::thread and other classes should be platform neutral, but provide a method to get at the private handles so that people can extend the class for specific platforms on their own. Another thing I would REALLY like to see is better documentation. I'd love to use more Boost classes, but I don't have time to reverse engineer them to figure out how they work. Chris. __________________________________ Celebrate Yahoo!'s 10th Birthday! Yahoo! Netrospective: 100 Moments of the Web http://birthday.yahoo.com/netrospective/

2 1

My Thoughts on the Best Logos
by Rob Stewart 08 Mar '05

08 Mar '05

I decided to jump in with my ideas for the best logos and my comments on them. 1. 67 Simeon Nasilowski I liked this one because the checkerboard is abstract for several things: building blocks (Boost provides software building blocks), fitting the missing piece (Boost often provides just what you're missing), blended parts of C++ syntax (you can infer :: and }{, for example). I also liked that the checkerboard itself could be used as an icon, including in the address/location bar of the browser. What I don't like is the color scheme. I think a bluer scheme would be better. "C++ Libraries" could also be replaced with other tag lines like: - Setting the Standard - C++: The Next Generation (might be a copyright problem) - Your C++ 2. 83 Emil Kirichev I liked the color wheel, since it could be extracted as an icon and it suggests a never ending stream of libraries from Boost. I don't like the multiple colors; a simpler scheme would be better, I think. "C++ Library" should be plural, at the least, and could be replaced with numerous tag lines. 3. 49 Cristian Peraferrer Mayn? This logo looks really sharp and might have been my first choice, except for a couple of issues. I liked the coloring and the lettering. Since there is no accompanying graphic, it would be difficult to form an iconic version of this logo. The shading in the letters and the border requires a high number of colors; will it look as attactive with less color depth? 4. 21 Jonathan Turkanis I like the grayscale variant best, but the black works OK for lower color depths. There's too much gap between the "C" and "boost." It doesn't render well at low resolution, including as an icon. 5. 38 Simeon Nasilowski I like the "b" variant best. (I'm partial to the blue color palette, it seems.) The blocks can be used separately as an icon and there's always room to add a tag line (push "boost" up and put the tag line below as with #83). The foreground block could be adorned with a "C" yielding "C++," though that leaves the other, exposed surfaces with nothing. I don't know if that will look right or not. Adding a tag line would improve this one quite a bit. -- Rob Stewart stewart(a)sig.com Software Engineer http://www.sig.com Susquehanna International Group, LLP using std::disclaimer;

1 0

Re: [boost] thread safety in boost date time
by Iain Hanson 08 Mar '05

08 Mar '05

On Tue, 2005-03-08 at 06:20 -0700, Jeff Garland wrote: > On Tue, 8 Mar 2005 14:48:00 +0200, Peter Dimov wrote > > Well I don't think just calling the _r function is enough to ensure the thread > safety of this code. I believe I would have to insert a lock in the date-time > code to make this assurance. > Yes it is. the _r versions require a user supplied buffer. So each caller supplying there own buffer is what makes them re-entrant. /ikh

1 0