stergios@athsys.uucp (Stergios Marinopoulos) (06/05/88)
I beleive mwm@violet.berkeley.edu has already mentioned that Lattice's
C++ will be a translator and not a compiler. What I would like to
know is if Lattice is basing this translator on AT&T's, *much* like
the designer C++ Programming System from Glockenspiel Ltd., Dublin
Ireland. Then if so could someone in the know address the following
issues?
* how does Lattice solve the "post linker linker" problem? -
does it go into the executable and patch it with a
linked list of all static objects and execute them before
entering main?.
* related to the above: If you do peform this ugly hack
are you going to get it right or mess it up (like AT&T
and therefore glockenspiel did) so bad that static global
objects cannot be depended on!
* again related to the above: will lattice *GUARANTEE* only *ONE*
vtable per class per executable? If not then just throw out the
possibility of having large programs developed. You would
be supprised how easy it is for executables to grow over
1 meg without this option!
* again related to the above: What about virtual destructors?
Are you going to get them right? Please, please say yes.
* what extensions will lattice support?
- multiple inheritance?
can live with out but would be a big win for true
object oriented programming.
- accept "old style" c function definitions?
*this is a must*
- interface to "old style" c libraries.
* document the naming convention for overloaded and virtual
functions. This is a must for debugging. Not that AT&T
documented it. It would just be nice to have in a product
you pay $$ for and make your living with!
* How about debugging? Are you going to support a C++ debuugger?
I could live with a regular dbx style debugger that has
alias commands. Dont even bother giving a machine level debugger
by itself.
Could a Lattice representative please comment on the above?
stergios marinopoulos
XPert XPorts
sun!athsys!cyclopes!stergios