PM>> But Paul, you've been arguing that a Real C Programmer would never view

 PM>> or modify a FILE structure, so there's no need for any sort of

 PM>> protection. Now



 PE> That is true.



 PM>> your saying that you'd like the compiler to give you warning messages

 PM>> when you do view or modify it. You can't have it both ways.



 PE> I don't mind being warned about something that I'm never going to

 PE> do anyway.  How is that having it both ways?



In one breath you are claiming that it is totally worthless, and in the
next you're saying you'd welcome it. Sounds like a classic case of double
think.



 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.



 PM>> Then why would you welcome warning messages about viewing or modifying

 PM>> FILE structures?



 PE> For the same reason I welcome Borland giving a warning message about

 PE> a program that goes "void main" - to try to raise the level of

 PE> competence of C programmers.



Throughout this whole thread your attitude has been that anyone who doesn't
mesaure up to your programming standards and does something stupid deserves
what they get. Now you're concerned with the competence of programmers.
More double think.



Using my technique will help programmers as they'll get an error messages
if they try to access anything in the structure. Doesn't that achieve what
you want?



 PM>> What about the programmer who comes along after you and has to maintain

 PM>> your code. He may not be fully versed in your techniques and may in fact

 PM>> be working on a system where the programs have a mix of different

 PM>> styles. In some cases he may have to view or modify the contents of

 PM>> structure because that's the way the program was written. If you then

 PM>> say he can't view or modify the contents of others, then it becomes

 PM>> easier to make mistakes.



 PE> That's what a comment in the header file saying "THESE MEMBERS ARE

 PE> ALL PRIVATE" can do quite adequately.



I choose to set my standards higher than just "adequate". A
comment in the header is only adequate assuming that you actually put one
in the header file (which, BTW, you don't), assuming that the programmer
actually sees it and assuming that they pay attention to it.



In an ideal world, all three would be true, but as the world is far from
ideal I'll eliminate the risks where I can.



 PM>> If the structure he isn't supposed to view or modify are private, then

 PM>> it's obvious from the compiler errors that he's done the wrong thing.



 PE> It's obvious from the documented interface too.  Like I say, how

 PE> many times have you seen people look at the internals of the FILE

 PE> data type.



Funny, none of the documentation I've seen says that you shouldn't look at
the internals of the FILE structure. None of your documentation says it
either, so it's hardly obvious. Try it with my code and you'll get an
error. Can't get much more obvious that than.



 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.



 PM>> So your only objection to my technique is that it infringes on the Real

 PM>> C



 PE> My objection is that it makes the code more complex, for no valid

 PE> reason.



Lets see what it takes to use my routines in a program:



    #include 



    int main(void)

        {

        DLLIST list;



        DLListCreate(&list);

        DLListInsertAfter(&list, "AAA");

        DLListDestroy(&list);

        return 0;

        }



If we were to use your technique:



    #include 



    int main(void)

        {

        DLLIST list;



        DLListDefaults(&list);

        DLListInit(&list);

        DLListInsertAfter(&list, "AAA");

        DLListTerm(&list);

        return 0;

        }



Since yours requires an extra function call, it is slightly more complex
that mine to use.



In the actual function there is very little extra code to handle having
everything private - one extra call to malloc and free and one extra
assignment per function. The fact is that the routines are going to be used
more often than they're going to be modified, so any extra benefits in
using the routines out-weights any extra complexity in the implementation.



I consider anything which can detect bugs as a benefit. My code will do
that. Your way relies on the programmer knowing what the right thing to do
is and doing it. Which way is more likely to pick up bugs?



 PM>> Programmer's right to shoot themselves in the foot and write buggy and

 PM>> error prone software.



 PE> No more buggy and error prone than the 20 years of people using

 PE> the FILE data type have found.  ie, totally irrelevant.



Yet you claim that you'd welcome warning messages for accessing FILE
structure "to try to raise the level of competence of C
programmers", so it's hardly totally irrelevant. Since my technique
will give error messages it's even more robust than just giving warnings.



 PM>> If you're not interested in writing robust and error free programs then

 PM>> your company has hired the wrong person.



 PE> Well since I am interested in writing robust and error free

 PE> programs, there's no problem.  BFN.  Paul.



Yet, by your own words:



 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.



you say you're not, unless you're planning to take up Ada programming.





Paul



--- GoldED/2 2.42.G0214+