Functions called tuple and array

I am having peculiar problems compiling a macro when I try to use “tuple” or “array” as function names.
The example is truly strange, without #includes but with the macro just named “tuple”:

// tuple.C:
int tuple(){return 0;}

root [0] .L tuple.C+ Info in <TMacOSXSystem::ACLiC>: creating shared library /Users/jfcaron/Projects/Proto2BeamTest2/code_test/./tuple_C.so /Users/jfcaron/Projects/Proto2BeamTest2/code_test/tuple_C_ACLiC_dict.cxx:80:38: error: reference to 'tuple' is ambiguous G__letint(result7, 105, (long) tuple()); ^ /Users/jfcaron/Projects/Proto2BeamTest2/code_test/./tuple.C:1:5: note: candidate found by name lookup is 'tuple' int tuple(){return 0;} ^ /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../lib/c++/v1/tuple:488:29: note: candidate found by name lookup is 'std::__1::tuple' class _LIBCPP_TYPE_VIS_ONLY tuple ^ 1 error generated. clang: error: no such file or directory: '/Users/jfcaron/Projects/Proto2BeamTest2/code_test/tuple_C_ACLiC_dict.o' Error in <ACLiC>: Compilation failed!
Is this a bug in libc++? Why should the name of a macro matter?

Some info that might be useful:

root [2] gSystem->GetMakeSharedLib()
(const char* 0x7fba72510ff0)"cd $BuildDir ; clang++ -c $Opt -m64 -pipe -Wshadow -W -Wall -Woverloaded-virtual -fsigned-char -fno-common -DR__HAVE_CONFIG -std=c++11 -stdlib=libc++ -pthread $IncludePath $SourceFiles ; clang++ $ObjectFiles  -dynamiclib -single_module -Wl,-dead_strip_dylibs -O2 -m64 -mmacosx-version-min=10.9 -stdlib=libc++ $LinkedLibs -o $SharedLib"

clang -v
Apple LLVM version 5.1 (clang-503.0.40) (based on LLVM 3.4svn)
Target: x86_64-apple-darwin13.1.0
Thread model: posix

The same thing happens for “array”. By the way, the headers and are very handy, and it’s a shame that there are difficulties with trying to .L macros.C+ that try to use them (even if they are not exposed to CINT). Will ROOT6 be able to use these out-of-the-box?

Jean-François

I think I tracked down the source of this problem. Somewhere as part of ".L foo+"ing a macro, ACLiC actually ends up inserting “using namespace std;” into the thing that gets compiled. This I found by grepping all my code for “using” and I noticed that the auto-generated dict.h from using “makecint” on some of my files contained “using namespace std;”. For my simple tuple.C example, I guess ACLiC also somewhere #includes so that the real clang++ compiler gets confused between my tuple function and std::tuple?

A global namespace inclusion in a header file is considered a SERIOUS code smell, why does ACliC do this? I found this post [url]ACLiC problem that claims it’s unavoidable, but surely something can be done to warn the user? Something better than the horrible mess of compiler warnings that I showed above? Can we generate a list of forbidden names from the std::namespace when ROOT is compiled/first run that the user can read?

Will this all go away with ROOT6?

Jean-François