История изменений
Исправление a--, (текущая версия) :
Хотя, конечно, самым цимесом было бы предъявить пример этого самого «не решили».
... и при этом еще с условием, чтобы это «не решили» было по свойствам похоже на двухсвязный список, каким он был при Николае I в ХХ веке.
Ну вот например такие условия на коллекцию:
1. Быстрое нахождение первого соседнего элемента перед итератором / после итератора
2. Быстрая вставка элемента перед итератором / после итератора
3. Быстрое удаление элемента по итератору / перед итератором / после итератора
4. Вместо полной стабильности итераторов как у списка разрешается слегка ослабленное свойство: обновление итераторов тоже быстрое и занимает время, пропорциональное количеству вставленных/удаленных элементов, а не количеству итераторов.
Т.е. если у нас 10М элементов и на каждый заведено по итератору, и мы вставили в случайные места 10 новых элементов, то затраты времени должны быть примерно 10, а не 10М и не 3К.
5. Специально, чтобы растаманам жизнь медом не казалась: стабильные итераторы на голову и хвост, обновление которых тоже пропорционально количеству вставленных/удаленных элементов (а можно и сильно быстрее, но мне пока что не ясно, насколько это можно сделать быстро).
Варианты реализации:
А. написать «с нуля» без unsafe
Б. написать без unsafe, используя как данность какую-то структуру данных раста, внутри которой unsafe
Какие есть мысли по этому поводу?
Исправление a--, :
Хотя, конечно, самым цимесом было бы предъявить пример этого самого «не решили».
... и при этом еще с условием, чтобы это «не решили» было по свойствам похоже на двухсвязный список, каким он был при Николае I в ХХ веке.
Ну вот например такие условия на коллекцию:
1. Быстрое нахождение первого соседнего элемента перед итератором / после итератора
2. Быстрая вставка элемента перед итератором / после итератора
3. Быстрое удаление элемента по итератору / перед итератором / после итератора
4. Вместо полной стабильности итераторов как у списка разрешается слегка ослабленное свойство: обновление итераторов тоже быстрое и занимает время, пропорциональное количеству вставленных/удаленных элементов, а не количеству итераторов.
Т.е. если у нас 10М элементов и на каждый заведено по итератору, и мы вставили в случайные места 10 новых элементов, то затраты времени должны быть примерно 10, а не 10М и не 3К.
5. Специально, чтобы растаманам жизнь медом не казалась: стабильные итераторы на голову и хвост, обновление которых тоже пропорционально количеству вставленных/удаленных элементов.
Варианты реализации:
А. написать «с нуля» без unsafe
Б. написать без unsafe, используя как данность какую-то структуру данных раста, внутри которой unsafe
Какие есть мысли по этому поводу?
Исправление a--, :
Хотя, конечно, самым цимесом было бы предъявить пример этого самого «не решили».
... и при этом еще с условием, чтобы это «не решили» было по свойствам похоже на двухсвязный список, каким он был при Николае I в ХХ веке.
Ну вот например такие условия на коллекцию:
1. Быстрое нахождение первого соседнего элемента перед итератором / после итератора
2. Быстрая вставка элемента перед итератором / после итератора
3. Быстрое удаление элемента по итератору / перед итератором / после итератора
4. Вместо полной стабильности итераторов как у списка разрешается слегка ослабленное свойство: обновление итераторов тоже быстрое и занимает время, пропорциональное количеству вставленных/удаленных элементов, а не количеству итераторов.
Т.е. если у нас 10М элементов и на каждый заведено по итератору, и мы вставили в случайные места 10 новых элементов, то затраты времени должны быть примерно 10, а не 10М и не 3К.
Варианты реализации:
А. написать «с нуля» без unsafe
Б. написать без unsafe, используя как данность какую-то структуру данных раста, внутри которой unsafe
Какие есть мысли по этому поводу?
Исправление a--, :
Хотя, конечно, самым цимесом было бы предъявить пример этого самого «не решили».
... и при этом еще с условием, чтобы это «не решили» было по свойствам похоже на двухсвязный список, каким он был при Николае I в ХХ веке.
Ну вот например такие условия на коллекцию:
1. Быстрое нахождение элемента перед итератором / после итератора
2. Быстрая вставка элемента перед итератором / после итератора
3. Быстрое удаление элемента по итератору / перед итератором / после итератора
4. Вместо полной стабильности итераторов как у списка разрешается слегка ослабленное свойство: обновление итераторов тоже быстрое и занимает время, пропорциональное количеству вставленных/удаленных элементов, а не количеству итераторов.
Т.е. если у нас 10М элементов и на каждый заведено по итератору, и мы вставили в случайные места 10 новых элементов, то затраты времени должны быть примерно 10, а не 10М и не 3К.
Варианты реализации:
А. написать «с нуля» без unsafe
Б. написать без unsafe, используя как данность какую-то структуру данных раста, внутри которой unsafe
Какие есть мысли по этому поводу?
Исправление a--, :
Хотя, конечно, самым цимесом было бы предъявить пример этого самого «не решили».
... и при этом еще с условием, чтобы это «не решили» было по свойствам похоже на двухсвязный список.
Ну вот например такие условия на коллекцию:
1. Быстрое нахождение элемента перед итератором / после итератора
2. Быстрая вставка элемента перед итератором / после итератора
3. Быстрое удаление элемента по итератору / перед итератором / после итератора
4. Вместо полной стабильности итераторов как у списка разрешается слегка ослабленное свойство: обновление итераторов тоже быстрое и занимает время, пропорциональное количеству вставленных/удаленных элементов, а не количеству итераторов.
Т.е. если у нас 10М элементов и на каждый заведено по итератору, и мы вставили в случайные места 10 новых элементов, то затраты времени должны быть примерно 10, а не 10М и не 3К.
Варианты реализации:
А. написать «с нуля» без unsafe
Б. написать без unsafe, используя как данность какую-то структуру данных раста, внутри которой unsafe
Какие есть мысли по этому поводу?
Исходная версия a--, :
Хотя, конечно, самым цимесом было бы предъявить пример этого самого «не решили».
... и при этом еще с условием, чтобы это «не решили» было по свойствам похоже на двухсвязный список.
Ну вот например такие условия на коллекцию:
1. Быстрая нахождение элемента перед/после итератора
2. Быстрая вставка элемента перед/после итератора
3. Быстрое удаление элемента по/перед/после итератора
4. Вместо полной стабильности итераторов как у списка требуется слегка ослабленное свойство: обновление итераторов тоже быстрое и занимает время, пропорциональное количеству вставленных/удаленных элементов, а не количеству итераторов.
Т.е. если у нас 10М элементов и на каждый заведено по итератору, и мы вставили в случайные места 10 новых элементов, то затраты времени должны быть примерно 10, а не 10М и не 3К.
Варианты реализации:
А. написать «с нуля» без unsafe
Б. написать без unsafe, используя как данность какую-то структуру данных раста, внутри которой unsafe
Какие есть мысли по этому поводу?