Как понять в базовом классе что виртуальная функция была перегружена в наследнике?

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

Правильно ли я понимаю, что у вас внутри calc вызывается два виртуальных метода (условно make_local_matrix и patch_global_matrix) и именно эти методы переопределяются в производных классах? И что в каких-то случаях, условно, patch_global_matrix не должен ничего делать?

Да. Каждый метод вызывается в своем цикле.

Тогда, грубо говоря, напрашивается создание дополнительных иерархий. Например:

class global_matrix_patcher_context {...};
class global_matrix_patcher_iface {
public:
  virtual void patch(global_matrix_patcher_context & ctx) = 0;
};
class actual_matrix_patcher : public global_matrix_patcher_iface {
public:
  void patch(global_matrix_patcher_context & ctx) override {...}
};
class noop_matrix_patcher : public global_matrix_patcher_iface {
public:
  void patch(global_matrix_patcher_context & ) override {}
};
...
class solver {
  virtual global_matrix_patcher_iface & get_patcher() = 0;
  ...
};

Внутри calc() вы формируете объект global_matrix_patcher_context и вызываете виртуальный метод get_patcher(), который вам вернет ссылку на global_matrix_patcher_iface. У этого patcher-а вы вызываете patch(), в который отдаете context. И уже внутри patch() делаете нужный цикл. Или вообще ничего не делаете.

Т.е. вместо того, чтобы делать цикл внутри calc перед которым вы проверите нужно ли что-то делать или нет, вы весь цикл перемещаете внутрь patch. А patch сможет забирать все нужное через context.

Это если вы хотите в рамках ООП оставаться. Но можно и без ООП здесь обойтись.

Ну начнем с того что я не хочу оформлять контекст в отдельный объект (и вообще не хочу его как то оформлять). И так мне пришлось вынести часть контекста в поля базового класса, и это оскорбляет мое чувство прекрасного - но пока сойдет.

Но главное, зачем делать сложно то что можно делать просто? Потому что кто то когда то забудет перегрузить check? У нас в этом проекте три разработчика (включая меня), два из них должны написать пять солверов-наследников. Ради этого я буду вводить доп. иерархии? Не буду, тут чем проще тем лучше.

Это если вы хотите в рамках ООП оставаться. Но можно и без ООП здесь обойтись.

Мне вообще пофик в какой я парадигме, я уже давно вышел из того возраста что бы заморачиваться по этому поводу. Я Вам жуткую вещь скажу, за вот такое:

class A{
  double x;
public:
  double get_x() const { return x; }
  void set_x(double x_){ x = x_; }
};

class A{
public:
  double x;
};

Но главное, зачем делать сложно то что можно делать просто?

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

Тогда вообще заведите в solver-е метод get_patcher, который будет возвращать либо указатель на реальную функцию, либо nullptr для случая, когда вам делать ничего не нужно. Получится, что в calc перед циклом вызвали get_patcher, проверили на nullptr, если не nullptr, сделали свой цикл.

Да и вообще, можно не метод get_patcher, а просто в solver-е завести поле типа указатель на функцию patcher. Наследник будет это значение задавать. А в calc вы его сможете проверять.

И не нужно извращаться с check-ами и проверками на переопределение виртуального метода в наследниках.

class A{
public:
  double x;
};

не хотите сношать мозг, будьте проще:

struct A {
  double x;
};

Раз вы пошли по пути ООП, значит вам нужно было абстрагирование от деталей.

Ой, ООП это инструмент (один из многих) а не религия. Можно делать ООП в С, можно на плюсах писать в функциональном стиле (хотя это сложнее).

Тогда вообще заведите в solver-е метод get_patcher,

Это сложнее чем check перегрузить.

Да и вообще, можно не метод get_patcher, а просто в solver-е завести поле типа указатель на функцию patcher.

А это уже конструктор придется делать (пока его нет).

Нет, при выборе чистота стиля vs простота я всегда выбираю простоту;-) Но это уже философия...

не хотите сношать мозг, будьте проще

Именно так я обычно и пишу;-) Но иногда таки по делу бывают приватные поля. Хотя первое что я показываю студентам, это как получить доступ к приватному полю. А то многие считают что это прямо какая то защита данных...

