[Geany-devel] Committed Project Build Commands to build-system branch

[Lex Trotman]

Hi Guys,

I thought the suggestion of having separate header file types would be
controversial ;-), otherwise it would have been done by now.

Let me run through a couple of points about C++ headers and why they need
full support as much as possible.

C++ headers are potentially much more complex than C ones with templates and
inline functions in them.  So not having language support is significant.
The C++ application I am working on (and which first got me using Geany
before I introduced it at work) has only medium complex templates but I
still spend as much time getting the .h file to compile as the .cpp file.
And thats without things such as template metaprogramming, which is code
written to run at compile time in headers.  As an example, the boost C++
libraries contain lots of complex functionality of which 75% is purely in
headers without any supporting body, so lots of work gets done at compile
time not at runtime, so its faster, but it makes the headers much more
complex.  I think the best example is the sprint library that is a complete
parser that does all the stuff bison does at compile time and in the .h
files.

The point of all this is that providing support for the C++ .h files is
important, so correctly detecting them is important.  So is compiling .h
files independently, it is annoying having to pick through errors in the
.cpp file (often caused by errors in the .h file) to find the .h errors and
fix them first, usually it gets so complex that errors get fixed only a few
at a time. It would be much easier to get the .h to compile first.  And on
gcc at least, that can leave a pre-compiled header that would speed up
further uses of that header.

Now despite all that, I agree with Enrico that the default should be that .h
is C, thats the historical use and it fits with Geany development.

The marking -*-C++-*- exists on all GNU headers which means it should be
present on most Linuxii, I don't know about windows though.  Looking at
other (non-system) library headers I've got available, most of the C++ .h
files identify themselves and interestingly about 15% of the C .h files
identify themselves as C. In terms of the delays in opening the file, it is
only intended to look at line 1 which has already been examined for shebang
so it is already available in memory, most of the overhead has already
occurred.  Having separate C++ header templates with the mark already in it
would help users to remember to add it.  BTW it would be good to have these
separate .h .hpp templates irrespective of the end result of these
discussions because creating headers using C or C++ templates and filenames
means you need to delete the main you don't want, add the guards etc.and
then change the file extension on save too.

In terms of using make object, the .h doesn't compile to a .o file so thats
no good, and I have to admit I don't quite see how make could be arranged to
support compilation of .h files for syntax purposes only, without it doing
them every build because there is no output file, I suppose separate targets
that do not run into the main build could work but I'm not sure how that
sits with autotools.

I can understand your concern about flow on effects with other languages,
unfortunately I don't know enough of them to contribute to a discussion of
if the same problem as .h occurs or if there are other differences between
headers and bodies that makes separate filetypes beneficial.

I did a quick survey of how other tools approach this problem (both IDEs and
just editors),
1. Emacs - templates are manual, uses extension or -*- to separate C & C++
2. Anjuta - separate templates for C and C++ headers and body, treats .h as
C++ for highlighting, autocomplete doesn't work for keywords
3. gedit - doesn't have templates, .h as C++, no autocompletion
4. kate - can't tell because documentation on website didn't work, but see
kdevelop
5. kdevelop - separate templates for C and C++ headers and bodies, .h
highlights as C++, don't know about autocompletion (too many 'not written
yet' in the manual and I'm not going to install it just for this)

Not much help really...:-P

In summary my judgement is that C++ users (me, I'm not claiming to be
unbiased) would gain significantly by having proper header file support and
C users much less.  And I don't see that either user community loses
anything.

The commit of the prototype yesterday was the result of me trying to find
out just what is involved, by the time I'd found out, I'd done it (at least
I think so). By doing it as a separate commit without any other changes you
can look at it and it can be bypassed if I stuffed it up too bad.

I have to continue to propose that this is a worthwhile change, please
consider it further.

Best Regards
Lex
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.geany.org/pipermail/devel/attachments/20081111/f82dfbbf/attachment.html>