Критерии хорошей, годной архитектуры

> Меня в свиге долбит три вещи:

Главный недостаток SWIG - он практически не понимает ни Си, ни Си++. Вроде сейчас есть генератор биндингов к Си++ на основе gccxml - это расово верный подход, но в деле я это не пробовал.

Поначалу прочел и аж дух захватило - чем же мы по средам у доски тогда занимаемся???

простите, это я не знаю чем Вы занимаетесь по средам у доски, но последние 5 лет я занимаюсь управлением командами разработчиков (и успешно), и, уж поверьте, проектирование архитектуры - это всегда «конкретные задачи решать», а ещё конкретные документы писать

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

сэр, я прекрасно помню о чём мы с Вами говорим, позволю себе процитировать Ваше исходное сообщение, к которому я апеллировал:

Связка Python и C++ форевер! Начнем рождественский холвиар?

смотреть тут

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

если что, вот Вам цитата:

Правильная архитектура подразумевает в частности применеие правильных инструментов, в частности правильных ЯП, для решения конкретных подзадач, что приводит в итоге к уменьшению чиcла строк кода;-)

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

Как через полиморфизм породить кучу списков для разных типов без оверхеда страшно любопытно посмотреть. МОжно в почту - aivanov(собака)keldysh(точка)ru

Спецкурс начинается в этом семестре (с фервраля/марта наверное - когда студенты появоятся в общем), корп. В комн. 81, скорее всего по четвергам будет в районе 14.00 начинаться. Математики там нет, сплошное программирование, если и правда интересно могу в почту кинуть программу.

За ссылку на SIP спасибо.

> простите, это я не знаю чем Вы занимаетесь по средам у доски, но последние 5 лет я занимаюсь управлением командами разработчиков (и успешно), и, уж поверьте, проектирование архитектуры - это всегда «конкретные задачи решать», а ещё конкретные документы писать

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

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

Если можно.

> Главный недостаток SWIG - он практически не понимает ни Си, ни Си++. Вроде сейчас есть генератор биндингов к Си++ на основе gccxml - это расово верный подход, но в деле я это не пробовал.

Гхм... мой примитивный C++ он в основном понимает;-)

> 2. то что Вы что-то не видели не может считаться доказательством отсутствия оного, считал что это должно быть очевидно

Буквально на днях обсуждали обзор наиболее распространенных в мире кодов для моделирования плазмы. Применяемые в них ЯП: С++, fortran, Python.

это прекрасно сэр, но повторюсь - отсутствие известных Вам прецедентов не может считаться опровержением/доказательством

> Буквально на днях обсуждали обзор наиболее распространенных в мире кодов для моделирования плазмы. Применяемые в них ЯП: С++, fortran, Python.

это прекрасно сэр, но повторюсь - отсутствие известных Вам прецедентов не может считаться опровержением/доказательством

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

>> Главный недостаток SWIG - он практически не понимает ни Си, ни Си++. Вроде сейчас есть генератор биндингов к Си++ на основе gccxml - это расово верный подход, но в деле я это не пробовал.

Гхм... мой примитивный C++ он в основном понимает;-)

И что, не приходится писать typemap'ы?

Приходится... а что ж делать-то?

Не понимает, это когда вообще не собирается - такое бывает, но редко.

Глянул boost http://tilarids.blogspot.com/2008/08/boost-python.html прям обещают златые горы и реки полные вина. Надо будет поковырять...

> Приходится... а что ж делать-то?

А мне с python-ctypeslib (основан на gccxml) - не приходится.

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

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

Разработка ПО - не наука. И тут нету нормальных определений и терминов. Согласно одним определениям архитектура и язык связаны, согласно другим - нет.

Тут спрашивали какую нотацию используют тру архитекторы. Начнем с того, что под должностью «архитектор» подразумевают разное. Некоторые под этим понимают главного админа (архитектор системы), кто-то руководителя разработки (главный среди главных программистов по технической части), в быдло-конторах это чертила UML во главе обезьян.

Наиболее адекватные архитекторы на мой взгляд используют маркерную доску и произвольную нотацию. Лично я люблю упрощенные сиквенс-диаграммы.

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

уточнение: речь шла про минимальный оверхед :)

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

#include <stdint.h>
#include <iostream>

class plain_data_type {
public:
	virtual void add(const plain_data_type* /*other*/) = 0;
	virtual void print() const = 0;
};

class int32_data_type : public plain_data_type {
public:
	
	typedef int32_t data_type;
	
	int32_data_type() : _value(0) { }

	explicit int32_data_type(data_type v) : _value(v) { }

	data_type value() const {
		return _value;
	}

	void set(data_type d) {
		_value = d;
	}

