January 2004 - Boost - lists.preview.boost.org

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

28 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 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

Re: [administrative] Formal Review Process
by Dave Gomboc 28 Jan '04

28 Jan '04

] David Abrahams wrote: ] ] ] Dave Gomboc <dave(a)cs.ualberta.ca> writes: ] ] ] ] It's a good idea, but I have to ask: is this a bicycle shed ] ] discussion? Does tweaking the seconding process really ] solve any of ] ] Thomas' problems? ] ] At least it's my shed. I think it can reduce the workload for ] the review wizard. ] ] Thomas Quoting issue here: that was Dave A.'s text, not mine. Dave

1 0

Re: [administrative] Formal Review Process
by David Abrahams 28 Jan '04

28 Jan '04

Dave Gomboc <dave(a)cs.ualberta.ca> writes: > ] I suggest that such a requirement be added to the formal > ] review process, with a specific (low, ie, 3) number of > ] "formal seconds" required for a formal review request in > ] order for it to reach the schedule. It should be explicitly > ] noted that "seconding" a review request does not imply a vote > ] to accept, nor a commitment on the part of the person > ] seconding to participate in the review. > > I also like the idea, but with a twist: it should be explicitly > noted that seconding a review request _does_ imply a commitment to > review the library should a review be scheduled for it. It's a good idea, but I have to ask: is this a bicycle shed discussion? Does tweaking the seconding process really solve any of Thomas' problems? -- Dave Abrahams Boost Consulting www.boost-consulting.com

2 1

Re: [boost] Re: [administrative] Formal Review Process
by Jeff Garland 28 Jan '04

28 Jan '04

On Mon, 26 Jan 2004 22:10:23 -0800, Thomas Witt wrote > > Jeff Garland wrote: > > I don't like the idea of a mailing list to solve this problem. > > Why? Really I just want to know. Because the primary issue is a lack of time and I don't see how complicating things with another mailing list solves that problem. Also, if review comments either intentionally or accidently wind up on a review list then there is a third list I now have to search when looking into the archive -- I've had to look on the dev and user groups a few times because I can't remember where a particular discussion occurred. > There is more to the filtering than meets the eye. The usual process > up to know was that somebody posted a request. That request usually > lead to some discussion. As a result in quite a few cases the Which is one reason why I believe this needs to stay on the dev list... > library author decided to tackle the issues before the request. I've > been following these discussions in order to see whether the request > is likely to be withdrawn or not. The net effect of all this a lot > of postings use review in the subject line and are neither requests > nor formal review related. I am not criticising poeple for doing > this I just try to present the current situation. Yep. > Another issue that is related to this problem is that we are already > close to having more review requests than we can handle. (I am not > talking about the wizard here, just the list and the reviewers). I don't agree. There were more reviews in 2002 (15) than 2003 (~10) by my count. My guess is that about 1 full review per month is about what can be reasonably done. I, for example, have not been a review manager for a year so I don't feel over-worked. >In the past we already had reviews where there was very little feedback. That is an issue for the review manager to handle. I would leave it up to the judgement of the review manager to decide if there has been enough participation. If the participation is too low then the library should probably be rejected for lack of interest. But again that is the judgement of the review manager to make. As for the number of review requests, > In my opinion we need some kind of staging in order to streamline > the influx of libraries in the formal review process and to improve > the quality of reviewed libraries. Thus making failure for trivial > reasons more unlikely. I don't recall any specific examples of this. We already have a multi-stage review process. Sure there are examples of people just joining and throwing out a library for formal review before it is ready, but someone then provides guidance on the process. > I think the idea of a separate mailing list fits into this staging > strategy. I.e. the review list would be reserved for review and > review only. One idea might be to require a pre review on the > developers list or required 2-5 people to second the review request. Sure, but it complicates life for users trying to decide which lists to subscribe to, post to, and search. There won't be anything to stop someone from posting a half-baked library on the new list or accidentally posting a review request on the dev list... > > I think some simple additions to the submission process would solve the > > 'heads-up' to the review manager problem: > > A copy of the Review Request posting should be sent directly to > > the review wizard (email here). If the review wizard does not > > respond with an acknowledgement within 48 hours another request > > should be made. > > As explained not every request leads to a review. Sure, but at least the submitter would be aware that you are paying attention. So the acknowledgement is not a date for the review, but just a little "hello, I see your request, have you read the submission guidelines" sort of mail. > > Also, note that the entire discussion of the Review Wizard is on > > the Formal schedule the review. > > I would really appreciate it if you could make that change. Sure. > > Finally, it seems to me the real solution is to either split the duties or > > find another review wizard volunteer. > > As of now I don't have a good idea how things can be split up. Perhaps you can offload the monitoring or organization of a particular upcoming review -- I'm sure we can figure something out. > > I'm willing to spend a couple hours a > > month on this if it would help, so Thomas send me an email > > off-list if you have something you want to offload on me. > > Thanks Jeff! I'll shoot you an email as soon as I see clearer. Let me know. Jeff