Ой, ООП это инструмент (один из многих) а не религия.

Молоток и микроскоп — это тоже инструменты (одни из многих). И оба могут использоваться для забивания гвоздей. Если вы используете микроскоп вместо молотка, то вам никто этого не запретит, но удивление вы вызовете, это точно.

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

И, по факту, полиморфизм здесь и не нужен-то особо.

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

Покажите пожалуйста, где я отказался от полиморфизма.

Но главное, зачем делать сложно то что можно делать просто? Потому что кто то когда то забудет перегрузить check? У нас в этом проекте три разработчика (включая меня), два из них должны написать пять солверов-наследников. Ради этого я буду вводить доп. иерархии? Не буду, тут чем проще тем лучше.

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

Насчет того, что вам тут кучу левых советов дали/дают - тут уже можно призадуматься, а может не такие уж они и левые, если советы одни и те же и дают их разные люди. Но ни в коем случае не собираюсь вас учить чему-либо или советовать, просто мысли вслух.

Добавление метода check (виртуального или невиртуального) указывает на то, что базовый класс начинает зависеть от деталей реализации производного класса. Это и означает «прощай полиморфизм».

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

Всё это звучит как: «Я! ХОЧУ! ЗАБИВАТЬ! ГВОЗДИ! МИКРОСКОПОМ!!! ЧТО НЕПОНЯТНОГО?! ГВОЗДИ ЗАБИВАЮТ МИКРОСКОПАМИ!!!»

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

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

Еще раз, следите за руками.

1) Если гонять цикл с patch_global_matrix без чека (всегда), то с полиморфизмом никаких проблем нет, не так ли?

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

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

4) Да, с т.з. «чистого ООП как религии» нужно цикл переносить в потомка. Либо выделять весь цикл в отдельную ф-ю, делать более сложной иерархию базовых классов и т.д. и т.п. - и маяться при этом с передачей контекста. И это будет очень наглядной иллюстрацией того, почему в олдскуле разработки числодробилок ООП является ругательством. Полученный код будет прекрасен, никто не забудет перегрузить метод check() - но с т.з. производительности и удобства расширения (в описанных пределах) это будет жуткая жуть. Потому что коллеги перегрузку check поймут сходу, а от игрищ с передачей контекста будут шарахаться вытаращив глаза.

разные это какие? Вот скажем KennyMinigun сходу ответил на поставленный вопрос, объяснил почему так в лоб делать нельзя, и подкинул идею с перегрузкой check(). Без множества лишних букв.

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

Аналогия с микроскопом и гвоздями не уместна, и вообще аналогия не является аргументом или доказательством.

Так вот. как правило оптимизация затрагивает несколько уровней абстракции (это неизбежная плата за оптимизацию).

Оптимизация, которая затрагивает несколько уровней абстракции — это не оптимизация, это перепроектирование.

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

По поводу производительности — это от кривизны рук зависит. По поводу удобства расширения — зависит от того, сколько разных кейсов дальнейшего расширения будет видно сразу. Чем больше — тем меньше проблем в будущем.

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

Так тут и с check-ом получаются лишние телодвижения. Да и с производительностью вопросы. Ибо, по факту, у вас есть некий блок кода, который зависит от двух параметров: a) нужно ли этот блок кода выполнять вообще и b) операция, которая часто вызывается внутри этого блока.

Вы эти параметры пытаетесь задать через виртуальные методы. Что для параметра b) чревато потерями на косвенный вызов.

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

Хотя лично мне вообще фиолетово. Я много разных извращений видел. В том числе и тех, которые были обусловлены объективными причинами. Но вот чтобы костыли так рьяно защищали...

Оптимизация, которая затрагивает несколько уровней абстракции — это не оптимизация, это перепроектирование.

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

Что для параметра b) чревато потерями на косвенный вызов.

Это копейки по сравнению с самим методом, он достаточно толстый.

Если бы вы оба эти параметра задавали через шаблоны

А тут вылезает еще один нюанс - этот код биндится в питон через SWIG. Биндинг шаблонов возможен, но неприятен. Если бы шаблоны были оправданы (с т.з. гибкости или производительности) то никуда не деться, но в данном случае они не нужны.