	void add(const plain_data_type* other) {
		this->_value += ((int32_data_type*)other)->value();
	}

	void print() const {
		std::cout << "int32_data_type value is [" << _value << "]" << std::endl;
	}
	
private:
    data_type _value;
};

int main()
{
	plain_data_type *d1, *d2, *d3;

	d1 = new int32_data_type(10);
	d2 = new int32_data_type(20);

	d1->add(d2);
	d1->print();

	return 0;
}

оверхед будет, но небольшой, относительно размера алгоритмов в большом и серьёзном проекте - вообще незаметный (имхо)

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

и да, чуть только нужен будет какой нестандартный тип - Вы тут же упрётесь в данную (или похожую) концепцию, что с шаблонами, что без них

//да, сам чаще использую шаблоны :)

Спецкурс начинается в этом семестре (с фервраля/марта наверное - когда студенты появоятся в общем), корп. В комн. 81, скорее всего по четвергам будет в районе 14.00 начинаться. Математики там нет, сплошное программирование, если и правда интересно могу в почту кинуть программу.

ок, тогда стукнусь в почту, заранее спасибо :)

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

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

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

Если можно.

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

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

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

специально старался не привязываться к определённой идеологии разработки и проектирования дабы не вводить лишних сущностей, так что если получилось малец сумбурно - извиняйте )

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

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

ну в физике (да и не только) известно много таких «установлений», причём последующие, скажем так, нередко «уточняли» результаты предыдущих с точностью до «всё оказывается совсем не так»

>помимо ошибочного (если хотите, могу пояснить подробно) связывания архитектуры и ЯП

Разработка ПО - не наука. И тут нету нормальных определений и терминов.

так, теоретики подтянулись :) идите-ка Вы голубчик просвещайтесь «насичот» rational unified process и его терминологии, к примеру

Тут спрашивали какую нотацию используют тру архитекторы.

разную, потому что существуют разные подходы и методики

Начнем с того, что под должностью «архитектор» подразумевают разное. Некоторые под этим понимают главного админа (архитектор системы), кто-то руководителя разработки (главный среди главных программистов по технической части), в быдло-конторах это чертила UML во главе обезьян.

Вы ещё про некоторые гос. конторы вспомните, там часто считается, что архитектор - это тот кто кирпичи кладёт «узорчиками»

идите-ка Вы голубчик просвещайтесь «насичот» rational unified process

Не, в фекалиях копаться не буду. Может еще меня на MS Project пошлете?

>идите-ка Вы голубчик просвещайтесь «насичот» rational unified process

Не, в фекалиях копаться не буду.

так, с Вами всё ясно, теперь вопрос - стоило ли портить клавиатуру и 4.2 наглое писать, раз Вам в теме разбираться лень?

Может еще меня на MS Project пошлете?

только в качестве наказания за очень большую провинность :)

раз Вам в теме разбираться лень?

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

Читал я про RUP по диагонали [..] люди родившее такое ниале

Фигня этот ваш Карузо! Мне Рабинович напел. (с)

Код... ну назвались кузовом - получайте груздей.

Если Вы и правда рук. группы разработчиков, то вроде как должны внимательно читать ТЗ. Я просил показать, как при помощи полиморфизма можно с минимальным оверхедом реализовать списки целых чисел и скажем double. Я не просил делать общий список разнорожных элеметов. Вы сделали список чего угодно (все что угодно моно обернуть data_plain-ом, например строку или файловый объект и сунуть в этот список), те формально требобвания даже перевыполнили. Плюсы - типа меньше нагрузка на компилятор и типа возможно динамическое связывание (так что ли г-н А писал?).

НО: таки для каждого нового типа придется наследника компилировать, так что про компилятор и дин связывание ИМНО некий миф. Остальное минусы - в списке может оказаться все, что угодно. Производительность ни к черту - вирт ф-ии вообще то требуют по крайней мере 20 тактов, если паямть не изменяет, не говоря про разрушение конвейра. Размер каждого элемента увеличивается на size_t. Для получения доступа к значению придеться юзать динамик каст. Про число строк кода я вообще не говорю.... А почему? Потому что кто то написал, что шаблоны могут быть заменены этой вот фигней...

Параметризация и пролимофизм все же ИМНО существенно разные вещи. Их можно использовать вместе (аццкая смесь выходит), можно по отдельности... КОнечно, можно забивать гвозди микроскопом и плющить молотком инфозорий так, что б их потом невооруженным взгялдом изучать, но мне казалось, что профи то должен знать чем надо бить а через что смотреть на инфузорий;-))))))

