Boost logo

Boost :

From: Edward Diener (eddielee_at_[hidden])
Date: 2002-11-14 16:23:10


OK, I completely missed the fact that there is just a concept there and not
an implementation. I mistakenly believed that some implementation was behind
this rather than just a generalized "here are the ideas, generalized
functions and classes, and types recommended, now make it work for you if
you like the concept of it." I don't see the point of that without some
actual reality of how it all comes together but that's fine with me and my
practical bent in this matter is evidently wrong for the situation.

Even in the case of STL iterators as the glue between algorithms and
containers, there is the proviso that if one creates an iterator for a
container of a particular category which follows certain implementation
details, then this will work for certain algorithms which expects that
"type" of iterator. So there is some reality behind it in the form of
algorithms which exhibit functionality in the STL. Naturally to me I thought
there has to be some get(), put(), operator[] reality behind property map to
make the concepts work. I didn't realize that this reality was up to the
implementor to write for his own property map. I admit that I don't see how
anyone can infer that from the docs, but evidently others understand all
this immediately and see the doc as being transparent in this regard.

I would still say to anyone willing to listen that the doc should spell this
out, ie. "all these concepts are for you the implementor to put together to
create the generic functions that work using the categories mentioned. There
is no implementation here." If I had read that I might still have been
interested in the concepts as pure ideas, but I would have probably moved on
pretty quickly, or further looked into the BGL to see what was a practical
implementation of this concept, but I would not have posted anything here
regarding the doc which I clearly didn't understand and couldn't make heads
or tails out of. It was my frustration about reading the pieces of what I
though was an implementation, and not having any idea how these pieces were
supposed to fit together to form some sort of reality, that led to my
frustration and initial post.

"David B. Held" <dheld_at_[hidden]> wrote in message
news:ar11in$b9j$1_at_main.gmane.org...
> Edward Diener wrote:
>
> > [...]
> > 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.
>
> But not necessarily that one could understand how it works the first
> time you looked at the docs. I have a modern physics textbook from a
> class I took in college. I like to read it now and then. But I can
> turn to any number of chapters, read them five times, and still have no
> meaningful understanding of what is written. The text is not poorly
> written, and I am not an idiot (though I might have a hard time finding
> people to vouch for that!). The problem is that I have weak calculus
> skills, and not enough physics background for the book to be more
> comprehensible. Sometimes, I just like to read the sidebars that
> describe an application of the principles to a real problem, and pretend
> that I understand what's going on. Since I'm not a mathematical
> prodigy, it is not feasible for me to read a bunch of PDEs and say:
> "Well, duh! That's obvious!" In the same way, my understanding is that
> the Property Map library is not a library like the RegEx library. There
> are no headers to be included, and no source files to be built, any more
> than the Iterator concept requires headers or source files. etc.


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk