[Geany-Devel] RFC: Merge C and C++ Filetypes (no troll)

[Matthew Brush]

On 2015-12-29 3:24 AM, Lex Trotman wrote:
> My only comment is to add to the point that the build commands are
> different.  For example C that uses "template" as a variable won't
> compile with C++, a trap for beginners or existing code (just like
> Geany used to have).
>

It's probably best that beginners learn early why using "template" or 
other C++ keywords is a rather bad idea, even in plain C. But yeah, 
there's otherwise a pretty big difference between languages/compilers.

> But I would like to also propose (again) an orthogonal split, C/C++
> headers from C/C++ bodies.  The headers need different compile
> commands from the bodies.  Using the same command as happens now
> generates a pre-compiled header file, and then any changes to the
> header source are not seen when the body is compiled.
>

As mentioned below, individual file-specific compile-commands is not 
very useful, at least with C or C++.

> This can waste significant time, just because the user hit compile
> after fixing a header issue, but before switching back to the body
> file.  Its a really nasty trap waiting for the unaware or beginner,
> and one which we shouldn't be creating.
>

This is more of a bug that (some) build-commands are bound to individual 
files, which is generally never useful. In most IDEs (including Geany), 
when you trigger a rebuild/re-run, it saves all the files and runs the 
project's build system. Geany supports this fine, and I've never 
personally found any of the file-specific build commands useful. IMO, if 
you trigger a filetype-specific build command on a header, building a 
pre-compiled header file is a perfectly reasonable thing to do (why 
would you individually compile a header otherwise, anyway? Only reason I 
can see is "on accident").

> As an alternative to separate filetypes, both of these problems could
> be avoided if build commands could be different for different
> extensions.  then one C/C++ filetype is definitely more viable.
>

Sounds like it would be useful.

Cheers,
Matthew Brush