Что-то это? Аргумент №1? Сперва добейся типа? Нет уж, спасибо. Очевидно бред этот RUP. Аргументировать не буду. По опыту знаю, что есть вещи в программировании, понимание которых нельзя передать словом, т.к. имеют простарнственно-образный, не вербальный характер.

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

на самом деле, если хорошенько приглядеться, архитектор вовсе и не обязан хорошо программировать,

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

ну в физике (да и не только) известно много таких «установлений»

Вам, пардонте, лавры Эйншетйна покоя не дают? Или Петрика?;-))))) Заметьте, что в физике новые теории не опровергают старых а лишь фиксируют область их применения и показывают что будет за этой областью. В IT все динамичней конечно... но пока что изложенные мною факты остаются фактами. Хотя со временем безусловно все изменится.

> оверхед будет, но небольшой

Виртуальная функция - это как минимум VPTR, что дает оверхед 32 бита. Для объекта «32-бит целое число» - это 100% оверхеда.

Если за двусвязный список говорить, то у него два пойнтера как мин еще. Так что даже для char на 64 битах это будет только 30%. Для односвязного 50%. Но дело даже не в том - это ж скока написать то надо будет... жууууть.

Ой, знаете, мы с Вами чуток о разном. Все вот в терминах UML чего то формулируют, я даже пытался че то читать по этому поводу... «Сильным это не нужно, а слабым не поможет». Для своих задач я как то все необходимые паттерны уже сам давно придумал (а они оказывается имеют офиц названия). А те которых не придумал - те мне просто не нужны, уж простите за такой дилетансткий снобизЪм. Это как с gdb - парился что вот как то им не пользуюсь... потом понял, в простых случая он не нужен, в сложных бесполезен, мосг и хорошая дигностика все равно эффективней.

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

То, что Вы называете проектированием архитектуры - для нас этот этап давно в прошлом, все ясно и прозрачно.

Это пока вы не начали писать чуть более другой тип приложений :)

А так согласен практически во всем.

Если Вы и правда рук. группы разработчиков, то вроде как должны внимательно читать ТЗ. Я не просил делать общий список разнорожных элеметов. Вы сделали список чего угодно (все что угодно моно обернуть data_plain-ом, например строку или файловый объект и сунуть в этот список), те формально требобвания даже перевыполнили.

эм, прошу прощения, наверное стоило дать пояснения, просто в 3 часа ночи голова не то чтобы чётко мыслит, я рассматриваю оверхед как написание одних и тех же алгоритмов для int, float, double и complex :) и, очевидно, это будет самый большой оверхед, гораздо больше описания типов вышеуказанным способом

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

//да, там есть несколько сложностей, о которых я не упомянул, но они все решаемые

Плюсы - типа меньше нагрузка на компилятор и типа возможно динамическое связывание (так что ли г-н А писал?).

про нагрузку на компилятор - это Вы зря, он «железный» - ему всё равно, про динамическое связывание - тоже не совсем то, а вот то что такие типы данных можно протаскивать через всякие FFI и бинарные интерфейсы - это да

НО: таки для каждого нового типа придется наследника компилировать,

в данном случае только для добавления типа, в случае шаблонов - уже для использования, чувствуете ньюанс?

так что про компилятор и дин связывание ИМНО некий миф.

Вы его придумали, не я :)

Производительность ни к черту - вирт ф-ии вообще то требуют по крайней мере 20 тактов, если паямть не изменяет, не говоря про разрушение конвейра. Размер каждого элемента увеличивается на size_t.

охохо, это самый весёлый вопрос :)

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

ну и на закуску - вот Вы учитываете в своём коде различия между между реализацией процессоров AMD и Intel, а по семействам? :)

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

а размер - фиг с ним, честно, мы совсем не про него говорим, не так ли?

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

так что, Вы не согласны что они могут быть заменены? :)

Да понял я, понял. Уже ж договорились;-))))

Оба решения имеют право на существование, ну а дальше... у каждой зверушки свои погремушки.

так что про компилятор и дин связывание ИМНО некий миф.

Вы его придумали, не я :)

Ну нет, я про это услыхал от Вас, а Вы вычиали у А... выкиньте А и возьмите лучше Дж.Элджера - ИМНО самая внятная книга по продвинотуму С++;-))))))))))))))

Параметризация и пролимофизм все же ИМНО существенно разные вещи.

вне всякого сомнения, разрешаю Вам застрелить всякого кто говорит иначе :)

Параметризация и пролимофизм [..] Их можно использовать вместе (аццкая смесь выходит)

«аццкая» смесь получается не из-за смешения параметризации и полиморфизма, а как следствие недостаточной квалификации разработчиков :)

Что-то это? Аргумент №1? Сперва добейся типа? Нет уж, спасибо.

