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

[torbenh]

On Mon, May 24, 2010 at 01:27:42PM +0100, Chris Cannam wrote:
> On Mon, May 24, 2010 at 12:18 PM, torbenh <torbenh at gmx.de> 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