[prev in list] [next in list] [prev in thread] [next in thread] 

List:       cfe-dev
Subject:    Re: [cfe-dev] C vs. C++: Inconsistent type classifications
From:       "Doug Gregor" <doug.gregor () gmail ! com>
Date:       2008-11-21 3:29:19
Message-ID: 24b520d20811201929y5d9ede1cp52661e71c56bf95e () mail ! gmail ! com
[Download RAW message or body]

On Thu, Nov 20, 2008 at 7:32 PM, argiris kirtzidis <akyrtzi@gmail.com> wrote:
> Doug Gregor wrote:
>>
>> There are several places where C and C++ have different definitions
>> for the same type classification terms. For example, "integer types"
>> in C include enumeration types, but "integer types" in C++ doesn't
>> include enumeration types. On the other hand, "object types" in C
>> doesn't include incomplete types, while "object types" in C++ does
>> include incomplete types.
>>
>> This presents a dilemma for the Type class, which has methods like
>> isIntegerType and isObjectType. It isn't clear whether these routines
>> should follow the C semantics, the C++ semantics, the current language
>> semantics, or whether we should decide on a case-by-case basis.
> How about having two methods when there are differences, e.g. isCIntegerType
> and isCXXIntegerType.
> Having checks with C++ semantics called by C-parts will probably lead to
> confusion and subtle bugs.

That seems a bit like the third option, and I think it has the same
drawbacks: what do you use in the common subset of C and C++, the "C"
version or the "CXX" version? Probably whatever is appropriate, but
that means going back to the documentation each time to see "C" vs.
"CXX" in the name to determine the various subtleties. I think it's
better to have one set of semantics, and where we need to deviate from
those we'll have more explicit code.

  - Doug
_______________________________________________
cfe-dev mailing list
cfe-dev@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
[prev in list] [next in list] [prev in thread] [next in thread]