> There you are definitely wrong. Of course headers are specifications,
> they specify the parameter types etc.
Headers contain specifications, I agree to that. However:
1) headers could contain anything, at least in C/C++.
2) said specifications can be part of a single file of code; there is
no need to split it in too.
> Now the question is whether to
> go beyond that (after all that's all the Ada syntax really does itself)
> and regard them as the proper repository of all the information
> that is part of the specification. That *is* a matter of taste
> and viewpoint.
I am not saying that separating specifications from implementations is
wrong. There is a use case for that.
What I am saying is that the artificial separation of code into header
and implementation files hurts productivity. **A lot**.
The same result (coding against specifications) can be achieved
without the separation of headers and implementation files OR without
the duplication of work.
>
> You are free to disagree with that as a desirable approach, but it
> is indeed a matter, not of religeon or morality (truly weird references
> in this discussion) but of desirable viewpoint. And you saying
> categorically that "they aren't" does not help the discussion.
Ok.
>
> The proper viewpoint to take here to support the idea of automatic
> generation is to recognize that there is a legitimate difference of
> opinion, but that there are lots of people whose opinion (not
> statement of fact) matches yours, that headers should not be
> regarded as specifications, and therefore it is useful to
> generate them automatically. I think if you take the attitude
> that everyone has to agree with your viewpoint, you will have
> even less success than you already have in pushing this idea.
Let's stay clear of politics. Please. I am not interested. I have a
job to do and many headers to create :-).
>
> There are two issues here really
>
> 1. How do we deal with the language distortion that your proposal
> causes. this seems a significant problem to me, and I have not
> really seen you address it.
I have already explained it, but I don't mind explaining it once more:
1) the pragma #autoinclude ("foo.hpp", "foo.cpp") instructs the
compiler to generate the header 'foo.hpp' from the implementation file
'foo.cpp'.
2) the compiler opens the file 'foo.cpp'.
3) for every class found in the file 'foo.cpp', a relevant class is
placed into the header.
4) for every member function that is not a candidate for inlining, the
compiler puts a function declaration in the header.
5) for every member function that is a good candidate for inlining,
the compiler puts the definition the header.
6) for every non-static variable in the implementation file, it puts
an 'extern' declaration in the header.
7) for every non-static standalone function in the implementation
file, it puts the relevant function declaration in the header.
8) for every namespace in the implementation file, the relevant
namespace is put in the header file.
9) when the compiler compiles foo.cpp, it checks if there is a
relevant autogenerated header in the same place. If there is not one,
then it proceeds to compile the implementation file as usual. If there
is an autogenerated header:
10) if a class in the implementation file is part of the header, then:
11) if a member function has only a declaration in the header, then
the function body is retrieved from the implementation file and the
function is compiled as if it was defined outside of the class.
12) otherwise, the header definition is used.
> This is completely wrong, it is quite normal to have specifications
> in Ada with multiple bodies, e.g. for different targets, then you
> select the body you want to use. This is one of the advantages of
> this approach. For example, this approach is used extensively in
> the GNAT Ada run time.
Does this happen at run-time? I don't think so.
>
>> How do headers thought of specifications are helpful in achieving high
>> quality? please give us a concrete example of a case that not having
>> the headers provides less quality.
>
> You can definitely answer this question yourself, I don't think you
> can expect anyone to give you a long tutorial on why this separation
> is desirable. A lot has been written on this subject, and there are
> lots of programs to use as examples.
Links?
I am asking this because in most of the links I have found, people
wish that headers did not exist.
The only legitimate case is that of multiple compilation targets, and
it is not something that cannot be handled with conditional
compilation and a nice module system.
And I am not exactly proposing banning headers already :-).
