Андрей159P.S. а что говорить а Питоне, в котором чтоб написать цыкл от 1 к 100 нужно использовать массив от 1 к 100. Это ж как интересно на машинном коде все будет работать?))))) На этом уроке я и закончил свое обучение начал гуглить все о скорости Питона и сравнении. Сам потестил также. Ой и медляра... Логика не подвела. Но рейтинг языка зашкаливает. Так и не понял в чем прикол популярности.
Я не думаю что Питон будет обязательно создавать массив. Скорее всего эта метафора
разворачивается в ленивый генератор последовательности.

Как на "машинном коде будет все работать" - это еще более холиварный вопрос. Скорее всего никак
т.к. машинного кода нет а есть "байт-код". (Здесь я возможно ошибаюсь т.к. давно не связывался
с этой змейкой. Вобщем пускай знающие прокомментируют где и на какой фазе рантайма или компилляции
мы получим машинный код. А пока я считаю в соотв. со сведениями из wiki что Python - интерпретатор
байткода).

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

А что будет дальше с результатом? Он будет отдан в stream?

Вообще каков КПД "конкатенации" как алгоритма?

Давайте сделаем O(1).

Надо еще подумать про базовый набор операций типа substr, replace e.t.c.

Давайте я очерчу парадигму.

1) Необходимо разработать строковый тип данных, обеспечивающий максимальную пропускную способность
операций конкатенации (+) или concat.

2) Для удобства использования и для исключения конфликтов пускай он называется lstring (Lazy-String).

3) Реализация должна использовать принцип "ленивых вычислений". То есть в цепочке операций




мы не делаем 100 конкатенаций а мы просто накапливаем список операций. До тех пор пока не будет
вызван явный процесс получения строки результата из интерфейса lstring.

4) Операции вывода в stream определяются для "списка операций".

5) Прочие строковые операции такие как length(), substr(), replace() также адаптируются
к "ленивой" парадигме. Например расчет length() не требует явного перерасчета s.

Для метода substr() также применяется логика отбрасывания ненужных операций.

6) Прочий API (работа с регулярками) адаптируется к stream исходной строки таким-же образом.
Сюда-же идут файловые операции и фасады для работы с консолью (printf, puts)

7) API отображения (map) наподобие .toUpper(), .to(Lower) также адаптируется к stream
результату без явного преобразования в строку.

kealon(Ruslan)maytonДавайте сделаем O(1).
придётся как-то сделать без операции копирования, которая и даёт O(len(A)+len(B))
но даже c rope (верёвкой) будет логарифм
Большое спасибо Руслан что вы напомнили мне о такой замечательной структуре данных как Rope(DataStructure).
Лежит в списке на прочтение. Но думаю что в данной задаче мы пока начнем что-то решать без верёвки.
Оставим на десерт когда все простые решения будут исчерпаны. Я верю что R/B-tree, hashmap, и LRU нас
спасали последние лет 50 в информатике и вычислительной технике и сейчас спасут.

Sergey_rbmaytonНадо еще подумать про базовый набор операций типа substr, replace e.t.c.

Да, начните таки думать о том, что давно уже сделано другими!
Милостивый государь! Я думаю что ваше восклицание требует определённых пояснений.
Что имелось в виду?
Какими "другими" ?

Изопропилmayton,

что это даст сообществу?
Пока не знаю. Я просто предложил свой "поток сознания". Жду реакции. В скобках замечу
что в этом форуме я - альтруист и вообще не преследую никаких оценок из серии что будет
полезно или безполезно для науки и народного хозяйства.

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