- Boost - lists.boost.org

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