RE: [boost] Re: Re: Re: Property_map docs
Title: RE: [boost] Re: Re: Re: Property_map docs From: Edward Diener [mailto:[EMAIL PROTECTED]] > OK, I am missing something in these docs which I expected to see and it is > not there for me. Evidently it is for everybody else and they consider it to > be adequate. I will say that no matter how poor the documentation seems to > me, it is probably on another level which I don't understand and which > others can easily figure out without any more specific explanation. I > apologize to all concerned and will simply bypass such implementations in > the future when the language of it is beyond my understanding. I thought > that by criticizing there would be others who might agree that the > documentation is not adequate for an intelligent C++ programmer to grasp, > and there would be an effort by either Mr. Siek, or someone else who > understands property map, to improve it and make it more understandable. I > was wrong and will leave it at that and wish everyone good luck in their > programming and documentation endeavors. If you're asking for the documentation to include more descriptions of the concepts that it builds upon, beyond links to other documents, you may well be asking for too much. Especially if you want an introduction to a subject area where much has already been written. OTOH, if there are things that seem out of place, or sections of the docs that leave you particularly confused, point them out -- preferrably suggesting alternative verbage where you can. Lets all take a deep breath and try to keep it as constructive as we can. Glen
[boost] Re: Re: Re: Property_map docs
"Christoph Kögl" <[EMAIL PROTECTED]> wrote in message news:1037063128.2680.0.camel@;localhost.localdomain... > Hi Jeremy (and Edward), > > I am just now reading that unfortunate Edward Diener thread. Normally I > am a quiet Boost > list/code consumer, but this is the time, I think, to speak up (a > little), just to let you know > that there are guys out here that very much appreciate Jeremy's > contributions to Boost. I appreciate Jeremy's Siek's other contributions also. > Edward may have let his frustration take the better of him, and I really > would like him > to read through the BGL (Boost Graph Library) docs, because that's where > property maps > are used in abundance and where enough example code lives to make the > concept > clear. Hey, there even is a book on the BGL which probably (I have not > read it) talks > about property maps as well. So, please, Edward, refrain from > prematurely posting harsh > remarks about seemingly unsuitable documentation (and note: I am not > saying anything about > your not being able to grasp the concept of property maps, I instead > suppose that you did not > devote enough time to trying to do so). I, for my part, have been using > the BGL (along with property > map implementations) extensively of late, and I cannot say that I > encountered undue difficulties with > the BGL/PM docs. The problem is that property map is presented separately from the BGL. Therefore a valid assumption would be that one could understand how it works separately from the BGL. > > Good night. > > PS. Edward, you may want to let us know what exactly your envisioned > area of application of the property map concept is. Then we may be able > to help you with > your specific problem(s). Here are some short answers to some of your > questions: I have no envisioned area of application. I was just reading through various Boost libraries trying to understand ideas and implementations and was befuddled by the property map docs. It seemed to imply that one could use generic algorithms to do mapping between a key and a value, and I like this idea in general, but I couldn't understand the specifics of how this was done and how it was used. The doc was saying to me "there is a way to use this concept so just dig and investigate and look at the source code and you will probably figure it out." That may not have been Mr. Siek's thought when he wrote it but that was my reaction to it. To me that isn't acceptable as documentation, so I wrote my criticism saying so. I will stand by my criticism that it isn't the way to explain anything and should be improved. Mr. Siek doesn't think so, and nobody else does either, so that's fine and I needn't attempt to use it in any way for myself if I don't understand how to use it. The concept sounds interesting but I > have no > > idea how it is implemented or used in a real situation. > > Well, the mathematical concept underlying property maps are maps (in the > mathematical > sense): let A, B be two sets, then a map m from A to B (denoted m: A->B) > is a subset of > AxB (the direct product of A and B) such that for ordered pairs (a,b), > (a,c) of m we have that > b=c holds (i.e. maps are left-unique binary relations). If you do not > understand the concept > of mathematical maps I am afraid you are out of luck (you =/= Edward > here, just the anonymous > "you"). Boost's property maps are one method to model mathematical maps > in C++ that mandates > not the use of one specific implementation (like some predefined > class(es) of function(s)), rather they > are "merely" a set of assumptions. Every C++ software artifact that > fulfills these assumptions (read: > abides by the specified syntactic and semantic requirements of the > property map concept) is a > property map. Software that in its code only uses the assumptions that > the property map concept > mandates (and not more) is guaranteed to work with /every/ artifact > implementing the property map > concept. Thanks for the explanation. I do appreciate it. > A more familiar case might be the concept of Input Iterator. > The std::find algorithm works > for every C++ artifact that implements the Input Iterator concept; you > are not confined to use > std::list::const_iterator, std::map::iterator etc., /any/ Input Iterator > works (not just those from the > standard library). Input iterators have necessary implementations which are explained in detail, or they won'[t work with the generic algorithms which use them. > So, actually, contrary to what Jeremy says, the > property map concept in itself > is not at all vague. It /could/ be defined more rigorously (read: > formally, which inevitably means > mathematically, because mathematics really is the only precise language > humankind currently has). > But this is not necessary nor would greatly support its understanding > for the average developer > (simply because the average developer is not trained in reading precise > formal specifications like > algebra
[boost] Re: Re: Property_map docs
"Ani Taggu" <[EMAIL PROTECTED]> wrote in message news:aqpjsn$t89$1@;main.gmane.org... > "Edward Diener" <[EMAIL PROTECTED]> wrote in message > news:aqnhte$mml$1@;main.gmane.org... > > "Jeremy Siek" <[EMAIL PROTECTED]> wrote in message > > news:Pine.GSO.4.44.021110230.4424-10@;zaphod.osl.iu.edu... > > > Hi Edward, > > > > > > On Sun, 10 Nov 2002, Edward Diener wrote: > > > eddiel> OK, here are some questions regarding the property map library; > > > eddiel> > > > eddiel> 1) What is a property map ? Is it a template class, a class, a > > > eddiel> template function, a function ? > > > > > > It is a "concept", as the term is used in the SGI STL docs: > > > http://www.sgi.com/tech/stl/stl_introduction.html > > > It has to do with specifying the contract between generic algorithms > > > (function templates) and the user of such algorithms. > > > > I am aware of your defintion of "concept" from Matt Austern's fine book. > But > > concepts imply implementations. > > > > I am a frequent listener here and it is quite uncommon to see such offensive > language. I wonder how you can "demand" better documentation from the > library author who had in spare time crafted a library good enough to be > included in boost. I didn't "demand" anything. Criticizing what I believe to be inadequate documentation is not a "demand". If programmers can't ask for better technology, and make criticisms accordingly, then we are all in a great deal of trouble professionally. Improving technology can not be done by pussyfooting around with endless awe and respect in our eyes. I have yet to see a valid argument against the suggestions and criticisms I posted. The doc is poor, but if everyone agrees it is good enough and understandable to them, fine and so be it. I am appreciative of many, if not almost all, of the fine ideas and implementations in the Boost libraries. Is it uncriticizable because it is freely done ? Sometimes criticism is needed to improve technology, and when that happens we are all winners. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] RE:Serialization library review
>Date: Mon, 11 Nov 2002 20:08:26 +0300 >From: Vladimir Prus <[EMAIL PROTECTED]> >> What is your evaluation of the design? >First comes my opinion on library scope. The biggest features that it >adds (compared with older 'describe' scheme) are saving of pointers and >versioning. Among other things also includes: a) non-intrusive serialization b) a systematic method of specifying serialization for templats c) the above are used to include serialization of all STL collection templates d) ability to specify particular archive format if the included ones don't suit you e) guaranteed archive portability between platforms >Also, the natuaral syntax at the top of that section seems correct to me. >If it is really not possible, then it should be told why. Well, As I said in the documentation, the cited syntax seems correct to me as well. I couldn't get it to compile in multiple environments. No one has been able to explain it to me either. If anyone knows why, I will add the expanation. > > What is your evaluation of the implementation? >There's missing typename at ../../boost/serialization/stl.hpp:124 in my copy, line 124 is a blank >And, BTW, is >typeid of *t is not equal to static type of *t, then *t is >already polymorphic, unless I'm missing something. Its only polymorphic if it has at least one virtual function. if it doesn't have at least one virtual function then dynamic_cast fails for lack of a vtable. >> What is your evaluation of the documentation? >Documentation does not say that "version" must be *static* member >function. because it doesn't have to be a static member function. In can be a member function or a virtual member function. >Rationale section talks about "saved objects must be const". I don't >understand what this means, and the example from reference for this >part compiles fine for me, while docs say it should not. hmmm - I'll refrase to "Save functions must be const" Of course save objects don't have to be const, The save function must specify const so the serialization process doesn't change them. The following looks overly generic: template< class T, class Allocator, template Container > boost::basic_oarchive & ::operator<<( boost::basic_oarchive & ar, const Container & t ); it would catch all classes which happen to be instances of templates with two parameters. The phrase "STL containers can be serialized using above syntax" is very confusing. I belive it should be stated that all STL containers can be serialized, without the interface above. > Did you try to use the library? With what compiler? Did you > have any problems? >Yes, with g++ 2.95.4 and 3.2 (although lack of Jamfile required manual compilation). >It did not compile, saying that: >./../boost/void_cast.hpp:28: redefinition of `struct boost::is_polymorphic' >/home/ghost/Work/boost/boost/type_traits/is_polymorphic.hpp:75: previous >definition of `struct boost::is_polymorphic' >In file included from ../../boost/serialization/serialization_imp.hpp:16, > from ../../boost/serialization/archive.hpp:4, > from archive.cpp:17: >./../boost/void_cast.hpp:28: redefinition of `struct boost::is_polymorphic' hmmm - my copy of boost_1_29_0 has no "is_polymorphic.hpp" in the type_traits directory. I only downloaded this 10 days ago. Is there a 1_29_1 that I should be using? >I think the library should not be accepted. I don't like to vote this >way, but I'm not convinced that serialization library with such requirement >for storing polymorphic pointers is really ready to go. Vladimir and I have has a spirted discussion on this issue for sometime. I understand his desire, but, after much effort, I have been unable to find any way to implement what he desires. Furthermore, I have come to the conclusion that it is logically impossible to do so - see last (unanswered) post. http://aspn.activestate.com/ASPN/Mail/Message/1384779 http://aspn.activestate.com/ASPN/Mail/Message/boost/1428284 http://aspn.activestate.com/ASPN/Mail/Message/1357868 http://aspn.activestate.com/ASPN/Mail/Message/1355485 Robert Ramey ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] boost::array and VC7 (oil & vinegar...vinegarette!!)
"Victor A. Wagner, Jr." <[EMAIL PROTECTED]> writes: > That worked!!! replacing BOOST_DEDUCED_TYPENAME with typename > At Monday 2002/11/11 10:58, you wrote: >>On Mon, 11 Nov 2002, Victor A. Wagner, Jr. wrote: >> > I deleted the token BOOST_DEDUCED_TYPENAME and "nothing obvious >> > happens" I still get the same error(s) in my compile. >> >> or try replacing BOOST_DEDUCED_TYPENAME with just "typename". My >>experience with MSVC 6 is that it handles the "typename" keyword very >>strangely. Sometimes it helps to have it, sometimes it helps to not have >>it. Fixed in CVS -- David Abrahams [EMAIL PROTECTED] * http://www.boost-consulting.com Boost support, enhancements, training, and commercial distribution ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Problem with , and request forextension
On Monday, November 11, 2002, at 8:59 AM, Kevin S. Van Horn wrote:
I have found that
boost::uint_t<64>::fast
gives a compiler error even on a platform (RH 7.3 on Intel) that has
64-bit integers available (as long long). On checking the
documentation
again, it does specify this behavior, but this strikes me as quite
unreasonable; if a platform has long long, I should be able to use it.
The reason it hasn't been added is that there is no guarantee that long
long constants can be used at compile-time (since it's not officially
part of C++).
I believe that all that is needed to fix this is inclusion of the
following lines:
#ifdef BOOST_HAS_LONG_LONG
template <> struct int_least_helper<0>
{ typedef long long least; };
#endif
#ifdef BOOST_HAS_LONG_LONG
template <> struct int_least_helper<5>
{ typedef unsigned long long least; };
#endif
The cases for 0 and 5 are left out deliberately so desired bit counts
beyond any integer type give an error. So a "fix" for this would have
to _add_ two new cases, still leave two error cases, and work when a
compiler doesn't have long long.
Also, I'd like to see the following added to :
boost::signed_int::type -- Gives the signed integer type of the
same
size as integer type T.
boost::unsigned_int::type -- Gives the unsigned integer type of the
same size as integer type T.
Rationale: I often find myself using
std::iterator_traits::difference_type
for quantities that are guaranteed to be nonnegative; for these I would
prefer to use an unsigned type.
Got a sample implementation? I could think of
template < typename T >
struct unsigned_int
{
typedef uint_t type;
};
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: pool benefit ratio for different compilers
"Bohdan" <[EMAIL PROTECTED]> wrote > > All boost::pool library is about allocation of small objects > of the same size. I'm just curious how malloc can be > accelerated if it handles different size allocations? > May be boost will also need something like that. > I understand that "char" can be treated as small object, > but i'm not sure if boost::fast_pool_allocator gives any acceleration > in this case. > malloc() cannot be accelerated very much: free() is missing information about allocated memory block size. new/delete probably won't be accelerated a lot using some pool management - new libraries took car of it already. I did comparison of Alexandrescu's SmallObjAllocator<> versus up-to-date allocators and found them much better. They ( Borland 6.0, Visual C++ 6.0 and Intel 6.0) use pools for small objects and are also _significantly_ faster than even hand tuned C++ code. I assume they are coded in assembler. The only exception I found was Linux GCC 2.94: SmallObjAllocator<> here has better characteristics (both speed/memory). /Pavel ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] help
Hi:
I have a question, if my base class has a clone pure virtual
function,what can I do to write
the wrap class?
struct Base
{ virtual int f() =
0; virtual Base* clone() =
0; };
struct BaseWrap : Base
{ BaseWrap(PyObject*
self_) :
self(self_) {} int f() { return
call_method(self, "f");
} Base* clone(){ return
call_method(self,
"clone");} PyObject*
self; };
If I write it like this,it report compile error.
kemeng
Re: [boost] boost::array and VC7 (oil & vinegar...vinegarette!!)
That worked!!! replacing BOOST_DEDUCED_TYPENAME with typename At Monday 2002/11/11 10:58, you wrote: On Mon, 11 Nov 2002, Victor A. Wagner, Jr. wrote: > I deleted the token BOOST_DEDUCED_TYPENAME and "nothing obvious > happens" I still get the same error(s) in my compile. or try replacing BOOST_DEDUCED_TYPENAME with just "typename". My experience with MSVC 6 is that it handles the "typename" keyword very strangely. Sometimes it helps to have it, sometimes it helps to not have it. Doug ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost Victor A. Wagner Jr. http://rudbek.com PGP RSA fingerprint = 4D20 EBF6 0101 B069 3817 8DBF C846 E47A PGP D-H fingerprint = 98BC 65E3 1A19 43EC 3908 65B9 F755 E6F4 63BB 9D93 The five most dangerous words in the English language: "There oughta be a law" ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: Property_map docs
"Edward Diener" <[EMAIL PROTECTED]> wrote in message news:aqnhte$mml$1@;main.gmane.org... > "Jeremy Siek" <[EMAIL PROTECTED]> wrote in message > news:Pine.GSO.4.44.021110230.4424-10@;zaphod.osl.iu.edu... > > Hi Edward, > > > > On Sun, 10 Nov 2002, Edward Diener wrote: > > eddiel> OK, here are some questions regarding the property map library; > > eddiel> > > eddiel> 1) What is a property map ? Is it a template class, a class, a > > eddiel> template function, a function ? > > > > It is a "concept", as the term is used in the SGI STL docs: > > http://www.sgi.com/tech/stl/stl_introduction.html > > It has to do with specifying the contract between generic algorithms > > (function templates) and the user of such algorithms. > > I am aware of your defintion of "concept" from Matt Austern's fine book. But > concepts imply implementations. > I am a frequent listener here and it is quite uncommon to see such offensive language. I wonder how you can "demand" better documentation from the library author who had in spare time crafted a library good enough to be included in boost. -Ani ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: Property_map docs
Hi Jeremy (and Edward), I am just now reading that unfortunate Edward Diener thread. Normally I am a quiet Boost list/code consumer, but this is the time, I think, to speak up (a little), just to let you know that there are guys out here that very much appreciate Jeremy's contributions to Boost. Edward may have let his frustration take the better of him, and I really would like him to read through the BGL (Boost Graph Library) docs, because that's where property maps are used in abundance and where enough example code lives to make the concept clear. Hey, there even is a book on the BGL which probably (I have not read it) talks about property maps as well. So, please, Edward, refrain from prematurely posting harsh remarks about seemingly unsuitable documentation (and note: I am not saying anything about your not being able to grasp the concept of property maps, I instead suppose that you did not devote enough time to trying to do so). I, for my part, have been using the BGL (along with property map implementations) extensively of late, and I cannot say that I encountered undue difficulties with the BGL/PM docs. Good night. PS. Edward, you may want to let us know what exactly your envisioned area of application of the property map concept is. Then we may be able to help you with your specific problem(s). Here are some short answers to some of your questions: > I am disappointed in the doc. The concept sounds interesting but I have no > idea how it is implemented or used in a real situation. Well, the mathematical concept underlying property maps are maps (in the mathematical sense): let A, B be two sets, then a map m from A to B (denoted m: A->B) is a subset of AxB (the direct product of A and B) such that for ordered pairs (a,b), (a,c) of m we have that b=c holds (i.e. maps are left-unique binary relations). If you do not understand the concept of mathematical maps I am afraid you are out of luck (you =/= Edward here, just the anonymous "you"). Boost's property maps are one method to model mathematical maps in C++ that mandates not the use of one specific implementation (like some predefined class(es) of function(s)), rather they are "merely" a set of assumptions. Every C++ software artifact that fulfills these assumptions (read: abides by the specified syntactic and semantic requirements of the property map concept) is a property map. Software that in its code only uses the assumptions that the property map concept mandates (and not more) is guaranteed to work with /every/ artifact implementing the property map concept. A more familiar case might be the concept of Input Iterator. The std::find algorithm works for every C++ artifact that implements the Input Iterator concept; you are not confined to use std::list::const_iterator, std::map::iterator etc., /any/ Input Iterator works (not just those from the standard library). So, actually, contrary to what Jeremy says, the property map concept in itself is not at all vague. It /could/ be defined more rigorously (read: formally, which inevitably means mathematically, because mathematics really is the only precise language humankind currently has). But this is not necessary nor would greatly support its understanding for the average developer (simply because the average developer is not trained in reading precise formal specifications like algebraic data types, modal/temporal logic, process algebras, whatever). The understanding therefore must come from practice and from reading existing code. The BGL provides plenty of it. Read it and learn from it. > OK, why not explain that in the doc and how it is done. Explanation is already there; read the code example right on the introductory doc page and follow the links to the (const_)associative_property_map pages a bit further down. Perhaps there is less of a problem than you (Edward) expect, the (const_)associative_property_map is really just a simple adapter (read the GOF book about the Adapter pattern if you haven't already done so). > You didn't answer the first question. There is no need to, the get/put/operator[] semantics are described in the docs. Look at the Valid Expressions boxes on the ReadablePropertyMap, WriteablePropertyMap, and LvaluePropertyMap pages. If you understand the SGI STL docs you understand the get/put/operator[] description as well. > Example of this in the doc please, with some function template showing this > technique as practical usage within your "concept". I am afraid this is a standard technique by now and the property map docs are not the right nor adequate place for talking about it in any detail. Several published articles (on the web, in CUJ etc.) or the SGI STL source code itself are available for perusal. And, again, for examples on how to use PMs you may always read the BGL sources or the BGL book. > I find it unbelievable that any college would accept your > documentation as adequate explanation of your concept. Either colleges have > deteriorated from what th
[boost] Re: Re: Re: Property_map docs
"Jeremy Siek" <[EMAIL PROTECTED]> wrote in message news:Pine.GSO.4.44.020951350.6135-10@;zaphod.osl.iu.edu... > Hi Edward, > > Since you feel so strongly about this, please write a new version of the > property map docs and send them to me. > > In future emails, I would appreciate it if you refrained from using such > an accusatory tone. At this point I'm feeling hurt by your words and > discouraged about volunteering my time to boost. I apologize for sounding accusatory. I don't understand what you are at with property_map although I discern a good idea in there. I just don't understand why you are unwilling to explain it in terms that others can use more easily. I know that I am missing how the mechanism works which links the property_map concept to the get(), put(), and operator[] functions. It is your idea and your documentation. If you feel that the documentation is fit for the use of others, so be it. I will move on to other libraries which I can understand. But I would like you to think about the possibility that what you perhaps understand intuitively, others don't because they don't have the information necessary to use your idea. I don't want to ever discourage you or any others from contributing to an organization so devoted to software excellence as Boost is. I am truly sorry if any nastiness crept into the discussion in my efforts to understand your software. > > Sincerely, > Jeremy > > On Mon, 11 Nov 2002, Edward Diener wrote: > eddiel> "Jeremy Siek" <[EMAIL PROTECTED]> wrote in message > eddiel> news:Pine.GSO.4.44.021110230.4424-10@;zaphod.osl.iu.edu... > eddiel> > Hi Edward, > eddiel> > > eddiel> > On Sun, 10 Nov 2002, Edward Diener wrote: > eddiel> > eddiel> OK, here are some questions regarding the property map library; > eddiel> > eddiel> > eddiel> > eddiel> 1) What is a property map ? Is it a template class, a class, a > eddiel> > eddiel> template function, a function ? > eddiel> > > eddiel> > It is a "concept", as the term is used in the SGI STL docs: > eddiel> > http://www.sgi.com/tech/stl/stl_introduction.html > eddiel> > It has to do with specifying the contract between generic algorithms > eddiel> > (function templates) and the user of such algorithms. > eddiel> > eddiel> I am aware of your defintion of "concept" from Matt Austern's fine book. But > eddiel> concepts imply implementations. > eddiel> > eddiel> > > eddiel> > If you were looking for some useful concrete component to implement some > eddiel> > kind of mapping, then I'm afraid you will be disappointed in the property > eddiel> > map library. > eddiel> > eddiel> I am disappointed in the doc. The concept sounds interesting but I have no > eddiel> idea how it is implemented or used in a real situation. > eddiel> > eddiel> > > eddiel> > eddiel> 2) What does the word "property" mean in the context of the name ? > eddiel> > > eddiel> > Here by property we mean something that is associated with some object. I > eddiel> > know this is vague, but there just is not much to the property map > eddiel> > concept. > eddiel> > eddiel> Yes, it is vague. Does that make you happy about it ? > eddiel> > eddiel> > > eddiel> > eddiel> 3) What is the difference between property map and std::map<> ? > eddiel> > > eddiel> > std::map<> is a class. property map is a concept (well, a collection > eddiel> > of concepts). You can use the boost::associative_property_map > eddiel> > adaptor to adapt std::map<> into a type that *models* property map. > eddiel> > eddiel> OK, why not explain that in the doc and how it is done. > eddiel> > eddiel> > > eddiel> > eddiel> 4) How does one use a property map ? > eddiel> > > eddiel> > You write function templates with template parameters that > eddiel> > have property map as their requirement. > eddiel> > eddiel> Example of this in the doc please. > eddiel> > eddiel> > > eddiel> > eddiel> 5) How does one create a property map of one's own ? > eddiel> > > eddiel> > Create a class and then define get(), put() and operator[] > eddiel> > function for the class. > eddiel> > eddiel> Example of this in the doc please. > eddiel> > eddiel> > > eddiel> > eddiel> 6) What are the prototypes for the get(), put(), and operator[] > eddiel> > eddiel> functions, and are these really global functions as the doc > eddiel> > eddiel> suggests or are they functions in the boost namespace ? > eddiel> > > eddiel> > They can live anywhere that argument dependent lookup can find them, which > eddiel> > means just about anywhere. > eddiel> > eddiel> You didn't answer the first question. > eddiel> > eddiel> > > eddiel> > eddiel> 7) What do the various categories actually do for property maps ? > eddiel> > > eddiel> > Like the iterator tags in the C++ std, they allow function templates to > eddiel> > dispatch to different code depending on the category of the property map. > eddiel> > eddiel> Example of this in the doc please, with some function template showing this > eddiel> technique as practical usage within your "c
[boost] config missing #define for Metrowerks compiler EH support
Hi, would it be possible to add the following piece of code somewhere in boost\config\Metrowerks.hpp: - begin code #if !__option(exceptions) # define BOOST_NO_EXCEPTIONS #endif - end code I guess the code is self-explanatory. Alberto Barbati ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: function queue
At 12:56 PM 11/11/2002, William E. Kempf wrote: > >Eric Woodruff said: >> William, >> >> I'm not sure. I haven't been following the development branch, and don't >> know exactly how to access it. > >$> cvs co -r thread_development boost >would check out the thread_development branch. Tweak as needed for your >environment. If you just want to look at a file or two, you can do it via the browser interface. See http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/boost/boost/ You can use the "Show only files with tag:" list at the bottom of the page to control what branch you are looking at. HTH, --Beman ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: function redesign for dynamic_any
On Monday 11 November 2002 11:45 am, Alexander Nasonov wrote: > This functionality can be usefull but not quite often. I think it's better > to keep 'call' member function for simple use and introduce different name > (call_ex?) for advanced use. So, you can use one of: > > // 1) > template > bool call(const Arg & a, const Arg & b) const; > // 2 > template > bool call_ex(const Arg & a, const std::type_info & ta, >const Arg & b, const std::type_info & tb) const; > > Implementation can first try to call 'call_ex' and if it throws internal > exception (default behavoir) then revert to 'call' member-function. I'm assuming you aren't referring to an actual C++ exception. I would assume that the default behavior of call_ex would be to call the call function in the derived class (assuming you are still planning to use the curiously recurring template pattern). > Current algorithm takes first argument a1 (which holds value v1 of type T1) > and tries to extract T1 & from a2 ... aN. If all extractions are ok then > invoke the foo: This seems like the best approach to me. Doug ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] iterator adaptors docs tid
Yitzhak Sapir <[EMAIL PROTECTED]> writes: > In the iterator docs for generator_iterator: > > http://www.boost.org/libs/utility/generator_iterator.htm > > It says (under title The Generator Iterator Object Generator): > > template > typename generator_iterator_generator::type > make_function_output_iterator(Generator & gen); > > The last line should say: make_generator_iterator. Fixed in CVS -- David Abrahams [EMAIL PROTECTED] * http://www.boost-consulting.com Boost support, enhancements, training, and commercial distribution ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Old Dinkum - does boost have (already) a workaround for this?
Gennaro Prota <[EMAIL PROTECTED]> writes: > On Mon, 11 Nov 2002 13:29:25 -0500, David Abrahams > <[EMAIL PROTECTED]> wrote: > > >>RTFM if you're interested. > > I had to look on the net for the meaning of "RTFM". After finding it > at http://piology.org/yabla.txt, well I can't do anything but thanking > you and congratulating on your finesse. Well, it's usually taken much more-lightly among friends and colleagues as "Read the Fine Manual" (http://www.ucc.ie/cgi-bin/acronym?rtfm) , since it's too useful a saying to have it always carry such offensive overtones. So, I never intended the meaning listed there, but I guess I should be more-careful with people who aren't likely to know the acronym already. -- David Abrahams [EMAIL PROTECTED] * http://www.boost-consulting.com Boost support, enhancements, training, and commercial distribution ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: function queue
Eric Woodruff said: > Yeah, it's the same concept. I had failed to distinguish thread_pool > versus thread_group. > > Hopefully, adding the timeout and growing logic does not sacrifice the > efficiency of the pool when it is full/has plenty to work on. Shouldn't be a large issue. If the pool is full (i.e. max_threads has been created and all are busy) the queue can still be added to, so there's no effect to the performance of add. The check for being full is a simple integer comparison, so shouldn't effect the performance. The check for decaying a thread uses conditions and timeouts, so also should not effect the efficiency. The only thing that can effect efficiency is the actual act of creating a thread when the pool grows, but careful specification of min/max/timeout can optimize this. If you have to, you can specify min/max to be the same, thus fixing the size of the pool and ensuring you never incur the overhead of growing the pool. However, this will often be at a sacrifice to resource utilization, so individual needs will have to dictate how one defines these parameters. -- William E. Kempf ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Old Dinkum - does boost have (already) a workaround for this?
On Mon, 11 Nov 2002 13:29:25 -0500, David Abrahams <[EMAIL PROTECTED]> wrote: >RTFM if you're interested. I had to look on the net for the meaning of "RTFM". After finding it at http://piology.org/yabla.txt, well I can't do anything but thanking you and congratulating on your finesse. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Can type_traits be user specialized?
Hi All! Suppose I'm writing some generic piece of numeric code that can be instantiated with a User Defined Type (UDT). And further suppose that I need to detect whether the generic numeric type represents either integer or floating point values. Can I use type_traits is_integral<> (or is_float<>)? That is, is the user allowed to provide her own specializations of this templates? If not, how should I let the user tell whether her numeric UDT is integer/float/signed/etc...? TIA, Fernando Cacciola ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Old Dinkum - does boost have (already) aworkaround for this?
Gennaro Prota <[EMAIL PROTECTED]> writes: > David Abrahams <[EMAIL PROTECTED]> wrote: > >>We have one in the iterator adaptors library. > > Sorry, I'm quite ignorant about that library. What is the workaround > precisely? RTFM if you're interested. Actually, I'm not sure if there's a workaround for any problem you're having, because you haven't exactly described a problem. If the problem is that there are 2 template parameters, you're out of luck. You can't make a reverse iterator around a pointer type without partial specialization or some help with the value type. -- David Abrahams [EMAIL PROTECTED] * http://www.boost-consulting.com Boost support, enhancements, training, and commercial distribution ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Boost.Bind testing patch for Sun
"Peter Dimov" <[EMAIL PROTECTED]> writes: > From: "David Abrahams" <[EMAIL PROTECTED]> >> "Peter Dimov" <[EMAIL PROTECTED]> writes: >> >> > From: "David Abrahams" <[EMAIL PROTECTED]> >> >> >> >> Even after applying other workarounds, the following patch seems to be >> >> required to get the Boost.Bind test to pass on the latest Sun >> >> compilers. Is it appropriate to apply this, or should this problem >> >> cause the test to fail? >> >> >> >> -BOOST_TEST( bind(&X::hash, _1)(x) == 23558 ); >> >> +BOOST_TEST( bind(&X::hash, _1)(x) == 23558 ); >> > >> > I think that the right thing is to #ifdef the bind<> path for Sun only. >> >> Thanks for responding, Peter. Would you mind making that change? > > It would be more appropriate for someone with access to Sun C++ to make > Sun-specific changes. :-) Neither of us has that at the moment, but I want to make sure the change doesn't get lost. -- David Abrahams [EMAIL PROTECTED] * http://www.boost-consulting.com Boost support, enhancements, training, and commercial distribution ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] boost::array and VC7 (oil & water)
Douglas Paul Gregor <[EMAIL PROTECTED]> writes: > On Mon, 11 Nov 2002, Victor A. Wagner, Jr. wrote: >> I deleted the token BOOST_DEDUCED_TYPENAME and "nothing obvious >> happens" I still get the same error(s) in my compile. > > ... or try replacing BOOST_DEDUCED_TYPENAME with just "typename". My > experience with MSVC 6 is that it handles the "typename" keyword very > strangely. Sometimes it helps to have it, sometimes it helps to not have > it. It already means "typename" for vc7, which is what he's testing with. -- David Abrahams [EMAIL PROTECTED] * http://www.boost-consulting.com Boost support, enhancements, training, and commercial distribution ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: function queue
Yeah, it's the same concept. I had failed to distinguish thread_pool versus thread_group. Hopefully, adding the timeout and growing logic does not sacrifice the efficiency of the pool when it is full/has plenty to work on. "William E. Kempf" <[EMAIL PROTECTED]> wrote in message news:3599.167.16.75.51.1037037372.squirrel@;frodo.kempf-ville.com... > > Eric Woodruff said: > > William, > > > > I'm not sure. I haven't been following the development branch, and don't > > know exactly how to access it. > > $> cvs co -r thread_development boost > would check out the thread_development branch. Tweak as needed for your > environment. > > > I called this class a function queue > > based on what I saw of the currently released boost::thread::thread_pool > > which was merely a collection of various threads that provided a grouped > > join. > > I think you're talking about boost::thread::thread_group here. The > boost::thread::thread_pool in the thread_development branch sounds like > your "function queue", unless I'm misunderstanding something from your > short description. > > > I needed to be abstracted from the thread itself. Thus, thread was > > not a good choice in the class's name. > > I'm not sure I follow this, but here's a short example of using a > thread_pool. > > int min_threads=3; > int max_threads=10; > int timeout=10; // seconds > boost::thread_pool pool(max_threads, min_threads, timeout); > pool.add(some_function_object); > pool.add(some_function_object); > pool.add(some_function_object); > pool.add(some_function_object); > pool.add(some_function_object); > > The number of threads that will be used to dispatch the queued function > objects will expand and contract between min_threads and max_threads, with > idle threads waiting for the specified timeout before terminating if there > are more than min_threads available. > > The user never directly accesses a thread in a thread_pool. He only adds > function objects to a queue on which the pooled threads will work. > > -- > William E. Kempf > > > ___ > Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost > ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: function queue
Eric Woodruff said: > William, > > I'm not sure. I haven't been following the development branch, and don't > know exactly how to access it. $> cvs co -r thread_development boost would check out the thread_development branch. Tweak as needed for your environment. > I called this class a function queue > based on what I saw of the currently released boost::thread::thread_pool > which was merely a collection of various threads that provided a grouped > join. I think you're talking about boost::thread::thread_group here. The boost::thread::thread_pool in the thread_development branch sounds like your "function queue", unless I'm misunderstanding something from your short description. > I needed to be abstracted from the thread itself. Thus, thread was > not a good choice in the class's name. I'm not sure I follow this, but here's a short example of using a thread_pool. int min_threads=3; int max_threads=10; int timeout=10; // seconds boost::thread_pool pool(max_threads, min_threads, timeout); pool.add(some_function_object); pool.add(some_function_object); pool.add(some_function_object); pool.add(some_function_object); pool.add(some_function_object); The number of threads that will be used to dispatch the queued function objects will expand and contract between min_threads and max_threads, with idle threads waiting for the specified timeout before terminating if there are more than min_threads available. The user never directly accesses a thread in a thread_pool. He only adds function objects to a queue on which the pooled threads will work. -- William E. Kempf ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Filesystem on mac
Beman, Thanks for the reply. I haven't much to add to what was said over the weekend. Unfortunately, Mac OS X or not, there are people in my lab and elsewhere who are going to rely on Mac OS 9 for a while yet, and the Codewarrior debugger seems to work better with Carbon applications. One of the reasons for using a path abstraction is that just to handle the differences between Mac OS 9 and 10. So I'll wait a few weeks until you've made your changes to filesystem, and then have another look at how to go about adding "old" mac paths. cheers, goof -- Geoff Leyland, Village Idiot Laboratoire d'energetique industrielle LENI-DGM-EPFL, CH-1015, Lausanne, Switzerland Phone: +41 (21) 693 3505, Fax: +41 (21) 693 35 02 ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] boost::array and VC7 (oil & water)
On Mon, 11 Nov 2002, Victor A. Wagner, Jr. wrote: > I deleted the token BOOST_DEDUCED_TYPENAME and "nothing obvious > happens" I still get the same error(s) in my compile. ... or try replacing BOOST_DEDUCED_TYPENAME with just "typename". My experience with MSVC 6 is that it handles the "typename" keyword very strangely. Sometimes it helps to have it, sometimes it helps to not have it. Doug ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Proposed Boost Assert -- once again
From: "Kevin S. Van Horn" <[EMAIL PROTECTED]> > It's been six days since I posted this, without a single response, so I'm > going to try again. Based on earlier discussions, I thought there might > be some interest in this. Does anyone have any problems with the proposed > interface? Should I turn this into a formal proposal for submission to > Boost? Peter, how does this compare with the changes to > you were planning to do / are doing? Sorry, I've been offline. I'll try to make the changes to assert.hpp ASAP so we can base the discussion on the new version. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Proposed Boost Assert -- once again
Kevin S. Van Horn wrote: It's been six days since I posted this, without a single response, so I'm going to try again. Based on earlier discussions, I thought there might be some interest in this. Does anyone have any problems with the proposed interface? Yes, althought a very minor ones. 1. I'd prefer to have BOOST_NDEBUG instead of BOOST_DEBUG, for consistency with NDEBUG. I simply want BOOST_ASSERT to work for debug builds. Or doesBOOST_DEBUG have non-empty initial value? 2. failed_exception can be safely derived from std::exception. Unlike std::logic_error, it does not use std::string. 3. Docs for BOOST_ASSERT say 'Otherwise, if user has already provided a definition for BOOST_ASSERT, the definition is left unchanged. Is this accurate? If user has provided its own definition for BOOST_ASSERT, then calling the BOOST_ASSERT macro will do what user coded. You must mean that if there's BOOST_ASSERT defined then won't change that definition. 4. I seem to see the point in separate BOOST_ASSERT and BOOST_ASSERT_MSG, but would like some better documentation on this. So, the summary is that you code looks very usefull and I'm going to use it. - Volodya ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Pool Iterators?
Hi Steve, Thanks for the reply. On Lundi, novembre 11, 2002, at 06:00 , [EMAIL PROTECTED] wrote: One possibility is to write an object type that sits between your object and the pool allocator, which adds a single pointer to your object. Something similar to what a doubly-linked list container would do when rebinding its Allocator. This gives you the ability to iterate over them, and also allows fast insertion and deletion. This pretty much what I've got. There's an object that talks to a the pool, and remembers everything that I've allocated in a vector (actually a holey_vector). This was really slow for deleting something, because searching through a list of 2 pointers for the one you want is a waste of time. I solved that my sticking a back-pointer in the object itself. This is a sufficient solution, but I think it lacks elegance compared to a possible pool_iterator, but, if you think it's the best idea, I'll go that way. One of the reasons I like the pool_iterator is that I store the pointers themselves in a vector with "holes". This makes insertion and deletion in the vector very fast, and you can iterate through it very quickly. The free list is a map of free indexes, which means it's easy to work out as you walk through the list which elements are free, and also, that any new allocations into free space are at the bottom of the list, so, with a bit of luck, you can cut the end off a shrinking list. I was pretty much of the opinion that this was just a cheap and nasty substitute for a real pool allocator (it's what I was using before I used pool), not in the least because when the vector resizes the whole thing moves. There's stuff in the code and comments about an "ordered" free list. If you can excuse my ignorance, does this mean that it's potentially possible to walk through the pool's storage at the same time as walking through the ordered free list and find out fairly cheaply which blocks are free? A similar approach, if you're willing to more seriously change the code that allocates/deallocates the objects, is to keep a doubly-linked list of pointers to the allocated objects. But then reference the objects indirectly through iterators of that list. If you reference them in this way, then deletion should be fast. That's not a bad idea. The easiest would be to just stick next and prev pointers in the objects themselves. But even so, if pool_iterators were possible in a generic way, everyone would benefit, and my code would "just work". cheers, goof -- "To a man with a hammer, everything looks like a nail." - Mark Twain Geoff Leyland, Village Idiot Laboratoire d'energetique industrielle LENI-DGM-EPFL, CH-1015, Lausanne, Switzerland Phone: +41 (21) 693 3505, Fax: +41 (21) 693 35 02 ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] boost::array and VC7 (oil & water)
I deleted the token BOOST_DEDUCED_TYPENAME and "nothing obvious happens" I still get the same error(s) in my compile. At Monday 2002/11/11 10:11, you wrote: "Victor A. Wagner, Jr." <[EMAIL PROTECTED]> writes: > unfortunately, the "test case" is (well it was) an operational program > to validate the format of some files produced by a product of my > client's. > The limited "callback" now given in VC7.0 (compared to VC6.0) gives me > almost no clue as to what was written to cause the error. I'll see if > I can chase it down sometime today. One quick thing you can try is deleting BOOST_DEDUCED_TYPENAME in your local copy in the line indicated by the error. If that fixes it, I'll make sure it's properly #defined in config.hpp. -- David Abrahams [EMAIL PROTECTED] * http://www.boost-consulting.com Boost support, enhancements, training, and commercial distribution ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost Victor A. Wagner Jr. http://rudbek.com PGP RSA fingerprint = 4D20 EBF6 0101 B069 3817 8DBF C846 E47A PGP D-H fingerprint = 98BC 65E3 1A19 43EC 3908 65B9 F755 E6F4 63BB 9D93 The five most dangerous words in the English language: "There oughta be a law" ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Old Dinkum - does boost have (already) a workaround for this?
David Abrahams <[EMAIL PROTECTED]> wrote: >We have one in the iterator adaptors library. Sorry, I'm quite ignorant about that library. What is the workaround precisely? Genny. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Boost.Bind testing patch for Sun
From: "David Abrahams" <[EMAIL PROTECTED]> > "Peter Dimov" <[EMAIL PROTECTED]> writes: > > > From: "David Abrahams" <[EMAIL PROTECTED]> > >> > >> Even after applying other workarounds, the following patch seems to be > >> required to get the Boost.Bind test to pass on the latest Sun > >> compilers. Is it appropriate to apply this, or should this problem > >> cause the test to fail? > >> > >> -BOOST_TEST( bind(&X::hash, _1)(x) == 23558 ); > >> +BOOST_TEST( bind(&X::hash, _1)(x) == 23558 ); > > > > I think that the right thing is to #ifdef the bind<> path for Sun only. > > Thanks for responding, Peter. Would you mind making that change? It would be more appropriate for someone with access to Sun C++ to make Sun-specific changes. :-) ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Possible Errors in Boost Config (mostly documentation)
John Maddock said: >> 5. BOOST_HAS_MPTASKS is defined in the config headers, but is >> undocumented. It is used only in Boost Threads. > > Can whoever is responsible for that one please supply docs and a test > case? This is for the Mac port of Boost.Threads. Mac Murrett will have to supply what you need here. -- William E. Kempf ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Boost.Bind testing patch for Sun
"Peter Dimov" <[EMAIL PROTECTED]> writes: > From: "David Abrahams" <[EMAIL PROTECTED]> >> >> Even after applying other workarounds, the following patch seems to be >> required to get the Boost.Bind test to pass on the latest Sun >> compilers. Is it appropriate to apply this, or should this problem >> cause the test to fail? >> >> -BOOST_TEST( bind(&X::hash, _1)(x) == 23558 ); >> +BOOST_TEST( bind(&X::hash, _1)(x) == 23558 ); > > I think that the right thing is to #ifdef the bind<> path for Sun only. Thanks for responding, Peter. Would you mind making that change? -- David Abrahams [EMAIL PROTECTED] * http://www.boost-consulting.com Boost support, enhancements, training, and commercial distribution ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Old Dinkum - does boost have (already) a workaround forthis?
Gennaro Prota <[EMAIL PROTECTED]> writes:
> Hi,
>
> due to the reasons we all know, the old VC6 lib requires at least two
> arguments for std::reverse_iterator (the iterator and the
> corresponding value_type) instead of one. In fact the definition is:
>
>
> template class _Ty,
> class _Rt = _Ty&,
> class _Pt = _Ty *,
> class _D = ptrdiff_t>
> class reverse_iterator : public _Ranit<_Ty, _D> {
> public:
> typedef reverse_iterator<_RI, _Ty, _Rt, _Pt, _D> _Myt;
> typedef _RI iter_type;
> typedef _Rt reference_type;
> typedef _Pt pointer_type;
>
>
>
> Before trying my own one, does boost have already a workaround for
> this? What I need is the classical
>
> typedef std::reverse_iterator reverse_iterator;
> typedef std::reverse_iterator const_reverse_iterator;
We have one in the iterator adaptors library.
--
David Abrahams
[EMAIL PROTECTED] * http://www.boost-consulting.com
Boost support, enhancements, training, and commercial distribution
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] boost::array and VC7 (oil & water)
"Victor A. Wagner, Jr." <[EMAIL PROTECTED]> writes: > unfortunately, the "test case" is (well it was) an operational program > to validate the format of some files produced by a product of my > client's. > The limited "callback" now given in VC7.0 (compared to VC6.0) gives me > almost no clue as to what was written to cause the error. I'll see if > I can chase it down sometime today. One quick thing you can try is deleting BOOST_DEDUCED_TYPENAME in your local copy in the line indicated by the error. If that fixes it, I'll make sure it's properly #defined in config.hpp. -- David Abrahams [EMAIL PROTECTED] * http://www.boost-consulting.com Boost support, enhancements, training, and commercial distribution ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] BOOST_HAS_NRVO
Daniel Frey <[EMAIL PROTECTED]> writes: > David Abrahams wrote: >> >> Daniel Frey <[EMAIL PROTECTED]> writes: >> >> > That was me, although I have no CVS write access >> >> Why don't we just fix that? What's your SourceForge UserID? > > dfrey42 > > Seems I have something to do for my 56K modem this evening - and I have > to read some docs on CVS branches... :o) Thanks! Done. Don't forget to ssh in to cvs.boost.sourceforge.net to create your home directory. -- David Abrahams [EMAIL PROTECTED] * http://www.boost-consulting.com Boost support, enhancements, training, and commercial distribution ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Proposed Boost Assert -- once again
I've always used the examples out of TC++PL of some assertions:
template
assertion (bool const condition) {
if (!condition) {
throw Exception ();
}
}
template
assertion (bool const condition, Exception const& exception) {
if (!condition) {
throw exception;
}
}
What about having a function-class based assertion that worked like:
assertion (!Sanity::invalidArgument || 0 != p, Throw (invalid_argument
("must not be zero")));
assertion (2 > x, Abort ());
or maybe even
assertion (2 > x, DontCompile ());
implementation ---
template
assertion (bool const condition, Function const& f) {
if (!condition) {
f ();
}
}
It looks very idiomatic to me.
I've also found things like this useful:
template
Condition const& assertNonZero (Condition const& condition) {
if (0 == condition) {
throw Exception ();
}
return condition;
}
Consider:
return x / assertNonZero (b - a);
"Kevin S. Van Horn" <[EMAIL PROTECTED]> wrote in message
news:Pine.LNX.4.44.020833530.25298-10@;speech.cs.ndsu.nodak.edu...
> It's been six days since I posted this, without a single response, so I'm
> going to try again. Based on earlier discussions, I thought there might
> be some interest in this. Does anyone have any problems with the proposed
> interface? Should I turn this into a formal proposal for submission to
> Boost? Peter, how does this compare with the changes to
> you were planning to do / are doing?
>
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: function queue
William, I'm not sure. I haven't been following the development branch, and don't know exactly how to access it. I called this class a function queue based on what I saw of the currently released boost::thread::thread_pool which was merely a collection of various threads that provided a grouped join. I needed to be abstracted from the thread itself. Thus, thread was not a good choice in the class's name. eric "William E. Kempf" <[EMAIL PROTECTED]> wrote in message news:3666.167.16.75.51.1037032721.squirrel@;frodo.kempf-ville.com... > > Eric Woodruff said: > > Is there any interest in a threaded function queue? I ran into a problem > > where I needed to asynchronously run methods but I didn't want to (or > > actually couldn't easlily) maintain threads to run them in. So I created > > a function queue where I could control the number of threads that were > > used to execute the (Boost.Function) functions. There is a lot of room > > for customization like specifying policies for controlling how/if the > > processing thread collection can grow. > > Unless I'm not understanding precisely what you mean, it sounds like your > talking about a "thread_pool", as implemented in the thread_development > branch. Could you compare contrast what you have in mind with what's > available there? > > -- > William E. Kempf > > > ___ > Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost > ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Serialization Library Review
David Abrahams wrote:
Here's a reminder of what to include in your review comments:
Here are some questions you might want to answer in your review:
What is your evaluation of the design?
First comes my opinion on library scope. The biggest features that it
adds (compared with older 'describe' scheme) are saving of pointers and
versioning.
There are other interesting things, for example, creating
human-readable archives with field/variable names. E.g. I might want to
create a dump file which can be directly read by Python (and should use
Python syntax for lists/maps). Those things are not supported, but I won't
discuss them for now --- it's a topic for future.
Regarding pointer saving, I was posting quite a lot, but was unable to
convince Robert there's a problem. Briefly, if some module saves pointers to
polymorphic class B, then it should *include headers* that declare *all classes
derived from B*. I don't think this requirement is reasonable.
More details can be found in:
http://aspn.activestate.com/ASPN/Mail/Message/1265629
http://aspn.activestate.com/ASPN/Mail/Message/1358054
I don't like the 'serialization' class, as well as arguments for putting
it in global namespace. The argument is that if it were in 'boost' namespace,
then to declare a specialization, one would have to open 'boost' namespace.
However, I don't declared my classes in global namespace, so to add a specialization,
I'd have to do that outside of my namespace, which is not better. In fact, I'd
*strongly* prefer free-standing functions.
It appears that under "Serialization of templates", the reference suggests
to declare something in namespace boost::serialization_detail. I think that
(1) that should be boost::serialization::detail and (2) user should not
declare anything in detail namespace.
Also, the natuaral syntax at the top of that section seems correct to me.
If it is really not possible, then it should be told why.
I would like to avoid declaring "version" function when I don't want
to use any versioning, althought I don't see how to do this in the current
library.
What is your evaluation of the implementation?
I'm not overly happy with the implementation --- it took me
quite a lot to understand what's going on there. Lack of
comments for internal classes cause some of the problems.
There's missing typename at
../../boost/serialization/stl.hpp:124
There's line
assert(is_polymorphic::value).
I guess this should be compile-time assertion? And, BTW, is
typeid of *t is not equal to static type of *t, then *t is
already polymorphic, unless I'm missing something.
What is your evaluation of the documentation?
Single-level index for reference docs makes nagivation hard.
Documentation does not say that "version" must be *static* member
function.
Rationale section talks about "saved objects must be const". I don't
understand what this means, and the example from reference for this
part compiles fine for me, while docs say it should not.
The 'register_type' method is documented only inside docs for particular
kind of exception. It should be moved elsewhere. Storing of base pointers
is in generally underdocumented.
The following looks overly generic:
template<
class T,
class Allocator,
template Container
>
boost::basic_oarchive & ::operator<<(
boost::basic_oarchive & ar,
const Container & t
);
it would catch all classes which happen to be instances of templates with
two parameters. The phrase "STL containers can be serialized using above syntax"
is very confusing. I belive it should be stated that all STL containers can
be serialized, without the interface above.
What is your evaluation of the potential usefulness of the
library?
I believe that the issue with storing polymorphic pointers makes the library
not very usefull. In effect, to store polymorphic pointers, I have to
implement registraction system and make loading of base classes create
derived classes using registered id. This almost amounts to implementing my
own serialization library.
Did you try to use the library? With what compiler? Did you
have any problems?
Yes, with g++ 2.95.4 and 3.2 (although lack of Jamfile required manual compilation).
It did not compile, saying that:
../../boost/void_cast.hpp:28: redefinition of `struct boost::is_polymorphic'
/home/ghost/Work/boost/boost/type_traits/is_polymorphic.hpp:75: previous
definition of `struct boost::is_polymorphic'
In file included from ../../boost/serialization/serialization_imp.hpp:16,
from ../../boost/serialization/archive.hpp:4,
from archive.cpp:17:
../../boost/void_cast.hpp:28: redefinition of `struct boost::is_polymorphic'
After commenting out part of void_cast.hpp, it did compile. However, the attached
program produced no output with 3.2. The line 36 simply did nothing ("step" in gdb
on it did not lead anywhere).
How much effor
Re: [boost] function queue
Eric Woodruff said: > Is there any interest in a threaded function queue? I ran into a problem > where I needed to asynchronously run methods but I didn't want to (or > actually couldn't easlily) maintain threads to run them in. So I created > a function queue where I could control the number of threads that were > used to execute the (Boost.Function) functions. There is a lot of room > for customization like specifying policies for controlling how/if the > processing thread collection can grow. Unless I'm not understanding precisely what you mean, it sounds like your talking about a "thread_pool", as implemented in the thread_development branch. Could you compare contrast what you have in mind with what's available there? -- William E. Kempf ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: pool benefit ratio for different compilers
> -Original Message- > From: Bohdan [mailto:warever@;mail.i.com.ua] > > <[EMAIL PROTECTED]> wrote in message > news:22602E7E3B92D411969B0090273CC28B1D235F@;cecexchange.cec.je > rviswebb.com... > > As John pointed out, you're not going to see much benefit (if any) when the > > standard library contains a pool allocator itself (as does STLport and > > glibc). > > All boost::pool library is about allocation of small objects > of the same size. I'm just curious how malloc can be > accelerated if it handles different size allocations? Recommended reading: http://gee.cs.oswego.edu/dl/html/malloc.html Doug Lea's malloc uses a technique he calls "binning", which is pool-based support for chunks of certain sizes. -Steve ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Boost.Bind testing patch for Sun
From: "David Abrahams" <[EMAIL PROTECTED]> > > Even after applying other workarounds, the following patch seems to be > required to get the Boost.Bind test to pass on the latest Sun > compilers. Is it appropriate to apply this, or should this problem > cause the test to fail? > > -BOOST_TEST( bind(&X::hash, _1)(x) == 23558 ); > +BOOST_TEST( bind(&X::hash, _1)(x) == 23558 ); I think that the right thing is to #ifdef the bind<> path for Sun only. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Old Dinkum - does boost have (already) a workaround for this?
Hi,
due to the reasons we all know, the old VC6 lib requires at least two
arguments for std::reverse_iterator (the iterator and the
corresponding value_type) instead of one. In fact the definition is:
template
class reverse_iterator : public _Ranit<_Ty, _D> {
public:
typedef reverse_iterator<_RI, _Ty, _Rt, _Pt, _D> _Myt;
typedef _RI iter_type;
typedef _Rt reference_type;
typedef _Pt pointer_type;
Before trying my own one, does boost have already a workaround for
this? What I need is the classical
typedef std::reverse_iterator reverse_iterator;
typedef std::reverse_iterator const_reverse_iterator;
Genny.
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] boost::array and VC7 (oil & water)
unfortunately, the "test case" is (well it was) an operational program to validate the format of some files produced by a product of my client's. The limited "callback" now given in VC7.0 (compared to VC6.0) gives me almost no clue as to what was written to cause the error. I'll see if I can chase it down sometime today. At Monday 2002/11/11 07:20, you wrote: "John Maddock" <[EMAIL PROTECTED]> writes: >> the remaining error is: >> c:\Boost Releases\boost\boost\detail\iterator.hpp(115) : error C2061: >> syntax error : identifier 'value_type' >> c:\Program Files\Microsoft Visual Studio .NET\Vc7\include\xlocmon(227) : >> fatal error C1903: unable to recover from previous error(s); stopping >> compilation >> >> I have NO idea what's causing that. > > Looks like an issue with BOOST_DEDUCED_TYPENAME - Dave? I don't know. What's the test case? If I can reproduce the problem, I can try to track it down. -- David Abrahams [EMAIL PROTECTED] * http://www.boost-consulting.com Boost support, enhancements, training, and commercial distribution ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost Victor A. Wagner Jr. http://rudbek.com PGP RSA fingerprint = 4D20 EBF6 0101 B069 3817 8DBF C846 E47A PGP D-H fingerprint = 98BC 65E3 1A19 43EC 3908 65B9 F755 E6F4 63BB 9D93 The five most dangerous words in the English language: "There oughta be a law" ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Proposed bit_struct submission to Boost
A local business had need of a facility to pack arbitrary-sized bitfields into
exactly 64 bits, with a guarantee of no padding. I wrote this class as a
generalization of that need, and would like your comments as to whether this
would be appropriate for submission to Boost. You can download the source
code, rough draft of documentation, and regression test from
http://www.cs.ndsu.nodak.edu/~kvanhorn/bitstruct.tgz (gzipped tar file)
or
http://www.cs.ndsu.nodak.edu//~kvanhorn/bitstruct.zip (ZIP file).
I have included the rough draft of the documentation below.
---
BITSTRUCT
Explanation
---
Neither C nor C++ provides a portable means of packing integer fields of
arbitrary numbers of bits (up to the largest integer size) into a
struct as compactly as possible, with a known layout. One might think
that bit-fields would do the job, but the C++ Standard makes very few
guarantees about bit-fields. Section 9.6 states, "Allocation of
bit-fields within a class object is implementation-defined. Alignment
of bit-fields is implementation-defined... Note: bit-fields straddle
allocation units on some machines and not on others." For example, suppose
that one defines the following struct with the expectation that it
will all fit into 64 bits, or two words on a 32-bit platform:
struct mystruct {
unsigned a : 3;
unsigned b : 20;
unsigned c : 20;
unsigned d : 10;
unsigned e : 11;
};
On a 32-bit, platform, the layout is quite likely (but not
guaranteed) to be
+--+---++ +---+-+-+
|a |b |unused | |c |d| |
+--+---++ +---+-+-+
+--++
|e |unused |
+--++
with the padding after b and d inserted to avoid bit-fields that
straddle word boundaries.
One therefore has to do one's own bit-twiddling in order to get
bit-fields packed in the desired manner. This is usually done by
defining various macros or inline functions, which can be error-prone and
quite tedious when bit-fields cross word boundaries. Furthermore, if one has
several different bit-field structures, there is no type checking to
ensure that one doesn't apply a macro to the wrong type.
The bit_struct class template is intended to solve this problem. The bit
field sizes and positions are part of the type of the bit_struct, and so it is
impossible to mismatch operations on different kinds of bit-field structures.
Template metaprogramming is used so that all operations are as efficient as
hand-crafted inline functions or macros would be.
Here is the interface:
typedef bit_struct BS;
// REQUIRE: N_i > 0, 0 <= i <= k.
// REQUIRE: (SUM i: 0 <= i <= k: N_i) is a multiple of CHAR_BIT.
// REQUIRE: 0 <= k < MAX_FIELDS, where MAX_FIELDS is currently 8.
zero_fields
// PROMISE: A value of type zero_fields_t
BS x(zero);
// REQUIRE: zero has type zero_fields_t.
// PROMISE: x is initialized with all fields set to zero.
BS x;
// PROMISE: x in valid state, but fields are arbitrary.
BS x(init_arr);
// REQUIRE: init_arr is convertible to type U const * for some integer type U.
// REQUIRE: At most the first N_i bits of init_arr[i] are nonzero.
// PROMISE: field i initialized to value init_arr[i], for 0 <= i <= k.
trunc_field
// PROMISE: A value of type trunc_field_t.
BS x(trunc, init_arr);
// REQUIRE: trunc has type trunc_field_t.
// REQUIRE: init_arr is convertible to type U const * for some integer type U.
// PROMISE: field i initialized to the low-order N_i bits of init_arr[i],
// for 0 <= i <= k.
BS::field
// REQUIRE: 0 <= i < k.
// PROMISE: This is an empty type with the following members:
// type: the value type of bit-field i -- boost::uint_t::fast.
// position: a compile-time integer constant giving the logical
// position of the bit-field in the bit_struct. Its value is
// (SUM j: 0 <= j < i: N_j).
// length: a compile-time integer constant equal to N_i.
BS::num_bits
// PROMISE: A compile-time integer constant equal to (SUM i: 0 <= i <= k:N_i).
BS::num_fields
// PROMISE: A compile-time integer constant equal to k+1 (the # of fields).
BS::uint_type
// PROMISE: An unsigned integer type whose size in bits evenly divides
// BS::num_bits.
BS::num_uints
// PROMISE: A compile-time integer constant equal to
// BS::num_bits / (size of BS::uint_type in bits).
BS::uint_type x.arr[BS::num_uints];
// Sole data member; representation of bit_struct.
x.put(field, val);
// REQUIRE: field has type BS::field for some i <= k.
// REQUIRE: val has type convertible to boost::uint_t::fast.
// REQUIRE: at most first N_i bits of val are nonzero.
// PROMISE: field i receives value val_i; other fields are unchanged.
x.put(trunc, field, val);
// REQUIRE: trunc has type trunc_field_t.
// REQUIRE: field has type BS::field for some i <= k.
RE: [boost] Pool Iterators?
> I'm using boost::pool for (evidently) allocating memory for a whole > bunch of objects (thanks Stephen Cleary for pool). Most of the time the > objects are entirely independent, however, from time to time, I'd like > to iterate through all the allocated objects (in this case to generate > some test statistics over then). To do this I keep a list of pointers > to everything I've allocated. The time spent keeping this list up to > date, particularly removing an object, is significant. > > One possible (and very nice fix) would be to have a pool_iterator that > let me, as I said, iterated through the allocated objects. As far as I > can tell, this doesn't exist. Does anyone have any comments on whether > this is a good idea, whether it's feasible, and perhaps how I might go > about it? One possibility is to write an object type that sits between your object and the pool allocator, which adds a single pointer to your object. Something similar to what a doubly-linked list container would do when rebinding its Allocator. This gives you the ability to iterate over them, and also allows fast insertion and deletion. A similar approach, if you're willing to more seriously change the code that allocates/deallocates the objects, is to keep a doubly-linked list of pointers to the allocated objects. But then reference the objects indirectly through iterators of that list. If you reference them in this way, then deletion should be fast. > The pools don't seem to have a bit-map of free blocks - and traversing > the free list at every increment would be horribly slow. I have a > "holey_vector" that uses a vector as storage, and keeps a sorted list of > free indexes, but I can't imagine this approach would work in a pool, > where the storage is a list of blocks at non-increasing addresses. > Marking blocks as free at the beginning of the block would take up at > worst a whole alignment worth of memory, kind of defeating the point of > the pool. > > So I'm guessing the best approach would be a bit map of free blocks. > Comments? I think that if you want to iterate over allocated objects, then keeping a list of allocated objects is the best bet (whether it's a list of allocated objects or a list of pointers to allocated objects). -Steve ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] BOOST_HAS_NRVO
David Abrahams wrote: > > Daniel Frey <[EMAIL PROTECTED]> writes: > > > That was me, although I have no CVS write access > > Why don't we just fix that? What's your SourceForge UserID? dfrey42 Seems I have something to do for my 56K modem this evening - and I have to read some docs on CVS branches... :o) Thanks! Regards, Daniel -- Daniel Frey aixigo AG - financial training, research and technology Schloß-Rahe-Straße 15, 52072 Aachen, Germany fon: +49 (0)241 936737-42, fax: +49 (0)241 936737-99 eMail: [EMAIL PROTECTED], web: http://www.aixigo.de ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: function redesign for dynamic_any
Douglas Gregor wrote:
> On Monday 11 November 2002 08:32 am, Alexander Nasonov wrote:
>> Additionally, two types of control are desired:
>> 1) Control over real types of arguments. It is a limitation of
>> dynamic_any library that arguments must be converted to _one_ type before
>> a call. But they can be of different types. Problem can be easily solved
>> by adding additional arguments to the 'call' member-function:
>>
>> template
>> bool less::call(const Arg & a, const std::type_info & ta,
>> const Arg & b, const std::type_info & tb) const
>> {
>> return a < b;
>> }
>
> I'm not sure I see why we need this functionality, but perhaps I'm not
> being imaginative enough at this hour. Do you have an example where this
> would help?
It was at the end of my post.
I know how it's hard to understand details without sufficient knowledge of
the topic. I tried to start documentation but it still unusable.
This functionality can be usefull but not quite often. I think it's better
to keep 'call' member function for simple use and introduce different name
(call_ex?) for advanced use. So, you can use one of:
// 1)
template
bool call(const Arg & a, const Arg & b) const;
// 2
template
bool call_ex(const Arg & a, const std::type_info & ta,
const Arg & b, const std::type_info & tb) const;
Implementation can first try to call 'call_ex' and if it throws internal
exception (default behavoir) then revert to 'call' member-function.
Some further thoughts and questions.
1. Support for N-unary functions (currently N=1,2). With increase of N
complexity is aslo increased. Imagine that you have N 'any' arguments a1
... aN that hold values v1 ...vN of type T1 .. TN and you would like to
call a foo defined as:
struct foo : function
// 'const arg &' repeated N times
{
template
void call_ex(const Arg & v1, const std::type_info &,
...
const Arg & vN, const std::type_info &) const
{
// user defined implementation
}
};
Current algorithm takes first argument a1 (which holds value v1 of type T1)
and tries to extract T1 & from a2 ... aN. If all extractions are ok then
invoke the foo:
foo & func = ...
func.call_ex(v1, typeid(v1),
extract(a2), a2.type(),
...
extract(aN), aN.type());
Otherwise apply the same to a2, ... aN arguments.
Remember that every extract uses dynamic_cast for a hierarchy with multiple
inheritance. Even for small N it can be expensive. Though some optimization
can be made IMHO.
2. Code bloat caused by generation of class hierarchy for every holded type.
This hierarchy is central to implementation and cannot be changed to
something else (but number of virtual functions can be minimized). The only
way is to teach users minimalizm in the library usage.
3. Integration with other libraries such as Serialization, variant and
visitor libraries.
Best regards,
Alexander Nasonov
mailbox: alnsn
server: mail.ru
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: pool benefit ratio for different compilers
<[EMAIL PROTECTED]> wrote in message news:22602E7E3B92D411969B0090273CC28B1D235F@;cecexchange.cec.jerviswebb.com... > As John pointed out, you're not going to see much benefit (if any) when the > standard library contains a pool allocator itself (as does STLport and > glibc). All boost::pool library is about allocation of small objects of the same size. I'm just curious how malloc can be accelerated if it handles different size allocations? May be boost will also need something like that. I understand that "char" can be treated as small object, but i'm not sure if boost::fast_pool_allocator gives any acceleration in this case. regards, bohdan ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] BOOST_HAS_NRVO
Daniel Frey <[EMAIL PROTECTED]> writes: > John Maddock wrote: >> >> Can whoever added this one, please add it to the docs (as a feature macro). > > That was me, although I have no CVS write access Why don't we just fix that? What's your SourceForge UserID? -- David Abrahams [EMAIL PROTECTED] * http://www.boost-consulting.com Boost support, enhancements, training, and commercial distribution ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Serialization Library Review
On Mon, Nov 11, 2002 at 09:07:40AM -0500, David Abrahams wrote: >In this system, we use term "serialization" to mean a system where >the current state of group of objects can be stored to a permanent >medium that may outlast the current program execution. At any later >time an equivalent group of objects can be restored from the >permanent medium. It is the goal of this system to permit this >facility to be included in any C++ program with a minimium of >additional effort. This description seems to indicate that the serialization library is not intended for other uses of serialization than giving an object lifetime beyond that of the program. For instance, serializing an object as a step in preparing it to be transferred to another computer in a distributed program. Is this true, or am I interpreting the text in a too narrow-minded way? -- Mattias Flodin <[EMAIL PROTECTED]> - http://www.cs.umu.se/~flodin/ Room NADV 102 Department of Computing Science Umeå University S-901 87 Umeå, Sweden -- During the Middle Ages, probably one of the biggest mistakes was not putting on your armor because you were "just going down to the corner." -- Jack Handy ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: Property_map docs
Hi Edward, Since you feel so strongly about this, please write a new version of the property map docs and send them to me. In future emails, I would appreciate it if you refrained from using such an accusatory tone. At this point I'm feeling hurt by your words and discouraged about volunteering my time to boost. Sincerely, Jeremy On Mon, 11 Nov 2002, Edward Diener wrote: eddiel> "Jeremy Siek" <[EMAIL PROTECTED]> wrote in message eddiel> news:Pine.GSO.4.44.021110230.4424-10@;zaphod.osl.iu.edu... eddiel> > Hi Edward, eddiel> > eddiel> > On Sun, 10 Nov 2002, Edward Diener wrote: eddiel> > eddiel> OK, here are some questions regarding the property map library; eddiel> > eddiel> eddiel> > eddiel> 1) What is a property map ? Is it a template class, a class, a eddiel> > eddiel> template function, a function ? eddiel> > eddiel> > It is a "concept", as the term is used in the SGI STL docs: eddiel> > http://www.sgi.com/tech/stl/stl_introduction.html eddiel> > It has to do with specifying the contract between generic algorithms eddiel> > (function templates) and the user of such algorithms. eddiel> eddiel> I am aware of your defintion of "concept" from Matt Austern's fine book. But eddiel> concepts imply implementations. eddiel> eddiel> > eddiel> > If you were looking for some useful concrete component to implement some eddiel> > kind of mapping, then I'm afraid you will be disappointed in the property eddiel> > map library. eddiel> eddiel> I am disappointed in the doc. The concept sounds interesting but I have no eddiel> idea how it is implemented or used in a real situation. eddiel> eddiel> > eddiel> > eddiel> 2) What does the word "property" mean in the context of the name ? eddiel> > eddiel> > Here by property we mean something that is associated with some object. I eddiel> > know this is vague, but there just is not much to the property map eddiel> > concept. eddiel> eddiel> Yes, it is vague. Does that make you happy about it ? eddiel> eddiel> > eddiel> > eddiel> 3) What is the difference between property map and std::map<> ? eddiel> > eddiel> > std::map<> is a class. property map is a concept (well, a collection eddiel> > of concepts). You can use the boost::associative_property_map eddiel> > adaptor to adapt std::map<> into a type that *models* property map. eddiel> eddiel> OK, why not explain that in the doc and how it is done. eddiel> eddiel> > eddiel> > eddiel> 4) How does one use a property map ? eddiel> > eddiel> > You write function templates with template parameters that eddiel> > have property map as their requirement. eddiel> eddiel> Example of this in the doc please. eddiel> eddiel> > eddiel> > eddiel> 5) How does one create a property map of one's own ? eddiel> > eddiel> > Create a class and then define get(), put() and operator[] eddiel> > function for the class. eddiel> eddiel> Example of this in the doc please. eddiel> eddiel> > eddiel> > eddiel> 6) What are the prototypes for the get(), put(), and operator[] eddiel> > eddiel> functions, and are these really global functions as the doc eddiel> > eddiel> suggests or are they functions in the boost namespace ? eddiel> > eddiel> > They can live anywhere that argument dependent lookup can find them, which eddiel> > means just about anywhere. eddiel> eddiel> You didn't answer the first question. eddiel> eddiel> > eddiel> > eddiel> 7) What do the various categories actually do for property maps ? eddiel> > eddiel> > Like the iterator tags in the C++ std, they allow function templates to eddiel> > dispatch to different code depending on the category of the property map. eddiel> eddiel> Example of this in the doc please, with some function template showing this eddiel> technique as practical usage within your "concept". eddiel> eddiel> > eddiel> > eddiel> I do not believe that any of these questions are answered clearly eddiel> > eddiel> in the property map documentation although they are all basic eddiel> > eddiel> points which should be explained to the end user. I know there is eddiel> > eddiel> a concept there of mapping keys to values but beyond that the eddiel> > eddiel> documentation seems abstruse at best and needlessly irritating at eddiel> > eddiel> worst. eddiel> > eddiel> eddiel> > eddiel> Please Boosters , think about explaining your ideas to the eddiel> > eddiel> programming world in ways that they understand and can use, rather eddiel> > eddiel> than in metaprogramming terminology which only a select few know. eddiel> > eddiel> Good documentation is as important, in its own way, as good code. eddiel> > eddiel> > I've taken another look at the docs, and I'm afraid I do not see a lot of eddiel> > room for improvement. The docs say pretty much what I said above, and eddiel> > include links to resources where one can learn more about generic eddiel> > programming. eddiel> > eddiel> > The property map library is by nature abstract. The main point of the eddiel> > library is not to provide concrete classes, but instead to describe a
[boost] Problem with , and request for extension
I have found that
boost::uint_t<64>::fast
gives a compiler error even on a platform (RH 7.3 on Intel) that has
64-bit integers available (as long long). On checking the documentation
again, it does specify this behavior, but this strikes me as quite
unreasonable; if a platform has long long, I should be able to use it.
I believe that all that is needed to fix this is inclusion of the
following lines:
#ifdef BOOST_HAS_LONG_LONG
template <> struct int_least_helper<0>
{ typedef long long least; };
#endif
#ifdef BOOST_HAS_LONG_LONG
template <> struct int_least_helper<5>
{ typedef unsigned long long least; };
#endif
Also, I'd like to see the following added to :
boost::signed_int::type -- Gives the signed integer type of the same
size as integer type T.
boost::unsigned_int::type -- Gives the unsigned integer type of the
same size as integer type T.
Rationale: I often find myself using
std::iterator_traits::difference_type
for quantities that are guaranteed to be nonnegative; for these I would
prefer to use an unsigned type.
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Proposed Boost Assert -- once again
It's been six days since I posted this, without a single response, so I'm going to try again. Based on earlier discussions, I thought there might be some interest in this. Does anyone have any problems with the proposed interface? Should I turn this into a formal proposal for submission to Boost? Peter, how does this compare with the changes to you were planning to do / are doing? -- I've taken the existing (but not documented for external use) that Peter Dimov wrote, and have modified/extended it to have the facilities that I would like to see. You can download my code from http://www.cs.ndsu.nodak.edu/~kvanhorn/boost_assert.tgz (gzipped tar format) or http://www.cs.ndsu.nodak.edu/~kvanhorn/boost_assert.zip (ZIP format). These packages include documentation and fairly extensive regression tests. Unfortunately, the tests are not fully portable, as they rely on shell scripts. I haven't yet taken a look at how the existing Boost regression tests manage portability; some issues are the need to run a program and test its output and exit status. Here's a very rough cut at the documentation: -- Header file: Purpose: to provide flexible alternative to assert() that allows the applications programmer to customize what happens when an assertion is found false, while making it easy to specify the most commonly desired behaviors. This facility is intended to be lightweight, with minimal dependencies on the rest of Boost or parts of the Standard Library that tend to bloat the size of executables. Definition: A static string is a value implicitly convertible to a const char * value that is either null or points to a null-terminated char array that remains valid and unchanged for the lifetime of the program. String literals and pointers to static const char arrays are examples. Components provided for users: - Class failed_assertion. - failed_assertion(char const * expr, char const * msg, char const * fct, char const * file, unsigned line); - PURPOSE: Indicates that an assertion with textual representation expr failed, at the indicated line number and file, within function fct. The string msg is additional information explaining the error. - REQUIRES: expr, msg, fct, and file are static strings. - REQUIRES: expr, fct, and file are non-null. (msg may be null.) - copy ctor, copy assign, public dtor also provided. - Public data members char const * assert_expression; char const * message; char const * function_name; char const * file_name; unsigned line_number; - Type assert_handler_t. This is a typedef for bool (*)(char const * expr, char const * msg, char const * func, char const * file, unsigned line, bool throw_exception) - expr is the text of the failed assertion. - msg is any additional text explaining the error. - func, file, and line are the function, file name, and line number at which the error occurred. - throw_exception indicates whether the user has indicated a preference for an exception to be thrown when an assertion fails. - Function assert_handler_t set_assert_handler(assert_handler_t h). Returns the old assert handler and sets h as the new assert handler. Initially there is no assert handler (null function pointer). See BOOST_ASSERT_MSG below for how the assert handler is used. - Macro BOOST_ASSERT_THROWS_FLAG. - Value is true if BOOST_ASSERT_THROWS is defined, false otherwise. - Macro BOOST_ASSERT_MSG(e, msg). - If BOOST_DEBUG is not defined, this is a no-op. - Otherwise, if user has already provided a definition for BOOST_ASSERT_MSG, the definition is left unchanged. - Otherwise, - If there is an assert handler h, calls h with BOOST_ASSERT_THROW_FLAG as the throw_exception argument. - If there is no assert handler, or if it returns true, then - if BOOST_ASSERT_THROWS is defined, throw a failed_assertion exception; - otherwise, print an error message to stderr and abort. - msg is a static string that provides additional explanation of the error; it may be null. - e may be evaluated more than once. - Macro BOOST_ASSERT(e) - If BOOST_DEBUG is not defined, this is a no-op - Otherwise, if user has already provided a definition for BOOST_ASSERT, the definition is left unchanged. - Otherwise, equivalent to BOOST_ASSERT_MSG(e, 0) Symbols that may be defined by users: - BOOST_DEBUG. If not defined, then BOOST_ASSERT(e) and BOOST_ASSERT_MSG(e, msg) are no-ops. This symbol is #undef'd if NDEBUG is defined. - BOOST_ASSERT_MSG(e, msg). Users may provide their own definition of this macro, which will override the definition in . - BOOST_ASSERT(e). Users may provide their own definition of this macro, which will override the definition in - BOOST_ASSERT_THROWS. If defined, then
Re: [boost] boost::array and VC7 (oil & water)
"John Maddock" <[EMAIL PROTECTED]> writes: >> the remaining error is: >> c:\Boost Releases\boost\boost\detail\iterator.hpp(115) : error C2061: >> syntax error : identifier 'value_type' >> c:\Program Files\Microsoft Visual Studio .NET\Vc7\include\xlocmon(227) : >> fatal error C1903: unable to recover from previous error(s); stopping >> compilation >> >> I have NO idea what's causing that. > > Looks like an issue with BOOST_DEDUCED_TYPENAME - Dave? I don't know. What's the test case? If I can reproduce the problem, I can try to track it down. -- David Abrahams [EMAIL PROTECTED] * http://www.boost-consulting.com Boost support, enhancements, training, and commercial distribution ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] function redesign for dynamic_any
On Monday 11 November 2002 08:32 am, Alexander Nasonov wrote:
> struct less : function
> {
> template
> bool operator()(const Arg & a, const Arg & b) const
> {
> return a < b;
> }
> };
I like this a lot.
> Additionally, two types of control are desired:
> 1) Control over real types of arguments. It is a limitation of dynamic_any
> library that arguments must be converted to _one_ type before a call. But
> they can be of different types. Problem can be easily solved by adding
> additional arguments to the 'call' member-function:
>
> template
> bool less::call(const Arg & a, const std::type_info & ta,
> const Arg & b, const std::type_info & tb) const
> {
> return a < b;
> }
I'm not sure I see why we need this functionality, but perhaps I'm not being
imaginative enough at this hour. Do you have an example where this would
help?
> 2) Controlled behavior when the call cannot be made. I propose to make it
> over 'nocall' member-function. Default handler can be implemented inside
> the 'function' as a single throw statement. Those users who wish other
> behavior can override 'nocall'.
Sounds good.
>
> How do you like it?
Very much. This is a big step toward making it easier to construct polymorphic
adaptors.
Doug
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Possible Errors in Boost Config (mostly documentation)
At 06:50 AM 11/11/2002, John Maddock wrote: >> 3. BOOST_COMPILER_VERSION is defined in the config headers, but is >> undocumented and unused. > >Good point, I think that Beman added this one for a couple of compilers in >order that BOOST_COMPILER would give more readable output - in other words >it's an internal detail, no documentation needed, you shouldn't use it. That's correct, IIRC. --Beman ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Serialization Library Review
This is a belated announcement that the review period of Robert Ramey's Serialization Library, which runs from 9 November to 18 November, has started. Here is an introductory paragraph describing the library, from its documentation. In this system, we use term "serialization" to mean a system where the current state of group of objects can be stored to a permanent medium that may outlast the current program execution. At any later time an equivalent group of objects can be restored from the permanent medium. It is the goal of this system to permit this facility to be included in any C++ program with a minimium of additional effort. Here's a reminder of what to include in your review comments: Your comments may be brief or lengthy, but basically the Review Manager needs your evaluation of the library. If you identify problems along the way, please note if they are minor, serious, or showstoppers. Here are some questions you might want to answer in your review: What is your evaluation of the design? What is your evaluation of the implementation? What is your evaluation of the documentation? What is your evaluation of the potential usefulness of the library? Did you try to use the library? With what compiler? Did you have any problems? How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? Are you knowledgeable about the problem domain? And finally, every review should answer this question: Do you think the library should be accepted as a Boost library? Be sure to say this explicitly so that your other comments don't obscure your overall opinion. You can download the library submission from http://groups.yahoo.com/group/boost/files/serialization6.zip -- David Abrahams [EMAIL PROTECTED] * http://www.boost-consulting.com Boost support, enhancements, training, and commercial distribution ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] N1398: Proposal for adding random numbers to the standardlibrary
At 04:07 PM 11/10/2002, Jens Maurer wrote: >Jens Maurer wrote: >> >> I've checked in my paper N1398 to libs/random/wg21-proposal.html >> This will be in the post-Santa Cruz mailing of the ISO C++ >> committee and will form the basis for discussion at the next >> meeting in Oxford, England. >> >> Thanks to all who offered comments and suggestions. > >I forgot: The modifications to Boost.Random so that it is >compatible with the specification are not yet checked in, >since the structure of the end-user interface has been changed >slightly. > >How should I proceed? It isn't just your random proposal. Every proposal will probably have at least minor changes compared to the Boost version. Regex has some fairly major interface changes, IIRC. Furthermore, the committee may change the interface yet again during the TR process. Some developers may just want to change their current Boost library to conform with the TR. Others may want to support both versions for a time. Howard Hinnant has suggested the library TR use namespace std::tr (or similar), so that if further interface changes are needed at the time of the next standard, implementors won't be forced to break existing user code. Boost might want to consider something similar, although I'm unsure of the details of how that might work. --Beman ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: BOOST_HAS_NRVO
Gennaro Prota wrote: > > On Mon, 11 Nov 2002 10:36:57 +0100, Daniel Frey > <[EMAIL PROTECTED]> wrote: > > >I agree to the rest > >of the discussion that this should be stable and independent of compiler > >flags. > > But are you speaking in general or for the sake of the test? :-) I was only refering to the test Terje provided. Regards, Daniel -- Daniel Frey aixigo AG - financial training, research and technology Schloß-Rahe-Straße 15, 52072 Aachen, Germany fon: +49 (0)241 936737-42, fax: +49 (0)241 936737-99 eMail: [EMAIL PROTECTED], web: http://www.aixigo.de ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] pool benefit ratio for different compilers
> Can anybody shed light on why fast_pool_allocator benefit ratio is so different > for different compilers ? It's because the malloc() and new speeds differ by compiler. If you're really interested, there's an outdated article in WDJ April '97 that compares malloc() and new speeds of several compilers: VC++ 4.2 was slowest, Borland C++ 5.1 was faster, and Watcom C++ 10.6 and Symantec C++ 7.2 the fastest. Of course, these are all *old* compilers! :) As John pointed out, you're not going to see much benefit (if any) when the standard library contains a pool allocator itself (as does STLport and glibc). -Steve ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] 'function' idea
On Monday 11 November 2002 04:56 am, Aleksey Gurtovoy wrote:
[snip my limited example]
> Hmm, interesting, so if this actually worked, we would be happy:
>
[snip nifty-looking is_callable implementation]
>
> ?
Well, you need to do some trickery to make it work when R=void, but otherwise
I think we would be _very_ happy if this worked. Is there a tweak to the core
language that would guarantee such a thing?
> > The reason I mention is_instantiable instead of __is_well_formed
> > is that is_instantiable can keep a class template interface, whereas
> > __is_well_formed would require a new grammar production.
>
> From http://aspn.activestate.com/ASPN/Mail/Message/1412095 I've got an
> impression that implementors are not too concerned about it.
>
> After all, '__is_well_formed' might be as easy to implement as this:
>
> void process_is_well_formed( args )
> {
> try
> {
> process_sizeof( args );
> args.expression_result = true;
> }
> catch (compiler_error const& )
> {
> args.expression_result = false;
> }
> }
>
> :)
At one time in GCC, checking for compilability was as easy as:
cp_silent++;
// instantiate the thing you want to check
cp_silent--;
Doug
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: BOOST_HAS_NRVO
On Mon, 11 Nov 2002 10:36:57 +0100, Daniel Frey
<[EMAIL PROTECTED]> wrote:
>I agree to the rest
>of the discussion that this should be stable and independent of compiler
>flags.
But are you speaking in general or for the sake of the test? :-)
Because in the latter case it's quite obvious. In the former, this is
a better argument to disagree with my disagreement: suppose the
function f() is in a pre-compiled library. Now, go down to the
implementation level and think of the possible calling conventions
class A {};
A f();
A a = f();
That begins to be off-topic though (and beyond the scope of the
standard), so I will not go on.
Genny.
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] boost::array and VC7 (oil & water)
> the remaining error is: > c:\Boost Releases\boost\boost\detail\iterator.hpp(115) : error C2061: > syntax error : identifier 'value_type' > c:\Program Files\Microsoft Visual Studio .NET\Vc7\include\xlocmon(227) : > fatal error C1903: unable to recover from previous error(s); stopping > compilation > > I have NO idea what's causing that. Looks like an issue with BOOST_DEDUCED_TYPENAME - Dave? John Maddock http://ourworld.compuserve.com/homepages/john_maddock/index.htm ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] BOOST_HAS_NRVO
>That was me, although I have no CVS write access and Dave applied the >patch. Anyway, I will prepare a patch for >http://www.boost.org/libs/config/config.htm#user_settable when I have >some time. Anything else that needs to be done? I don't think so, I'll apply the test program and some minimal docs when I get a chance, I still worry that the test may only work for some compiler settings, and that would really mess up the config regression tests, but I guess we'll see :-) > Is it possible to test for this? If so can a test program be supplied > please - the test program should compile and run only if the feature is > available - see one of the boost_has_XXX.cxx files for examples. >AFAICS, Terje's program is correctly detecting it. I agree to the rest >of the discussion that this should be stable and independent of compiler >flags. The "broken" NRVO of the Intel compiler is not a problem for >operators.hpp, as it returns 'T' instead of 'const T', so the test >matches the current use of the NRVO. Thanks Terje. OK good. Thanks, John Maddock http://ourworld.compuserve.com/homepages/john_maddock/index.htm ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] boost::array and VC7 (oil & water)
> Yup, this works > #elif defined(BOOST_MSVC) && (BOOST_MSVC == 1300) && > defined(BOOST_DINKUMWARE_STDLIB) && (BOOST_DINKUMWARE_STDLIB == 310) > > I'd check it in, but I haven't write access to the repository. > I still have the problem in ONE of my programs. I've changed to: #elif defined(_MSC_VER) && (_MSC_VER == 1300) && defined(BOOST_DINKUMWARE_STDLIB) && (BOOST_DINKUMWARE_STDLIB == 310) Which is working for all the array test programs that VC7 can handle, and should work for Intel C++ as well (the previous version wouldn't have), BTW I don't want to check for BOOST_DINKUMWARE_STDLIB on it's own as this can be set on non-Wintel platforms as well. What else is still failing? John Maddock http://ourworld.compuserve.com/homepages/john_maddock/index.htm ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] function redesign for dynamic_any
I'm trying to redesign functions for dynamic_any. Currenly, I have this:
struct less : function_vv
{
template
bool operator()(const T & a, const T & b) const
{
return a < b;
}
};
Two trailing 'v' in function_vv are indicators that less accepts two
arguments by value or const reference. First change I'm going to make is to
remove these trailing letters and to introduce more natural syntax (idea is
taken from Boost.Function):
struct less : function
{
template
bool operator()(const Arg & a, const Arg & b) const
{
return a < b;
}
};
The 'arg' is a placeholder for pseudo-template parameter. Compare it with
Arg defined in less::operator() and with less::operator() signature.
This change doesn't solve other problem: using of a 'call' function:
using namespace boost;
using namespace boost::dynamic_any;
any > a, b;
bool result = call(less(), a, b); // here is a problem
I would like it to be:
any > a, b;
bool result = less()(a, b); // much better
Curiously recurring pattern suits fine here. Let the class template
'function' to accept end function (less in our case). Call operator that
takes two 'any' values can be implemented inside the 'function' (constness
of arguments leaved apart for simplicity):
template
struct function
{
template
typename function_result::type
operator()(any & a, any & b)
{
// implementation
}
// implementation
};
But it will be hidden by the call operator defined in EndFunction.
EndFunction::operator() should be renamed:
struct less : function
{
// note the name
template
bool call(const Arg & a, const Arg & b) const
{
return a < b;
}
};
Additionally, two types of control are desired:
1) Control over real types of arguments. It is a limitation of dynamic_any
library that arguments must be converted to _one_ type before a call. But
they can be of different types. Problem can be easily solved by adding
additional arguments to the 'call' member-function:
template
bool less::call(const Arg & a, const std::type_info & ta,
const Arg & b, const std::type_info & tb) const
{
return a < b;
}
2) Controlled behavior when the call cannot be made. I propose to make it
over 'nocall' member-function. Default handler can be implemented inside
the 'function' as a single throw statement. Those users who wish other
behavior can override 'nocall'.
As a summary I can demonstrate less function that compares first by type and
then by value:
struct less : function
{
template
bool call(const Arg & a, const std::type_info & ta,
const Arg & b, const std::type_info & tb) const
{
return (ta == tb) ? (a < b) : ta.before(tb);
}
template
bool nocall(const any & ta,
const any & tb) const
{
return a.type().before(b.type());
}
};
// Example:
typedef any > any_less;
std::vector v = get_it();
std::sort(v.begin(), v.end(), less());
How do you like it?
Best regards,
Alexander Nasonov
mailbox: alnsn
server: mail.ru
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Possible Errors in Boost Config (mostly documentation)
> I found some documentation problems in the Boost Configuration > Reference, and possibly some obsolete symbols in the configuration > headers. These comments all apply to the boost_1_29_0 release. Here > are the specifics: Thanks! > 1. The config headers may define > > BOOST_NO_STD_WSTREAMBUF > > which is not mentioned in the documentation; however, the documentation > mentions > > BOOST_NO_STD_WSTREAM > > which is not defined in any config header, but is used in > > > libs/format/test/format_test1.cpp I think we ended up changing the name at some point - it needs to be changed to BOOST_NO_STD_WSTREAMBUF throughout. > 2. No config header defines BOOST_HAS_PTHREAD_YIELD, although it is > described in the documentation. It is used in some tests and one place > in Boost Threads. I think pthread_yield is only required on some obsolete unix systems, most now have the POSIX standard sched_yield. The configure script will pick this one up if the platform requires it. > 3. BOOST_COMPILER_VERSION is defined in the config headers, but is > undocumented and unused. Good point, I think that Beman added this one for a couple of compilers in order that BOOST_COMPILER would give more readable output - in other words it's an internal detail, no documentation needed, you shouldn't use it. > 4. BOOST_DECL is defined in the config headers, but is undocumented and > unused except in test libs/config/test/config_info.cpp. These are a hang up from the previous config system, I think that the only code that used them has now been removed, so unless anyone objects I'll remove these > 5. BOOST_HAS_MPTASKS is defined in the config headers, but is > undocumented. It is used only in Boost Threads. Can whoever is responsible for that one please supply docs and a test case? > 6. BOOST_NO_CWTYPE is defined in the config headers, but is undocumented > and unused. Thanks: it's typo in the one place it appears: it should be BOOST_NO_CWCTYPE > 7. BOOST_STD_EXTENSION_NAMESPACE is defined in the config headers and > widely used, but is undocumented. I'll get it added, thanks. > 8. The documentation states, in guidelines to Boost authors, > > "Boost files that use macros defined in should have > sensible, standard conforming, default behavior if the macro is not > defined. This means that the starting point for porting > to a new platform is simply to define nothing at all > specific to that platform. In the rare case where there is no sensible > default behavior, an #error message should describe the problem." > > Aren't there some macros, such as BOOST_STATIC_CONSTANT, > BOOST_USE_FACET, BOOST_NESTED_TEMPLATE, etc., that you can count on > always being defined to something, even on (the mythical) fully > standard-conforming platforms? Yes, the inevitable exceptions :-) These all get defined to sensible defaults in suffix.hpp if they're not otherwise defined, they're exceptions because they simplify code, rather than going through the usual: #ifdef SOMTHING .. code #else ... code #endif all over the place. John Maddock http://ourworld.compuserve.com/homepages/john_maddock/index.htm ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] 'function' idea
Douglas Gregor wrote:
> Yep. We just need:
>
> template T get();
>
> template typename TN>
> struct is_callable :
>
> mpl::bool_c<__is_well_formed(static_cast(get()(get(),
> get(), ..., get(>
> {
> };
Hmm, interesting, so if this actually worked, we would be happy:
#include "boost/static_assert.hpp"
typedef char (&no_tag)[1];
typedef char (&yes_tag)[2];
template< long > struct sink { typedef sink type; };
template T get();
template< typename Functor, typename R, typename T1 >
no_tag is_callable_helper(...);
template< typename Functor, typename R, typename T1 >
yes_tag is_callable_helper(
typename sink<
sizeof(static_cast(get()( get() )))
>::type*
);
template<
typename Functor, typename R, typename T1
>
struct is_callable
{
BOOST_STATIC_CONSTANT(bool
, value = sizeof(is_callable_helper(0))
== sizeof(yes_tag)
);
};
struct her {};
struct my { int operator()(int); };
BOOST_STATIC_ASSERT((!is_callable::value));
BOOST_STATIC_ASSERT((!is_callable::value));
BOOST_STATIC_ASSERT((is_callable::value));
?
>
> The reason I mention is_instantiable instead of __is_well_formed
> is that is_instantiable can keep a class template interface, whereas
> __is_well_formed would require a new grammar production.
>From http://aspn.activestate.com/ASPN/Mail/Message/1412095 I've got an
impression that implementors are not too concerned about it.
After all, '__is_well_formed' might be as easy to implement as this:
void process_is_well_formed( args )
{
try
{
process_sizeof( args );
args.expression_result = true;
}
catch (compiler_error const& )
{
args.expression_result = false;
}
}
:)
Aleksey
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] BOOST_HAS_NRVO
John Maddock wrote: > > Can whoever added this one, please add it to the docs (as a feature macro). That was me, although I have no CVS write access and Dave applied the patch. Anyway, I will prepare a patch for http://www.boost.org/libs/config/config.htm#user_settable when I have some time. Anything else that needs to be done? > Is it possible to test for this? If so can a test program be supplied > please - the test program should compile and run only if the feature is > available - see one of the boost_has_XXX.cxx files for examples. AFAICS, Terje's program is correctly detecting it. I agree to the rest of the discussion that this should be stable and independent of compiler flags. The "broken" NRVO of the Intel compiler is not a problem for operators.hpp, as it returns 'T' instead of 'const T', so the test matches the current use of the NRVO. Thanks Terje. Regards, Daniel -- Daniel Frey aixigo AG - financial training, research and technology Schloß-Rahe-Straße 15, 52072 Aachen, Germany fon: +49 (0)241 936737-42, fax: +49 (0)241 936737-99 eMail: [EMAIL PROTECTED], web: http://www.aixigo.de ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: Property_map docs
for some reason that I can't really put my finger on, I found your reply offensive. At Sunday 2002/11/10 23:19, you wrote: "Jeremy Siek" <[EMAIL PROTECTED]> wrote in message news:Pine.GSO.4.44.021110230.4424-10@;zaphod.osl.iu.edu... > Hi Edward, > > On Sun, 10 Nov 2002, Edward Diener wrote: > eddiel> OK, here are some questions regarding the property map library; > eddiel> > eddiel> 1) What is a property map ? Is it a template class, a class, a > eddiel> template function, a function ? > > It is a "concept", as the term is used in the SGI STL docs: > http://www.sgi.com/tech/stl/stl_introduction.html > It has to do with specifying the contract between generic algorithms > (function templates) and the user of such algorithms. I am aware of your defintion of "concept" from Matt Austern's fine book. But concepts imply implementations. I don't believe I've read Matt Austern's fine book, so I can't compare his concept of concept with what I get from reading Jeremy's documentation. I will point out that simply because concepts imply implementations (a premise I'm not sure I accept), doesn't mean that any implementations actually exist. There ARE some examples of implementations of this concept, but I don't see how that's relevent to the discussion of a concept itself. > > If you were looking for some useful concrete component to implement some > kind of mapping, then I'm afraid you will be disappointed in the property > map library. I am disappointed in the doc. The concept sounds interesting but I have no idea how it is implemented or used in a real situation. It is a valid complaint that you don't know how to USE the concept, but not that you cannot implement it. > > eddiel> 2) What does the word "property" mean in the context of the name ? > > Here by property we mean something that is associated with some object. I > know this is vague, but there just is not much to the property map > concept. Yes, it is vague. Does that make you happy about it ? What does Jeremy's happiness have to do with the value of the documentation? Abstract things simply aren't concrete. How concrete an explanation is possible? > > eddiel> 3) What is the difference between property map and std::map<> ? > > std::map<> is a class. property map is a concept (well, a collection > of concepts). You can use the boost::associative_property_map > adaptor to adapt std::map<> into a type that *models* property map. OK, why not explain that in the doc and how it is done. I believe the example code does exactly what you ask. > > eddiel> 4) How does one use a property map ? > > You write function templates with template parameters that > have property map as their requirement. Example of this in the doc please. While I'm also curious how to write (function/class) templates with parameters that have requirements, I'm not sure that THIS document is the proper place for that information. > > eddiel> 5) How does one create a property map of one's own ? > > Create a class and then define get(), put() and operator[] > function for the class. Example of this in the doc please. You know, if every document we ever have stood by itself and went all the way down to "basics" (whatever those are...do we need to go down to the 1's and 0's of some extant machine to satisfy your requirment?), documentation would be MUCH larger than it is now. Fortunately we normally get to _refer_ to other things and we figure the average reader can understand what's being said (or written). > > eddiel> 6) What are the prototypes for the get(), put(), and operator[] > eddiel> functions, and are these really global functions as the doc > eddiel> suggests or are they functions in the boost namespace ? > > They can live anywhere that argument dependent lookup can find them, which > means just about anywhere. You didn't answer the first question. although they weren't explicitly shown "in the doc" they are certainly visible by their use in the function foo do you really need a more formal declaration of their prototypes? > > eddiel> 7) What do the various categories actually do for property maps ? > > Like the iterator tags in the C++ std, they allow function templates to > dispatch to different code depending on the category of the property map. Example of this in the doc please, with some function template showing this technique as practical usage within your "concept". Again, I don't think that all documents need to show everything expecially if other examples already exist. Did you go look at any usages of iterator tags? > > eddiel> I do not believe that any of these questions are answered clearly > eddiel> in the property map documentation although they are all basic > eddiel> points which should be explained to the end user. I know there is > eddiel> a concept there of mapping keys to values but beyond that the > eddiel> documentation seems abstruse at best and needlessly irritating at > eddiel> worst. > eddi
[boost] Sandbox I/O docs
I finally added documentation for the I/O libraries in the Sandbox. Check it out! Daryle ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
