I ran into a compiler bug in Clang by accident about 10 years ago.
The story is that I checked in a code change that passed unit tests locally, that then broke an automated build. This was bizarre because this was at Google and our check-in process guaranteed that we had run the test suites successfully, which required the very compile that broke.
It turns out that the local compile was with GCC, and the automated one was Clang. The construct that they treated differently went like this.
There was a class A with a protected property bar, and a subclass B. I also had unit test code in a class TestB which was a friend class to B. And in that unit test code I accessed foo.bar where foo was of class B.
GCC looked at that access, decided that bar is protected, foo is of class B, and TestB is a friend, so TestB has access.
Clang looked at that access, found that bar is protected and from class A, TestB is NOT a friend, so TestB had no access.
The problem went to a local expert who read the spec and decided that GCC was per the spec, Clang was not, and submitted a bug report to Clang.
As for me I figured that if the very first thing that I thought to try with protected, friend and subclasses was an edge case that nobody could agree on, perhaps C++ wasn't the right language for me...
The story is that I checked in a code change that passed unit tests locally, that then broke an automated build. This was bizarre because this was at Google and our check-in process guaranteed that we had run the test suites successfully, which required the very compile that broke.
It turns out that the local compile was with GCC, and the automated one was Clang. The construct that they treated differently went like this.
There was a class A with a protected property bar, and a subclass B. I also had unit test code in a class TestB which was a friend class to B. And in that unit test code I accessed foo.bar where foo was of class B.
GCC looked at that access, decided that bar is protected, foo is of class B, and TestB is a friend, so TestB has access.
Clang looked at that access, found that bar is protected and from class A, TestB is NOT a friend, so TestB had no access.
The problem went to a local expert who read the spec and decided that GCC was per the spec, Clang was not, and submitted a bug report to Clang.
As for me I figured that if the very first thing that I thought to try with protected, friend and subclasses was an edge case that nobody could agree on, perhaps C++ wasn't the right language for me...