24 May
2010
24 May
'10
3:05 p.m.
On Mon, May 24, 2010 at 01:27:42PM +0100, Chris Cannam wrote:
On Mon, May 24, 2010 at 12:18 PM, torbenh
<torbenh(a)gmx.de> wrote:
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,
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. 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