3 3

Re: [boost] Re: [administrative] Formal Review Process
by Douglas Gregor 28 Jan '04

28 Jan '04

On Tuesday 27 January 2004 01:20 am, Thomas Wenisch wrote: > This idea of seconding a review request is an extremely good idea. It > adds formality to what is captured in the current process as "post to list > and see if there is interest". The fact that someone seconds a review > request demonstrates that there is interest in the library, and that there > are people who are following the review list that might be inclined to > review. > > I suggest that such a requirement be added to the formal review process, > with a specific (low, ie, 3) number of "formal seconds" required for a > formal review request in order for it to reach the schedule. It should be > explicitly noted that "seconding" a review request does not imply a vote > to accept, nor a commitment on the part of the person seconding to > participate in the review. It just is an indication that a library is > interesting and worthy of review (and worthy of consuming time on the > schedule that could be used reviewing other libraries). I too like the idea of seconding a formal review request, but I'd rather that "seconding" imply that someone has looked over the library and found that it is in reasonably good shape for a formal review. Otherwise, we'll still have the problem Thomas W. is describing where a formal review is requested, several people "second" because they are interested, but the formal review won't happen because the library isn't ready. Doug

2 1

bccx and lambda (possible config problem)
by Russell Hind 28 Jan '04

28 Jan '04

Using 1.31-RC1, I have successfully made use of some of boost with Borland's bccx compiler. (I think John Maddock has done the work for this, so thanks). But I can't use the bind from Lambda with the new compiler with functions that return void. e.g. this won't compile (error is "lambda_functors.hpp": a void function may not return a value at line 159) #include <boost/function.hpp> #include <boost/lambda/lambda.hpp> #include <boost/lambda/bind.hpp> using namespace boost::lambda; void test(int a, int b) { } int main(int argc, char * argv[]) { boost::function<void (int a, int b)> f(bind(test, 10, _1)); return 0; } Has anyone any ideas if the config for bccx needs updating, or is this just a bug in the compiler and so we'll have to wait for an update to it? Thanks Russell

1 0

Re: Detection of wchar_t for Intel compiler
by Giovanni Bajo 28 Jan '04

28 Jan '04

Guillaume Melquiond wrote: > There was a recent change to the config/compiler/intel.hpp file in > order to change (one more time) the way the detection of wchar_t works. I did it, and discussed it on this very list. > So I've committed a trivial fix to CVS head. However it was a bit > annoying to note that a patch had been committed to such an important > place carefreely (otherwise the bug would have been found). This is my > first concern: the configuration of a compiler had been changed > without even being tested. You're implying way too much. There was a typo on my part, sure, but it wasn't detected under Windows. I *did* test it, and we did discuss the patch on the list. I never commit untested patches. > Second concern: since the patch was not tested on this > compiler/platform configuration, is it sure it behaves sanely? Please, review our discussion on the topic. > Sincethere was a lot of > changes in this area, shouldn't a specific test file be added in order > to finally ensure the correct detection of wchar_t? I can also > directly exercise some testcases if provided; I can test with ICC 7 > and 8 for Linux. We need to do a detection through the preprocessor. > Finally, my third concern: shouldn't such changes be committed to the > release branch since they directly involve the configuration of an > existing compiler? Again, please review the discussion. I told that I would commit it to the release branch after a few days, to not destabilize the branch. In fact, I was awaiting fallouts on different platforms, just like the one you fixed. If I had committed it to the release branch immediatly, I would have broken it as well. > Sorry for this long mail, but since release time draws near, I wanted > to point out this problem. Thank you for the fix. -- Giovanni Bajo

