Add comment explaining ViewProvider
This was only documented via examples (e.g. ViewProvider<GlTextureView>), but it's better to explain it properly in the header where the base case is defined. PiperOrigin-RevId: 488813144
This commit is contained in:
		
							parent
							
								
									a28ccb0964
								
							
						
					
					
						commit
						8b319e963a
					
				|  | @ -18,6 +18,28 @@ namespace internal { | |||
| template <class... T> | ||||
| struct types {}; | ||||
| 
 | ||||
| // This template must be specialized for each view type V. Each specialization
 | ||||
| // should define a pair of virtual methods called GetReadView and GetWriteView,
 | ||||
| // whose first argument is a types<V> tag object. The result type and optional
 | ||||
| // further arguments will depend on the view type.
 | ||||
| //
 | ||||
| // Example:
 | ||||
| //   template <>
 | ||||
| //   class ViewProvider<MyView> {
 | ||||
| //    public:
 | ||||
| //     virtual ~ViewProvider() = default;
 | ||||
| //     virtual MyView GetReadView(types<MyView>) const = 0;
 | ||||
| //     virtual MyView GetWriteView(types<MyView>) = 0;
 | ||||
| //   };
 | ||||
| //
 | ||||
| // The additional arguments and result type are reflected in GpuBuffer's
 | ||||
| // GetReadView and GetWriteView methods.
 | ||||
| //
 | ||||
| // Using a type tag for the first argument allows the methods to be overloaded,
 | ||||
| // so that a single storage can implement provider methods for multiple views.
 | ||||
| // Since these methods are not template methods, they can (and should) be
 | ||||
| // virtual, which allows storage classes to override them, enforcing that all
 | ||||
| // storages providing a given view type implement the same interface.
 | ||||
| template <class V> | ||||
| class ViewProvider; | ||||
| 
 | ||||
|  |  | |||
		Loading…
	
		Reference in New Issue
	
	Block a user