GNOME Bugzilla – Bug 681071
size_t is used as if it was in the global namespace.
Last modified: 2012-09-10 07:30:46 UTC
Created attachment 220150 [details] [review] Use std::size_t instead of size_t The C++ standard says that size_t is only guaranteed to be defined in the std:: namespace. The attached patch replaces all occurrences of size_t with std::size_t.
I think this bug is worth a higher severity than trivial. This can already be a real problem for those who use gcc version 4.7. See e.g. these posts on libsigc-list: https://mail.gnome.org/archives/libsigc-list/2012-July/msg00007.html https://mail.gnome.org/archives/libsigc-list/2012-July/msg00011.html size_t is not the only problem in glibmm. Some other examples: time_t in glib/src/date.[h|cc]. ptrdiff_t in glib/glibmm/ustring.h, glib/glibmm/arrayhandle.h and other files. glib/glibmm/dispatcher.cc and glib/glibmm/stringutils.cc use errno (not std::errno), but that's probably correct. The C++11 draft standard, http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2011/n3242.pdf section 19.4 says: "The header <cerrno> is described in Table 43. Its contents are the same as the POSIX header <errno.h>, except that errno shall be defined as a macro." Macros don't belong to a namespace. You need access to a compiler and a standard C++ library that don't pollute the global namespace more than is required by the C++ standard, or else it will be very difficult to get everything correct.
Pushed, thanks. Kjell, feel free to make similar fixes.
(In reply to comment #1) > This can already be a real problem for those who use gcc version 4.7. I was probably wrong there! I've built libsigc++ with gcc 4.7.0, and it works without adding std:: to size_t and ptrdiff_t. See also this post to libsigc-list: https://mail.gnome.org/archives/libsigc-list/2012-September/msg00000.html When Mohsen Pahlevanzadeh failed to build libsigc++ it was not because he used gcc 4.7.1. It was because he tried to build an old version of libsigc++ where sigc++/signal_base.h lacked #include <cstddef>. It's still a good idea to add std:: where appropriate, but it's not as urgent as it would have been if gcc 4.7 had required it.