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
[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
[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:
templatetypename Arg
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)
templatetypename Arg
bool call(const Arg a, const Arg b) const;
// 2
templatetypename Arg
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 : functionfoo, void (const arg , , const arg )
// 'const arg ' repeated N times
{
templateclass Arg
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),
extractT1 (a2), a2.type(),
...
extractT1 (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: Proposed Boost Assert -- once again
I've always used the examples out of TC++PL of some assertions:
template typename Exception
assertion (bool const condition) {
if (!condition) {
throw Exception ();
}
}
template typename Exception
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 typename Function
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 typename Condition, typename Exception
Condition const assertNonZero (Condition const condition) {
if (0 == condition) {
throw Exception ();
}
return condition;
}
Consider:
return x / assertNonZerorange_error (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
boost/assert.hpp you were planning to do / are doing?
___
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
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( bindunsigned int(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] 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] 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] 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( bindunsigned int(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] 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
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 class Generator typename generator_iterator_generatorGenerator::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: 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) templatetypename Arg bool call(const Arg a, const Arg b) const; // 2 templatetypename Arg 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] 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
[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
[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 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
[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] 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
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: 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: 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 algebraic data types, modal/temporal logic, process algebras, whatever). The understanding
