Article of interest: Python pros/cons for the enterprise

[Nicola Musatti]

On Feb 24, 1:01 am, Paul Rubin <http://phr...@NOSPAM.invalid> wrote:
> Nicola Musatti <Nicola.Musa... at gmail.com> writes:
> > >>>    a = [f(x) + g(y) for x,y in izip(m1, m2) if h(x,y).frob() == 7]
> > [...]
> > > There you replace one line of code with 40+ lines to get around the
> > > absence of GC.  Sounds bug-prone among other things.
>
> > Come on, you didn't define f, g, izip, h or frob either. It's more
> > like 5 to one. Furthermore your code is more compact due to the
> > existence of list comprehensions, not because of GC. Had you written a
> > loop the difference would be smaller.
>
> No I don't need a loop if I don't use the listcomp.  I could say
>
>   a = map(lambda x,y: f(x)+g(y), ifilter(lambda x,y: h(x,y).frob==7,
>                                        izip(m1, m2)))
>
> the listcomp is basically syntax sugar for that.
>
> The issue here is that Python is simply more expressive than C++,
> which doesn't support creation of higher order functions like that.

I see. The C++'s closest equivalent would probably be something like

int func(int x, int y) { return f(x) + g(y); }
bool filter(int x, int y) { return h(x,y).frob() == 7; }

transform_if(m1.begin(), m1.end(), m2.begin(),
        std::back_inserter(a), func, filter);

Assuming that instead of izip you had the following, which is more in
style with how the C++ standard library usually works:

template <typename InIter1T, typename InIter2T,
        typename OutIterT, typename FuncT, typename FilterT>
inline void transform_if(InIter1T begin1, InIter1T end1,
        InIter2T begin2, OutIterT out, FuncT func, FilterT filter)
{
    while ( begin1 != end1 )
    {
        if ( filter(*begin1, *begin2) )
            *out++ = func(*begin1, *begin2);
        ++begin1;
        ++begin2;
    }
}

Nameless, local function definitions and a form of type inference
should officially become part of C++ in little over a year. These will
help achieve closer expressiveness for similar statements, but the
lack of native tuples in the language will probably make it impossible
to get much closer.

> However, one of the consequences of programming in this style is
> you allocate a lot of temporary objects which best managed by GC.

According to which metric? This statement appears as totally
gratuitous to me. You seem to forget that deallocation of local
objects only entails stack readjustment. You can hardly beat that with
dynamic memory management.

Cheers,
Nicola Musatti