Hey,
> After thinking more about it, I see a conceptual flaw in that approach,
> since implicit_vector cannot be used as l-value, while vector_base<>
> can, it would lead to very misleading code, where implicit_vectors would
> have (empty, or throwing exceptions) operator overloads... The risk here
> is that vector_base<> would become a holdall.
Well, you can disable operator= in all symbolic types directly, thus
preventing any lvalue problems :-)
> What is so bad about having a common overload which would hold the size
> and the opencl context, and then two separate sub-classes? Am I missing
> something?
It is the combinatorial explosion for tests and such. Already now we
have to split up tests into one for each numeric type to keep the memory
consumption under control. When using {implicit_vector_base,
vector_base} \times { implicit_matrix_base, matrix_base }, compilation
times for tests will grow by another factor of four. This is a clear
disadvantage for having two separate base classes. On the other hand, I
don't see a real advantage. Maybe I miss something?
Best regards,
Karli
------------------------------------------------------------------------------
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60135031&iu=/4140/ostg.clktrk
_______________________________________________
ViennaCL-devel mailing list
ViennaCL-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/viennacl-devel
