This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Builtins in `std'
On Wed, May 23, 2001 at 09:55:31AM -0700, Mark Mitchell wrote:
> Jakub> As I already wrote, this is especially bad in the global
> Jakub> namespace, because there the library has hard time to take
> Jakub> care of all the global namespace functions. Like:
>
> We already do not put these names in the global namespace.
Really? As I see bits/c_std/ it puts everything into global namespace and
then drags them into the std:: namespace.
> Jakub> #include <cstring>
>
> Jakub> using namespace std;
>
> Jakub> int foo () { return strchr ("abc", 'a') != 0; }
>
> Jakub> will not be optimized while if it is replaced by
> Jakub> std::strchr it will (although as soon as those builtins are
>
> This one uses the one in `std', thanks to the `using', so it will be
> treated just like `std::strchr'. And the library can easily make
> `std::strchr' call `std::__builtin_strchr' just as it does for
> `std::fabs'.
So how do you explain that
#include <cstring>
using namespace std;
int foo () { return strchr ("abc", 'a') != 0; }
is not optimized while
#include <cstring>
using namespace std;
int foo () { return std::strchr ("abc", 'a') != 0; }
is? Clearly if strchr is present both in global namespace and in std
namespace, it is taken from global namespace.
> In C++, there is no such standard function as `::strchr', and it would
> be wrong to optimize it specially. A user program like:
But the C++ standard includes implicitely ISO C standard which defines what
strchr does.
>
> char *strchr(const char *, int) { return 0; }
>
> must be accepted, must not count as a redefinition of the `strchr' in
> the standard library, must not result in errors about defining two
> functions with the same type, etc. I don't think such a function can
> be `extern "C"', though.
This can be solved by the lazy builtins, where only prototype with extern "C"
would make the builtins alive.
Jakub