[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
RE: [cdt-dev] c/cpp projects and content-types
|
This is a problem beyond language choice. In cygwin, and presumably other
gnu envs, stddef.h gets included multiple times with different macros
settings. Boooo.
If you include a header file multiple times with the semantics different
each time, then you shouldn't be using the Fast indexer. Actually you
shouldn't be allowed to write code, but I digress ;).
In most cases where I see the __cplusplus macro used it's to wrap around
extern "C" to allow a declaration to be used and linked correctly from
either language. And, yes, all other cases are trouble for the Fast indexer.
Doug Schaefer, QNX Software Systems
Eclipse CDT Project Lead, Tools PMC member
http://cdtdoug.blogspot.com
-----Original Message-----
From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On
Behalf Of Chris Recoskie
Sent: Tuesday, July 11, 2006 10:03 AM
To: CDT General developers list.
Subject: RE: [cdt-dev] c/cpp projects and content-types
> 1. Include file is processed as the ?#include? statement is
> encountered in the source file (the PDOM calculation case?). In this
> case we should use the language of the current source file that
> includes the given include being processed, and thus we do not have
> the problem of .h language detection in this case.
The PDOM can still have problems with this though. It only parses a given
file once. What if I have the following header?
foo.h
====
#ifdef __cplusplus
// do something C++ specific
#else
/* do something C specific */
#endif
Depending on the language of the first source file that the parser
encounters that uses this file, one code path or the other gets parsed, and
from there on gets used. If the same header gets included from more than
one file, and those files are each C and C++ respectively, then you will
get problems. This scenario does happen... people use it when calling C
code from C++ to take care of the extern C stuff.
The language issue is murky in general as well. My C or C++ might not be
your C or C++. Maybe I'm using ANSI C++ in my project but you're using
Embedded C++, and both our projects are in the workspace and we both
include the same header. Again, the file should be parsed differently.
===========================
Chris Recoskie
Team Lead, IBM CDT Team
IBM Toronto
http://www.eclipse.org/cdt
"Sennikovsky,
Mikhail"
<mikhail.sennikov To
sky@xxxxxxxxx> "CDT General developers list."
Sent by: <cdt-dev@xxxxxxxxxxx>
cdt-dev-bounces@e cc
clipse.org
Subject
RE: [cdt-dev] c/cpp projects and
11/07/2006 09:47 content-types
AM
Please respond to
"CDT General
developers list."
<cdt-dev@eclipse.
org>
Here are some thoughts regarding the mixed language problem:
MBS linker problem: we should have the newly created project consistent and
buildable out of the box. So the approach of manual linker change in order
to make a pure C project after project creation maight not work. I also
agree that dynamic linker detection based upon the project contents may be
painful, so we might still have a C, C++, FORTRAN, etc. nature associated
with the project to define the primary language to be used and to select a
linker based upon the primary language. The primary language could be as
well used in UI, e.g. to define the default perspective, etc.
The .h language problem: as I understand there are two different ways of
how includes can be processed:
1. Include file is processed as the ?#include? statement is
encountered in the source file (the PDOM calculation case?). In this
case we should use the language of the current source file that includes
the given include being processed, and thus we do not have the problem
of .h language detection in this case.
2. Include file is processed independently (the CModel
calculation). In this case we do have the problem of detecting the .h
file language, but since the CModel source information (ITranslationUnit
children) contains only the main outline info, I think it might be
calculated in the same way both for both C and C++ .h files. Also in
case we make the CModel use the PDOM this problem might disappear as
well.
Although since we might still need the primary language info, we could use
it for the .h language calculation as well, I just think that having one
and the same. h file be processed depending on the language of the source
file that includes it may provide a better flexibility and consistency of
the created PDOM info.
Content type case insensitivity issue: It might make sense to talk to
platform guys one more time regarding this. There is a bug regarding this
already: https://bugs.eclipse.org/bugs/show_bug.cgi?id=105022, probably it
could be fixed for the next major platform release.
Mikhail
From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On
Behalf Of Daoust, Dave
Sent: Tuesday, July 11, 2006 5:00 PM
To: CDT General developers list.
Subject: RE: [cdt-dev] c/cpp projects and content-types
I would like to see the project type be "cdt" and that the two cases below
be resolved as:
1. Have a preference for how to open .h files (by default this should be
C++)
2. Have a Linker page on the managed build that can describe the linker
(g++, gcc, ld, whatever)
It would also be good to have a languages tab that is used to enable
the visiblity of the settings for C++/C/Fortran/8 Ball/whatever else is
contributed
Then we could use the new project wizards to set the default for each
project (eg. New C++... would set .h files to C++, linker to g++, and
enable C and C++)
If anybody wanted to mix-n-match more than this, they could do it from the
properties directly.
- Dave
From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On
Behalf Of Doug Schaefer
Sent: Tuesday, July 11, 2006 8:53 AM
To: CDT General developers list.
Subject: RE: [cdt-dev] c/cpp projects and content-types
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.
Doug Schaefer, QNX Software Systems
Eclipse CDT Project Lead, Tools PMC member
http://cdtdoug.blogspot.com
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_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev