Talk:Compatibility of C and C++

Latest comment: 8 years ago by Cyberbot II in topic External links modified

Legal / valid / conforming edit

The term "legal" isn't much used in the C++ standard. However, there are a few notable uses in the C compatibility section. See for instance C.1.5 Clause 7: declarations

"Valid" / "invalid" is widely used in the context "valid C, invalid in C++". The term "conforming program" is only used in C. The corresponding C++ term is "well-formed program". Because of this, I'm changing back to valid/invalid. decltype (talk) 14:44, 9 March 2009 (UTC)Reply

To clarify: "Valid" / "invalid" is widely used in the context "valid C, invalid in C++" in the C++ Standard (not just colloquially). For instance:

E.g., at file scope,

int i;
int i;

is valid in C, invalid in C++

— C.1.2 Clause 3: basic concepts

static struct S { // valid C, invalid in C++

int i;
// ...

};

— C.1.5 Clause 7: declarations

Therefore I fail to see why such use would be technically incorrect in the article. decltype (talk) 18:09, 9 March 2009 (UTC)Reply

There are around 15 instances of "valid" ([1]) in the C99 standard. The problem I have with using these terms is that developers often use valid/invalid when discussing the behavior of the compiler they use, which probably accepts extensions that are not conforming/well-formed C/C++. By using the terms conforming/well-formed we are calling out the fact that we are referring to what the standard document says, not the behavior of a particular compiler (yes, of course many developers do believe that everything their compiler does is mandated by the standard, but we at least should get it right). Derek farn (talk) 00:44, 10 March 2009 (UTC)Reply

struct, union, or enum declaration in C++ are not first class types edit

I think that the statement that is found in the section about valid C constructs is misleading, if not wrong. The situation in C++ is just more subtle than it is stated: a struct declaration implies an implicit typedef, if there is no other symbol in identifier scope that inhibits it.

In consequence the code in the next section that is meant to demonstrate this behavior is misleading, too. Indeed, the result for C and C++ is different, as is it done here C refers to the global variable and C++ to the type. But if I put the extern declaration into the function, both refer to the integer variable T in the sizeof operator, since then there is already an identifier T in the scope and the implicit typedef will not trigger. Gustedt (talk) 17:09, 10 September 2010 (UTC)Reply

No implicit conversion from double-pointer to const-double-pointer edit

With Visual Studio 2008/2010, I realized that you can implicitly convert from int** to const int** when compiling as C (/TC), but not as C++ (/TP). The same is true for volatile. In particular, this code works with the former but not the latter:

  int** a;
  const int** b = a;

You can see further discussion at the C++ FAQ Lite. Should this be added? – kentyman (talk) 16:38, 1 December 2010 (UTC)Reply

Adding. – kentyman (talk) 16:41, 1 December 2010 (UTC)Reply

C allows struct, union, and enum types to be declared in function prototypes, whereas C++ does not. edit

That it is not true. There is no problem in C++ in declaring or returning a struct,union and enum in a function. — Preceding unsigned comment added by 89.67.175.56 (talk) 23:17, 11 November 2012 (UTC)Reply

C++ cast operators edit

Wouldn't it be a good idea to use C++ cast operators instead of C-style casts in the C++ examples? --Antred (talk) 15:47, 24 September 2013 (UTC)Reply

External links modified edit

Hello fellow Wikipedians,

I have just modified one external link on Compatibility of C and C++. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:

When you have finished reviewing my changes, please set the checked parameter below to true or failed to let others know (documentation at {{Sourcecheck}}).

This message was posted before February 2018. After February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than regular verification using the archive tool instructions below. Editors have permission to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the RfC before doing mass systematic removals. This message is updated dynamically through the template {{source check}} (last update: 18 January 2022).

  • If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
  • If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—cyberbot IITalk to my owner:Online 18:06, 31 March 2016 (UTC)Reply