А так выглядит как то, что вы всеми силами хотите убедить форумчан в том, что вы все делаете правильно.

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

Знаете, есть такой парадокс. Очень редко среди разработчиков числодробилок встречаются настоящие программисты (я к таким тоже не отношусь). И не потому что мало платят или там еще что то... настоящий программист с опытом работы в большой конторе будет все делать очень правильно, но его код не будет работать. А жуткое кривое поделие кого нить кто не знает что такое полиморфизм (вообще) работать будет. Это сухая констатация факта, увы...

Это копейки по сравнению с самим методом, он достаточно толстый.

Т.е. у вас есть:

for(int i = 0; i != N; ++i)
  f(i, ...);

и вы хотите оптимизировать это вот так:

if(check) {
  for(int i = 0; i != N; ++i)
    f(i, ...);
}

потому что вызов пустого f() дорого. Тогда как непустой f() получается на порядок-два «тяжелее» пустого.

А вы уверены, что эта возня с check-ом вообще даст вам какой-нибудь прирост, тем более, что вызываться это будет из Python-а?

А тут вылезает еще один нюанс - этот код биндится в питон через SWIG.

У вас методы check() и f() будут из Python напрямую вызываться?

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

Так нужно определиться либо для вас производительность важна, либо нет. Если не важна, то все разговоры о «с т.з. производительности и удобства расширения (в описанных пределах) это будет жуткая жуть.» идут прямиком в /dev/null.

Знаете, есть такой парадокс. Очень редко среди разработчиков числодробилок встречаются настоящие программисты (я к таким тоже не отношусь). И не потому что мало платят или там еще что то... настоящий программист с опытом работы в большой конторе будет все делать очень правильно, но его код не будет работать. А жуткое кривое поделие кого нить кто не знает что такое полиморфизм (вообще) работать будет. Это сухая констатация факта, увы...

Это не пародокс, это реалии жизни. Очень много софта пишется НЕпрограммистами, причем критически важного типа оборудования для АЭС. Это объясняется тем фактом, что проще врача/физика/экономиста и т.д. обучить навыкам программирования, чем программиста научить разбираться в медицине/физике/экономике и т.д.

А вы уверены, что эта возня с check-ом вообще даст вам какой-нибудь прирост, тем более, что вызываться это будет из Python-а?

Из питона вызывается calc(), который ну очень толстый.

У вас методы check() и f() будут из Python напрямую вызываться?

Нет конечно. Но лишняя параметризация это всегда для SWIG геморрой.

Так нужно определиться либо для вас производительность важна, либо нет. Если не важна, то все разговоры о «с т.з. производительности и удобства расширения (в описанных пределах) это будет жуткая жуть.» идут прямиком в /dev/null.

1) Производительность важна. Проверка check() и накл. расходы на вызов вирт. методов в данном случае малы, ровно как и накл. расходы на исп. питона.

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

И главное -а к чему этот разговор? Вы меня пытаетесь в чем то убедить? Вы пытаетесь что то понять для себя? Я не понимаю, а к чему вот эти много букв сейчас?

Это объясняется тем фактом, что проще врача/физика/экономиста и т.д. обучить навыкам программирования, чем программиста научить разбираться в медицине/физике/экономике и т.д.

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

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

Я не понимаю, а к чему вот эти много букв сейчас?

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

Плюс к тому вы явно удивились реакции, между тем, реакция вполне себе ожиданная. Я пытаюсь объяснить вам чем она была вызвана.

Ну вы же сюда пришли за чем-то. Что бы что-то узнать.

Ну я уже все что хотел по заданному вопросу узнал;-)

Плюс к тому вы явно удивились реакции, между тем, реакция вполне себе ожиданная. Я пытаюсь объяснить вам чем она была вызвана.

Да нет, это типичная реакция ЛОР-а. Из нетривиального - я вот задумался, насколько специфика мышления проф.программистов виновата в том что они не могут работать над числодробилками. Ведь моя специфика мышления как физика мешает мне быть программистом, вон как все возбудились на невинные на мой взгляд вещи...

Судя по этому треду, стиль мышления проф.программиста ортогонален стилю мышления физика

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

