Re: [boost] Report from Berlin C++ Standards Committee meeting

From: Peter Dimov (pdimov_at_[hidden])
Date: 2006-04-13 07:44:59

Andy Little wrote:
> "Peter Dimov" wrote
>
>> What I really want is this:
>>
>> void foo( myvec& v, const myset& s, int a )
>> {
>> // ...
>>
>>    inline bool f( int x ) { return std::abs( x ) < a && s.find( x )
>> != s.end(); }
>>
>>    v.erase( std::remove_if( v.begin(), v.end(), f ), v.end() );
>> }
>>
>> for obvious readability reasons. This syntax also allows me to use a
>> more descriptive name instead of f, and the consistency with
>> ordinary function definitions will make it easier to teach. It may
>> be somewhat easier to parse or specify, but I haven't considered
>> this in detail.
>
> Its interesting that you bring up the teaching issue AFAIK.  Robert
> Rameys earlier point regarding  the benefits of  what seems to just
> be a "cool" feature to C++ is apt . Do local functions, named or
> unnamed really add that much to the language?. They do certainly add
> another layer of complexity to the parser and whats more important
> another layer of complexity that students will feel that they must
> learn and use.

Yes, local functions do add to the language. What you currently need is:

static bool f( int x, int a, myset const & s )
{
    return abs( x ) < a && s.find( x ) != s.end();
}

void foo( myvec& v, const myset& s, int a )
{
    // ...

    v.erase(
        std::remove_if( v.begin(), v.end(),
            std::bind( f, _1, a, std::ref( s ) ) ),
        v.end()
    );
}

As you can see, there is an additional bind needed to pass the arguments 
from the enclosing context to f, but the more important thing is that f 
needs to be defined outside of foo, removed from the point of use. A local 
function decreases complexity, and it's much easier to grasp because it's 
just like an ordinary function, only defined inside of foo.

> C++'s main problem is that it doesnt have enough standard libraries
> to compete with (say) Java. Two obvious ones still not on the horizon
> are Unicode and GUI. ( I am going to try to do something about the
> GUI, though there must be much greater GUI experts than me that could
> do a better job).  A major reason given by the committee AFAICS (in
> GUI case) was that the committee doesnt have enough time to deal with
> it. Yet there seems to be adequate time to discuss the addition of
> more complexities to the language itself. A great language missing
> some essential standard libraries. Will that be C++ epitaph?

This is a pretty common view, but C++ has been missing essential standard 
libraries for more than ten years, and it still competes with Java. C++ 
simply doesn't play by the marketing rule that whoever has the more 
checkboxes wins. It doesn't even have garbage collection! An automatic loss, 
you'd think.

Not only that; what standard libraries C++ does have are often simply not 
used (iostreams, locale.)