Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Здравствуйте, Carc, Вы писали:

C>>Надо обработать большой массив по не совсем тривиальному алгоритму. Можно создать его копию, можно и не создавать. На написание кода с копией уйдет час Вашего времени, без копии — 4 часа. Что предпочтете ?
C>>[/q]
C>>Насколько большой? Что за алгоритм (модифицирует массив или нет)?

PD>Я специально не стал конкретизировать. Вопрос такой — сделаете копию, если без копии сделаете за 4 часа, а с ней — за час ? Не важно, что там, время на разработку указано.
Ну я поэтому и написал, что сделал бы через фасадную функцию обработки массива. А та уж будет как-то выбирать функцию реализации.
А эти самые несколько разных функций разных реализаций будут работать по-разному. В зависимости от требований и главное их сочетаний: надежность, скорость, требования к памяти, как часто используется. Как верно написал _student, как часто оный функционал вовсе нуже пользователю (импорт\экопрт раз в месяц, или по 3 раза за минут).
Мысль была в том, чтобы скрыть за фасадом выбор конкретных реализаций. Оставить себе свободу выбора на будущее, и в то же время полностью контролировать выбор в конкретный момент.

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


C>>Массив большой это что — по памяти или по числу элементов?

PD>А что, это не связано одно с другим как elems.size*sizeof(elem) ?
В математике связано. У пользователя нет. У пользователя нет математики: у него более приземленные понятия (быстро, надежно, тормозит\не тормозит, вызывает в UI какие-нить фризы и.т.д). И вот тут вот и всплывает то самое магическое sizeof(elem). Если там sizeof(long), то вроть и пофиг (для конечного пользователя системы), а если там sizeof(нихрена_себе_PFF-ка_с_жесткого диска), то очень даже и есть разница.
Дьявол — он в деталях. Универсального подхода здесь нет.

Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Здравствуйте, Carc, Вы писали:

C>>Надо обработать большой массив по не совсем тривиальному алгоритму. Можно создать его копию, можно и не создавать. На написание кода с копией уйдет час Вашего времени, без копии — 4 часа. Что предпочтете ?
C>>[/q]
C>>Насколько большой? Что за алгоритм (модифицирует массив или нет)?

PD>Я специально не стал конкретизировать. Вопрос такой — сделаете копию, если без копии сделаете за 4 часа, а с ней — за час ? Не важно, что там, время на разработку указано.
Ну я поэтому и написал, что сделал бы через фасадную функцию обработки массива. А та уж будет как-то выбирать функцию реализации.
А эти самые несколько разных функций разных реализаций будут работать по-разному. В зависимости от требований и главное их сочетаний: надежность, скорость, требования к памяти, как часто используется. Как верно написал _student, как часто оный функционал вовсе нужег пользователю (импорт\экспорт раз в месяц, или по 3 раза за минуту).
Мысль была в том, чтобы скрыть за фасадом выбор конкретных реализаций. Оставить себе свободу выбора на будущее, и в то же время полностью контролировать выбор в конкретный момент.

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


C>>Массив большой это что — по памяти или по числу элементов?

PD>А что, это не связано одно с другим как elems.size*sizeof(elem) ?
В математике связано. У пользователя нет. У пользователя нет математики: у него более приземленные понятия (быстро, надежно, тормозит\не тормозит, вызывает в UI какие-нить фризы и.т.д). И вот тут вот и всплывает то самое магическое sizeof(elem). Если там sizeof(long), то вроть и пофиг (для конечного пользователя системы), а если там sizeof(нихрена_себе_PFF-ка_с_жесткого диска), то очень даже и есть разница.
Дьявол — он в деталях. Универсального подхода здесь нет.