PM>> As a Real C Programmer, I suppose you don't bother with function

 PM>> prototypes, you ignore those pesky warning messages the compiler insists

 PM>> on spitting out and you'd never consider running Lint over your code.

 PM>> After all, Real C Programmers don't need to be protected from

 PM>> themselves.



 PE> No, I do follow the warning messages, because they make sense.

 PE> And if the compiler were to give me a warning message whenever

 PE> I tried to modify or even view a variable within the FILE

 PE> structure, I would welcome such a warning also.



But Paul, you've been arguing that a Real C Programmer would never view or
modify a FILE structure, so there's no need for any sort of protection. Now
your saying that you'd like the compiler to give you warning messages when
you do view or modify it. You can't have it both ways.



With my approach you get a compiler error if you try to access the members
in the structure. If you really feel you must access them, then you can get
around it fairly easily.



 PE> Until then, I add prototypes, and don't touch variables in the FILE

 PE> data type, BEFORE the compiler gives me a warning.  The compiler

 PE> catches the prototypes I *accidentally* missed.  It doesn't catch the

 PE> FILE modifications, but then that is not something I lament - I'm

 PE> hardly likely to *accidentally* be modifying the FILE data type.



Then why would you welcome warning messages about viewing or modifying FILE
structures?



What about the programmer who comes along after you and has to maintain
your code. He may not be fully versed in your techniques and may in fact be
working on a system where the programs have a mix of different styles. In
some cases he may have to view or modify the contents of structure because
that's the way the program was written. If you then say he can't view or
modify the contents of others, then it becomes easier to make mistakes.



If the structure he isn't supposed to view or modify are private, then it's
obvious from the compiler errors that he's done the wrong thing.



 PM>> The point of all of the above things and OO techniques such as

 PM>> encapsulation, *is* to protect the programmer from themselves.



 PE> And you've hired the wrong person, and used the wrong language,

 PE> if that is your aim.



So your only objection to my technique is that it infringes on the Real C
Programmer's right to shoot themselves in the foot and write buggy and
error prone software.



A programmer, in any language, who isn't interested in improving the
reliability of their programs is a cowboy, and I wouldn't let them near any
system I was responsible for.



 PM>> The end

 PM>> result is, hopefully, a more robust and error free program.



 PE> Ada 95? is probably what you're looking for if that's what you

 PE> are trying to achieve.  Still not a good idea to hire the sort

 PE> of people who would want to modify the FILE data type though.



If you're not interested in writing robust and error free programs then
your company has hired the wrong person.





Paul



--- GoldED/2 2.42.G0214+