Foo_ (foo@nomail.com) on 3/9/08 wrote:
---------------------------
>It's not just syntax, it's semantics. Compare the lame std::string type with Python's
>str and unicode types, for example.

OK, what are the differences?

>Compare the garbage collector with the burden
>of managing memory by hand.

In the RBTree example I linked to, the entire memory management burden equates to:

    void copy(RedBlackTree *x)

    {

        ...

	// Delete x

        x->m_left  = NULL;

        x->m_right = NULL;

        delete x;

    }



    ~RedBlackTree() {

        delete m_left;

        delete m_right;

    }

... and that's if you decide to manage memory by hand rather than using smart pointers.

>Compare the standard library.

Am I allowed to include Boost?

>Compare the fact that
>everything is an object (including functions, methods...) with C++'s typing mess. etc.

The fact that not everything has to be an object is an important part of C++'s support for multiple programming paradigms. OO isn't always the simplest way to represent something.

>Unless you only program Mandelbrot-calculation loops it is quite clear how Python is more concise than C++.

I was hoping for something a little more concrete than being asked to compare a bunch of things and told the answer was "quite clear".

>For a start, C++'s crippled standard library should be a big warning against using
>that language for general-purpose tasks, unless you are masochistic.

I actually quite like C++'s standard library and the underlying concepts. I also use Boost and many other libraries, as any serious programmer would.

>>I look at examples like http://www.dmh2000.com/cjpr/cmpframe.html
>
>Sorry that's a stupid example. You don't write red-black trees in pure Python,
>it is not "idiomatic" by any meaning of the word. And the example itself is a straight
>translation from a textbook algorithm, no wonder line counts end up quite similar.

That's not the point. I wouldn't bother writing a red-black tree anyway. The point is to express a set of concepts in a language to see how they turn out.

To illustrate what I was talking about, however, this is the code that the author gave to implement the Visitor design pattern on his tree:

// ===============================================================

// C++ NEEDS SOME DECLARATIONS BEFORE THE MAIN RedBlackTree class.

// skip down a little to line this up with the other side

// ===============================================================

// requires forward declaration to resolve cycle between NodeVisitor and RedBlackTree

template<class T> class RedBlackTree;



// use an abstract class for the node visitor. it is templatized to match the templated RedBlackTree declaration

template<class T> class NodeVisitor {

public:

    // need a virtual destructor for the concrete classes

    virtual ~NodeVisitor() {}



    // ise a pure virtual function so a concrete class must implement

    // the proper signature

    virtual void visit(const RedBlackTree<T> *node,int depth) = 0;

};



...



    // 'const' means this method doesn't change the object state

    // and the visitor is not allowed to change the object state.

    // that may not be what is desired but is used here to 

    // illustrate something you can do in C++ that you can't do

    // in the other languages and that illustrates the bias towards

    // extensive static type checking

    void inorder(NodeVisitor<T> *visitor,int depth) const {

        if (m_left != 0) {

            m_left->inorder(visitor,depth+1);

        }

        visitor->visit(this,depth);

        if (m_right != 0) {

            m_right->inorder(visitor,depth+1);

        }

    }

Over 30 lines and it doesn't even work with plan functions!

This was his Python effort:

    # inorder traversal using a class as the visitor

    def inorderClass(self,visitor,depth):

        if self.__left != None:

            self.__left.inorderClass(visitor,depth+1)

        visitor.visit(self,depth)

        if self.__right != None:

            self.__right.inorderClass(visitor,depth+1)

            



    # inorder traversal using a function as the visitor

    def inorderFunction(self,visit,depth):

        if self.__left != None:

            self.__left.inorderFunction(visit,depth+1)

        visit(self,depth)

        if self.__right != None:

            self.__right.inorderFunction(visit,depth+1)

15 lines of code and it supports both classes that implement the "visit" method and functions.

