Re: VAX/VMS C

Re: VAX/VMS C

[Mike Feldman]

If I wanted to read detailed commentary on C compilers and C coding style
I'd be reading the C news feed, not the Ada one. Once more: _please_ try
to post stuff that's relevant to the purpose of the list...

The recent discussions of tasking semantics, for example, are focusing on
good meaty technical stuff, not flames about C compilers.  OK?

"C" vrs ADA

[Glen Harman]

Hello, sorry to interrupt your regularly scheduled news articles, but I
didn't know where else to turn...

I am a senior EE student whose current career goal is to work in an aerospace
and/or military research field.  To better my chances, I would like to 
supplement my Fortran skills with another language.  "C" has been recommended
to me many times, and I was just about to buy a manual when I started hearing 
about ADA.

I have heard that is is the DoD language, but what does that mean?  Are all 
aerospace and military contractors required to use it?  Is it suggested learningfor the major corporate engineers?  Is it filtering down into the public 
engineering sectors?  Is it too specialized to be applied elsewhere if I didn't
get the desired job?

Being that I am relatively unfamiliar with what is being used in these fields,
I am turning to those of you in the know.  If you have any thoughts on the pros
and cons of either language, and/or would care to make a suggestion, I would
greatly appreciate it. If you could, please recommend a book on the subject. 

Please send replies to:  \!{cbmvax, pyrnj, bpa }\!vu-vlsi\!harman

Thank you for you help!

Glenvar Harman

Re: "C" vrs ADA

[spf]

In article <1065@vu-vlsi.UUCP> harman@vu-vlsi.UUCP (Glen Harman) writes:
>supplement my Fortran skills with another language.  "C" has been recommended
>to me many times, and I was just about to buy a manual when I started hearing 
>about ADA.

Learn them both.  C is the assembly language, and Ada the High Order
Language (HOL), of the next ten years in the DoD community.  The DoD
doesn't much like C from a lifecycle point of view, but has trouble
denying its availability and current performance advantage over Ada
(just like assembly with respect to FORTRAN 20+ years ago).

Steve Frysinger

---
Why would I waste my time expressing someone else's opinion?

Re: "C" vrs ADA

[R.A. Agnew]

In article <12513@clyde.ATT.COM>, spf@moss.ATT.COM writes:
> In article <1065@vu-vlsi.UUCP> harman@vu-vlsi.UUCP (Glen Harman) writes:
> The DoD > doesn't much like C from a lifecycle point of view, but has trouble
> denying its availability and current performance advantage over Ada
> (just like assembly with respect to FORTRAN 20+ years ago).
> 
> Steve Frysinger

What performance advantage?? The DEC Vax Ada compiler generates tighter code than the 
Vax C compiler (no slouch) not to mention the fact that I generate code 5 to 10
times faster in Ada due to problem level abstraction and re-use.

Re: "C" vrs ADA

[David C. Albrecht]

> > What performance advantage?? The DEC Vax Ada compiler generates tighter
> > code than the  Vax C compiler (no slouch)...

> This says more about the relative investment in the compilers than about
> the languages.  DEC has a history of being unenthusiastic about C; it shows.
> -- 

Well then if DEC is unenthusiastic about C the people responsible for unix
(B&B) must be somnabulistic since the VAX C compiler beats the pants
off of pcc.

David Albrecht

Re: "C" vrs ADA

[Peter da Silva]

In article <138@kesmai.COM>, dca@kesmai.COM (David C. Albrecht) writes:
> Well then if DEC is unenthusiastic about C the people responsible for unix
> (B&B) must be somnabulistic since the VAX C compiler beats the pants
> off of pcc.

If the VAX 'C' compiler (presumably the gode gen) beats the pants off PCC,
the runtime must be a DOG. VAX 'C' is the worst 'C' development environment
it has ever been my misfortune to work under, both because of the poor
support for VMS in VAX C, and because of the incredibly poor performance
of the resulting programs. I'll take BDS 'C' for the Z80 any day over
DEC's "product".

DEC has indeed been unenthusiastic about 'C', and anything else to do
with UNIX. The old NIH syndrome.
-- 
-- Peter da Silva `-_-' ...!seismo!soma!uhnix1!sugar!peter
--                  U   <--- not a copyrighted cartoon :->

Re: "C" vrs ADA

[Rahul Dhesi]

In article <584@sugar.UUCP> peter@sugar.UUCP (Peter da Silva) writes:
>[VAX/VMS C] is the worst 'C' development environment
>it has ever been my misfortune to work under, both because of the poor
>support for VMS in VAX C, and because of the incredibly poor performance
>of the resulting programs.

I think the $39.95 MIX C compiler for MS-DOS is somewhat worse.

Even a very careful reading of the VMS C documentation and release
notes reveals absolutely no bugs or deficiencies in the VMS C
environment.  If anything, as the manual makes clear, VMS C adds
functionality to the original UNIX implementation.

Compare this with the large number of bugs and deficiencies that are
documented in the manual for almost every UNIX program.

Also note that VMS C runtime environment automatically converts all
command-line arguments to lowercase, thus greatly simplifying argument
parsing.  And no lint-like program is provided, saving you the
temptation of using one and having to face the rude diagnostics it
would probably give you.

But perhaps the most outstanding advantage of VMS C environment is that
the cursor control routines require a terminal manufactured by DEC or
something equivalent.  This saves no end of trouble--no more time
wasted having to create termcap entries for strange terminals of
questionable quality.
-- 
Rahul Dhesi         UUCP:  {ihnp4,seismo}!{iuvax,pur-ee}!bsu-cs!dhesi

VAX/VMS C

[Jim Sullivan]

In article <1069@bsu-cs.UUCP> dhesi@bsu-cs.UUCP (Rahul Dhesi) writes:
>In article <584@sugar.UUCP> peter@sugar.UUCP (Peter da Silva) writes:
>>[VAX/VMS C] is the worst 'C' development environment
>
>
>Even a very careful reading of the VMS C documentation and release
>notes reveals absolutely no bugs or deficiencies in the VMS C
>environment.  If anything, as the manual makes clear, VMS C adds
>functionality to the original UNIX implementation.
>
>Compare this with the large number of bugs and deficiencies that are
>documented in the manual for almost every UNIX program.

Of course, if the bug is not documented, it doesn't exist.  Personnally,
I'd rather know about the bugs before I hit them.  Honesty is the best
policy.

>Also note that VMS C runtime environment automatically converts all
>command-line arguments to lowercase, thus greatly simplifying argument
>parsing.

unless you want mixed case arguments.  Of course, the rest of VMS uses
uppercase arguments....

>          And no lint-like program is provided, saving you the
>temptation of using one and having to face the rude diagnostics it
>would probably give you.

because you've written bad, unportable code.  Just cause C lets you do
things doesn't mean that you should do these things.  Lint is very useful
in tracking down the bad things that you didn't mean to do.  Of course,
DEC seems to think that some things I consider illegal are perfectly legal.
For example, taking the address of a constant! (&2) or a[]="string"; inside
a function. (thanks to local C guru for comfirmation)

>But perhaps the most outstanding advantage of VMS C environment is that
>the cursor control routines require a terminal manufactured by DEC or
>something equivalent.  This saves no end of trouble--no more time
>wasted having to create termcap entries for strange terminals of
>questionable quality.

Just have to spend your money on new terminals if you don't have the DEC
supported terminal. (see discussion in comp.os.vms about SMG)

>Rahul Dhesi         UUCP:  {ihnp4,seismo}!{iuvax,pur-ee}!bsu-cs!dhesi

Jim Sullivan	HCR Corporation