------- Comment #8 from peter at cordes dot ca 2009-02-12 17:56 ------- Would it cause any problems for g++ to behave more like a C compiler when it comes to NULL? e.g. I found this bug report after finding that kscope 1.9.1 didn't compile, because it expected NULL to match the void* version of an overloaded function.
locationlistmodel.cpp:204: error: call of overloaded ‘createIndex(int&, int&, NULL)’ is ambiguous .../qabstractitemmodel.h:288: note: candidates are: QModelIndex QAbstractItemModel::createIndex(int, int, void*) const .../qabstractitemmodel.h:290: note: QModelIndex QAbstractItemModel::createIndex(int, int, int) const .../qabstractitemmodel.h:299: note: QModelIndex QAbstractItemModel::createIndex(int, int, quint32) const This was in released alpha code (http://qt-apps.org/content/show.php?content=96992) so presumably it built ok on some compiler. (Although maybe it used to just pick one of the int overloads, if that's what Lubos was talking about having to debug.) As a mostly C programmer, this just seems like something stupid in the standard, and the sort of behaviour you should only get with -std=c++0x, but not -std=gnu++0x. As everyone else is saying, who in their right mind actually wants this behaviour? And more importantly, would changing it ever make g++ actually mis-compile anything? (not counting compiling stuff like kscope, or test.c below, where the result "should" be an error message, not a binary) Anyway, NULL should be a void*, damn it. Yes, I'm a C programmer. -- peter at cordes dot ca changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |peter at cordes dot ca http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35669