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