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
> >
>