Hi,
I have been using Geany without the C filetype and opening all C files as C++. I use about 50% each of C and C++, and since I merged the two filetypes quite a few of headaches went away.
Some of the benefits:
- C or C++ tags always work - Special highlighting of C++ keywords so I know to avoid in C - All C and C++ constructs always work - No ambiguity of *.h files (except w/ Obj-C)
Some of the drawbacks:
- Using C++ build commands for C doesn't make much sense (although some claim compiling plain C as C++ to be a virtue) - The default C++ extension wouldn't be suitable for plain C
Some non-issues (AFAICT): - Both filetypes already use the same Scintilla C++ lexer - For Geany's purposes the CTags C++ parser works for both C and C++
It might be useful to only have one filetype for both. I'm content editing my config files locally, but I just thought it worth discussing to see if I'm mistaken on the perceived benefits/drawbacks.
Cheers, Matthew Brush
I'm not sure about the combination, would have to examine it further. 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).
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.
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.
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.
Sadly a proposal that the Geany build system accommodate different commands for different extensions, made during the last major build system upgrade, was rejected as "too complicated". And I'm not interested in going back and adding it now, but would be happy to advise anyone who wanted to do it.
I suggest that all of these issues should be examined together.
Cheers Lex
On 29 December 2015 at 20:11, Matthew Brush mbrush@codebrainz.ca wrote:
Hi,
I have been using Geany without the C filetype and opening all C files as C++. I use about 50% each of C and C++, and since I merged the two filetypes quite a few of headaches went away.
Some of the benefits:
- C or C++ tags always work
- Special highlighting of C++ keywords so I know to avoid in C
- All C and C++ constructs always work
- No ambiguity of *.h files (except w/ Obj-C)
Some of the drawbacks:
- Using C++ build commands for C doesn't make much sense (although some claim compiling plain C as C++ to be a virtue)
- The default C++ extension wouldn't be suitable for plain C
Some non-issues (AFAICT):
- Both filetypes already use the same Scintilla C++ lexer
- For Geany's purposes the CTags C++ parser works for both C and C++
It might be useful to only have one filetype for both. I'm content editing my config files locally, but I just thought it worth discussing to see if I'm mistaken on the perceived benefits/drawbacks.
Cheers, Matthew Brush _______________________________________________ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
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
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 :)
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.
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.
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.
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 _______________________________________________ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
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
Le 29/12/2015 11:11, Matthew Brush a écrit :
Hi,
I have been using Geany without the C filetype and opening all C files as C++. I use about 50% each of C and C++, and since I merged the two filetypes quite a few of headaches went away.
Some of the benefits:
- C or C++ tags always work
This is a bug in current code that I think Jiří fixed in his scope PR. But yeah, that's a fairly good point.
- Special highlighting of C++ keywords so I know to avoid in C
- All C and C++ constructs always work
I can understand this being useful in headers, really less in source files, and as some I find this being some arbitrary C++ leaking into C
- No ambiguity of *.h files (except w/ Obj-C)
If only C++ people used some *meaningful* extensions, like .hpp or .hh… Anyway, yeah, maybe for headers it could have a reasonable benefit to warrant some weirdy things. I sure got my share of C++ headers opened as C annoying me -- to the point I got a slight look at allowing extension patterns to include some path portion so I could force C++ for some known locations.
BTW, IIRC currently creating a custom "C Header" filetype has some drawbacks, because it's not recognized as C by CTags, because we used the filetype's ID instead of the parser's ID to determine some logic or something; but again it's something that should be fixed, and again IIRC Jiří's scope PR takes care of this too.
Some of the drawbacks:
- Using C++ build commands for C doesn't make much sense (although some claim compiling plain C as C++ to be a virtue)
(but they are wrong and simply try to shove some C++ down honest C programmer's throats, so let's ignore them :))
- The default C++ extension wouldn't be suitable for plain C
Indeed that would be a problem. Here again having a "C Header" filetype highlighting C++ stuff would solve it (once the other bugs are fixed).
Some non-issues (AFAICT):
- Both filetypes already use the same Scintilla C++ lexer
- For Geany's purposes the CTags C++ parser works for both C and C++
I would indeed believe that CTags should mostly be fine parsing C as C++, but when the C code is using C++ keywords as identifiers (i.e. function `void template(void) {}` does't parse as C++). Again, this *might* be fine for headers, but maybe less for sources.
Sure, using C++ keywords as identifiers for C generally doesn't give much, but failing on them is not really a great idea either: some people do use them (heck, we used to), and disallowing them is a bit of an arbitrary decision from us.
It might be useful to only have one filetype for both. I'm content editing my config files locally, but I just thought it worth discussing to see if I'm mistaken on the perceived benefits/drawbacks.
It's indeed at least interesting to consider, because at least for .h headers there really is some mixed stuff all over the place -- even, simply look in Scintilla's source tree.
However, it being for build commands [1], or default extension, etc., I'm not sure having one single "C and C++ headers and sources" is a great idea. But maybe fixing all the bits and having 4 (!) filetypes (C, C header, C++ and C++ header), and handling C headers as if they were C++ could be a good idea to try out. It would please Lex as he could get the header build commands empty, we could keep default extension and build commands, C++ headers with .h extensions would work as expected, and I wouldn't expect much breakage because of using a C++ parser for C headers.
Regards, Colomban
Oops, forgot the [1]
However, it being for build commands [1], or default extension, etc., I'm not sure having one single "C and C++ headers and sources" is a great idea.
[1] I mostly agree stock build commands are seldom (if ever) useful with C and C++, but for the most basic "Hello World". .o generation is even less useful. However, I do have a custom script (that fetches some deps by inspecting includes) there I use to build very simple or test stuff, and it's very handy in such cases. But in all cases, we could imagine having many sorts of commands, maybe a linter or anything; anyway not necessarily the same handling both C and C++.
On Sat, Jan 2, 2016 at 7:39 PM, Colomban Wendling < lists.ban@herbesfolles.org> wrote:
Le 29/12/2015 11:11, Matthew Brush a écrit :
Hi,
I have been using Geany without the C filetype and opening all C files as C++. I use about 50% each of C and C++, and since I merged the two filetypes quite a few of headaches went away.
Some of the benefits:
- C or C++ tags always work
This is a bug in current code that I think Jiří fixed in his scope PR. But yeah, that's a fairly good point.
- Special highlighting of C++ keywords so I know to avoid in C
- All C and C++ constructs always work
I can understand this being useful in headers, really less in source files, and as some I find this being some arbitrary C++ leaking into C
- No ambiguity of *.h files (except w/ Obj-C)
If only C++ people used some *meaningful* extensions, like .hpp or .hh… Anyway, yeah, maybe for headers it could have a reasonable benefit to warrant some weirdy things. I sure got my share of C++ headers opened as C annoying me -- to the point I got a slight look at allowing extension patterns to include some path portion so I could force C++ for some known locations.
BTW, IIRC currently creating a custom "C Header" filetype has some drawbacks, because it's not recognized as C by CTags, because we used the filetype's ID instead of the parser's ID to determine some logic or something; but again it's something that should be fixed, and again IIRC Jiří's scope PR takes care of this too.
Some of the drawbacks:
- Using C++ build commands for C doesn't make much sense (although some claim compiling plain C as C++ to be a virtue)
(but they are wrong and simply try to shove some C++ down honest C programmer's throats, so let's ignore them :))
- The default C++ extension wouldn't be suitable for plain C
Indeed that would be a problem. Here again having a "C Header" filetype highlighting C++ stuff would solve it (once the other bugs are fixed).
Some non-issues (AFAICT):
- Both filetypes already use the same Scintilla C++ lexer
- For Geany's purposes the CTags C++ parser works for both C and C++
I would indeed believe that CTags should mostly be fine parsing C as C++, but when the C code is using C++ keywords as identifiers (i.e. function `void template(void) {}` does't parse as C++). Again, this *might* be fine for headers, but maybe less for sources.
Sure, using C++ keywords as identifiers for C generally doesn't give much, but failing on them is not really a great idea either: some people do use them (heck, we used to), and disallowing them is a bit of an arbitrary decision from us.
It might be useful to only have one filetype for both. I'm content editing my config files locally, but I just thought it worth discussing to see if I'm mistaken on the perceived benefits/drawbacks.
It's indeed at least interesting to consider, because at least for .h headers there really is some mixed stuff all over the place -- even, simply look in Scintilla's source tree.
+1 for having the headers parsed/lexed by the C++ parser (with sources it may be a bit dangerous and typically the sources have the right C++ extension).
Jiri
Am 06.01.2016 um 21:12 schrieb Jiří Techet:
It's indeed at least interesting to consider, because at least for .h headers there really is some mixed stuff all over the place -- even, simply look in Scintilla's source tree.+1 for having the headers parsed/lexed by the C++ parser (with sources it may be a bit dangerous and typically the sources have the right C++ extension).
Not replying to Jiří specifically.
-1. .h is legitimately a C, it's just that many people get it wrong. And I don't want C++ keywords highlighted in C headers while they are not highlighted it C source files. This is just confusing.
Best regards
On 2016-01-06 12:23 PM, Thomas Martitz wrote:
Am 06.01.2016 um 21:12 schrieb Jiří Techet:
It's indeed at least interesting to consider, because at least for .h headers there really is some mixed stuff all over the place -- even, simply look in Scintilla's source tree.+1 for having the headers parsed/lexed by the C++ parser (with sources it may be a bit dangerous and typically the sources have the right C++ extension).
Not replying to Jiří specifically.
-1. .h is legitimately a C, it's just that many people get it wrong. And I don't want C++ keywords highlighted in C headers while they are not highlighted it C source files. This is just confusing.
Why is .h any more C than C++ or Obj-C? Because it came first? I agree it's stupid that in the later part of last millennium, they decided on the convention to use .h for C++ and Obj-C (and others?) headers since it was already a convention in C, but it did become a convention in C++ and now it's widely used, for example [0][1][2][3] among many, many others.
What's more, it's especially useful to see C++ keywords highlighted in .h header files, since they can be included in C++ as well as C[4][5][6] unless their author wants to make them less useful by using said keywords in the header. I think the most common case would be someone doing it inadvertently (as happened in Geany), which is where having them highlighted differently gives a visual queue that something is wrong[7].
Cheers, Matthew Brush
[0]: https://git.gnome.org/browse/gtkmm/tree/gtk/gtkmm [1]: https://github.com/qtproject/qtbase/tree/dev/src/corelib/global [2]: https://gcc.gnu.org/onlinedocs/libstdc++/latest-doxygen/files.html [3]: http://sourceforge.net/p/scintilla/code/ci/default/tree/src/ [4]: https://git.gnome.org/browse/gtk+/tree/gtk/gtkwidget.h#n38 [5]: https://github.com/spurious/SDL-mirror/blob/master/include/SDL.h#L61 [6]: http://sourceware.org/git/?p=glibc.git;a=blob;f=include/stdlib.h;h=352339e85... [7]: Or if the author is being evil on purpose, it gives them the smug satisfaction that they're making life hard for C++ programmers :)
On Wed, Jan 6, 2016 at 9:23 PM, Thomas Martitz kugel@rockbox.org wrote:
Am 06.01.2016 um 21:12 schrieb Jiří Techet:
It's indeed at least interesting to consider, because at least for .h headers there really is some mixed stuff all over the place -- even, simply look in Scintilla's source tree.+1 for having the headers parsed/lexed by the C++ parser (with sources it may be a bit dangerous and typically the sources have the right C++ extension).
Not replying to Jiří specifically.
-1. .h is legitimately a C, it's just that many people get it wrong. And I don't want C++ keywords highlighted in C headers while they are not highlighted it C source files. This is just confusing.
I agree with Matthew here - I think the "damage" caused by parsing C headers with the C++ parser/lexer is much smaller than vice versa. Actually a few months back a user of my ProjectOrganizer plugin wrote me just because of that - he had a C++ project with "h" headers and was surprised that tag generation didn't work for him.
I created (a highly sophisticated) pull request here:
https://github.com/geany/geany/pull/857
Power users can always add *.h back to C types but I think having it in C++ is a better default.
Cheers,
Jiri
On 8 January 2016 at 08:00, Jiří Techet techet@gmail.com wrote:
On Wed, Jan 6, 2016 at 9:23 PM, Thomas Martitz kugel@rockbox.org wrote:
Am 06.01.2016 um 21:12 schrieb Jiří Techet:
It's indeed at least interesting to consider, because at least for .h headers there really is some mixed stuff all over the place -- even, simply look in Scintilla's source tree.+1 for having the headers parsed/lexed by the C++ parser (with sources it may be a bit dangerous and typically the sources have the right C++ extension).
Not replying to Jiří specifically.
-1. .h is legitimately a C, it's just that many people get it wrong. And I don't want C++ keywords highlighted in C headers while they are not highlighted it C source files. This is just confusing.
I agree with Matthew here - I think the "damage" caused by parsing C headers with the C++ parser/lexer is much smaller than vice versa. Actually a few months back a user of my ProjectOrganizer plugin wrote me just because of that - he had a C++ project with "h" headers and was surprised that tag generation didn't work for him.
I created (a highly sophisticated) pull request here:
https://github.com/geany/geany/pull/857
Power users can always add *.h back to C types but I think having it in C++ is a better default.
As the failing tests show, better have a BIG warning about breaking change if we do this.
Cheers,
Jiri
Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
On Thu, Jan 7, 2016 at 11:14 PM, Lex Trotman elextr@gmail.com wrote:
On 8 January 2016 at 08:00, Jiří Techet techet@gmail.com wrote:
On Wed, Jan 6, 2016 at 9:23 PM, Thomas Martitz kugel@rockbox.org
wrote:
Am 06.01.2016 um 21:12 schrieb Jiří Techet:
It's indeed at least interesting to consider, because at least for.h
headers there really is some mixed stuff all over the place --even,
simply look in Scintilla's source tree.+1 for having the headers parsed/lexed by the C++ parser (with sources
it
may be a bit dangerous and typically the sources have the right C++ extension).
Not replying to Jiří specifically.
-1. .h is legitimately a C, it's just that many people get it wrong.
And I
don't want C++ keywords highlighted in C headers while they are not highlighted it C source files. This is just confusing.
I agree with Matthew here - I think the "damage" caused by parsing C
headers
with the C++ parser/lexer is much smaller than vice versa. Actually a few months back a user of my ProjectOrganizer plugin wrote me just because of that - he had a C++ project with "h" headers and was surprised that tag generation didn't work for him.
I created (a highly sophisticated) pull request here:
https://github.com/geany/geany/pull/857
Power users can always add *.h back to C types but I think having it in
C++
is a better default.
As the failing tests show, better have a BIG warning about breaking change if we do this.
Fixed now.
Actually the tests "failed" because the tested files were C++ headers and the previously-generated tags files were incorrect because of the used C parser. So yeah, BEWARE USERS, HEADERS MIGHT BE PARSED CORRECTLY :-)
Jiri
Am 07.01.2016 um 23:00 schrieb Jiří Techet:
On Wed, Jan 6, 2016 at 9:23 PM, Thomas Martitz <kugel@rockbox.org mailto:kugel@rockbox.org> wrote:
Am 06.01.2016 um 21:12 schrieb Jiří Techet: It's indeed at least interesting to consider, because at least for .h headers there really is some mixed stuff all over the place -- even, simply look in Scintilla's source tree. +1 for having the headers parsed/lexed by the C++ parser (with sources it may be a bit dangerous and typically the sources have the right C++ extension). Not replying to Jiří specifically. -1. .h is legitimately a C, it's just that many people get it wrong. And I don't want C++ keywords highlighted in C headers while they are not highlighted it C source files. This is just confusing.I agree with Matthew here - I think the "damage" caused by parsing C headers with the C++ parser/lexer is much smaller than vice versa. Actually a few months back a user of my ProjectOrganizer plugin wrote me just because of that - he had a C++ project with "h" headers and was surprised that tag generation didn't work for him.
I created (a highly sophisticated) pull request here:
https://github.com/geany/geany/pull/857
Power users can always add *.h back to C types but I think having it in C++ is a better default.
Yes you're only changing the default. I just stated my opionion and won't try to block the change. Go a head if you prefer.
Power users can always add *.h back to C types but I think having it in C++ is a better default.
Yes you're only changing the default. I just stated my opionion and won't try to block the change. Go a head if you prefer.
Agree, I shouldn't be defending C programmers over C++ programmers, although I support elimination of C++ coders who use .h for their headers :)
Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel