Я работаю над проэктом, который писали множество программистов уже лет 15 как, и до сих пор вставляем новые возможности, исправляем старые(вносим новые :) ) ошибки.
Глядя на исходные тексты, точнее на их халтурность, я не могу понять: толи некоторые(большинство из них) программисты не владеют языком С++, толи они специально пишут запутанно, чтобы только они и могли там разобраться. Некоторые из этих программистов до сих пор работают на фирме, и стиль их нисколько не поменялся.
Например, копируют куски кода, вместо того чтобы оформить в виде функции и вызывать её. Используют #definы или константы, там где по смыслу надо использовать enum. В качестве битовых масок тоже используют DWORD, long - но только не enum! И частенько встречаешь "волшебные" константы прямо в коде без каких либо комметрариев, типа 0x00200. И попробуй пойми, чего сие значит. (Разобраться конечно можно, но сходу не понятно, и нужно тратить время чтобы понять).
Я сейчас много меняю таких мест, вместо DWORD(и т.п.) ставлю конкретный тип (enum), глядя на который сразу видно какие значения могут быть.
А вы как думаете, нужно ли писать код интуитивно понятный (а стало быть лёгкий в поддержке и для других программистов) или лучше шифровать (чтобы другие попотели пока поймут)?
Дело в том что если ты успеешь написать кучу "зашифрованного" кода, то на фирме ты будешь незаменимый человек, единственный способный делать в нём изменения :).

Быдлокодеры
Увы и ах... Они повсюду...

Может они выросли из asm программистов а привычки остались!?
1. не факт что enum лутше для битовых масок.
2. Тем более если работать например с MAPI. Там все маски в DWORD
ну и при программирование для CE платформ битовая маска например комбинаций дней недели в DWORD/long будет менее ресурсоемкой чем enum. Да и вообще как бы принято что битовые комбинации integer а не enum.
01000101 для меня более предпочтителен чем (Days::Monday | Days::Friday | Days::Sunday)
да и вообще в спецификациях языка ето не оговорено, так что тут все на любителя.

бональный loop разбитый на кучу функций - ето еще куда хуже. не факт что при компилирование оптимизация вызовов будет построена оптимально. так что процессор прыгающий на хз какие интервалы вместо sbs не есть гут.
Так что разбиение на функции или нет должно быть отдельно продумано для каждого проекта и т.д. и т.п.
Ну и само собой чем больше вы напишите код под себя тем дольше будет привязан заказчик к вам, что является весьма не хилым фактором в программирование. :)
P.S.: Все выше сказанное вообще фиолетово при написание калькулятора :)

man встроенные функции(inline)
а за копипасту расстреливать на месте надо.

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

На таком языке как плюсы трудно писать интуитивно понятный код :-)
Проблема в том что пишут на коленке, не продумывая архитектуру .
А константы использовать или перечисления - это мелочи.

про inline речи не было

А что такое " при компилирование оптимизация вызовов будет построена оптимально" ?
компилятор обычно с этим справляется лучше чем программист.
И почему по-твоему копипаста лучше чем встроеннье функции ?

1. не факт что enum лутше для битовых масок.
------
Лучше. Поименованные константы всегда будут лучше... ибо иначе их не вводили бы.
2. Тем более если работать например с MAPI. Там все маски в DWORD
------
Ну и? Проинициализируй заданные enum-константы... работа конечно не из приятных, но делать ее надо однажды...
01000101 для меня более предпочтителен чем
------
Ну и чем он для тебя лучше? Простой вопрос - есть две системы нумерации дней: европейская - с Понедельника... американская - с Воскресения... В принципе есть и еще одна - ирландская, для рабочих дней - со Среды... Как у тебя будет с порядком единичек при переделке?
бональный loop разбитый на кучу функций - ето еще куда хуже
------
Пссс... Была бы функциональность функций правильной и цикл легко читаемым/понимаемым, а куда там управление будет Juvp'ать - пофиг...
Ну и само собой чем больше вы напишите код под себя тем дольше будет привязан заказчик к вам
------
Чем больше ты успеваешь производить кода, тем больше у тебя заказчиков и тем чаще они к тебе возвращаются...
Ну подумай сам - пусть есть задачка объемом этак с 200Мб, под 1000 форм, 4-5 тыс типов объектов...
ты месяц роешься в хитром коде, пытаясь что-то поправить как надо заказчику...
или
за 10 минут делаешь нужную заказчику правку и через 20 минут генерации и компиляции готов передать заказчику требуемое...
Куда он пойдет?