2 1

Re: [constant] New version + YANL- tests with MS 7.1
by David Abrahams 28 Jan '04

28 Jan '04

"Paul A. Bristow" <boost(a)hetp.u-net.com> writes: > However, the major snag is MS lack of __typeof__. Until this is solved, it is a > non-starter :-(( The problem isn't with the MS compiler, but with the library. Libraries that rely on nonstandard language extensions are non-starters at Boost. -- Dave Abrahams Boost Consulting www.boost-consulting.com

2 1

Re: class static constants, mpl, and linker problems
by David Abrahams 28 Jan '04

28 Jan '04

Matthias Troyer <troyer(a)itp.phys.ethz.ch> writes: > Dear Daniel, > > If you use BOOST_STATIC_CONSTANT you need to additionally provide a > definition on conforming compilers. The correct usage is like in: > > // declaration > class A { > BOOST_STATIC_CONSTANT(int , x=1); > }; > > .... > > //definition > #ifndef BOOST_NO_INCLASS_MEMBER_INITIALIZATION > int A::x; > #endif > > > I hope that clarifies this issue, Another approach is to use mpl::int_<n> or integral_c<T,n> which supply the definitions themselves. -- Dave Abrahams Boost Consulting www.boost-consulting.com

2 3

Re: class static constants, mpl, and linker problems
by Daniel Krügler 28 Jan '04

28 Jan '04

Hello Matthias, Matthias Troyer schrieb: > Dear Daniel, > > If you use BOOST_STATIC_CONSTANT you need to additionally provide a > definition on conforming compilers. The correct usage is like in: > > // declaration > class A { > BOOST_STATIC_CONSTANT(int , x=1); > }; > > .... > > //definition > #ifndef BOOST_NO_INCLASS_MEMBER_INITIALIZATION > int A::x; > #endif > > > I hope that clarifies this issue, No, it doesn't, please read the original thread carefully. I am aware of the fact, that an integral or enumeration type static member needs a corresponding definition and I hope my contribution has made that clear to everyone. Your answer implies, that users of the boost library are responsible for providing these definitions for boost constants. If so, I think that would be bad news. Consider those many hidden constants in whatever boost::details namespace or other implementation-dependent data items. How should the boost user correctly provide the necessary definitions? To my opinion boost should at least provide in the libs section source files with possibly necessary definitions of all externally accessible constants, which the user can translate if necessary. I also want to add, that although my example seems artifical, it should show a basic problem. Consider a simple "algorithm" like std::max which takes constant references as arguments. You cannot demand, that boost users must watch out for those or similar expressions in their code and take proper resolutions by hand?? Second, your response did not take into account the problems with the effects of the /Ze and /Za flags of the current VC7.1 compiler which I also think is a very important issue. Daniel

2 2

RE: [boost] Re: Re: [administrative] Formal Review Process
by Powell, Gary 28 Jan '04

28 Jan '04

] I suggest that such a requirement be added to the formal ] review process, with a specific (low, ie, 3) number of ] "formal seconds" required for a formal review request in ] order for it to reach the schedule. It should be explicitly ] noted that "seconding" a review request does not imply a vote ] to accept, nor a commitment on the part of the person ] seconding to participate in the review. I also like the idea, but with a twist: it should be explicitly noted that seconding a review request _does_ imply a commitment to review the library should a review be scheduled for it. Dave --------------------------------------------------- I agree with Dave and Doug, seconding implies both a commitment to review the library and a preliminary review such that you agree that the library is ready for review. The point being that you are expressing an interest in the library and that some sort of vetting has been done to insure that the rest of us won't all say, "Great but needs a heap of work." One can always post a "I'm thinking about getting my code ready is there enough interest to bother" email and gauge whether anyone cares. Those posting do not imply that you'll second it or approve it but that you think there's at least potential. Otherwise people won't waste their time reviewing, or documenting, or developing uninteresting stuff. BTW, Go ahead and add me to the list of review managers. It seems like a long time since I've been asked, so I'm guessing I've dropped off the list. -Gary- PS As for having my name on a web site, I seem to be inundated with spam merely by being on this list, so I doubt it will get much worse.

