Skip to main content

[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


Back to the top