На таком языке как плюсы трудно писать интуитивно понятный код :-)
------
Угу... на VB6 - лЯХко... прямо сейчас ищут писателя для _нового_ проекта...

как-то писал конечный автомат, который чё-та там парсил. На VB. Странное дело - не плевался.

А почему не на хакселе?

Конечный автомат, который парсит там чего-то, в зависимости от того, чего он там парсит
- LR(0), LL(1) или LARL - занимает 10-15 строк... если, конечно, не писать что-то типа
рекурсивного спуска и называть его автоматом...
Я уже описывал один VB6 проект... точнее - одну его форму, весом в ~250Кб... там мешанина
из управления элементами формы, локального пересчета значений и кусков SQL. Там никто
не в состоянии гарантировать, что изменения корректны...
Из того, что Я видел в других проектах и что ваял сам на Аксесе, система программрования
(плюс сроки и область применения) вынуждает лепить именно такой код. Изменить методику
можно, но это совсем не дешево...

мне нравится с++. А на каком языке проще писать понятный код?
А вот константы или перечисления - это совсем не мелочи, если говорить о программах посложнее Хелоуворда, хоть в пару тысяч файлов.
Я предпочитаю использовать конкретный тип(т.е. определённый мной) там где это возможно. DWORD это не конкретный тип, это может быть всё что угодно. Например параметр функции (DWORD dwMode) ни о чем не говорит. Какие значения может принимать dwMode? Может быть все возможные, т.е. от 0 до 0xFFFFFFFF ? Где искать константы или дэфайны которые могут быть использованы в качестве фактического параметра? Попробуй найди в сотне заголовков! Понять параметр можно только анализируя код функции, а если он там не используется(а только передаётся дальше), может придётся полазить в 20 других функций по стеку пока увидишь подстановку конкретной константы (что может быть и не возможным, если напр. она считана из файла), или придётся шагать внутрь 20ти других функций куда передается этот параметр пока не доберёшся до кода зависящего от этого dwMode. Другое дело если это не DWORD, а enum TMode. Глянув на него сразу видишь смысл этого типа, диапазон значений. К тому же мной опредёлённому типу можно присвоить значение только этого типа и никакого другого(если конечно я не разрешу), что есть гарантия от случайной ошибки типа: вместо дня недели подставил месяц.

для большинства задач лучше не думать об оптимизации, лучше думать о понятности кода. Потому что пользователю всё равно: отреагирует программа на нажатие энтера за 1милисекуну или за 10. Только там где это критично стоит думать. Но экономить на функциях (если применение их оправдано большей понятность программы) не стоит никогда. Ведь их можно и inline сделать.
В идеале, если кусочку кода (это может быть и одна строчка) можно присвоить имя (которое учавствует в мышлении программиста при описании алгоритма), то это участок кода должен быть оформлен в виде функции. Даже если вызов её встречается только один раз.
Если напр. 5 строк программы, которые можно было оформить в виде функции, всё же(как зачастую и бывает) являются просто строками некой большой функции, то через год какой нибудь программист вставит внутрь этих строчек свой код, а через год внутрь этих еще и т.д. Тогда каша получается - всё перемешано. А я такие каши вижу частенько.

Я выбираю плюсы если есть выбор только между c и c++.
Последнее время плотно занимаюсь питоном, вот на нем точно проще писать понятный код.
А также до кучи из мэйнстрима : шарп, джава.
Хотя плохому танцору...

А вот такой подход избавляет от случайных ошибок приведения целых чисел к перечислению.
class Month {
public:
static Month Januar() { return Month(1); }
....
static Month December() { return Month(12); }
private:
explicit Month(int);
};

