Yes, the two main uses
that I haven’t seen a good workaround is with header files as Markus mentions
below, and with managed make which needs to link in the C++ runtime, or use a
C++ specific linker if there are C++ files in the
project.
One option would be to
scan the resources in a project and look for C++ content types to do this
behaviour, but my guess is that would be as painful as the Binary Parser is now
J.
From: cdt-dev-bounces@xxxxxxxxxxx
[mailto:cdt-dev-bounces@xxxxxxxxxxx] On
Behalf Of Schorn,
Markus
Sent:
Tuesday, July 11, 2006 8:36 AM
To: CDT General
developers list.
Subject: RE: [cdt-dev] c/cpp projects and
content-types
In CDT various techniques
are used to figure out whether to treat (parse, highlight, ..) a file as c- or
c++ file. Some of them seem
to be workarounds for the problem that content-types use case
insensitive
file patterns. (*.c vs
*.C).
I think we should rely on
the content type as much as possible. I just want to compute it smarter by
preferring case-sensitive matches over insensitive ones.
However, whatever we
do, a conflict will remain for the *.h files as the extension is used for
both c and
c++-code. We can use the
C++project nature to determine the language of *.h-files. In a mixed
setup
I would parse headers as
C++, it's usually the better choice. So mixed projects should use the
C++
nature.
The C++-project nature then
will be a synonym for
"Assume that *.h-files contain c++ code."
and can probaly be better
replaced by a project preference.
Markus.
From: cdt-dev-bounces@xxxxxxxxxxx
[mailto:cdt-dev-bounces@xxxxxxxxxxx] On
Behalf Of Sennikovsky, Mikhail
Sent: Dienstag, 11. Juli 2006
13:29
To: CDT General developers list.
Subject: RE: [cdt-dev] c/cpp projects and
content-types
#1 makes more sense
to me from the current perspective. And this is actually how MBS gnu
tool-chain is currently defined: Managed Make Gnu C++ projects by default
allow having both C and C++ sources currently, while Gnu C projects allow C
only.
Note that generally
it is possible that the C or C++ projects contain some other language, e.g.
FORTRAN. In this sense the project nature should be used for identifying the
primary language only, while the language should be determined based upon the
file name (i.e. file extension) given the content type and/or some other info.
We’re going to stick to this approach in the future to allow multi- and mixed-
language support in CDT.
Talking of C and C++
I think it is reasonable to have one type of project for supporting both C and
C++ in the future.
Are there any
specific requirements for the content type bugs you’re working on that require
the pre-defined list of supported languages?
Mikhail
From: cdt-dev-bounces@xxxxxxxxxxx
[mailto:cdt-dev-bounces@xxxxxxxxxxx] On
Behalf Of Schorn,
Markus
Sent:
Tuesday, July 11, 2006 1:57 PM
To: CDT General
developers list.
Subject: [cdt-dev] c/cpp projects and
content-types
Hi,
I am fixing bugs
related to the content types. I am confused about the meaning of c- vs. c++
projects.
Which one is
correct?
Interpretation
1:
c-project allows for
plain c, only.
c++-project must be
used for c++-code or mixed setups.
Interpretation
2:
c++-project allows
for c++, only.
c-project must be
used for c-code or mixed setups.
Markus.
From: cdt-dev-bounces@xxxxxxxxxxx
[mailto:cdt-dev-bounces@xxxxxxxxxxx] On
Behalf Of Leherbauer, Anton
Sent: Dienstag, 11. Juli 2006
09:37
To: CDT General developers list.
Subject: RE: [cdt-dev] Please accept my
contributions to C/C++ editor
Sergey,
thanks for the
patches.
I'll have a
look.
Toni
From: cdt-dev-bounces@xxxxxxxxxxx
[mailto:cdt-dev-bounces@xxxxxxxxxxx] On
Behalf Of Sergey Prigogin
Sent: Monday, July 10, 2006 8:39
PM
To: CDT General developers list.
Subject: [cdt-dev] Please accept my
contributions to C/C++ editor
Bugzillas 148582 and
140489
contain patches implementing "smart indenting" and "smart caret
positioning" in C/C++ Editor. Could please somebody take a look at these
patches and apply them to the HEAD. Thanks a
loot.
-Sergey