Все таки ИМНО это стиль мышления. Скажем математики думают совершенно не так как физики, ооох как с ними тяжко бывает...

Тут нужно или все-таки договориться и учесть все аспекты

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

найти специалиста одновременно во всех нужных областях

Увы, нельзя объять необъятное. Людей умеющих на приличном уровне кодить, знающих физику и числ. методы исчезающе мало - хорошо если два из трех присутствует.

Судя по этому треду, стиль мышления проф.программиста ортогонален стилю мышления физика, хотя и то и то естественные науки.

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

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

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

Я бы не стал обобщать. Многих нынешних программистов вообще не учат вычислительный код писать. Но те, кого учили это делать, проблем с числодробилками не испытывают.

Для программиста код — это основной результат (а при сопровождении еще и основные входные данные).

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

Мне приходилось работать с чужими кодами на фортране древними как те самые мамонты. Но конечно как правило от работы с чужим кодом пытаются уворачиваться, если это только не какие то специфические библиотеки. Ну и с т.з. программирования числодробилки довольно таки примитивны (большинство из них). Это не браузер и не СУБД... Обратная сторона - обычно их пишут маленькими коллективами (больше одного разработчика уже редкость) и пишут довольно быстро.

Но те, кого учили это делать, проблем с числодробилками не испытывают.

А где их взять? У нас вечные проблемы, найти человека на проект...

Наверное, ты прав во всём. Осталось только понять, почему реакция на твоё сообщение не такая, какую ты ожидал.

Бггг, я бы сильно удивился если бы тут не пришло несколько человек которые бы начали говорит что все делается неправильно.

Даже если начать заниматься сексом на красной площади, советов наверное будет меньше чем на ЛОР-е по поводу правильного дизайна кода;-)

Очевидно что ему все завидуют, как тому метанпрогу, поэтому и говорят, что он сделал костыли

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

Ну вот на фоне всего этого трудозатраты на код оказываются всего лишь процентами от общих трудозатрат.

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

А где их взять?

На рынке?

У нас вечные проблемы, найти человека на проект...

А у нас — объяснить, что наши цены — это еще не дорого :)

Ну вот на фоне всего этого трудозатраты на код оказываются всего лишь процентами от общих трудозатрат.

Ну не процентами... хотя мне трудно понять как оценивать трудозатраты в этой области. По человеко-часам не очень выходит. В последние годы я долго думаю и потом быстро делаю. Вот как это «долго думаю» оценить?

На рынке?

Три грустных ха. История «год ищем человека на проект с хорошей ЗП» это правило а не исключение. Все кто нормально умеет писать числодробилки уже пишет числодробилкии и на них очередь стоит.

Вот как это «долго думаю» оценить?

Зависит от того, занимаетесь ли вы продуктовой разработкой, заказной или аутстафингом :)

Три грустных ха.

А вы именно в штат ищите?

https://stackoverflow.com/questions/1966362/sfinae-to-check-for-inherited-mem...

дальше наследование от промежуточного шаблонного класса, если надо чтобы шаблоны наружу не торчали

Ну вот на фоне всего этого трудозатраты на код оказываются всего лишь процентами от общих трудозатрат.

Это если уже разбираться в используемом ЯП. А если на ЛОР выяснять базовые вопросы каждый раз, когда вроде хотелось бы применить какую-нибудь «новомодную» фичу (которой не было в Фортран77), но чe-то не получается, то эти проценты могут вырасти во что-то существенное. Непонятно, почему автор использует С++. В науку пробрались злобные программисты и насилуют физиков С++'ным ООП? Ведь ветка эта создана на ЛОР с обсуждением «как сделать на С++», а не на форуме физиков, «как сделать на Фортране». T.e. что-то заставляет автора колоться, плакать, но продолжать есть кактус. Хотя, упоминание о троллинге говорит о многом :)

А подавляющее число современных числодробилок пишутся на плюсах.

Зависит от того, занимаетесь ли вы продуктовой разработкой, заказной или аутстафингом :)

