Hi, > See above :-) There are good reasons for dropping infos<>(), > particularly as we cannot assume that each OpenCL SDK returns the > requested information as rapidly as we might need it. > > > > Hmm, then a good solution would be to internally use infos<> whenever a > viennacl::ocl object is not yet created or cached ; it would centralize > the C API calls into the infos.hpp header instead of the class > definitions. I can do that, and add similar methods for ocl::program and > ocl::kernel if needed.
we agreed that we will get rid of infos<> entirely once all other classes get the respective members. Why should we torture the compiler with member functions, which redirect to a templated function just to call a C routine? If you want to use infos<> as a convenience layer which gets instantiated for a few types, I'm okay with that. But unconditionally using it in all member functions to come will certainly not result in the reduced compilation times you were suggesting initially. ;-) Best regards, Karli ------------------------------------------------------------------------------ "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available. Simple to use. Nothing to install. Get started now for free." http://p.sf.net/sfu/SauceLabs _______________________________________________ ViennaCL-devel mailing list ViennaCL-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/viennacl-devel