питон никогда еще не пробовал. вот почитал чуть чуть и увидел это:
"Python поддерживает динамическую типизацию, то есть тип переменной определяется только во время исполнения."
что это значит? типа dynamic_cast в c++?
Но мне кажется что компилятор должен как можно больше делать во время компиляции(поменьше оставлять на время выполнения). т.е. выявлять ошибки несоотверствия типов.
Когда пишешь свою программу, во время написания можно всё протестировать. Но когда лазишь в огромной программе, которую не ты писал, и делаешь много изменений - нет возможности всё протестировать. Здесь безопастно полагаться только на компилятор, что он сообщит если что не так. А оставлять выявление проблемы на время выполнения - я бы не рискнул.
В с++ я предпочитаю и dynamic_cast не пользоваться(только за редкими исключениями). А в питоне получается только эта возможность и есть. Что то мне это не нравится...

"Полиморфизм (все функции виртуальные)."
копаясь в проэкте на работе обнаружил бездумное использование virtual функций. Программист 'просто так' сделал кучу функций виртуальными. На самом деле большинство из этих функций не использовались как виртуальные, т.е. наследники их не переопределяли. Дело в том что каждая виртуальная функция увеличивает трудность поддержки кода. Если я хочу изменить аргументы виртуальной функции, то мне нужно быть внимательным чтобы изменить его и у всех переобределённых функций наследников. А если я не замечу у насленика такую функцию - я сделал ошибку, которую компилятор не обнаружит, а вылезет она только во время работы.
Поэтому "все функции виртуальные" считаю недостатком языка.

Ты рассуждаешь о предмете о котором не имеешь ни малейшего представления .
dynamic typing

А зачем менять аргументы ? Просто перегрузи и используй свой вариант.

Еще раз повторяю, ты не имеешь понятия о чем рассуждаешь.

разумеется я рассуждаю только на основе моих знаний с++. Разве в питоне виртуальность не такая как в с++? разве в питоне динамическое приведение типа не такое как dynamic_cast в с++(за исключением того что в с++ это нужно писать явно, а в питоне это делается интерпретатором неявно, за кулисами)?
Тогда объясни.

интересный вопрос: зачем?
Представь себе бывает нужно поменять. Поменяешь у базового класса, поменяешь у 20ти наследников, а у 21го недоглядел, не поменял. И тогда, если у базового функция не абстрактная, то 21й наследник будет использовать именно её, а не свою специфическую. Что и есть ошибка, которая может проявиться сразу, а может и через год.

...то 21й наследник будет использовать именно её...
------
21-й наследник будет использовать ту, которая определена правилами.
В случае Плюсов, дай бог памяти, это будет последняя из определенных в предках соответсвующих факическому типу объекта.
Учи матчасть.
Что и есть ошибка, которая может проявиться
------
Она "проявляется" при тестировании. По этому вопросу, опять таки - учи матчасть.

да вот мат часть кажись я получше знаю. Так и быть объясню вам, далеко от плюсов отошедших.
Во-первых, везёт вам что занимаетесь такими программами, что есть возможность всё протестировать. Во вторых, даже тест не гарантирует отсутствие ошибок. Особенно, если тестирует не девелопер, а тестировщик, который исходники не видит, да и частенько языка не понимает. Но даже если девелопер тестирует, тоже гарантии нет. Ошибка может проявиться только после изменений, косвенно влияющих на данный код или зависящих от данного кода.
Во вторых пример.(только по существу вопроса, т.е. виртуальности. не обращайте внимание например на утечки памяти, не хочу отвлекать от сути).
У базового класса есть виртуальная функция, которая не пустая, а что-то делает. И некоторые наследники не переопределяют её. А некоторые наследники переопределяют.
class A
{
virtual void myfun(int n);
}
class B : A
{
}
class C : A
{
virtual void myfun(int n);
}
// ..... и еще 25 наследников ...
main()
{
A* p = new B;
p->myfun(76); // вызов A::myfun()
p = new C;
p->myfun(33); // вызов С::myfun()
}
Прошло сто лет и надо добавить параметр в функцию. Этот параметр обрабатывается только в функции одного из наследников (которого я здесь даже не показал), функция базового класса(А) новый параметр просто игнорирует, класса С - тоже.
class A
{
virtual void myfun(int n, bool b);
}
в A добавил, и во всех других наследниках, которые переопределяют эту функцию, кроме С. в C не добавил, не доглядел.
В main подправим, это даже компилятор потребует.
main()
{
A* p = new B;
p->myfun(76, false); // вызов A::myfun()
p = new C;
p->myfun(33, false); // вызов A::myfun() !!!!!!!!!!!!!!!!!!! ошибка !!!!!
}

