Note that opencv 3.3 added initializer list constructors for cv::Mat and cv::Mat_. As a result, code using uniform initialization syntax may change meaning:
cv::Mat a{2, 2, CV_8UC1};
In opencv 3.2 that creates a 2 by 2 matrix with data type 8UC1. In opencv 3.3 it creates a cv::Mat with a single column containing 3 integers.
In the latest release (3.3.0) this even took over from the copy constructor because the initializer_list constructor was implemented as an constructor template for all std::initializer_list<T> without placing limits on T:
cv::Mat foo = cv::imread("foo.png");
cv::Mat copy{foo};
In opencv 3.2 this invokes the copy constructor. In opencv 3.3.0 this creates a 1x1 matrix containing some strange value. Templates that don’t know they’re dealing with a cv::Mat are especially prone to bugs because of this. A PR has been merged that makes sure the above code invokes the copy constructor again in opencv 3.3 (by restricting the initializer list constructor to arithmetic types), but it’s not in a release yet:
https://github.com/opencv/opencv/pull/9507
Personally I made sure that none of our code was accidentally using the std::initializer_list constructor by adding a static_assert(!std::is_same<T, T>::value, "") inside the constructor in the opencv header and then recompiling all our code. Not pretty, but it works.