LINUX.ORG.RU

История изменений

Исправление sena, (текущая версия) :

И, кстати, ещё один момент. Предположим, текст промаркирован где-то там, выше. А ты выделил и скопировал в середине. Что ты скопировал?

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

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

И ещё. Работа программиста со строками будет просто адской. Берём часть одной строки и часть другой. Что это за строки? Что за кодировки? Это нужно будет постоянно искать маркер, который где-то там. Сколько этих маркеров программа не знает. Всё усложняется драматически.

Не сильно усложняется даже по сравнению со старым однобайтовым текстом. Да, для работы со строками удобней будет использовать библиотеку, но это же сегодня надо делать и для юникода. Собственно работа с маркером языка будет подобна тому что и сегодня с маркером новой строки (который у нас ещё и двух типов - юниксовый однобайтовый и досовский из двух байт). Обычно строки при загрузке из текстового файла разбивают по этим маркерам. А тут нужно будет разбивать дополнительно и по маркеру 255. Всего-то! Примерно столько же работы. А если в каждой строке хранится её кодировка, то всё просто. То есть ты всегда будешь знать какой язык у тебя в строке хранится.

Исправление sena, :

И, кстати, ещё один момент. Предположим, текст промаркирован где-то там, выше. А ты выделил и скопировал в середине. Что ты скопировал?

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

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

И ещё. Работа программиста со строками будет просто адской. Берём часть одной строки и часть другой. Что это за строки? Что за кодировки? Это нужно будет постоянно искать маркер, который где-то там. Сколько этих маркеров программа не знает. Всё усложняется драматически.

Не сильно усложняется даже по сравнению со старым однобайтовым текстом. Да, для работы со строками нужно будет использовать библиотеку, но это же сегодня надо делать и для юникода. Собственно работа с маркером языка будет подобна тому что и сегодня с маркером новой строки (который у нас ещё и двух типов - юниксовый однобайтовый и досовский из двух байт). Обычно строки при загрузке из текстового файла разбивают по этим маркерам. А тут нужно будет разбивать дополнительно и по маркеру 255. Всего-то! Примерно столько же работы. А если в каждой строке хранится её кодировка, то всё просто. То есть ты всегда будешь знать какой язык у тебя в строке хранится.

Исправление sena, :

И, кстати, ещё один момент. Предположим, текст промаркирован где-то там, выше. А ты выделил и скопировал в середине. Что ты скопировал?

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

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

И ещё. Работа программиста со строками будет просто адской. Берём часть одной строки и часть другой. Что это за строки? Что за кодировки? Это нужно будет постоянно искать маркер, который где-то там. Сколько этих маркеров программа не знает. Всё усложняется драматически.

Не сильно усложняется даже по сравнению со старым однобайтовым текстом. Да, для работы со строками нужно будет использовать библиотеку, но это же сегодня надо делать и для юникода. Собственно работа с маркером языка будет подобна тому что и сегодня с маркером новой строки (который у нас ещё и двух типов - юниксовый однобайтовый и досовский из двух байт). Обычно строки при загрузке из текстового файла разбивают по этим маркерам. А тут нужно будет разбивать дополнительно и по маркеру 255. Всего-то! Примерно столько же работы.

Исходная версия sena, :

И, кстати, ещё один момент. Предположим, текст промаркирован где-то там, выше. А ты выделил и скопировал в середине. Что ты скопировал?

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

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

И ещё. Работа программиста со строками будет просто адской. Берём часть одной строки и часть другой. Что это за строки? Что за кодировки? Это нужно будет постоянно искать маркер, который где-то там. Сколько этих маркеров программа не знает. Всё усложняется драматически.

Не сильно усложняется даже по сравнению со старым однобайтовым текстом. Да, для работы со строками нужно будет использовать библиотеку, но это же сегодня надо делать и для юникода. Собственно работа с маркером языка будет подобна тому что и сегодня с маркером новой строки (который у нас ещё и двух типов - юниксовый однобайтовый и досовский из двух байт). Обычно строки при загрузки из текстового файла разбивают по этим маркерам. А тут нужно будет разбивать и по маркеру 255. Всего-то Примерно столько же работы.