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

[Matthew Brush]

On 2015-12-29 4:15 AM, Lex Trotman wrote:
> On 29 December 2015 at 21:48, Matthew Brush <mbrush at codebrainz.ca> wrote:
>> 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.
>
> There is no reason why a C program can't use "template" or "throw" as
> variables, its only a problem if they appear in external headers that
> are used by C++.  Compiling it with C++ is the only reason that it
> would be a problem, and why should that happen, its C!!! C is not C++,
> as Colomban would say :)
>

It's silly to arbitrarily limit the code's portability. I could 
understand not wanting to litter the code with superfluous casts and 
such, but avoiding using a (mostly) compatible language's keywords for 
no reason, breaking compatibility, serves no purpose, unless you can 
guarantee that nobody, ever, in the whole world, for ever-more, will 
need to use a C++ compiler or some broken C compiler that uses a 
combination of both languages (ex. MSVC). This is not usually applicable 
to noobies.

>>
>>> 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++.
>
> No, they are not much use to you and I, but they are for beginners,
> and beginners are the very people who can't be expected to configure
> stuff on day one.  Or write makefiles. So the default commands should
> exist, and be safe.
>

They aren't very useful to beginners either, beyond maybe a "Hello 
World" program on page 1 of some tutorial that prints "hello world".

>>
>>> 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.
>
> Actually it doesn't include Geany, Geany only saves the current file,
> not any other changed files.  Thats something else that was suggested
> previously, and rejected.
>

IME, most IDEs save all of the "project files" (which I guess doesn't 
apply to Geany), and the runs the incremental project build system, and 
then (if chosen so), runs the project target. I can't imagine many cases 
where anything else (with C/C++) would be very useful. You can't do 
anything useful with a .o or .pch file from within Geany.

>> 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").
>
> Indeed, thats what I said above, its easy to do by accident.  And when
> its done by accident the PCH is not expected, so its tends to take
> some time to find the problem.
>

But in the end, the problem is that there is a useless file-specific 
command that does something surprising, which a project-wide "build" 
command wouldn't.

Cheers,
Matthew Brush