> The reason it is not in the standard is that its behaviour in the presence of symlinks may differ depending on the filesystem and compiler I have the feeling

> The reason it is not in the standard is that its behaviour in the presence of symlinks may differ depending on the filesystem and compiler I have the feeling that the difference matters to almost nobody and should be avoidable by the few people it actually affects. I had more issues with colliding include guards than I had with symlinks and I still end up replacing CLASSNAME_H with PROJECT_CLASSNAME_H in our own headers every now and then since the autogenerated guards are too naive.