[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
RE: [cdt-dev] c/cpp projects and content-types
|
Hi Chris,
the rename refactoring does a text-search through all c- and c++-files
and creates potential matches for inactive code (#ifdef .. #endif).
Markus.
> -----Original Message-----
> From: cdt-dev-bounces@xxxxxxxxxxx
> [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Chris Recoskie
> Sent: Dienstag, 11. Juli 2006 16:51
> To: CDT General developers list.
> Subject: RE: [cdt-dev] c/cpp projects and content-types
>
> But if the locations in the file are different for the
> declaration, won't
> you get Bad Things (TM) happening if you go and do something
> like rename
> refactor a function? Then it would only rename the one that
> actually got
> parsed, because it's the only one it knows about, right? Or
> are we still
> doing a full text search/replace as well?
>
> ===========================
>
> Chris Recoskie
> Team Lead, IBM CDT Team
> IBM Toronto
> http://www.eclipse.org/cdt
>
>
>
>
>
> Doug Schaefer
>
> <DSchaefer@xxxxxx
>
> m>
> To
> Sent by: "CDT General
> developers list."
> cdt-dev-bounces@e <cdt-dev@xxxxxxxxxxx>
>
> clipse.org
> cc
>
>
>
> Subject
> 11/07/2006 10:16 RE: [cdt-dev] c/cpp
> projects and
> AM content-types
>
>
>
>
>
> Please respond to
>
> "CDT General
>
> developers list."
>
> <cdt-dev@eclipse.
>
> org>
>
>
>
>
>
>
>
>
>
> 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
> _______________________________________________
> 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
>
