[ROOT] Re: [CINT] Re: FW: rootcint problem with

From: William Tanenbaum (wmtan@fnal.gov)
Date: Mon Jun 03 2002 - 15:51:25 MEST


Fons,
	Fine.  No problem.
Bill


Fons Rademakers wrote:
> 
> Hi Bill,
> 
>    bit/types.h is a gcc/linux internal header file, which is not part of
> POSIX, like for example the X11 or Motif or whatever other 3rd party
> header files. In case of those headers you should either use the -p
> option of rootcint or change the code using #ifndef __CINT__ constructs.
> If you want to write portable code use only POSIX headers.
> 
> Cheers, Fons.
> 
> On Mon, 2002-06-03 at 04:09, William Tanenbaum wrote:
> > 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
> --
> Org:    CERN, European Laboratory for Particle Physics.
> Mail:   1211 Geneve 23, Switzerland
> E-Mail: Fons.Rademakers@cern.ch              Phone: +41 22 7679248
> WWW:    http://root.cern.ch/~rdm/            Fax:   +41 22 7679480



This archive was generated by hypermail 2b29 : Sat Jan 04 2003 - 23:50:54 MET