2 1

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

28 Jan '04

> I'm opposed to this idea because: > > 0. Testing this configuration is a burden on developers > > 1. It gives an implied guarantee that it will work for the user > (see 2) > > 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 > > 3. If we don't need that control for some libraries today, but we > need it tomorrow, we'll have to take the feature of being able > to do the big #include back from the user > Ok, I give up ;) I did look at the existing jamfiles, etc. I still think that from all the users using boost, there is quite a little percentage that are willing to use bjam to compile the libraries needing separate compilation (of course, that's just my fild guess). 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. Best, John

1 0

Re: [boost] Re: [administrative] Formal Review Process
by John Torjo 28 Jan '04

28 Jan '04

> I don't want to waste review manager capacity. It takes a lot of effort > being a review manager. > >> >> Having a [review] tag in the subject for the formal reviews seems >> pretty ok. I tend to agree with Jonathan - I think the discussion >> should still happen in the main list, > > > Why? If not, people would have to subscribe to yet one more list. I'm afraid, compared to how many subscribers the boost list has today, the new review list would have much less. Therefore, we might end up with much less reviewing than before. Or maybe, everyone already subscribed to boost could be automatically subscribed to the boost-review list. This would make much more sense. Best, John

1 0

Re: [boost] Indexed set library
by JOAQUIN LOPEZ MU?Z 27 Jan '04

27 Jan '04

Hi Arkadiy, Thanks for your praises! ----- Mensaje original ----- De: Arkadiy Vertleyb <vertleyb(a)hotmail.com> Fecha: Martes, Enero 27, 2004 9:04 pm Asunto: [boost] Indexed set library [snip] > > I am wondering what the current state of the library is. I > thought the > formal review has been requested -- is this correct? Anything new > sincethen? > Formal review was requested in December. The pending list is rather long, so I don't know when/if I'll be admitted for review. In the meantime the library is being augmented in two directions: * There was a query some months ago about the possibility of having "sequence sets" implemented with indexed_set (see http://lists.boost.org/MailArchives/boost/msg58666.php for details). I wrote a fast sketch of a new type of index called "sequenced" with which sequence sets can easily be constructed (see http://tinyurl.com/3dto3) Currently I'm growing this sketch into a full-fledged implementation for future inclusion into the library. The main problem is a lot of doc rewriting is necessary, since the original documentation was too focused on regular set-like indices. * A volunteer has begun studying the possibility of implementing hashed indices. I cannot say how long this will take. Regards, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

1 0

Re: [boost] Re: Cutting over to MPL - some progress.
by Phil Richards 27 Jan '04

27 Jan '04

On Fri, 23 Jan 2004 16:54:14 -0500, David Abrahams wrote: [I wrote:] >> I'll have a look at zip_view, but on first looks it doesn't exactly look >> simple :-) > Replacing lambda expressions with metafunction classes would be my first > strategy. Well, I replaced zip_view with transform and got the following (non-scientific) results: % time g++ -Wall -W -I. -I/home/pgr/src/boost -DWITH_ZIP_VIEW pq.cpp -c real 0m59.201s user 0m56.444s sys 0m0.475s [without zip_view, using transform] % time g++ -Wall -W -I. -I/home/pgr/src/boost pq.cpp -c real 0m14.074s user 0m13.418s sys 0m0.372s Well, that's much better. (Though there is probably still some room for improvement yet - it's still 3 or 4 fold slower than without the MPL.) How difficult would it be to produce a full family of mpl transform functions? Currently, there are the 1 and 2 sequence forms, but I could use a 3 sequence version :-) (The multi-sequence version is what I would have called "zip_with" from my old F.P. days...) Given the progress I've made, I will put together yet another release of my library. This version allows user choice of the base units in their dimensional analysis (so if you want bananas/second you can have it). It still uses fixed-size vectors of powers, though - so if you have a banana-system and you want to multiply a banana-system-based quantity by a "physical system"-based quantity, it won't let you. Personally, that's the way I like it... phil -- change name before "@" to "phil" for email

1 0

