[exception][mpl] Boost.Exception uses unqualified size_t
The Boost.Exception library uses size_t without any qualification, which leads to unexpected ADL problems related to mpl::size_t. I'm currently not able to provide a minimal use case as I don't fully understand where this happens, but if I replace size_t with std::size_t in boost/exception/detail/object_hex_dump.hpp my problems go away. I tried to look around in other Boost libraries, but all other occurrences of size_t are qualified as std::size_t. Regards Hartmut ------------------- Meet me at BoostCon http://boostcon.com
On Sat, Nov 14, 2009 at 5:45 PM, Hartmut Kaiser <hartmut.kaiser@gmail.com> wrote:
The Boost.Exception library uses size_t without any qualification, which leads to unexpected ADL problems related to mpl::size_t.
This was a bug in exception/object_hex_dump.hpp because it used unqualified size_t without #including <stdlib.h>. The use of size_t is now qualified, see trunk revision 57668. I suspect however that we would have had the same issue even if object_hex_dump.hpp did #include <stdlib.h>. Isn't it too risky for mpl to define its own size_t? Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode
Emil Dotchevski wrote:
I suspect however that we would have had the same issue even if object_hex_dump.hpp did #include <stdlib.h>. Isn't it too risky for mpl to define its own size_t? Maybe it's a naive question but, isn't it <cstddef> that should be included to get size_t in std ?
-- ___________________________________________ Joel Falcou - Assistant Professor PARALL Team - LRI - Universite Paris Sud XI Tel : (+33)1 69 15 66 35
joel wrote:
Emil Dotchevski wrote:
I suspect however that we would have had the same issue even if object_hex_dump.hpp did #include <stdlib.h>. Isn't it too risky for mpl to define its own size_t? Maybe it's a naive question but, isn't it <cstddef> that should be included to get size_t in std ?
Or even better: boost/compatibility/cpp_c_headers/cstddef.
On Sun, Nov 15, 2009 at 9:32 AM, Andrey Semashev <andrey.semashev@gmail.com>wrote:
joel wrote:
Emil Dotchevski wrote:
I suspect however that we would have had the same issue even if object_hex_dump.hpp did #include <stdlib.h>. Isn't it too risky for mpl to define its own size_t?
Maybe it's a naive question but, isn't it <cstddef> that should be included to get size_t in std ?
Or even better: boost/compatibility/cpp_c_headers/cstddef.
Is there anywhere where all this wisdom is written down - a kind of "Boost Common Knowledge" page(s)? - Rob.
Robert Jones wrote:
On Sun, Nov 15, 2009 at 9:32 AM, Andrey Semashev <andrey.semashev@gmail.com>wrote:
joel wrote:
Emil Dotchevski wrote:
I suspect however that we would have had the same issue even if object_hex_dump.hpp did #include <stdlib.h>. Isn't it too risky for mpl to define its own size_t?
Maybe it's a naive question but, isn't it <cstddef> that should be included to get size_t in std ?
Or even better: boost/compatibility/cpp_c_headers/cstddef.
Is there anywhere where all this wisdom is written down - a kind of "Boost Common Knowledge" page(s)?
What wisdom do you mean? Boost.Compatibility is documented here: http://www.boost.org/doc/libs/release/libs/compatibility/index.html As for the size_t type, I believe, the Standard says which header should define it.
Andrey Semashev wrote:
joel wrote:
Emil Dotchevski wrote:
I suspect however that we would have had the same issue even if object_hex_dump.hpp did #include <stdlib.h>. Isn't it too risky for mpl to define its own size_t? Maybe it's a naive question but, isn't it <cstddef> that should be included to get size_t in std ? Or even better: boost/compatibility/cpp_c_headers/cstddef. Is it provided with basic boost files ? Cause I can't find it in my distribution
-- ___________________________________________ Joel Falcou - Assistant Professor PARALL Team - LRI - Universite Paris Sud XI Tel : (+33)1 69 15 66 35
joel wrote:
Andrey Semashev wrote:
joel wrote:
Emil Dotchevski wrote:
I suspect however that we would have had the same issue even if object_hex_dump.hpp did #include <stdlib.h>. Isn't it too risky for mpl to define its own size_t? Maybe it's a naive question but, isn't it <cstddef> that should be included to get size_t in std ? Or even better: boost/compatibility/cpp_c_headers/cstddef. Is it provided with basic boost files ? Cause I can't find it in my distribution
I can clearly see it in the release branch. And it was there for ages. What distribution do you use?
Andrey Semashev wrote:
joel wrote:
Emil Dotchevski wrote:
I suspect however that we would have had the same issue even if object_hex_dump.hpp did #include <stdlib.h>. Isn't it too risky for mpl to define its own size_t? Maybe it's a naive question but, isn't it <cstddef> that should be included to get size_t in std ?
Or even better: boost/compatibility/cpp_c_headers/cstddef. Why is that better? It includes stddef.h and adds a couple of usings. Why is that better than cstddef (which does something a bit similar but moreish on gcc)? I don't understand, and would like to.
Patrick
Patrick Horgan wrote:
Andrey Semashev wrote:
Or even better: boost/compatibility/cpp_c_headers/cstddef.
Why is that better? It includes stddef.h and adds a couple of usings.
It's not. This header is intended to be used only on platforms that don't have <cstddef>, by adding cpp_c_headers to the include path, IIRC.
Peter Dimov wrote:
Patrick Horgan wrote:
Andrey Semashev wrote:
Or even better: boost/compatibility/cpp_c_headers/cstddef.
Why is that better? It includes stddef.h and adds a couple of usings.
It's not. This header is intended to be used only on platforms that don't have <cstddef>, by adding cpp_c_headers to the include path, IIRC. Thanks. That's what I thought the compatibility docs said.
Patrick
Peter Dimov wrote:
Patrick Horgan wrote:
Andrey Semashev wrote:
Or even better: boost/compatibility/cpp_c_headers/cstddef.
Why is that better? It includes stddef.h and adds a couple of usings.
It's not. This header is intended to be used only on platforms that don't have <cstddef>, by adding cpp_c_headers to the include path, IIRC.
It is better because some native c* headers are missing some std imports. Not that it is often the case for size_t, though.
On Sun, Nov 15, 2009 at 12:33 AM, joel <joel.falcou@lri.fr> wrote:
Emil Dotchevski wrote:
I suspect however that we would have had the same issue even if object_hex_dump.hpp did #include <stdlib.h>. Isn't it too risky for mpl to define its own size_t?
Maybe it's a naive question but, isn't it <cstddef> that should be included to get size_t in std ?
It is quite common for CPP files to include C library headers which often #include <stddef.h>. So, yes, <cstddef> is the correct header to include for C++ programs but <stddef.h> should also work. Right? Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode
Emil Dotchevski wrote:
On Sun, Nov 15, 2009 at 12:33 AM, joel <joel.falcou@lri.fr> wrote:
Emil Dotchevski wrote:
I suspect however that we would have had the same issue even if object_hex_dump.hpp did #include <stdlib.h>. Isn't it too risky for mpl to define its own size_t? Maybe it's a naive question but, isn't it <cstddef> that should be included to get size_t in std ?
It is quite common for CPP files to include C library headers which often #include <stddef.h>. So, yes, <cstddef> is the correct header to include for C++ programs but <stddef.h> should also work. Right?
If you're using std::size_t then no, stddef.h will not work.
Thanks Emil! Regards Hartmut ------------------- Meet me at BoostCon http://boostcon.com
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost- bounces@lists.boost.org] On Behalf Of Emil Dotchevski Sent: Saturday, November 14, 2009 10:34 PM To: boost@lists.boost.org Subject: Re: [boost] [exception][mpl] Boost.Exception uses unqualified size_t
On Sat, Nov 14, 2009 at 5:45 PM, Hartmut Kaiser <hartmut.kaiser@gmail.com> wrote:
The Boost.Exception library uses size_t without any qualification,
which
leads to unexpected ADL problems related to mpl::size_t.
This was a bug in exception/object_hex_dump.hpp because it used unqualified size_t without #including <stdlib.h>. The use of size_t is now qualified, see trunk revision 57668.
I suspect however that we would have had the same issue even if object_hex_dump.hpp did #include <stdlib.h>. Isn't it too risky for mpl to define its own size_t?
Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
participants (7)
-
Andrey Semashev -
Emil Dotchevski -
Hartmut Kaiser -
joel -
Patrick Horgan -
Peter Dimov -
Robert Jones