But this is how I would do it in C++, especially since it's a template class anyway:

    // inorder traversal using either a class or a function as the visitor

    template <class Visitor>

    void inorder(Visitor& visitor, int depth) const {

        if (m_left != NULL)

            m_left->inorder(visitor, depth + 1);



        visitor(*this, depth);



        if (m_right != NULL)

            m_right->inorder(visitor, depth + 1);

    }

This replaces all of the C++ code I quoted above, and supports both plain functions and functor classes; duplicate for classes that have a Visit method if you like. It is line-for-line identical to the Python version except:

1. The "template" line.

2. It will give a compile-time error if you try to use it with a function or object that does not have the required signature.

3. You don't have to keep typing "self" all the time. (It reminds me of when I used to program OO-style in C.)

>>Also, one of the things I like most about C++
>>is that doing nice stuff is concise;
>
>IMO only a Java or Pascal programmer can find C++ concise. There is no conciseness
>in the way you declare and use function types, method pointer types, etc., in C++.

It's a tradeoff. If I want to tell the compiler what type I think a variable should be so that it can give me a compile-time error if I'm wrong (it happens), then I have to tell it somehow, and saying what the type is when I declare and use it the first time isn't a huge burden. (It also means that VisualAssist (http://www.wholetomato.com/) knows what methods to show me when I start typing something and it wants to auto-complete them for me.)

In the next version of C++ the "auto" keyword is going to be redefined to allow the class to remain unspecified, i.e.

auto Blah = ...;

The concrete type will still be known and enforced at compile time, but you don't have to state it if you don't care.

This can be useful in some cases, but I will generally continue to state the type for the same reason I use assert() in my code -- the more information I give the compiler about what I think is going on, the more likely it is going to be able to tell me if I'm wrong.

>>Perhaps some concrete examples would be nice to highlight what I've overlooked.
>
>You can find some concrete examples here:
>http://shootout.alioth.debian.org/
>
>Since those examples are very short and calculatory programs, they don't really
>highlight what the high-level semantics of Python or Ruby can bring in terms of conciseness.

They also seem to want to write everything as low-level as possible. Take this for example:

#include <iostream>

#include <fstream>

#include <stdlib.h>

#include <stdio.h>



using namespace std;



#define MAXLINELEN 128



int main(int argc, char * * argv) {

    ios_base::sync_with_stdio(false);

    char line[MAXLINELEN];

    int sum = 0;

    char buff[4096];

    cin.rdbuf()->pubsetbuf(buff, 4096); // enable buffering



    while (cin.getline(line, MAXLINELEN)) {

        sum += atoi(line);

    }

    cout << sum << 'n';

}

This is the simple Python version:

import sys



def main():

    count = 0

    for line in sys.stdin.xreadlines():

        count += int(line)

    print count

But why not simply write it like this in C++?

#include <iostream>



using namespace std;



int main()

{

    int i, count = 0;



    while (cin >> i)

        count += i;



    cout << count;

}

Or, to emulate the "print sum(itertools.imap(int, sys.stdin))" version:

#include <iostream>

#include <numeric>



using namespace std;



int main()

{

    cout << accumulate(istream_iterator<int>(cin), istream_iterator<int>(), 0);

}

That's 10 lines of C++ code in their main function vs 1 line in mine.

These are just silly toy examples, but every one I look at is like this, and I haven't even used anything outside of the current STL, let alone TR1 or Boost or any of the other libraries I normally use.

>>>C++ is good for some applications, python is good for some applications.
>>
>>As I said right at the beginning. A classic Pentium is fine for plenty of applications as well.
>
>Your classic Pentium does not have abstraction, maintainability and robustness
>advantages over a Core 2 Duo, while Python has over C++.

Well, I disagree that Python has abstraction, maintainability, or robustness advantages over C++. Abstraction-wise they seem pretty much the same as far as I can tell, and I think static typing is a win for maintainability and robustness simply because you are far more likely to detect a mistake at compile time rather than hoping you have the right test cases to catch it at run time rather than your customer.