Выскажусь не совсем по теме, но пример очень неудачен. 

Во-первых, все достоинства C++ в данном случае сводятся к удобству для программиста (при этом некий достаточно близкий аналог можно реализовать и на C с помощью макросов - решение потенциально "небезопасное", но все же). А вот производительность полученного кода (которая в задачах такого рода обычно является наиболее критичной) будет, мягко говоря, невысокой. 

Во-вторых, это как раз тот случай, когда с помощью предлагаемого инструмента можно успешно решать проблемы, которые при использовании других инструментов просто не возникают.   В нормальных условиях такие вещи пишутся на Фортране - он для них специально предназначен, поэтому все необходимое уже встроено в язык, а конечный результат будет работать заметно быстрее, чем код на C (о C++, C#, Java и т.д. можно и не вспоминать).

Для кого лучше? Давай больше конкретики. Для приведённого случая я не понимаю чем "лучше".



Производительность будет не НИЖЕ, чем при реализации на С. С чего ей быть невысокой? 



Не попал. На фортране это будет выглядеть также громоздко как и на С. И насчёт производительности опять мимо. Давай код на фортране, сравним. 

Пробовал?   

Проблема в "накладных расходах" на создание и уничтожение промежуточных экземпляторов матриц. Вот в этой твоей строчке:

каждый перегруженный оператор и функция tr() (кстати, что понимается под "делением"?) создают экземляр результата, который после использования, кстати, еще и уничтожить нужно. В одной этой строке это произойдет как минимум три раза, и при больших размерах матриц это весьма накладно.

Другое дело, что и на C можно написать столь же "производительный" код - если каждый оператор тупо заменить соответствующей функцией. Но зачем? А оптимизация этого вычисления неизбежно приведет к отказу от использования класса для матриц, и от C++ фактически ничего не останется.



Опять тот же вопрос - пробовал?   

Код на Фортране дать не проблема, но мне нужно иметь образец, который требуется переписать. А в наличии только одна строка, причем с не вполне понятным смыслом. Выдай кусок побольше - напишу аналог.

Вы говорили про пару (на конкретный класс). Если брать крупный проект, в нем пара сотен классов будет. По паре на класс - и вперед.


Вы прекрасно знаете о чем речь. Применяя возможности языка можно не заботится и перемене типов. Написание собственных типов - это основное преимущество С++ перд Си. Если понадобится матрица объектов, то на Си (как вы суже сказали) это делается при помощи указателя на void. Естественно это самый надежный и защищенный механизм    Речь шла не о конкретной матрице, а о возможности языка.

Я говорил про работспособность "супер языков высокого уровня". Для того, чтобы заработал шарп сколько дополнительного надо поставить? Сколько это весит?

Добавлено через 5 минут и 54 секунды

Почему вы уверены, что там не ссылки?

Я пробовал. Но не спора ради, а помогал человеку - заядлому фортранисту. Он академик по статистике, у него там матрицы были порядка 5000х5000. Мне было лень разбираться с фортраном и я помог ему на С++.
В общем может быть он слабый программист, может фортран у него был какой-то медленный не знаю. В общем на С++ пошустрее получилось.

Нет тут никаких накладных расходов.



Ты знаешь, что такое передача по ссылке, inline и NRVO? В этой строчке не произойдёт ниодного копирования.



Ты ведь изначально утверждаешь, что код на фортране будет работать намного быстрее, чем код на С++. Вот и докажи. Я не вижу никаких предпосылок в пользу этого утверждения. 



Т.е. ты даже никогда не писал подобного кода на фортране?  Я думал твои заявления подкреплены хоть каким-то опытом (пускай односторонним и ошибочным).

Ссылки на что? Если обсуждаемый класс хоть сколько-нибудь функционален, то при каждой бинарной операции результат должен куда-то записываться, причем это "куда-то" не может совпадать ни с одним из операндов. 

Вот совсем простой пример. Пусть у нас есть такая строка:

где A,B,C,D - матрицы, оператор "+" соответствующим образом перегружен. Что произойдет? Будет вызван первый "+", соответствующий метод сложит A и B, и ему надо куда-то деть результат. Соответственно, будет вызван конструктор Matrix и в итоге появится еще один экземпляр, в который будет записан результат. Потом будет вызван второй "+", которому будет скормлен этот новый экземпляр и C, результат попадет в D. Итого по дороге был создан (и спасибо, если не забыт в памяти) лишний экземпляр.

Если бы человек писал все это "вручную", то, конечно, проще было бы сразу написать поэлементное сложение трех матриц. Тогда ничего промежуточного не возникает. Но компилятор при использовании класса Matrix проделать это сам не может, у него для этого недостаточно информации. Поэтому он честно обеспечит генерацию дополнительной промежуточной матрицы.



Скорее всего, и то, и другое. Фортран достаточно сильно эволюционировал за время своего существования, и, к сожалению, добрых 90% людей, "знающих Фортран", пишет не на современном языке, а на том, который был современным в пору их молодости. Ну и естественно, что результаты получаются так себе - во-первых, подавляющее большинство преимуществ появляется при использовании двух-трех последних по времени вариантов, во-вторых, на оптимизациею конструкций, актуальных, например, для Fortran 77, разработчики современных компиляторовЮ по понятным причинам, тратят весьма немного времени и сил.

Фантом, ты про шаблоны чтонить слышал? 

на лицо плохое знание С++ 
***
из книги "Язык программирования С++. Специальное издание" Страуструп. 11.6. Большие объекты. стр. 331.





Это сообщение отредактировал(а) zim22 - 20.9.2009, 14:35

См. чуть выше.



Знаю. Только ты объясни внятно, куда денется, например, результат умножения матриц A и B при прогонке твоего кода, и как этому помогут передача по ссылке, inline и NRVO? Или у тебя все расчеты делаются не программой, а сразу компилятором?   



Для тех, кто в танке, повторяю еще раз: для того, чтобы показать, что код на Фортране для решения твоей задачи будет эффективнее, чем твой код на C++, мне надо увидеть как минимум постановку твоей задачи. А еще лучше - твой код.

Что тебе сейчас можно написать? Ты даже не сподобился объяснить, во что перегрузил деление. Если его убрать, то близкий аналог твоего 

 на Фортране перепишется так:


Очень громоздко, правда?   

Фантом, 
если A, B, C, D -  матрицы,
то в С++ код
A = B + C + D;

преобразуется к виду

цикл( i,j )
  A[i,j] = B[i,j] + С[i,j] + D[i,j];


потому что перегруженные операторы сложения построят AST, а перегруженный оператор присваивания это дерево преобразует в оптимальный вид, и сгенерирует при компиляции оптимальный код

Это сообщение отредактировал(а) GoldFinch - 20.9.2009, 14:43

Юноша, давай для определенности сразу договоримся о том, что я "чтонить" о "чемнить" слышал еще тогда, когда тебя еще в проекте не было. 

кстати вариант. метапрограммирование называется 

вспомнилась подпись Qraizer: одни с годами умнеют, другие просто становятся старше.

Это сообщение отредактировал(а) zim22 - 20.9.2009, 14:50

На C++ участвовал только в одном коммерческом проекте. Как только предоставилась возможность, перешёл в другой - на C# и чувствую себя в нём гораздо удобнее.


ООП - оно и в африке ООП.
Лисп действительно мультипарадигменный язык, в отличие, от C++. Это раз.
Лисп проще, чем C++, но при этом гибче. Это два.
Пока достаточно.


Человек, способный писать на одном ЯП - быдлокодер.


Слышал про лисп-машины? Как думаешь, системный язык там какой?


Зелёное хуже, чем мокрое?


Хорошо, давай я пишу твою задачу на C++, а ты мою на лиспе. Ок?

Добавлено через 53 секунды

Метапрограммирование в C++ убогое по сравнению с тем же Nemerle.

Нет, скорее невнимательное чтение кое-кем предшествующей переписки.   

Эта идея, конечно, частично спасает положение. Правда, ниоткуда не следует, что 

•  W4FhLF ее реализовал,
•  W4FhLF реализовал ее более эффективно, чем разработчики какого-нибудь IFC,
•  получившееся в результате является "удобным и лаконичным".

Однако остаются и проблемы. 

Во-первых, матрицы, с которыми приходится иметь дело, велики (а помощь небес не безгранична). 

Во-вторых, в одном вычисляемом выражении может встретиться, вообще говоря, сколько угодно бинарных операций (и, соответственно, промежуточных результатов). Пример Стауструпа можно модифицировать для этого случая, но размер буфера неизбежно придется ограничить.

В-третьих, модификация того же примера для случая матриц произвольного размера (а в реальных задачах редко когда все матрицы сплошь одинаковые) приведет к необходимости написать нечто, весьма сильно напоминающее полноценный менеджер памяти. Человек, конечно, может все, но стоит ли изобретать велосипед самому и собирать его из подручных материалов?

  

а смысл? ну докажу я, что я круче тебя в тысячу раз. тебе же от этого лучше не станет