Re: [GD-General] Eiffel

[Jesse J. <jes...@mi...>]

At 5:16 PM -0800 12/22/01, Brian Hook wrote:
>Anyway, back to the point -- how does C++'s templates provide 
>genericity that is better than Eiffel's?  After looking at Eiffel, 
>it seems like it supports generic programming in a much more open 
>and friendly fashion and without all the compile time weirdness that 
>C++ jams down our throat.

The difference is that templates are a Turing complete compile time 
language. This is obviously enormously powerful (and awkward because 
templates were never designed to do this). This lets you do all 
manner of things. Here are a few:

1) STL knows exactly which types it's dealing with. This means it can 
switch off the type and use optimized code as appropriate.  For 
example, when a vector resizes it has to copy the old elements into a 
new block. A good implementation will use memcpy for primitive types 
(and user types that the user marked as POD) instead of an element by 
element copy.

Another trick that STL implementations use is to use partial 
specialization so that all pointers share the same code. This cuts 
way down on bloat if you use a lot of containers of pointers in your 
code. AFAIK Eiffel's collections don't take advantage of type info 
like this.

2)  Like C++ Eiffel is statically typed. But sometimes you have to 
store arbitrary data. This has traditionally been done with unions in 
C++, but templates can provide a cleaner solution. For example, 
boost::any is a non-template class that contains a templated class. 
This lets you do things like have heterogeneous containers:

    std::vector<boost::any> c;
    c.push_back(1);   // int
    c.push_back(std::string("one"));
    etc

    if (int* ip = boost::any_cast<int*>(c[0]))
       // it's an int, muck around with it
    else (std::string* ip = boost::any_cast<std::string*>(c[0]))
       // it's a string

I don't think Eiffel can do this because it lacks member templates.

3) There are a number of libraries that really push templates. 
Blitz++ for example allows you to write matrix code in a natural 
style (A = B*C + D) but uses expression templates to optimize the 
code and eliminate temporaries at compile time. This allows them to 
meet or beat Fortran's performance. Try that in Eiffel. :-)

There are also a number of lambda libraries out there for C++. These 
allow you to write closures in C++. For example:

    int c[4] = [1, 2, 3, 4];
    for_each(c, c+4, cout << arg1 << " ");

will execute the expression 'cout << arg1 << "' for each element in 
the iterator range assigning the element value to "arg1". Some of 
them even support conditional expressions in the expression. Of 
course Blitz and the lambda libraries are much more complex and push 
templates a lot further than STL. It's still not clear that libraries 
like this will be useable by mortals in production code.

>My biggest concern with Ruby right now is performance.  Looking at 
>the benchmarkst at the GCLS, it looks like Ruby is pretty far behind 
>the other languages, including Lua (which I would guess is Ruby's 
>primary competitor -- Python, Ruby and Lua seem to be accomplishing 
>much the same thing).

Ruby's pretty darn cool, but I'd have to agree with you. It might be 
good for protoyping though. BTW there's supposed to be a decent Cocoa 
wrapper for Ruby although I haven't checked it out yet.

>>But the biggest problem with C++ might be that it simply requires 
>>too much time and study to become proficient in the language and 
>>aware of all the pitfalls.
>
>I would put this another way: C++ was trying to be idiom-neutral and 
>provide all the tools for any kind of programming style.  Because of 
>this, you can become very proficient in one tiny aspect of C++.  I 
>feel I know C++ very well for my purposes, but because I 
>purposefully have avoided templates, exception handling, MI and many 
>other things that I consider more problematic than worthwhile, I 
>can't say I "know" C++.  In fact, I'm not sure many people can say 
>they know the whole language since the whole language is overkill 
>for any specific framework design.

Very very few people know the entire language. I know an awful lot, 
but there are still plenty of arcane template rules that I haven't 
bothered to learn.

>I would even argue that any framework that uses EVERY element of C++ 
>is probably a disaster.  Which goes back to my complaints about STL 
>=)

This is absolutely not true. Take your earlier list: "templates, 
exception handling, and MI". Every single one of these is *very* 
useful in frameworks and I've seen multiple frameworks that used them 
effectively.

I can only think of two C++ features that I avoid: virtual base 
classes and exception specifiers. Virtual base classes are one of the 
worst part's of the language and exception specifiers have an 
unfortunate tendency to abort your program if the wrong exception 
sneaks through.

   -- Jesse