- Boost - lists.boost.org

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

28 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

Re: [boost] Re: move_ptr
by Peter Dimov 28 Jan '04

28 Jan '04

Howard Hinnant wrote: > On Jan 26, 2004, at 4:59 PM, Daniel Wallin wrote: > >> Howard Hinnant wrote: >>> <snip> >>> And I submit that: >>> S<T[], my_deleter> >>> is more elegant syntax than: >>> S_array<T, my_deleter> >> >> FWIW, I'm not sure it's a good idea to design the interface around >> partial specialization. std::vector<> replaces almost every possible >> need for array allocation, so does this use case really need to be >> less verbose? Is it worth dropping support for older compilers? > > Need to be? No. But I still like it. <shrug> I was convinced > because that's how a newbie expected it to work. I'm starting to not like it. :-) The problem is: template<class X> void f(S_ptr<X> px); where f doesn't support arrays. A reasonably common occurence. S_array<> doesn't match, but S_ptr<T[]> does. The author of f would need to learn about enable_if to prevent array pointers from being passed to f. This is not good, although the exact degree of not-goodness is somewhat debatable.

6 8

Re: [boost] move_ptr
by Daryle Walker 28 Jan '04

28 Jan '04

On 1/26/04 6:42 PM, "Howard Hinnant" <hinnant(a)twcny.rr.com> wrote: [SNIP] > for me. Does that address your concern, or have I missed your point? Yes. No. (You did address the concern and not missed the point.) -- Daryle Walker Mac, Internet, and Video Game Junkie darylew AT hotmail DOT com

1 0

Re: [boost] Boost.Thread request: event object
by Daryle Walker 28 Jan '04

28 Jan '04

On 1/26/04 4:50 PM, "Hurd, Matthew" <hurdm(a)sig.com> wrote: >> On Behalf Of Sean Kelly [SNIP] >> or better yet: >> >> 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 Mac, Internet, and Video Game Junkie darylew AT hotmail DOT com

1 0

Re: [boost] [administrative] Formal Review Process
by Daryle Walker 28 Jan '04

28 Jan '04

On 1/26/04 10:33 AM, "David Abrahams" <dave(a)boost-consulting.com> wrote: [SNIP] > I think we should: > > a. Make being a review manager or a moderator or a wizard one of the > conditions of having a library in boost [TRUNCATE] This might create a barrier (anyone that wants a writer hat to have an admin hat forced on them) that discourages contributions. Let's not blur the line between writers and admins. -- Daryle Walker Mac, Internet, and Video Game Junkie darylew AT hotmail DOT com

1 0

Re: [boost] impl(ementations) - keeping it simple
by Daryle Walker 28 Jan '04

28 Jan '04

On 1/25/04 11:23 PM, "John Torjo" <john.lists(a)torjo.com> wrote: > Again, I'm pretty frustrated that some libraries have source files that > need to be compiled separately (using bjam). > > I was thinking that we could have a directory '/boost/impl', and each > library that has sourse files could have an .hpp file that includes all > of its source files (that would normally need to be compiled separately). > > This way, any user, even not having bjam, can include the implementation > of a library, as simple as: > // this is included in ONLY one source file > #include <boost/impl/filesystem.hpp> We have some implementation files as *.cpp for a reason. Some implementations were _never_ meant to be forced through the #include system (structure-wise, not just size-wise). If the files are large, the compilation time can go up dramatically. > As a regular user, I'd rather have the above, than having to use bjam to > build a library. You wouldn't know it from how most talk about it here, but you don't need to use Bjam (I don't). You can include the appropriate Boost files (or search directories) directly in your IDE project file. For mandatory source, finding the file initially, or knowing that they're needed, is the problem. > If people agree, I volunteer to create the /boost/impl directory for all > the libraries that now need to be compiled separately, somewhere this week. I wouldn't agree. But I do think we need a top-level "src", "boost_src", "source", or "boost_source" directly that all the mandatory source files will be moved to for easy access. -- Daryle Walker Mac, Internet, and Video Game Junkie darylew AT hotmail DOT com

1 0

Re: [boost] Re: impl(ementations) - keeping it simple
by Robert Ramey 28 Jan '04

28 Jan '04

Reece Dunn wrote: >John Torjo wrote: >>Maybe to simplify the process, in boost-root (where boost-build.jam file >>exists), we could have a makefile which automatically builds bjam from the >>source files and the invokes it with a given configuation. >> >>like: >>make msvc >>(instead of bjam "-sTOOLS=msvc") >> >>Unfortunately, I don't have any makefile knowledge. ahhh - we've come full circle. >I am knowledgeable in makefiles, but this leads to a problem: you need to >configure the makefile to handle all the various compiler and platform >combinations - something bjam already handles, so why duplicate this effort? >Is there a bjam file for bjam?! That way it could be bootstrapped. But then >why not just download a pre-built version of bjam? Bascally I think the whole purpose of bjam is to address the concerns of the original poster. Unfortunately, this is not obvious from the information on bjam that comes with the system. I realise that the information is available - its just that is spread around in several places. Bjam is a large subject and requires almost a book to explain it. BUT it (or something like it is necessary for boost - as was obvious to the original poster. The central purpose of the bjam system is to specify how to build programs in a generic way independent of any particular platform while at the same time specify how each platform handles particular aspects of the application developement. This is a very ambitious concept and has resulted (not surprisingly) in a system that is pretty elaborate. A very ambitiuos effort. In one important way, its not ambitious enough. Unlike the rest of boost, it seems directed a bit narrowly to building and testing boost libraries. I get this impression from the fact that much effort is being invested in the code but relatively little in producing a complete, coherent and well organised explanation of how to make best usage of it. Maybe we can sucker someone in writing an O'Reilly book on this which would include the bjam system? Of course this would need a more polished system. I'm sorry go on about this, the thing just drives me crazy. John Torjo - bjam is exactly what you're looking for - its just not clear from the explanation. Robert Ramey

2 1