Re: CINT improvement news

From: Masaharu Goto (gotom@hpyiddq.jpn.hp.com)
Date: Thu Jul 03 1997 - 07:45:42 MEST


Nick,

 I've been very sorry for leaving your problem unresolved for a long time.
 Today, I get, at least, a workaround and a light in the dark to 
 identify the cause.

Workaround-1:

 It seems like that the calling function as local variable initialization
 causes the crash.
     int jp=index(row,col);
 If you re-write it as follows, it worked fine.
     int jp;
     jp = index(row,col);
 There are several locations you need to change.
 This is a bug.

Workaround-2:
 As I proceed with above change, I found another problem. It crashes when
 compiling bytecode. For the time being, please use optimization level 3.
 Default is 4 which turns on incremental bytecode compilation of tribial
 functions.

   root[0] .O3
   root[1] .x main.cc

 With these workaround, you macro worked.

Masaahru Goto

> 
> Hi Masa,
> I have been out for a day or 2 and am now reading my emails in reverse
> order as they came in, so maybe you have already sent me another mail about
> the subject. However, from the scenario below I myself would prefer
> method 1) to be implemented since to me this seems to be in line with the
> ANSI proposed standard. I am not at all a specialist in C++ and therefore
> let myself always guide by some text books adhering the ANSI standard.
> Therefore it is important for me that the ROOT/CINT functionality should
> at least provide a fully ANSI C++ compatible environment, such that
> a simple user like me should no difference in coding for e.g. g++ to
> compile code, or coding fopr ROOT/CINT.
> 
>                                                     Cheers,
>                                                      Nick.
> 
> P.S. I hope the CINT major improvements will also cure the problem I
>      recently mentioned to you.
> 
> *----------------------------------------------------------------------*
>  Dr. Nick van Eijndhoven                Department of Subatomic Physics
>  email : nick@fys.ruu.nl                Utrecht University / NIKHEF
>  tel. +31-30-2532331 (direct)           P.O. Box 80.000
>  tel. +31-30-2531492 (secr.)            NL-3508 TA Utrecht
>  fax. +31-30-2518689                    The Netherlands
>  WWW : http://www.fys.ruu.nl/~nick      Office : Ornstein lab. 172
>  ----------------------------------------------------------------------
>  tel. +41-22-7679751 (direct)           CERN PPE Division / ALICE exp.
>  tel. +41-22-7675857 (secr.)            CH-1211 Geneva 23
>  fax. +41-22-7679480                    Switzerland
>  CERN beep : 13+7294                    Office : B 160 1-012
> *----------------------------------------------------------------------*
> 
> *** Masaharu Goto wrote :
> > 
> > Rooters,
> > 
> >  I made a major improvement on CINT C++ interpreter.  
> > 
> > Operator precedence:
> >   CINT used to have different operator precedence to ANSI standard. This
> >  part was one of the oldest code which was rather messy. This time, I 
> >  completely re-write this part with a better implementation. Operator
> >  precedence should be compliant to the standard now.
> >  The new version will be copied to CERN soon.
> > 
> > 
> >  And next is a question to Rooters about another enhancement.
> > 
> > Operator new:
> >   I'd like to make an improvement on 'operator new' handling. Before I
> >  make a change, I'd like to ask ROOT users about my idea.  Now, you can 
> >  only use default operator new provided by OS and ROOT/CINT.  You could 
> >  overload operator new, but it is not a simple job. I have following 
> >  alternatives of future enhancement.
> > 
> >  1) ANSI/ISO standard says there is not default operator new with arena
> >    argument. Gussing that this is the most popular way of using overloaded
> >    new, CINT provides embedded operator new with arena argument. With
> >    this enhancement, a user can write following macro without having his
> >    own operator new(). 
> > 
> > 	 class Txxx;
> > 	 char buf[10000];
> >          Txxx *p1 = new Txxx;
> > 	 Txxx *p2 = new((void*)buf) Txxx;
> > 	 Txxx *p3 = new((void*)buf) Txxx[10];
> > 
> >  2) Allow user to overload operator new at his one risk. Overloading
> >    operator new in interpreter environment is simple. But doing so in
> >    compiled code is not. One has to go throught painful thinking. I
> >    do not explain in detail , but there is an inevitable reason.
> > 
> >  I prefer to implement 1).  Give me your opinion.
> > 
> > Masaharu Goto
> > 
> 



This archive was generated by hypermail 2b29 : Tue Jan 04 2000 - 00:26:19 MET