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