On 2015-12-29 4:15 AM, Lex Trotman wrote:
On 29 December 2015 at 21:48, Matthew Brush mbrush@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