source code size metric: Python and modern C++

[David Abrahams]

Brian Quinlan <brian at sweetapp.com> writes:

> Cheers,
> Brian 
>
>> -----Original Message-----
>> From: python-list-admin at python.org
> [mailto:python-list-admin at python.org]
>> On Behalf Of David Abrahams
>> Sent: Tuesday, December 03, 2002 12:00 PM
>> To: Brian Quinlan
>> Cc: python-list at python.org
>> Subject: Re: source code size metric: Python and modern C++
>> 
>> Brian Quinlan <brian at sweetapp.com> writes:
>> 
>> > David Abrahams wrote:
>> >> The type-safe version could easily look like this instead:
>> >>
>> >>    ServerProxy
>> > s("http://www.sweetapp.com/cgi-bin/xmlrpc-test/rpc1.py");
>> >>    int result = s.call_method<int>("add", 2, 3);
>> >>
>> >> That's not too bad.
>> >
>> > You can only do this in the special case where all the arguments and
> the
>> > result are of the same type.
>> 
>> Not true.
>> 
>>     struct ServerProxy
>>     {
>>        ...
>>        // use a family of these with different arities
          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>        template <class R, class A1, class A2>
>>        R call_method(char const* name, A1 a1, A2 a2);
>>        ...
>>     };
>> 
>> > Do I really have to pick another example to demonstrate this?
>> 
>> It's up to you, bubba.
>
> Now all you've done is generalize it so that any combination of 2
> arguments will work. 

Not if you read the comment.

> XML-RPC methods can accept an arbitrary number of
> arguments of mixed type. Is there a way to templatize that?

The comment above says it all. Arity means "number of arguments" in
case you didn't know.  The limit on the number of parameters to a
function is actually bounded by some internal limit in your compiler,
which is required to be documented. So in practice, you can only go
that high.

You can generate these with the Boost.Preprocessor library so you
don't have to write them all out by hand, but it's cumbersome (see
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/boost/boost/boost/python/call.hpp?rev=HEAD&content-type=text/vnd.viewcvs-markup
for an example). In C++, the library writer often pays a high price
for delivering a convenient interface to users.

My point is that C++ _can_ usually deliver the expressive interface
needed so that users don't have to get their hands so dirty. However,
it's often going to cost someone a lot of effort. Better to pay it
once in the development of a good library, than a thousand times in
different applications.

You could say that the reason C++ programs are said to be longer than
Python programs is that the C++ user generally doesn't have the right
libraries at her disposal (though I have to argue strongly with some
contentions I've read that things like high-level containers are
unavailable in C++).  Of course, the other side of the coin is that
the cost of writing the libraries in C++ might be prohibitive.

> You could do the following:
>
> Method<float> method("add");
> method << 5 << 5.6;
> method.do() 

There are lots of variations. Here's another:

ServerProxy.call_method("add", (arg_tuple(5), 5.6, 7, "hello"));

Incidentally, we did have some experience with writing "scripting in
C++" at Boost. Our regression testing system used to be run by this
program:

http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/boost/boost/status/Attic/regression.cpp?rev=1.27&content-type=text/vnd.viewcvs-markup

Which was coded in a "scripting style", according to the author. It
was considered to be a success in that department. I think that with
the right library components available, you can write C++ programs
this way.

-Dave

-- 
                       David Abrahams
   dave at boost-consulting.com * http://www.boost-consulting.com
Boost support, enhancements, training, and commercial distribution