ГВ>Кхм. Вообще-то, они не только под дотнетом работают. Это как раз и говорит о мощности и высокоуровневости этих языков.

если мерой LISP .Net померять, так .Net вообще отдыхает и нервно курит

ПК>Да-да! А еще ножи бывают настоящие, "опасные", а бывают пластиковые, "безопасные"

Граждане! Будтье бдительны!!!
В магазинах города появились поддельные елочные игрушки. С виду они как настоящие, но радости от них никакой.

Общество защиты прав потребителей.

class Base
{
public:
   void act()
   {
     // prefix
     do_action();
     // postfix
   }

private:
   virtual void do_action() = 0;
};

> ПК>class Base
> ПК>{
> ПК>public:
> ПК>   void act()
> ПК>   {
> ПК>     // prefix
> ПК>     do_action();
> ПК>     // postfix
> ПК>   }
>
> ПК>private:
> ПК>   virtual void do_action() = 0;
> ПК>};
> ПК>

Bill Venners: In Java, instance methods are virtual by default—they can be overridden in subclasses unless they are explicitly declared final. In C#, by contrast, instance methods are non-virtual by default. To make a method virtual, the programmer must explicitly declare it virtual. Why is non-virtual the default in C#?

Anders Hejlsberg: There are several reasons. One is performance. We can observe that as people write code in Java, they forget to mark their methods final. Therefore, those methods are virtual. Because they're virtual, they don't perform as well. There's just performance overhead associated with being a virtual method. That's one issue.

A more important issue is versioning. There are two schools of thought about virtual methods. The academic school of thought says, "Everything should be virtual, because I might want to override it someday." The pragmatic school of thought, which comes from building real applications that run in the real world, says, "We've got to be real careful about what we make virtual."

When we make something virtual in a platform, we're making an awful lot of promises about how it evolves in the future. For a non-virtual method, we promise that when you call this method, x and y will happen. When we publish a virtual method in an API, we not only promise that when you call this method, x and y will happen. We also promise that when you override this method, we will call it in this particular sequence with regard to these other ones and the state will be in this and that invariant.

Every time you say virtual in an API, you are creating a call back hook. As an OS or API framework designer, you've got to be real careful about that. You don't want users overriding and hooking at any arbitrary point in an API, because you cannot necessarily make those promises. And people may not fully understand the promises they are making when they make something virtual.

ПК>template< class T>
ПК>void my_function( const T& t1, const T& t2 )
ПК>{
ПК>   . . .

ПК>   . . . = scalar_multiplication( t1, t2 );

ПК>   . . .
ПК>}
ПК>

public class Matrix<class PrimitiveType> { 
  public Matrix<PrimitiveType> Invert() {
  //делаем обратную матрицу
    }
    public Matrix<PrimitiveType> Multiple(Matrix<PrimitiveType> to) {
    //перемножаем матрицы
    }
    //итд итп
}

Matrix<double> identity=new Matrix<double>;
identity=identity*