On 2010-07-09, Sean McBride <sean@...> wrote:
> Then I tried another build with all the same settings
> except using clang and there are hundreds of errors:
> I'm not a C++ expert, but many of the errors look legitimate.
> Anyone interested in helping getting this building?
I've looked at these errors, and it seems like most of them happen in two cases: the first is when a method of a templated parent class is called (from a method of a derived class). This is easily fixed by prefixing that call with the parent class name and "::" which I've actually done in a few cases (and SVN committed).
(In those cases, with the added prefix the code even becomes more readable since it's now clear where the method belongs to.)
The second case, and actually the cause of most errors from the clang compiler in vxl, is when a vnl_matrix_fixed<T,n,m> is used where a vnl_matrix<T> and is expected, and similarly for vnl_vector<T> & vnl_vector_fixed<T,n>.
Although there is the following convertor:
operator const vnl_vector_ref<T>() const
in class vnl_vector_fixed, and vnl_vector_ref is a derived class from vnl_vector, the clang compiler does not automatically use this to allow a vnl_vector_fixed in contexts where a vnl_vector is expected.
Again, I've modified some of these cases, thereby also cleaning up a bit, in those cases where mixing vnl_vector and vnl_vector_fixed was not a good idea.
In most cases, I've inserted an explicit vnl_vector (or vnl_matrix) constructor, which costs a memcopy; in most cases these should be replaced by using the as_ref() method of vnl_vector_fixed to avoid the memcopy; I'll do that one of these days.
From yesterday's dashboard of the clang compiler, it seems like these modifications will help to reduce the number of errors. (And the other builds look very green today -- seems nothing got broken.)
To be continued...
Any feedback is of course welcome!
And please keep us informed about your clang+vxl experiences.