dynamic_cast работает только с полиморфными типами и связь с питоном вообще отсутствует.
Ознакомься с темой, почитай о языках с динамической типизацией.

Это говорит о хреновом проектировании.
Потом ты звонишь всем клиентам и просишь поменять сигнатуры функций в клиентском коде ? :-)

Спасибо, о Гуру ! :-)

Хоть вся твоя проблема кажется надуманной, но можно сделать вот так.
class superclass{
virtual void myfun(int n, bool b)=0;
};
class A:superclass{};
С помощью компилятора найдешь все классы.

везёт вам
------
Не нам везет - куЁм свое везение сами. Частенько это стоит большего количества
работы...
может проявиться только после изменений
-----
А после изменений тестировать не надо?
ошибка !!!!!
-----
Это не ошибка - это именно то, что ты написал.
И с подобными описками тоже можно бороться. Например, можно, изначально,
еще в правилах кодинга, задать требование об отсутствии использования встроенных
типов в качестве параметров и тогда это выглядит так:
class MyFuncParam { ... }
class A
{
virtual void myfun(MyFuncParam& n);
}
...etc...

тут любые изменения не затрагивают базовый код, независимо от изменений содержимого
MyFuncParam.

С помощью компилятора найдешь все классы.
-----
Что-то меня сомнения берут. Бо, чистую виртуальную функцию обязан определять _хотя бы один_ из потомков. Как только один определит - ситуация становится эквивалентной первичной - может быть опущена в потомках.

В отличии от C++ питон выкинет исключение, а не дёрнет подходящий метод из цепочки наследования сверху. Которой и не будет вовсе. Просто, надо писать на питоне, а не на C++ с синтаксисом питона.
Наследование применяется в двух случаях - для создания функциональности в предке, чтобы не дублировать её в потомке и для реализации полиморфизма: имея ссылку или указатель на базовый класс, вызывать методы определённые в потомке. Для первой цели в питоне применяют наследование, для второй - нет.
Полиморфизм реализуют так:

class Оne:
  "One"
  def write(self):
    print "one"
class Тwo:
  "Two"
  def write(self):
    print "two"
def writer(dest):
  dest.write(" variable ")
print "start"
obj = Оne()
writer(obj)
obj = Тwo()
writer(obj)

Классы One и Two никак не обязаны быть связаными между собой, единственное, что требуется, наличие метода write(). Если мы меняем сигнатуру где-то в одном месте, а в другом забываем это сделать:

class Оne:
  "One"
  def write(self, var):
    print "one " + var

то вызов:

def writer(dest):
  dest.write(" variable ")
obj = Тwo()
writer(obj)

сгенерирует исключение:

Traceback (most recent call last):
  File "test.py", line 21, in <module>
    writer(obj)
  File "test.py", line 12, in writer
    dest.write(" variable ")
TypeError: write() takes exactly 1 argument (2 given)

писать надо короткоги ясно - не должно быть ситуаций, когда один класс делает работу всего приложения через стотыщь мильонов функций-членов, или одна функция на 10 тыс строк выполняет всю работу определенной подсистемы. Тут важно грамотное проектирование, и желательно сразу с поддержкой unit-тестов...
Очень хорошой в смысле писания "правильного" кода является книжка Code Complete - там много полезных советов на такие темы.
унаследованный код тоже можно рефакторить, избавляться от дублирования кода, разбивать длиные функции на меньшие, например, центральная функция является точкой входа, и определяет логику вычислений, но из нее зовуться только другие функции, которые и выполняют всю работу.

Если в потомке, определена, то в потомках потомка конечно не надо.
Но в его примере все наследуют от одного 'A'.

