- Boost - lists.boost.org

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