Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Здравствуйте, Shmj, Вы писали:
PD>Голосование по эффективности и расходам ресурсов
PD>https://rsdn.org/poll/9966Автор: Pavel Dvorkin
Дата: 23.02.24
Вопрос: Надо обработать большой массив по не совсем тривиальному алгоритму. Можно создать его копию, можно и не создавать. На написание кода с копией уйдет час Вашего времени, без копии — 4 часа. Что предпочтете ?
Павел, «ну кто так строит» (ц).
Надо обработать большой массив по не совсем тривиальному алгоритму. Можно создать его копию, можно и не создавать. На написание кода с копией уйдет час Вашего времени, без копии — 4 часа. Что предпочтете ?
Насколько большой? Что за алгоритм (модифицирует массив или нет)?
Массив большой это что — по памяти или по числу элементов?
Имхо, тут сразу же всё упрется в структуры данных (векторы, деки, списки односвязные или двухсвязные) ну и.т.д.
А мы ж прекрасно понимаем, что структуры данных и алгоритмы обработки идут рука об руку. Для одних алгоритмов хороши одни структуры памяти, а для других другие (я в смысле идиомы: бинарный поиск азмЪ езмЪ гут, но уже извольте отсортированный массив подать).
Тут сразу же вспоминается Скотт Мейерс, с его клевыми рецептами.
А по сути я б сам сделал иначе в архитектурном плане.
Разделил бы реализации, и доступ к ним.
Handle_Array_WithCopy(MyArray& ar);//функция с созданием копии
Handle_Array_NOCopy(MyArray& ar);//функция без копии
//общая функция - суть фасад, она сама выбирает какую реализацию звать.
//А уж как выбирает - в рантайме, в дизайн-тайме, мрачно хардкодно - это уже детали
//Главное: эта фасадная функция скрывает доступ к деталям реализации
//PS: потом можно и открыть доступ к реализационным функциями отдельно.
//Главное в другом: по умолчанию реализацию лучше держать закрытой, и скрывать детали выбора
//- чтоб через единственную точку доступа все шло - а именно через фасадную Handle_Array(MyArray& ar);
Handle_Array(MyArray& ar);
Доводилось такое применять в боевом коде, при конверташке строк в разных кодировках туда-сюда-обратно.