дык, а я о чем говорю! Но выбирать уже не приходится. Ты пришел на работу и у тебя есть хреново спроектированная программа. Те люди которые её писали уже здесь не работают. И твоя задача перепроектировать её получше. Эту задачу вообщето тебе начальство не ставит, начальству надо чтоб притензий от заказчиков не было и не более. Но тебе в этом дерьме ковыряться и поэтому ты сам хочешь навести там порядок, на свой страх и риск. Так вот каждая виртуальная функция усложняет эту задачу. Т.к. ошибку, которую я привёл в примере, можно обнаружить только в результате тестирования. А протестировать огромную программу не всегда возможно. Просто хотя бы из за отсутствия времени. Там где нет виртуальности - проще, т.к. об ошибке сообщит компилятор, и ты никуда не денешся - подправиш.
Виртуальность хорошая вещь, но использовать её нужно только там где без нее не обойтись. И в шею гнать надо программистов которые 'на всякий случай' делают каждую функцию виртуальной. А питон сразу делает это, даже тебя не спросит...
не понял. клиенты - простые пользователи и ни о чём вышеописанном не подозревают.

это тоже ошибка выполнения, которая обнаруживается только тестированием.

Unittest входит в базовую библиотеку питона, юнит-тестирование выявляет эту ошибку (в С++, кстати, нет). Проверка же типов / сигнатур в рантайме - особенность динамических языков.

для меня, как незнатока питона, это звучит несколько "волшебно". Т.е. юниттест "чудестным" образом обнаружит ошибку.
Разве этот тест не сам программист должен написать? Разве всегда возможно написать тест который обнаружит любые ошибки? А тест для теста тоже надо писать? ведь и в тесте может ошибка оказаться. Я не против юниттестов, наверняка очень хорошая практика, но не панацея, 100процентной гарантии нет.

Это не "любая ошибка". Программа 100% валится на попытке вызова метода - соответственно, независимо от того, что именно будет проверять юнит-тест, ошибка будет выявлена.
Тесты, да, пишет сам программист.

Это у тебя с твоим вариантом полиморфизма нет, а в тут есть.

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

http://www.amazon.de/Working-Effectively-Legacy-Robert-Martin/dp/0131177052
ps

Эта цель должна быть поставлена сверху, иначе можно сразу забить. У меня та же проблема, и время на наведение порядка уже выделено. Надо грамотно работать с начальством ;)

Ошибки выявляемые на этапе компиляции безопаснее, только все разговоры об этом в сообществе С++ сильно преувеличивают значимость статической типизации.

ну не знаю, может стоит профессию поменять :-)

а ежели не вызвал?
-----
Почитай, хоть на ознакомительном уровне, документацию к NUnit\JUnit
и посмотри примеры.
что тогда?
-----
Тогда тебя уволят. Ибо сначала делается проектирование, потом пишутся
тесты, и только потом делается и тестируется код...

З.Ы. Ответь себе на простой вопрос - Какой код является правильным? - отчень многие
вопросы отпадут.

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

редко встретишь такое непонимание!
Речь идёт о ситуации когда проектирование, тесты и сам код были написаны задолго до тебя! И написано не лучшим образом.

это спорный и далеко не однозначный вопрос

Если скорость важна, то обычно покупают больше железа. А выбирать нужно тот язык который знаешь.
Всё ИМХО

в этом то и проблема, но это скорее это проблема не только самих программеров а скорее всего и самой организации в целом и прежде всего проэкт менеджмента.
среднестатистическому проэктлидеру, который допустим мало разбираетется в программировании, наверняка пофиг как и что там реализовано и насколько рационально, для него важно что продукт работает, т.е. цели и задачи выполнены и прежде всего что все сделано в срок.
Когда требуется новые фичерс для готового продукта, то все исходят из того что готовый продукт уже работает и испробыван временем,
какието изменения в нем самом, пусть даже и необходимые, череваты тем что:
а.) эти измененя могут повлиять на сам исходный продукт.
б) на изменеение и тестерование требудется время и ресурсы, которые незапланированы.
в) соответсвенно их останется меньше для реализации самой новой функции.
Хорошо если руководство понимает что нужно навести порядок в проекте, и выделяет на это время и ресурсы, а если это делать на свой страх и риск то так или иначе, останишся крайним.

Это однозначный вопрос. Чем "ближе" я к железу, тем больше у меня возможностей для оптимизации.

С Web разработками такой подход часто имеет место быть. А для решения вычислительно сложных задач требуется не только количественный рост, но и качественный.

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

Такой подход имеет место быть везде

Т.е. плюсы - это наиболее качественное из имеющихся?