Re: boost::optional issue with borland-5.6.4
by Fernando Cacciola 27 Jan '04

27 Jan '04

Samuel Krempp <krempp(a)crans.ens-cachan.fr> wrote in message news:1074872783.4142.160.camel@marvin.localdomain... > boost::format compilation fails with what seems to be a boost::optional > issue. > http://boost.sourceforge.net/regression-logs/cs-win32_metacomm/links.html#f… .6.4 > says : Fixed in Main CVS. I'll merge it to 1.31.0RC2 as soon as I can test it with VC7.1 and GCC3.3.1 Fernando Cacciola SciSoft

1 1

Indexed set library
by Arkadiy Vertleyb 27 Jan '04

27 Jan '04

Hi all, I was just playing with the indexed set library (to provide alternative, set-based, implementation for our RTL tables), and my first impression is that it is very useful. I didn't have any problems in achieving my goal, either with the documentation (which is very clear), or with the library itself. Although I was using the simplest form of indexed_set (I only needed the "compatible predicate" feature missing from std::set), I still think that the idea of having multiple synchronized indexes is very useful (based on my past experience, when I could greatly benefit from such library), and that this library could eventialy become a great addition to Boost. I am wondering what the current state of the library is. I thought the formal review has been requested -- is this correct? Anything new since then? Arkadiy

1 0

Re: [Function] Implemented operator== and operator!=
by David Abrahams 27 Jan '04

27 Jan '04

Douglas Gregor <gregod(a)cs.rpi.edu> writes: > where deref does something like: > > template<typename Pointer, typename Pointee = typename Pointer::element_type> > struct do_deref > { I suggest template< typename Pointer , typename Pointee = typename pointee<Pointer>::type > struct do_deref { }; Or even leaving out the Pointee parameter altogether. See boost/pointee.hpp. -- Dave Abrahams Boost Consulting www.boost-consulting.com

1 0

Re: 1.31.0 Progress (or lack thereof)
by David Abrahams 27 Jan '04

27 Jan '04

"John Maddock" <john(a)johnmaddock.co.uk> writes: >> Heh, not my department. I'm actually shocked that we're wedging >> is_abstract into the release branch. > > Normally a really bad idea, but in this case it's straight addition: it has > no impact on existing code, and I know that some folks who develop with the > release versions are asking for it. Sure, but it adds tests, which as we've seen subsequently add delays. It's a feature addition; no two ways about it. -- Dave Abrahams Boost Consulting www.boost-consulting.com

1 0

Re: [administrative] Formal Review Process
by David Abrahams 27 Jan '04

27 Jan '04

Thomas Witt <witt(a)acm.org> writes: >> b. Use a regular rotating schedule for review managers. If you're >> not going to be available when your time comes up, it should be >> your responsibility to find someone to swap with. > > From my experience strict rotating works almost never due to time > constraints or library topic. Yeah, but the result is that people would know well in advance when they're scheduled and what library they're scheduled for, and... > I am unsure whether this is not too much pressure to put it on highly > skilled volunteers. ... it would take the pressure off of *you* to find replacement reviewers. But if you're willing to keep that part of the pressure, so much the better for the rest of us. -- Dave Abrahams Boost Consulting www.boost-consulting.com

1 0

Re: [administrative] Formal Review Process
by David Abrahams 27 Jan '04

27 Jan '04

Thomas Witt <witt(a)acm.org> writes: >> I don't think automating would help here. >> How about having the email' addresses of all the review managers on >> the formal_review_process.html page? >> (and update this page as review managers are added or deleted) > > I think having names and email adresses on the website is at least > controversial, if only for mail address harvesters. Though it might be > a good idea to have the author care for a manager. This could be done > on a mailing list. Mail addresses are easy enough to obfuscate in ways that are transparent to humans. -- Dave Abrahams Boost Consulting www.boost-consulting.com

1 0

Another compressed_pair issue
by David Abrahams 26 Jan '04

26 Jan '04

Just for the sake of completeness, it would probably be a good idea to note that the use of compressed_pair wouldn't be transparent on an implementation where a class with virtual functions can be empty. Of course, I doubt any such implementation exists, but it is possible. -- Dave Abrahams Boost Consulting www.boost-consulting.com

1 0