Я не знаю таких слов;-(

А вы именно в штат ищите?

По разному. Коллеги тут в штат искали, иногда ищут на конкретный проект...

По разному. Коллеги тут в штат искали

С поиском в штат есть та проблема, что вы ограничены локальным рынком + некоторым числом разработчиков, которые готовы на переезд к вам (соответственно, чем меньше город, тем уже список предложений).

А подавляющее число современных числодробилок пишутся на плюсах.

Что же они, дураки все, берут этот дурацкий С++, который пахнет ООП, когда все можно было на теплом ламповом Фортране77 зачислодробилить?

Старшие товарищи тоже недоумевают. Модно, молодежно?

Город то Москва... но это не спасает.

Старшие товарищи тоже недоумевают. Модно, молодежно?

Ну так покажите сосункам, как быть настоящими мужчинами - только Фортран, только хардкор. С какого года там в Фортран ООП ввели, с 2003? важно заранее знать, а то дашь студням задание - и они и на Фортране в ООП вляпаются.

Город то Москва…

Ну так и Москва по сравнению, скажем, со Штатами – это отнюдь не большой рынок труда, со своей спецификой.

Для реализации конкретного солвера нужно отнаследовать базовый и перегрузить виртуальную ф-ю

Всё ещё не вижу необходимость проверять оверрайды в рантайме, тем более для виртуальных.

Сделать pure virtual и таким образом обязать имплементировать в потомках. А если нужно чтобы метод потомка не влиял на результат — так и писать ничего не делающей пустой заглушкой.

Наследников будет штук пять

Тем более не проблема.

Тогда вообще заведите в solver-е метод get_patcher, который будет возвращать либо указатель на реальную функцию, либо nullptr для случая, когда вам делать ничего не нужно.

Вон виш, eao197 об том же самом.

Не, ну с США мы по уровню ЗП конкурировать не можем. Хотя кое кто оттуда у нас работает, но это джаст фор фан - у нас интересно;-).

зачем? Я и сам то фортрана не знаю, мы студентов сразу плюсам учим.

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

Не, ну с США мы по уровню ЗП конкурировать не можем.

Так это как раз часть специфики работы в Мск. Далеко не все горят желанием переезжать в Мск. И, если уж срываться с места, то почему бы не туда, где изначально уровни ЗП выше, а климат приятнее :)

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

С этим не поспоришь, я сам больше люблю занятость по проектам. Хотя у нас и в штате то свободный график (и даже случаи удаленки были, в госорганизации). Российские учОные фконец распоясались;-)

А если геттер на сеттере сидит и толстый объект по значению возвращает, да еще и в куче постоянно память выделять пытается - тады ой...

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

А свой менеджер памяти - это стандартные или нестандартные выкрутасы с содержимым объекта в памяти? А лазить в поля структуры по смещению и кастовать пойнтер?

«стандартные выкрутасы» являются стандартными для каких то стандартных задач - с чего Вы взяли что числодробилки High Performance Computing к этим задачам относятся?!

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

Бгг, Вы бы слышали как фортранисты поливают плюсовиков на научных семинарах - местные ЛОРовские срачи это детский сад. И ведь все по своему правы... но увы, старая школа уже уходит. Физически;-(

с чего Вы взяли что числодробилки High Performance Computing к этим задачам относятся?!

Ваш изначальный вопрос был конкретный, про конкретное использование языка С++, а не про поболтать о том, какие интересные штуки-хрюки бывают в High Performance Computing. Есть какой-то аргумент в пользу того, что надо извращаться с невиртуальным методом и наследованием, и что подобное извращение актуально только в области HPC? Тем более, что мы уже выяснили, что в вашем случае виртуальный вызов вместо невиртуального - это не дорого? Хаки с невиртуальним методом - это одно, сеттеры-геттеры - другое, собственный менеджер памяти - третье, и все это нельзя грести под одну гребенку «так надо, потому что такая область». Одно может быть неадекватным в любой области, другое - неадекватным в одной области и вполне адекватным компромиссом в другой.

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

ну это понятно, С++ из другой области вылез

Можно ли забивать болт молотком? Понятно что нельзя, это моветон. Тем не менее в альпинизме изначально для ИТО использовались болты которые именно что забивались в выдолбленное отверстие именно что молотком. Удобно, держит сколько нужно (ногой встать), и можно легко купить.

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