нет, это к тому что о вкусе устриц есть смысл спорить лишь с тем кто их ел

Очевидно бред этот RUP.

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

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

мистический склад сознания? :) может Вам в философы?

О-хо-хо... если хотите всерьез говорить за эффектиновсть, то это не здесь, и даже лучше не со мной - приходите к нам в 81-ю комнтату, и там Вадим Левченко Вас просветит. Я то так, все что знаю в этом отношении знаю от него...

Про СВИГ - никто ес-но от него производительности не ждет. На питоне пишется интерфейс, его производиельность вообще никого не волнует. Мы то говорим про С++, и это крутится вннутри одного вызова протащенного через питон, свиг и еще черти че.

Компилятор код как правило учлучшает (если -O3;-)))), но то что вирт ф-ии тормозят медицинский факт (по сравнению с инлайном).

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

Дальше все в реализацю упирается. Нам удается ускорится в десятки раз, за счет специфических алгоритмов, но тут уже роляет каждый такт - если на шаг на ячейку вычисления занимают 10-20 тактов, сами пониаете + 10 тактов это потеря 50%-100% производительности.

> «аццкая» смесь получается не из-за смешения параметризации и полиморфизма, а как следствие недостаточной квалификации разработчиков :)

Да-да, я уже публично признал себя дилетанотом а Вас Гуру, войдете в комнату - все падем ниц. Только скажите когда придете чтоб мы пол подмели;-)))))

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

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

так что, Вы не согласны что они могут быть заменены? :)

Рррррр!!! Да список можно сделать и вообще без компьюетра, на бумажных карточках.

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

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

И я остаюсь при своем убеждении, что связка С++ и Питон позволяет решать большую часть задач, встающих перед программистами

скажу больше, не только «большую часть», а вообще все, иначе нафига Вы эту связку используете :) но не только связка С++/Python, но и связка C++/OCaml и С/Python и много других связок позволяют эффективно решать задачи :) это единственное что я хочу донести в данном случае, нисколько не утверждая что Вы не решили свою задачу выбранными инструментами лучше чем все кто за это брались

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

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

> оверхед будет, но небольшой

Виртуальная функция - это как минимум VPTR, что дает оверхед 32 бита. Для объекта «32-бит целое число» - это 100% оверхеда.

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

это не будет означать не то что он плохой архитектор, а то что полез нее в своё дело :)

читать так: это будет означать не то что он плохой архитектор, а то что полез нее в своё дело

«Сильным это не нужно, а слабым не поможет».

Вы недооцениваете важность документирования мыслей и организации эффективной коммуникации в команде

А те которых не придумал - те мне просто не нужны, уж простите за такой дилетансткий снобизЪм.

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

То, что Вы называете проектированием архитектуры - для нас этот этап давно в прошлом, все ясно и прозрачно.

это как фрактал - вещь самоподобная

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

может применить древний подход?

1. сделай чтобы это работало
2. сделай чтобы это работало правильно
3. сделай чтобы это работало быстро

ибо предварительная оптимизация - это зло (и сразу, предварительная пессимизация - тоже)

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

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

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

не буду утверждать ничего, но

правильно читать: не буду утверждать ничего не видя кода и не зная конкретного проекта

Да-да, я уже публично признал себя дилетанотом а Вас Гуру

зря Вы мне ФГМ и раздутое ЧСВ приписываете, я совсем не такой :)

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

дык, ну согласен же я с Вами :) сам за то шаблоны люблю, но тащить их через либы - это засада, я вообще делают так обычно - готовлю инструмент для решения задачи, далее обёртываю всё шаблонное хозяйство в обычные классы и тащу наружу

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

> 3. сделай чтобы это работало быстро

свидетельствует что из «кисоньки» Вы выжимаете последние капельки, либо что Вы свои представления о том как тут должно быть Вы пытаетесь рассказать компилятору

Дело в том, что если оно работает правильно и медленно, то считайте что не работает - нафик никому не надо. А так да, и капли последние, и для того компилятор должен делать что то разумное...

Лан, думаю тут хватит писать, если есть желание - в почту. aivanov(собака)keldysh(точка)ru

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

И это правильно.

>>Принцип Калашникова: «Избыточная сложность — это уязвимость»

Наверно поэтому его пистолет-пулемёт

Штурмовая винтовка, салага.

> поэтому код какой есть, только для демонстрации идеи

О, боги...

оверхед будет, но небольшой

Я плакал.

> под оверхедом мы сейчас рассматриваем необходимость переписывания алгоритмов под разные типы данных

И это «небольшой» ?!?!

Чувак, твои программисты получают з.п. за строчки кода, правильно?

xDD