On 2015-12-29 4:15 AM, Lex Trotman wrote:
On 29 December 2015 at 21:48, Matthew Brush <mbr...@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
_______________________________________________
Devel mailing list
Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel
