Как я создаю свой собственный ostream/streambuf?
Как сказал Бруно, вы можете использовать FFimageLoading для своего списка. Я написал демо, вы можете сослаться на него.
Это GIF демо.
Если вы использовали FFimageLoading, прежде всего, вы должны обратиться к по этой ссылке , которая готовит работающую среду.
Ниже приведен мой код демонстрации.
MainPage.xaml
MainPage.xaml.cs
public partial class MainPage : ContentPage
{
public MainPage()
{
InitializeComponent();
var grouped = new ObservableCollection() {
new ImageLink{LinkSource="http://loremflickr.com/600/600/nature?filename=simple.jpg" },
new ImageLink{LinkSource="http://loremflickr.com/600/600/nature?filename=simple.jpg" },
new ImageLink{LinkSource="http://loremflickr.com/600/600/nature?filename=simple.jpg" },
new ImageLink{LinkSource="http://loremflickr.com/600/600/nature?filename=simple.jpg" },
};
listview.ItemsSource= grouped;
}
}
ImageLink
public class ImageLink
{
public ImageLink()
{
}
public string LinkSource { get; set; }
}
3 ответа
Канонический подход заключается в определении собственного потокового буфера. Вы должны взглянуть на:
- статьи Анжелики Лэнгер о выводе IOStreams
- статьи Джеймса Канзе о фильтрации потоковых потоков
- boost.iostream для примеров применения
Я не уверен, что то, что Вы хотите сделать, возможно. Эти << операторы не являются виртуальными. Таким образом, Вы могли определить yourstream &operator << (yourstream &strm, int i), чтобы сделать то, что Вы хотите с преобразованием порядка байтов и подсчетом, и это будет работать, когда Ваш код назовет его непосредственно. Но если Вы передаете объект yourstream в функцию, которая ожидает ostream, любое время, когда вызовы функции <<, это перейдет к исходной ostream версии вместо Вашего.
Насколько я понимаю, потоковые средства были настроены так, чтобы можно было "легко" определить новый потоковый тип, который использует другой вид буфера (как, скажем, двухсторонняя очередь символов), и можно очень легко добавить поддержку вывода собственных классов через <<. Я не думаю, что Вы предназначаетесь, чтобы смочь переопределить средний слой между теми.
И особенно, весь смысл эти << интерфейс должен обеспечить приятно вывод форматированного текста, в то время как он кажется на фактическое желание двоичного выхода. (Иначе ссылка на "порядок байтов" не имеет никакого смысла.) Даже принимающий существует некоторый способ сделать это, я не знаю, он произведет неловкий двоичный выход в лучшем случае Например, полагайте, что перегрузка конечного пользователя производит точку в 3D пространстве. Версия конечного пользователя <<, вероятно, сделает что-то как << '(' << x << ", " << y << ", " << z << ')'. Это будет выглядеть хорошим в текстовом потоке, но это - много потраченных впустую и абсолютно бесполезных символов в двоичном потоке, который идеально просто использовал бы << x << y << z. (И сколько вызовов к << они должны рассчитать как?)
Для A + C) Я думаю, вам следует посмотреть на фасеты, они изменяют то, как объекты записываются как символы. Здесь вы также можете хранить статистику о том, сколько раз вы транслировали свои объекты. Посмотрите Как форматировать мои собственные объекты при использовании потоков STL? для примера.
Для B) Вам необходимо создать свой собственный streambuf и подключить свой поток ostream к этому буферу (аргумент конструктора). См. Ссылки Люка + Получение новых классов streambuf . Короче говоря, вам необходимо реализовать это для ostream (минимум):