Re: [Boost-users] [review] Formal Fast-Track review of the Boost.Functional/Factory library - 2 days left

From: Tobias Schwinger (tschwinger_at_[hidden])
Date: 2007-12-21 19:41:36

Nat Goodspeed wrote:
> I'm willing to concede that I may be burdened with outdated notions of 
> how to solve such problems. I would be very interested to know how I 
> should do it better.

That's really not my point! I didn't say (nor even think) your code was
inferior -- even if it was, it probably would've been my fault providing 
insufficient documentation.

( I like being misunderstood as little as I like to misunderstand in
this particular way... Please don't :-). )

What I was trying to say is that your use case (although common) is not
the only one there is...

> The issue I mentioned above keeps recurring across different projects: 
> given a string from a file or a script, I need to instantiate a distinct 
> C++ class corresponding to that string. I mention an abstract base class 
> because I don't know how, other than virtual functions, I should access 
> the features of such an object.

...and that it varies in nuances:

In one project we'll want a search tree in the other one a hash table
(size vs. speed). In one project we'll want to use 'typeid(T).name()' 
for the search key another one will need fixed integral IDs and yet 
another one will assign integral IDs at runtime and finally one project 
will use strings...

The Factory utility should make those things sufficiently trivial to
implement, however.

> I would dearly love to see the best way to leverage boost::factory to 
> address this problem. If, in the process, I learn new tricks myself, all 
> the better!

Guessing from the follow-up you might have used the best way for your
particular case.

Now, if we can make everything a template and code towards an interface
defined by a Concept instead of an abstract base class (I know it isn't 
always a good idea), we don't need Boost.Function to introduce runtime- 
polymorphism (there just is none) and we can shift the invocation of an 
abstract member function from the inside of a performance-critical code 
block to its invocation...

> Perhaps the library is more squarely targeting a whole family of 
> real-world problems that I haven't yet encountered. I wouldn't mind 
> being educated about those use cases, either.
> 
> You see where I'm going with this. More examples would really help -- 
> not just when trying to use the library, but even to decide whether this 
> library can help me solve the problem at hand.

Yes, your critique is well-taken. The documentation can use some more
detail in this place.

>> My personal feeling towards a more full-featured 'boost::factory' is 
>> that it will be either overly simplified or a tool to break a butterfly 
>> on a policy-based wheel...
> 
> Heh. I hope my remarks about the name boost::factory didn't come across 
> as arrogant or condescending. If so, profuse apologies!

Just to make one thing clear: I'm not enough of a sadist to get high by
pissing off others telling them how much they suck. When I do, it makes
me feel sorry, but this time it's really just a misunderstanding ;-).

So: All I was trying to say is that we probably either won't agree on a
single best way to write 'boost::factory' or introduce so many Policies
that usage becomes more complicated than a from-scratch implementation.

> It may well be that the library, just as it stands, is far more powerful 
> than I have yet realized. Again, I'd love to be enlightened about other 
> use cases.

Its power stems from the combination with well-established Boost 
components and generic programming techniques.

Regards,
Tobias