Masaharu, Fine. In this specific case, the #include of <hash_map> was done like this: #ifdef CMS_NO_HASH_MAP #include <map> #else #include <hash_map> #endif so the author of the code was apparently aware that hash_map was a compiler specific header. Also, this made it easy to work around the "problem". I was not aware that <hash_map> was so compiler specific. Because of this, I see no serious problem with CINT not supporting it. However, the problem is not in hash_map itself, but in <bits/types.h>. If <bits/types.h> is also specific to gcc2xx, I see no problem. However, if it is much more widespread, the problem might resurface with a #include other than <hash_map>. Bill Tanenbaum Masaharu Goto wrote: > > Hello Bill, > > <hash_map> is not included in ANSI/ISO standard. And I can only find it > in gcc2.xx, but not in gcc3.xx and VC++. It is very likely same problem > occurs if you use non standard header, because I am not intended to > support them. Basically, what I am doing is > > 1) Provide Cint version of standard header file so that Cint will > support or reasonably emulate how standard library works. > I am trying to cover all or , at least, good portion of ANSI C, > ANSI/ISO C++ and subset of POSIX, Win32. > > 2) If a user tries to use non standard header, I am giving a second > chance by reading files under /usr/include/. However, this works > only if you are lucky. Because many of the files under /usr/include > are compiler dependent. Your case fall into this category. Anyway, > you'll have to modify your code if you port it to another compiler. > > Thank you > Masaharu Goto > > >Masaharu, > > I am converting existing code (written by someone else) to work with > >ROOT, rather than with Objectivity. The header file that this code > >included that caused the problem was <hash_map>. Apparently, it > >indirectly includes <bits/types.h>, although I have not traced the chain > >of #includes. > > > > In this particular case, I was able to avoid the #include of <hash_map > > > >and work around the problem. I am, however, worried that next time that > >this happens there may be no obvious workaround. > > > >Bill Tanenbaum
This archive was generated by hypermail 2b29 : Sat Jan 04 2003 - 23:50:54 MET