heintze@fmcsse.enet.dec.com (Siegfried Heintze) (10/17/90)
At this time it appears that C++ will be our implementation language for
a product that must run on several UNIX(tm) flavored platforms in a addition
to VMS.
We have also decided that VMS is going to be our development platform.
Since all the target platforms are not clearly defined at this time, it appears
wise to purchase a C++ to C translator.
(1) Should we plan on using a C++ to C translator for our development on VMS?
Some people are promoting this and I argue this is a bad idea because
(a) The generated C code is unreadable (is this true for all C++ to C
translators?).
(b) Using the VMS debugger on this criptic C code will significantly
decrease our productivity.
Therefor I promote the notion that we need to purchase (or otherwise
legally
aquire) a C++ compiler and a C++ to C translator. I propose we only use
the C++ to C translator as a porting tool.
I would like to solicit comments from people who have actually used
various C++ to C translators for developement of real products. Is it
feasible to use a translator or are we justified in
purchasing a C++ compiler?
(2) Assuming we decide to purchase a C++ compiler from a third party:
Since there are several vendors who offer C++ compilers, I propose we
make a chart with the vendors on the top horizontal axis and the
possible attributes (ie the pros and cons) for each compiler on the
vertical
axis (like Byte Magazine does when it evaluates elements of a class of
products).
Please list what entries (ie, rows) you think we should have on this chart.
An example
might be: "does vendor supply debugger" or "Price". And if you know the
answers for some
certain vendors, please include this information also.
(3) Same as (2) for C++ to C translator.
Sieg
cdb@midas.WR.TEK.COM (Christopher David Browne) (10/18/90)
In article <16435@shlump.nac.dec.com> heintze@fmcsse.enet.dec.com (Siegfried Heintze) writes: >At this time it appears that C++ will be our implementation language for >a product that must run on several UNIX(tm) flavored platforms in a addition >to VMS. > >We have also decided that VMS is going to be our development platform. > >Since all the target platforms are not clearly defined at this time, it appears >wise to purchase a C++ to C translator. > > products). Here at Tektronix we bought a C++ translator from Glockenspiel that was supposed to run on VMS. We found that you cannot link to a library module that contains a printf or cout statement. We tried to find out how to link from the manuals that we received but the manuals only covered the DOS os not VMS, we don't have a DOS platform. We got nowhere with ImageSoft, Glockenspiels outlet, with repeated calls for a month and a half. Then three or four weeks ago ImageSoft found out from Glockenspiel that it was a known bug and that it was fixed in a new releas and that they would mail that releas to me post hast. I am still here waiting for it. I would not recommend the Glockenspiel C++ because of the customer assistance and documentation. Chris Browne Disclamer: I speak for myself.
davidm@uunet.UU.NET (David S. Masterson) (10/19/90)
In article <16435@shlump.nac.dec.com> heintze@fmcsse.enet.dec.com (Siegfried Heintze) writes: At this time it appears that C++ will be our implementation language for a product that must run on several UNIX(tm) flavored platforms in a addition to VMS. We have also decided that VMS is going to be our development platform. You'll be sorry :-(. C++ does not appear to be well supported on VMS at this time. G++ might be the best for what you are suggesting, but you'll have to decide whether you can live with the Gnu Public License. Having gone through this myself, in the long run, I think you'll wish you had some of the development niceties of a good Unix platform (for instance, Sun's C++ development environment). Since all the target platforms are not clearly defined at this time, it appears wise to purchase a C++ to C translator. The hard part will be getting the standard libraries you'll use (like streams) to move to the new system. If you have the source code to the C++ system you'll be using, it shouldn't be a problem to move to a new platform that doesn't have a C++ compiler. Of course, that can be rather expensive (in money or effort or both). (1) Should we plan on using a C++ to C translator for our development on VMS? Some people are promoting this and I argue this is a bad idea because (a) The generated C code is unreadable (is this true for all C++ to C translators?). In order to get some of the link-time (and run-time) error checking that working with C++ allows, the compiler "swizzles" information into a form that might be considered difficult to read. (b) Using the VMS debugger on this criptic C code will significantly decrease our productivity. Quite true (someone around here complains of that all the time). Most of our programmers have taken to debugging their code without the VMS debugger (which is still a loss in productivity). G++ does have GDB+ for doing debugging, but I don't know if this has been ported to VMS. Therefore I promote the notion that we need to purchase (or otherwise legally aquire) a C++ compiler and a C++ to C translator. I propose we only use the C++ to C translator as a porting tool. G++ is the only C++ compiler for VMS that I know of (are there others?). Since G++ comes with full source, you don't need the C++ to C translator as you could port G++ to the new environment. VMS development of C++ code at this time can be a BEAR. :-( -- ==================================================================== David Masterson Consilium, Inc. uunet!cimshop!davidm Mtn. View, CA 94043 ==================================================================== "If someone thinks they know what I said, then I didn't say it!"
dan@oresoft.com (Daniel Elbaum) (10/23/90)
In <CIMSHOP!DAVIDM.90Oct18104621@uunet.UU.NET> cimshop!davidm@uunet.UU.NET (David S. Masterson) writes: :In article <16435@shlump.nac.dec.com> heintze@fmcsse.enet.dec.com :(Siegfried Heintze) writes: : At this time it appears that C++ will be our implementation language for a : product that must run on several UNIX(tm) flavored platforms in a addition : to VMS. : We have also decided that VMS is going to be our development platform. :You'll be sorry :-(. C++ does not appear to be well supported on VMS at this :time. ... :The hard part will be getting the standard libraries you'll use (like streams) :to move to the new system. Oregon C++ runs under VMS; the library contains entry points which emulate commonly-used UNIX I/O system calls. A source- level debugger is included, along with some other goodies. Send mail to support@oresoft.com for more info. -- Fear, like pain, may just be His way of hurting us. ({uunet,tektronix,reed,sun!nosun,m2xenix}!oresoft!(dan)@oresoft.com)