Re: [LAD] Looking for an introduction to rt programming with a gui

From: torbenh <torbenh@email-addr-hidden>
Date: Mon May 24 2010 - 16:05:31 EEST

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-dev
Received 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