On Mon, May 24, 2010 at 01:27:42PM +0100, Chris Cannam wrote:
> On Mon, May 24, 2010 at 12:18 PM, torbenh <torbenh@email-addr-hidden> 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 Linux-audio-dev@email-addr-hidden http://lists.linuxaudio.org/listinfo/linux-audio-devReceived on Mon May 24 16:15:10 2010
This archive was generated by hypermail 2.1.8 : Mon May 24 2010 - 16:15:10 EEST