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