[Boost-users] Re: [BGL] forced client complexity

From: Christopher D. Russell (cdr_at_[hidden])
Date: 2004-03-31 12:46:33

A well written critique. I had to go look up the word "prolix" (i.e.
verbose). In defense of BGL:

I am no BGL expert despite having read the book several times and writing a
complex client application that uses dozens of different graph types. I
admit, it was some hard work getting going with BGL. However, this is because
I didn't know C++ templates nearly as well as I thought I did.

Certainly there's nothing in the library that would preclude anyone from
writing simpler BGL-derived classes that offer solutions that are packaged to
solve specific problems. Post specific problems and people will help.

> It is difficult for me to assess whether the
> simplicity I yearn for isn't present for stylistic
> reasons or whether it would rather necessitate a
> sacrifice of flexibility, functionality or
> implementation clarity.

Having become baseline proficient with BGL, I would disagree that it's overly
complex. To me BGL is an elegant solution to a class of very complex problems
that strikes a reasonable balance between complexity and flexibility. In my
opinion, if you frequently use graphs BGL is well worth the investment
required to learn how to use it.

- Chris

"Provisional Dissonance" <prosonance_at_[hidden]> wrote in message
news:20040331094800.93338.qmail_at_web60105.mail.yahoo.com...
> If one accepts the axiom that "a picture is worth a
> thousand words," then it naturally follows that
> discussion of graphs is always overly prolix. Sadly,
> the same reasoning is also applicable to the code of
> graph libraries.  Boost.Graph seems to expose and
> require an unnecessarily large amount of complexity,
> though.  Whereas libraries like Spirit go to great
> lengths to make hard things easy, BGL seems to try
> only to make hard things possible.  The amount of
> scaffolding required to use BGL for even the simplest
> of projects often dwarfs the code size of a naive, yet
> functional, special-purpose implementation.
>
> While I understand that the BGL is deeply entrenched
> in boost culture, certain academic circles, and even
> publications, I nonetheless suggest that BGL lacks the
> ease of use necessary for widespread adoption.  Even
> knowing that ease-of-use is not a criterion for
> acceptance into boost, looking at what is required of
> the client to use the BGL always leaves me feeling
> perplexed.  Is there any particular reason that a
> simplified interface is not made available?  Perhaps a
> container adapter could be packaged with the library
> allowing a compromise of functionality and flexibility
> for simplicity?  If a graphing problem is trivial,
> shouldn't BGL provide a trivial solution?  Why are the
> simplest useful examples several hundred lines of
> code?
>
> I apologize for all of my vague criticisms - my
> intention is not to flame but rather to test the
> waters.  It is difficult for me to assess whether the
> simplicity I yearn for isn't present for stylistic
> reasons or whether it would rather necessitate a
> sacrifice of flexibility, functionality or
> implementation clarity.  Nor is it clear to me to what
> extent these criteria can be compromised to promote
> clarity of client code.  For what it is worth, the
> kind of ease-of-use I'm imagining might look like:
>
> #include <less_than_10_graph_headers>
> ...
> digraph<some_node_type,some_edge_context_type> g;
> g << "vertex" << make_pair("vertex",
> "implicit_vertex");
> g.add_edge("brother", "sister", "sibling");
> if(g.find(make_pair("brother", "sister")))
>             related = true;
>
> Could someone please elucidate on why it is
> impossible/impractical/unnecessary/whatever for a
> graph library to have such an interface? Should I
> accept that the BGL is not the magic bullet graph
> library and move on, or can this kind of simplicity be
> somehow found within?
>
> Thanks in advance,
> prs
>
>
> __________________________________
> Do you Yahoo!?
> Yahoo! Finance Tax Center - File online. File on time.
> http://taxes.yahoo.com/filing.html
> _______________________________________________
> Unsubscribe & other changes:
http://lists.boost.org/mailman/listinfo.cgi/boost
>