редко встретишь такое непонимание!
-----
Или наоборот. Понимание. Причем до уровня, когда сначала оценивается то,
с чем придется работать и только по результатам принимается решение по
извечному вопросу - Что делать?
задолго до тебя!
-----
Разумеется.
И написано не лучшим образом.
-----
Вот это уже вопрос к тебе.
Когда брался за работу как оценивал Сколько Работы нужно выполнить?
Насколько имеющийся код соответствует документации?
Как поставлен процесс разработки?
Что вообще от тебя ждут?
Уже сколько раз приходилось отказываться от работы просто потому, что
объем необходимой работы был много больше, чем заявляемый при найме.

да это написано в любой книжке по проэктменеджменту.
Что нужно как можно больше времени и сил отдавать спецификации
и продумать все возможные ситуации для каждого этапа
проекта и прежде всего для тестирования и только потом писать код.
Это все конечно так, вопрос только на сколько это используется на практике?
Опятьже все упирается в организацию процессов на фирме и насколько
"умный" проэктменеджмент и слаженный коллектив...

это скорость.
------
Скорость это количество процессоров в кластере.
А писать надо на том, на чем будет проще и понятнее.

В чём заключается результат? Что такое "рабочая программа"?
Если вас устраивает расчёт стоимотси опциона за 1день тогда программа делающая это за 12часов - рабочая. Но если у меня есть программа делающая это за 6 часов, то вы понимаете, кто получит прибыль ;-), которая к слову не идёт ни в какое сравнение с расходами.

Качество программы должно расти, а не только количество железа :-) Иначе бы на 8корах был бы занят только 1 :-)

покупать больше железа получается только если у тебя веб-сервис или т.п. SaaS. а вот если у тебя сотни клиентов, то приходится оптимизовывать софт, чтобы он выжимал все возможное из железок...

да я уже давно работаю на этой фирме. Просто раньше я писал свою программу с нуля. Сейчас она уже написана и редко меняется. Теперь я больше поддерживаю другие программы фирмы. А вот документации зачастую вообще нет. Впрочем есть которая описывает разные настройки, внутренние переменные которые включают-отключают фичи. Но документация реализации - такого практически нет. Да она и не нужна если программа написана понятно.

кстати, OCaml вполне себе доганяет C++ по скорости, при этом получается куча полезных вещей типа статической проверки типов и т.п. на гугл видео есть рассказ 'Caml Trading', ну и у lionet.livejournal.com есть описания производительности окамла как замены С++

Чем "ближе" я к железу, тем больше у меня возможностей для оптимизации.
------
Чем ближе ты к железу, тем меньше у тебя возможностей для оптимизации.
Просто потому, что объем низкоуровневого кода "несколько" больше и "за
деревьями леса не видно"... выиграешь в оптимизации трех команд пару нансек
и потеряешь на чем-то глобальном пару милисек...
но и качественный.
-----
Чтобы код был качественным, ты должен видеть и понимать его целиком.
На низком уровне возможность это сделать теряется.
вычислительно сложных задач
-----
Хммм... году этак в... ну да ладно об годах... В распоряжении прогера были
СМ-3, какие-то килобайты памяти, немножко мебагайт диска и транслятор с
Фортрана. Задача была не сложная - что-то из трассировки многослойных
печатных плат... Единственная проблема - размерность задачи. Она явно не
соответствовала возможностям системы - памяти не хватало.
Если кто-то возмется сейчас за день написать подсистему кеширования для
подобной задачи и справится за день - Я его буду уважать... но оценил бы
полную задачку, учитывая то железо и язык, в пару-тройку недель...
Тем не мение мужичек, которому пришлось писать код, справился с задачей
на 5-ть... и всего за день.

вопрос только на сколько это используется на практике?
------
Тут всего два варианта.
Первый - это используется - проект живет и если он имеет смысл - развивается.
Второй - это не используется - проект развивается до некоторого уровня и затем помирает.
Третьего варианта нет.
От проектменеджеров конечно зависит "многое", но они ограничены тем что знают и что
документировано...

Согласен. Поэтому не ассемблер или машинный код ;-)

Здесь я имею ввиду качественный по скорости, а не по поддержке. Ещё раз, если нужна скорость, то иногда приходится немного жертвовать дизайном. Если скорость не нужна - то и с++ часто не нужен.

В С++ есть возможности для мета-программирования. То, что какой-то компилятор для OCalm может сделать быстрый код, который работает быстрее кода, сгенерированного каким-то компилятором для с++ я согласен.

