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

Не знаю, об одном ли мы подумали, но дело тут похоже идёт к созданию аллокаторов, выделяющих элементы двусвязного списка на массиве, впрочем за этим не слежу.

Но мне другое не нравится - почему в ваших тестах хранятся такие маленькие, и к тому же одинаковые объекты. Вот для примера, в текстовом редакторе в A2 текст хранится как двусвязный список «кусочков»:

	Piece* = окласс
	перем
		next*, prev* : Piece;
		len*, startpos* : размерМЗ; (* в литерах *)
		attributes* : Attributes;
		pstyle* : ParagraphStyle;
		cstyle* : CharacterStyle;
		link* : Link;

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

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

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

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

Т.е. было бы прямо реально интересно увидеть структуру данных для текстового редактора, которая была бы реализована на Расте, без gc и при том, желательно, в safe.

Не знаю, об одном ли мы подумали, но дело тут похоже идёт к созданию аллокаторов, выделяющих элементы двусвязного списка на массиве, впрочем за этим не слежу.

Но мне другое не нравится - почему в ваших тестах хранятся такие маленькие, и к тому же одинаковые объекты. Вот для примера, в текстовом редакторе в A2 текст хранится как двусвязный список «кусочков»:

	Piece* = окласс
	перем
		next*, prev* : Piece;
		len*, startpos* : размерМЗ; (* в литерах *)
		attributes* : Attributes;
		pstyle* : ParagraphStyle;
		cstyle* : CharacterStyle;
		link* : Link;

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

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

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

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

Не знаю, об одном ли мы подумали, но дело тут похоже идёт к созданию аллокаторов, выделяющих элементы двусвязного списка на массиве, впрочем за этим не слежу.

Но мне другое не нравится - почему в ваших тестах хранятся такие маленькие, и к тому же одинаковые объекты. Вот для примера, в текстовом редакторе в A2 текст хранится как двусвязный список «кусочков»:

	Piece* = окласс
	перем
		next*, prev* : Piece;
		len*, startpos* : размерМЗ; (* в литерах *)
		attributes* : Attributes;
		pstyle* : ParagraphStyle;
		cstyle* : CharacterStyle;
		link* : Link;

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

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

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

Вот такой пример было бы (для меня) более интересно разобрать, чем список чисел.

Не знаю, об одном ли мы подумали, но дело тут похоже идёт к созданию аллокаторов, выделяющих элементы двусвязного списка на массиве, впрочем за этим не слежу.

Но мне другое не нравится - почему в ваших тестах хранятся такие маленькие, и к тому же одинаковые объекты. Вот для примера, в текстовом редакторе в A2 текст хранится как двусвязный список «кусочков»:

	Piece* = окласс
	перем
		next*, prev* : Piece;
		len*, startpos* : размерМЗ; (* в литерах *)
		attributes* : Attributes;
		pstyle* : ParagraphStyle;
		cstyle* : CharacterStyle;
		link* : Link;

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

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

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

Вот такой пример было бы (для меня) более интересно разобрать, чем список чисел.