dror@well.sf.ca.us (Dror Matalon) (04/12/91)
I recently asked about saber C++ and here are the responses I got. I apologize for taking so long, I had trouble with posting. Most of the people that responded liked Saber C++. >From apple!cs.sfu.ca!miron Mon Mar 18 09:05:16 1991 Hi. I just got my copy of Saber-C++ last week. Managed to crash the cfront compiler that came with it on a piece of code, and now I am waiting for support to get back to me. I also managed to crash the debugger itself, but I haven't reproduced it yet. >From apple!pacific.csl.uiuc.edu!steven Mon Mar 18 15:24:40 1991 We are very happy users. At least once a week I shudder at the thought of how long it would have taken to track down a bug without it. |> Specifically, how much of the language does it support, what version, Its very close to the CFRONT2.0 release -- in fact, cfront2.0 is included. It does have some bugs, but no more (and very possibly less) than one could expected with a new product, and it can only get better. About the only caveat is that given my choice, I'd rather have a sparcstation 2 to run it on (it works fine on some kind of sparc 1, but I'm impatient.) Also, I don't suggest running it on a diskless workstation (get at least local swap) and/or get a minimum of 16M on the machine. It has a pretty big executable image. steven parkes --------------------------------------- University of Illinois Coordinated Science Laboratory steven@pacific.csl.uiuc.edu ------------------------- >From apple!aeg.dsto.oz.au!dch Mon Mar 18 18:32:50 1991 We are using Saber C++ but are not happy with it. The following is the text of a fax we sent to Saber last week. Begin fax ********************************************************************** Problems with Saber C++ 1.0.1 We are using Saber C++ 1.0.1 which is supplied with AT&T C++ 2.0. We are running under SunOS 4.1.1. In previous correspondence with Saber C++ support, we have reported several problems with the Saber C++ environment and translator. The list below shows the problems which we have earlier reported when running Saber C++ 1.0 and were assured would be resolved with release 1.0.1. The only improvement we have seen in 1.0.1 is a small increase in speed. Compiling and linking our large programs is still unacceptably slow. Current problems are as follows: 1. There is a limitation of 279 #include directives in any one file. If more than this are used then either invalid syntax errors are reported (we have isolated these errors to an empty file) or "too many file buffers" is reported. 2. When compiling some programs a bus error is produced in the C++ translator itself. There is no way to remove this bus error since the programs compile perfectly under Sun C++. This may be related to the above problem. 3. There is a severe limitation on the level of nested "includes" allowed. When exceeded, the error "unreasonable include nesting" is reported. Sun have recognized the problem and supplied a patch for Sun C++ to remove this bug. 4. Variable argument handling using the header stdarg.h does not work under Saber C++ but does work under Sun C++. This means variable arguments cannot be used under Saber C++. The above problems make Saber C++ unusable with our project. As a result of the problems encountered with Saber C++ and the faster speed of compiling under Sun C++, we are no longer using Saber C++. Any suggestions would be appreciated including news of further releases and whether they will resolve these problems. Peter Temple Avionics Engineering Group Aeronautical Research Laboratory Defence Science and Technology Organisation Salisbury, South Australia. End fax ************************************************************************ To Saber's credit they responded promptly, also by fax. I don't have the reply to hand right now but I believe most of the problems have been resolved (or will be in the next release) with the exception of the speed problem. This could well be a result of the way we are using the product. Ours is a very large project with many libraries, NIH and XGL for starters. We may be able to improve performance by compiling only the modules we are debugging and linking the rest. We are looking at that now. While, dbxtool doesn't speak C++ (ie doesn't understand references etc) the software engineers working on the project would rather have used it and hordes of cout's rather than Saber because of the recompile time. If you have any detailed questions email me and I'll pass them on to our software engineers. David C. Hanslip E-mail: dch@aeg.dsto.oz.au Aeronautical Research Laboratory Phone: +61 8 259 5792 DSTO Salisbury, South Australia Fax: +61 8 259 5507 >From apple!uunet.UU.NET!meaddata!meaddata.com!marko Wed Mar 20 13:15:25 1991 Well, I am a pretty happy Sabre C++ user. My first taste of Sabre came as I was debugging a _huge_ application that was consistently core dumping. The problem was that neither dbx or gdb could tell me where the error was occurring. Most of the stack trace was through functions that the debuggers could not name for me. I had heard that our organization was in the process of evaluating Sabre C++ as our primary work environment (for 250+ people) and asked to try it out. Sabre C++ had some trouble dealing with my myriad of object libraries, most of which were compiled with AT&T C++ 2.1 (Sabre only supports 2.0) but tech support was able to help by suggesting I dump the debugging information from these files when I loaded them. This allowed me to completely load my application and run it under the Sabre environment. Sabre was quick to find that some Motif 1.1 code was accessing to far into an array (array length 2 trying to access the third element) and gave me a complete stack trace so I could track down the problem, and put in a work around in my code. (BTW, Motif 1.1.1 fixed this bug.) All in all, I'm quite happy. I look forward to using it to actually develop code in Sabre; the class and xref browsers look quite fun. -- --- Mark Osbourne (marko@meaddata.com) (...!uunet!meaddata!marko) -- >From apple!Larry.McRCIM.McGill.EDU!stevej%bnrmtl.UUCP Wed Mar 20 13:20:18 1991 If you want to use the X version of Saber C++, you need a lot of memory, that is more that 16mb. -- Steve Juneau Recherches Bell-Northern Ltee 3, Place du Commerce phone: (514) 765-8246 Verdun, Quebec, Canada fax: (514) 876-3681 H3E 1H6 email: bnrmtl!stevej@larry.mcrcim.mcgill.edu >From apple!tcs.com!robert Thu Mar 21 14:35:15 1991 I have been using SaberC for a couple of years and I am wildly enthusiastic about it. I am now learning SaberC++. The most useful things about SaberC (most of which carry over to C++) are very good static program checking (better than lint) and detection of run-time errors. This is the big win. a debugger will not do much or any of this for you. This includes using variables that have not been initialized, writing into freed memory, freeing memory that has already been freed, writing past the end of an array, assigning a value to an enumerated type that is illegal, casting a base class pointer to a derived class pointer when the base class pointer does not point to a derived class object, etc. Admittedly, some of this is less useful in C++ than in C because you are less likely to make mistakes with malloc and free in C++ since you have constructors and destructors to do a lot of the memory management for you. Still, these kind of errors can be extremely pernicious and take hours or days to track down. I can say that in my previous project, using SaberC, I found malloc/free errors in 70+k-lines programs that could have taken an indefinite amount of time to find. What I am liking so far about SaberC++ as a new user of the language is that it is helping me learn the language. My entire group is learning C++ and using SaberC++ at the same time. C++ is a fairly complex language, and I think that SaberC++ is helping me master it more quickly than just cfront. I can type things in and see if they do what I think they should. There are also a lot of information-viewing features, like expanding a section of code to see all the temporary objects and type conversions that take place. And the class browser. Another benefit of an interpreted environment is that you can load in a few classes and play with them, without having to write a program. You can fire up a few objects and see what they do, look at their insides, etc. I believe that Saber-C made me a lot more productive in C programming by finding many very tricky and hard-to-detect errors. It is a little early to say about SaberC++. When I started using SaberC, I had release 2.0, which was very buggy. Release 2.3 was quite good, and 3.0 was excellent. So far, SaberC++ is on release 1.0.1a, which has quite a few bugs, but I expect that it will evolve into an excellent product within one or two years. And even now, I believe that it will be quite useful. The major drawback is that the interpreted code runs very slowly. You can also load in compiled code, which runs about as fast as compiled code in dbx, but you don't get as good debugging. What I usually do is load in the stuff I am testing in source, and the rest compiled. Another advantage is you can run in your environment without loading and linking everything, as long as you don't follow execution threads that call unresolved functions or reference unresolved variables. This makes prototyping and testing a lot easier. In summary, I think that anyone who wants to program in C++ without saber is probably making a mistake. ----------------------------------------------------------------------------- Robert Blumen | rblumen@tcs.com Senior Software Engineer | 2121 Allston Way, Berkeley, CA 94704 Teknekron Communications Systems, Inc. | (415) 649-3759 >From apple!tcs.com!robert Fri Mar 22 19:44:04 1991 > > I believe that Saber-C made me a lot more productive in C programming by > finding many very tricky and hard-to-detect errors. It is a little early > to say about SaberC++. When I started using SaberC, I had release 2.0, > which was very buggy. Release 2.3 was quite good, and 3.0 was excellent. > So far, SaberC++ is on release 1.0.1a, which has quite a few bugs, but I > expect that it will evolve into an excellent product within one or two > years. And even now, I believe that it will be quite useful. > For example, some one in my group showed me this code today: class A { private: int i; }; class B : public A { public: B(int foo) { i = foo; } }; this code loads and runs in saber. They do have pretty decent customer support, though. ----------------------------------------------------------------------------- Robert Blumen | rblumen@tcs.com Senior Software Engineer | 2121 Allston Way, Berkeley, CA 94704 Teknekron Communications Systems, Inc. | (415) 649-3759 >From pacbell!indetech!infmx!herbach Mon Mar 25 14:05:55 1991 As you may know, we have a bunch of people using Sun C++. Because of limitations in dbx++ (it's brain-dead), we've been evaluating Saber. Preliminary results indicate that it is better but MUCH slower--so slow in fact that Nanda is recommending against it at least until we check what Sun has fixed in their imminent 2.1 release. I'll let you know more as we learn it if you wish. Good luck, Martin