On Mon, May 24, 2010 at 01:27:42PM +0100, Chris Cannam wrote: > On Mon, May 24, 2010 at 12:18 PM, torbenh <[email protected]> wrote: > > classic C++ and "modern c++" are two pairs of shoes. > > if your afraid of writing templates. modern c++ is not for you. > > I'm puzzled as to why templates should be considered "modern" these > days, but never mind.
dunno. but wikipedia calls this particular style modern c++ http://en.wikipedia.org/wiki/Asio_C%2B%2B_library http://en.wikipedia.org/wiki/Modern_C%2B%2B_Design seems to be based on the book: "Modern C++ Design" by Andrei Alexandrescu, > My very mundane point is just that (even without considering C++0x) > C++ is a big enough language that many quite different styles of > expression in it are commonplace. You had a toy example in another > email that summed the elements in a series -- think how many different > ways there already are to write that. An average, competent C++ > developer might find it easier to read code in a totally different > language, than C++ written by an equally competent developer with a > different background. And on the whole, the more you try to write > really efficiently in a particular style of the language, the more > likely you are to alienate other developers. > > So my complaint is about reading, not writing. the efficiency i am talking about is presenting the compilers optimizer with the whole algorithm. without hiding some parts behind a virtual method invocation. the difference is basically: class X { virtual void do_something(); } void well_do_something( X & x ) { x.do_something(); } vs. template <class T> void well_do_something( T & x ) { x.do_somthing(); } in the latter the compiler sees the complete algorithm. and can optimize properly. but this is the direction into which the whole STL is moving. > > Maybe the situation can improve, even as the language and library > continue to expand. It depends on whether individual new features are > compelling enough to coalesce the interests of many different sorts of > developers and draw them away from the alternatives. For example, the > functor-based stuff in the "classic" STL was clearly not compelling > enough (increasing fragmentation). But some of the examples you have > given might be. yes. making a functor a real closure was pretty annoying. thats why boost::bind came to the rescue. but boost::bind is still pretty awkward compared to a c++0x lambda. > > > Chris -- torben Hohn _______________________________________________ Linux-audio-dev mailing list [email protected] http://lists.linuxaudio.org/listinfo/linux-audio-dev
