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

I was going to mention the global variables, but in fairness I think
[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] 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.
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of christopher diggins ----- Original Message ----- From: "Jonathan Turkanis" <technews@kangaroologic.com>
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
[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. the
address of the temporary objects.
I have to go no, but I'll continue this discussion later.
CD

Brian Braatz wrote:
[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.
What I found frustrating about the discussion is that Christopher never articulated exactly why he prefered his own filter concepts to the existing ones. Jonathan

----- Original Message ----- From: "Brian Braatz" <brianb@rmtg.com>
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.
It is hard to not be insulted by your suggestions that I don't understand the topics, that I am unwilling to accept new ideas, and that I need to read more books. I have said it before on this list, and I will say it to you: I would suggest that you do not jump to conclusions about my (or anyone else's) lack of knowledge on a subject. I am far more familiar with generic programming than you probably realize. This kind of innuendo accomplishes little, except aggravation. It also makes the Boost mailing list a very inhospitable place. Christopher Diggins Object Oriented Template Library (OOTL) http://www.ootl.org

It is hard to not be insulted by your suggestions that I don't understand the topics, that I am unwilling to accept new ideas, and that I need to read more books. I have said it before on this list, and I will say it to you: I would suggest that you do not jump to conclusions about my (or anyone else's) lack of knowledge on a subject. I am far more familiar with generic programming than you probably realize. This kind of innuendo accomplishes little, except aggravation. It also makes the Boost mailing list a very inhospitable place.
Hi, Cristopher I do believe this discussion became too ... personal. But IMO you are partially responcible for that either. If you bring an idea that kind of contradict to common accepted rules you should expect people to attack it from all possible angles. More specifically: you presented an idea to use raw function pointer in places where we now used to use different means. There is no particular reason why it wouldn't work in some specific cases, but *our* experience tells us not to do it. In long term you lose more then you win. Now we (and by 'we' and 'our' I mean people that disagree that usage of raw function pointers has an advantages) couldn't share our experience though mailing list, so we are trying to communicate it though references to known C++ experts. It's not the best way I admit, but this is not exact math either where I could present you with formal proof. As for " why not provide that variant either?", my position is that we (boost community) shouldn't promote solutions that in our opinion deemed to fail this way or another at some point, especially if there is generally accepted alternative. Regards, Gennadiy
participants (4)
-
Brian Braatz
-
christopher diggins
-
Gennadiy Rozental
-
Jonathan Turkanis