RE: [boost] Re: Functions as Filters (was Program Reuse...)

From: Brian Braatz (brianb_at_[hidden])
Date: 2005-01-13 22:46:05

[christopher diggings ]
Reading and writing to cin and cout, is a long established effective 
practice which results in generic and easily reused code. I am not
simply 
advocating for needs of novice programmers. I am not a novice, but I
always 
want my code to be written as if for novices whereever possible. It is
my 
experience that when writing as if for novices usually results in code
which 
is more easy to maintain, reuse and document.

[Jonathan Turkanis]
> I was going to mention the global variables, but in fairness I think
the 
> four
> global streams have special status. If I could redesign the standard 
> iostreams
> library without concern for backward compatibility, I'd change a
number of
> things but I'm not sure I'd require users to write
>
>     std::cout::instance() << "Hello World!\n";
>
> I'm interested to know exactly what Christopher thinks is too complex 
> about the
> filter concepts, since I'm sure others will share his view.

[christopher diggings]
I don't think they are too complicated! They do precisely what they
should 
do, the way they should do it.

[And now for Brian Braatz's 2 cents] 
I have been watching this thread with interest.

And I find it odd. Yes Odd...

I agree that a simple interface is always good to have for novices. And
I prefer to provide a "advanced" interface where I can. This is, in
general, why I like modern techniques of C++. As with template based
techniques, I am more enabled to give the users something easy to get
their head around, yet, also provide for the ability to use my concept
generically or even alter some key functionality of my concept. (i.e.
std::allocator and its usage in STL is a simple example). At the end of
the day, I am willing to make my interface "a tad weird for newbies",
but exponentially increase the things that can do with my component.

What I see though, is Christopher making an argument for dumbed down C++
because many of the developers out there have not yet learned the modern
techniques.

This is a philosophical discussion at some level. And at that level I
partly agree with you in principle. From a boost level though, to me at
least, boost is not about "purposely dumbed down so you can use it
without having to learn anything new". That would be the opposite of
what boost is. At least to me personally, Boost is about the power of
generic programming, not purposely making global variables so things are
easier for newbies. Learning and using boost requires commitment.
(indeed). But the payoff of skills and abilities more than pays for
itself.

Chris, I suggest to you that you get a copy of the book Modern C++ and
really give it a good read. It covers a lot of the new techniques now
available to us because our compilers are now more compliant. We don't
have to live in the stone ages anymore (applause!).

I really get the sense, that if you were to take the time to understand
some of the newer ideas on how to write code, you might not feel like
everyone is disagreeing with you on this list. There are a number of
mind blowing things that can be done with Generic Programming, but you
first have to get your head into it and you have to be willing to accept
new ideas.

> -----Original Message-----
> From: boost-bounces_at_[hidden]
[mailto:boost-bounces_at_[hidden]]
> On Behalf Of christopher diggins
> ----- Original Message -----
> From: "Jonathan Turkanis" <technews_at_[hidden]>
> > I don't see why this is better than
> >
> >   struct toupper_filter : input_filter {
> >        template<typename Source>
> >        int get(Source& src) { return toupper(boost::io::get(src)); }
> >   };
> >
> > and its cousins.
> 
> Then that pretty much closes the discussion. If you do not see the
> benefits
> of the lower complexity, then there really is little more I can do to
> convince you otherwise.
> 
> >> int main() {
> >>   fstream("input.txt") > Filter(ToUpper);
> >> }
> >
> > This won't work, since fstream("input.txt") produces a temporary
object
> > which
> > cannot be used to initialize a non-const reference. Therefore
operator<
> > would
> > have to be declared to take a const reference, and the non-const
> > extraction
> > functions would not be usable.
> 
> I already made it work by creating temporary helper objects which take
the
> address of the temporary objects.
> 
> > I have to go no, but I'll continue this discussion later.
> 
> CD