| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 1307.1 | | WJG::GUINEAU | | Wed Apr 06 1988 22:33 | 21 |
|
> If I do manage to open 'PRT:', would I use the same method in opening
> 'SER:'?
Yup!
> Would I be right in assuming that writing to 'SER:' and 'PRT:' will
> produce the same results except that the output to 'SER:' will not go
> through a driver that translates escape sequences and there will be a
> problem with carriage return and line feed (on 'SER:')?
Your on a roll :-)
> I want to my LA100 without a silly printer driver getting in the way.
> Would outputing to 'SER:' solve all my problems?
Thats how..
John
|
| 1307.2 | Yes but ... | STKEIS::LJONSSON | | Thu Apr 07 1988 08:33 | 5 |
|
That answers all my questions except the first and most important
one - How do I open 'PRT:' or 'SER:' and write to them?
/Lars
|
| 1307.3 | | WJG::GUINEAU | | Thu Apr 07 1988 11:43 | 20 |
|
something like:
main()
{
FILE *fopen(),fp;
fp = fopen("PRT:","w"); /* Open channel to PRT: device */
/* fp is now a "pointer to a file" */
putc(c, fp); /* Send character in c to PRT */
fclose(fp);
}
John
|
| 1307.4 | C Coding Warning | TLE::RMEYERS | Randy Meyers | Thu Apr 07 1988 22:17 | 34 |
| Re: .3
You hit a sort point with me!
Never declare fopen or any other standard C routine in your programs.
Always include the appropriate include file that contains the definition.
#include <stdio.h>
main()
{
FILE *fp;
char c = '\n';
fp = fopen("PRT:","w"); /* Open channel to PRT: device */
/* fp is now a "pointer to a file" */
putc(c, fp); /* Send character in c to PRT */
fclose(fp);
}
I realize that the author of .3 was quickly dashing off an example
and is blameless. However, providing your own declarations for
standard C functions and failing to include the proper include file
are common mistakes for beginning C programmers. I just want to
warn people away from those mistakes.
If my tone sounds shrill, please forgive me. I have been heavily
involved with writing the C guidelines for the new Software
Engineering Manual, and I'm afraid it has made me a bit overly
critical.
Sorry.
|
| 1307.5 | more info on proper guidelines, etc. | MVCAD3::BAEDER | D. Scott DTN 237-2961 SHR1-3/E19 | Fri Apr 08 1988 01:38 | 9 |
| this may not be the right place, BUT...I for one would like to hear
A LOT more about this manual...I'm a firm believer in standards,
etc. BUT after joining dec last summer was surprised to see not
a lot of visibility in this area, and really haven't heard a lot
about anything like this...(other than refs to something about 10
yrs old)...MORE INFO P L E A S E ! ! !
thanks....scott
|
| 1307.6 | RMS is the way | WJG::GUINEAU | | Fri Apr 08 1988 03:00 | 13 |
|
Re .4, .5
I agree with Scott - Standardize us!!
My reply on using fopen was purely academic... I have only just begun
to use C on PC type computers (shame to call Amiga a *PC*. How about
"Home SuperMini"? :-)
Anyway, I'm used to FAB's and RAB's !
John
|
| 1307.7 | Software Engineering Manual | TLE::RMEYERS | Randy Meyers | Fri Apr 08 1988 05:21 | 37 |
| Re: .4, .5, .6
Sigh, this isn't the place to discuss it, but I started the whole thing
so I guess I owe an explanation.
The new Software Engineering Manual is indeed an update (major rewrite)
of the old Software Engineering Manual. This manual gets updated
every ten years whether it needs it or not. :-)
In general, the manual has been reorganized. The old SEM was broken
down by language with huge sections on BLISS and MACRO and not much
on anything else. Now, the bulk of the manual is in a language
independent section that tries to be a more high level discussion
of the engineering process. Individual language guidelines appear
as appendixes.
In general, I suspect that there is less dogma and more meat in the
new SEM. In the C appendix we have tried to avoid religious issues
and stick to describing engineering practices that actually impact
the maintainability of the software. For example, which of the
many indentation styles you choose, as long as used consistently,
does not really impact the quality of your code. However, failing
to use the type checking abilities of the language or failing to
divide the program into proper modules has a great impact.
We haven't completely succeeded in eliminating subjective from the
objective in the C appendix. I suspect that if we had more time
we could do a better job.
How do you get a copy? I believe the current plan is that everyone
will get a copy. Just sit tight for another couple of months.
If you are new to C and dying for help with your style, I recommend
the book "C Programming Guidelines" by Tom Plum (vice chair of the ANSI
C committee).
With those words, we should probably return to the original discussion.
|