чтобы он выжимал все возможное из железок...
------
Ну это кому как...
Кто-то выжимает что может из железок, кто-то заменяет 1000 Писюков Майнфреймом...
Об том, что объем требуемых вычислений растет быстрее производительности
систем Я помню...

 ну вот мы продаем продукт. мейнфрейм клиенту для него не нужен, но вот в потолки существующих железок мы вполне упираемся...

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

Да она и не нужна если программа написана понятно.
-----
Она нужна всегда. Даже когда имеется идеально написанный код, то в этом коде
не описаны условия его корректной работы. Например, написан анализатор для
грамматики типа LL(1)... по коду требования к грамматике не определишь...
Теперь я больше поддерживаю другие программы фирмы.
-----
Тут два пути.
Путь первый. Первое - оцениваешь каждую новую задачу. Второе - говоришь шефу
- это займет столько времени. Несогласный шеф получает задачу обратно и ищет
другого исполнителя.
Второй, путь. Ищешь новую работу.

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

в потолки существующих железок мы вполне упираемся...
------
В потолки существующих железок упираюсь даже Я на своем домашнем
компостере... притом, что у меня ДЕЛЛ 1420 - пара ксеонов...

у нас сейчас стандартные модели - 4xQuadCore + куча памяти. Но потоки передаваемых данных растут быстрее чем мощность железа...

Вы не подумайте, я за дизайн :-). И рефакторинг у меня занимает достаточно много времени. Но всё таки, в частности, виртуальные функции работают медленнее обычных, и иногда приходится это как-то обходить, особенно если функция вызывается очень часто.

Но потоки передаваемых данных растут быстрее чем мощность железа...
------
Повторюсь:
Об том, что объем требуемых вычислений растет быстрее производительности
систем Я помню...

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

не ООП? :-)

ООП не панацея ;-)
Виртуальным фунциям есть альтернативы.

Разумеется ООП, но с пересмотром архитектуры задачи.

не могли бы на примере. Что такое архитектура задачи?
Вот простой пример:
У меня есть класс отвечающий за преобразование систем координат (читай трансформацию объектов). Я ему передаю точки, он мне их трансформирует.
template <typename Point>
class Transform
{
virtual void transform(Point& out, const Point& in) const = 0;
}
Т.к. объекты могут быть большими вызов функции будет частым, и если преобразование будет простым, то стоимость вызова функции будет сопоставима со стоимостью её вычисления.
Что делать? :-)

А что пишете-то?

можно не наследовать, а передавать функцию как параметер... я в одном из своих DSL строю дерево вычислений, где сразу подставляются нужные функции, а не используется наследование и вызов виртуальных функций - производительность выросла заметно...

1. Параметр чего?
2. То есть у преобразований нет общего класса?

да - тут вообще не обязателен ООП. пример можно найти в разделе 2.2.4 в SICP, это реализуется и в C++ без особых проблем

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

Завтра посмотрю, но я пока склоняюсь применить статический полиморфизм
template <typename Derivate, typename Point>
class Transform
{
void transform(Point& out, const Point& in) const { return Derivate::transform(out, in); }
}

Согласен, надо интерпретировать задачу с выгодной стороны для себя. Понял что вы имели ввиду.

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

Что значит "сразу на весь массив"? В цикле? Если функция оптимизирована как inline то разве это не одно и то же.
К слову Point здесь может использоваться не только как точка в прямом смыле ;-).

разве это не одно и то же.
-----
нет.
К слову Point здесь может использоваться не только как точка в прямом смыле ;-).
-----
Так ведь без разницы. Можно задать три произвольные парно непаралельные плоскости
и тем самым определить точку в пространстве... А можно и упростить до двумерности,
или даже одномерности, если модель позволяет...
Именно об этом Я тебе и писал...

