Michael.Z wrote, On 07/05/08 09:05:
> On May 6, 1:21 am, Nick Keighley <nick_keighley_nos...@[EMAIL PROTECTED]
>
> wrote:
<snip>
> Regarding to your post:
>> so he had two different types didn't he?
>
> He did have two different types. Its "void *" in header file while
> "struct List *" in List.c;
> eg.
> /*List.h*/
> typedef void *List;
>
> /*List.c*/
> typedef struct List{....} *List;
In that case what he provided was wrong. No ifs, not buts, it is just
plain wrong. Wrong as in the definition of the language says that it is
wrong.
> However there was no conflicting type error,
The error is still there, it is just hidden from the compiler so that it
does not tell you about it. It is no more correct than driver the wrong
way up a one way street at 100mph is legal if you do not get caught. Not
being caught does not make it legal.
> the reason is he did not
> include file "List.h" in his "List.c".
That, whilst not forbidden by the language, is generally considered to
be bad practice. The reason it is considered to be bad practice is
specifically *because* it hides errors like this.
> So I removed #include "Table.h" from my "Table.c", it complied well.
Compiling does not make it correct. If you have a good relation****p with
your tutor/lecturer/teacher you should explain to your lecturer that his
code is wrong. If your relation****p is not good enough to get away with
that you should ask him why it fails to compile if the header file is
not included (but avoid arguing the point if it will affect your
grades). In either case, you should take any code presented with at
least a pinch of salt, and if he does not understand the problem you
should take the entire course with a whole keg of salt as what you are
being taught is wrong.
--
Flash Gordon
|