а ведь задача в первом случае поставлена некорректно. Некорректо тем что сразу предлагается абстрактый базовый класс. Т.е. предполагается что пользователь этого класса(функция или класс которые будут с ним работать) будет работать именно с базовым классом, не зная о реальном классе(наследнике). Однако второй вариант не удовлетворяет этому требованию, т.к. здесь уже работа с конкретным классом образованным аргументами шаблона. Уже нельзя например передать пользователю массив указателей на базовый класс (где смесь указателей на разные наследники, у каждого из которых своя функцию трансформ).
Шаблоны второго типа я использовал в своей практике. А вот шаблоны с виртуальным функциями - не помню. Даже наоборот, чтобы избавиться от виртуальности класса я делал его(или его пользователя) шаблонным. Т.е. эти два приёма (в моей практике)исключают друг друга: либо шаблонность, либо виртуальность.

почему?

А можно Point = std::vector<Point3> к примеру

Зависит от того как ты сделаешь. Если начнёшь огород городить с ооп как в этом примере, то будет не одно и тоже. Заинлайнишь функции, будешь держать все вершины в одном линейном пуле - будет одно и тоже, получишь хорошо оптимизированный компилятором код на выхлопе.
А теперь к нашим баранам - виртуальным функциям. 99% случаев когда заводят речь про издержки виртуальных функций - гонят. Потому, что либо задача такая, где две лишние милисикунды не играют роли, либо архитектура кривая, либо неверно выбран алгоритм. Тут как бы глобально разговор завели, про динамические языки сказав: а) виртуальные функции порождают проблемы при изменении кода, б) они медленные. Так вот, глобально - они не порождают там проблем и они быстрые, а специфичные случаи десятков миллионов вызовов, это просто специфичные случаи, где оптимизация в виде отказа от лишнего такта на поиск в vtbl должна проводиться в самую последнюю очередь, после выбора правильной архитектуры и алгоритма.

Компилятору, я думаю, всё равно, метод класса или функция.

Согласен.

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

Да, это понятно. Но если у меня объекты лежат в массиве и я на каждый объект вызваю функцию, то должно быть одинаково. Коммутативность вроде как. Поэтому и классы тут должны быть непричём.

На последнего. К вопросу об том, на каком уровне должно быть кодирование:
C# Trading Software Developer v Dublin City
A new position has opened up with one of Dublin-s financial trading companies.
We are seeking a talented Senior Software Engineer who has previous Trading platforms / investment banking development experience.
This position requires the candidate to have solid C# or C++ development skills. Java will also be accepted as long as you can demonstrate the ability to write low-level code. You will be working on a real-time trading system.
З.Ы. из вчерашней почты.

в ближайшее время с рынка провалят типичные процессоры типа Intel 86
их заменят FPGA
и програмирование на классическом С++ также к динозврам..
накроется медным тазом Windows и братва которая его так долго писала..... "Бил" почит в позе бозе туда ему и дорога.... придурку тормоз ходячий
ну если кому хочеться ещё париться на старых технологиях и инвестировать время в покойников ! почему бы не мусолить тему !

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

мне кажется что вы немного выдаете желаемое за действительность:
1. FPGA никогда незаменят чипы процессоров, хотябы потому что они гораздо дороже чем ASIC при массовом производстве.
2.почему собственно? Т.е. вы думаете что "аппаратное" программирование намного проще,
гибко, универсально и намного дешевле? сомневаюсь. Стадартизированные языки как раз намного удещевляют и упрощают рещение
конкретных задач.
3. кто бы как неотносился к Билли но факт остается фактом, его продукты
ипользуются в бизнесе намного чаще чем остальные, и даже в индустрии, поэтому и для потребителя дещевле испльзовать системы для уже
существующих платформ чем заказывать новое железо, новые операционки и т.д.

скорее всего человек имеет ввиду чтото типа VHDL или Verilog

париться на старых технологиях
------
Гы... и это говорит человек, желающий купить радиоламы?

а на чем программироваться будут эти процессоры?
------
Они будут чудесным образом самопрограммирующиеся - на что захотят - на то и запрограммируются...
пока количество новых программ превысит и вытеснит количество старых
-----
Эээ... набери в поисковике "кобол программист" и посмотри насколько вытеснен Кобол последними новинками...

кстати когда пред миром остро встала проблема Y2K то многие большие фирмы приглашали "пионеров-пенсионеров" которые знают старые языки и платили им за это неплохие денюЖки...

многие большие фирмы приглашали
------
Они и сейчас ищут. И делают это на регулярной основе. Просто далеко не каждый прогер
может работать в режиме - "строка 576, идентификатор 'Home29' заменить на 'Home28'"...