Where Is C Not a Subset of C++

Where is C not a subset of C++?

If you compare C89 with C++ then here are a couple of things

No tentative definitions in C++

int n;
int n; // ill-formed: n already defined

int[] and int[N] not compatible (no compatible types in C++)

int a[1];
int (*ap)[] = &a; // ill-formed: a does not have type int[]

No K&R function definition style

int b(a) int a; { } // ill-formed: grammar error

Nested struct has class-scope in C++

struct A { struct B { int a; } b; int c; };
struct B b; // ill-formed: b has incomplete type (*not* A::B)

No default int

auto a; // ill-formed: type-specifier missing

C99 adds a whole lot of other cases

No special handling of declaration specifiers in array dimensions of parameters

// ill-formed: invalid syntax
void f(int p[static 100]) { }

No variable length arrays

// ill-formed: n is not a constant expression
int n = 1;
int an[n];

No flexible array member

// ill-formed: fam has incomplete type
struct A { int a; int fam[]; };

No restrict qualifier for helping aliasing analysis

// ill-formed: two names for one parameter?
void copy(int *restrict src, int *restrict dst);

Does C++ contain the entire C language?

No, C++ is not a superset of the C language. While C++ contains a large part of C, there are subtle difference that can bite you badly where you least expect them. Here are some examples:

C has the concept of tentative definitions which doesn't exist in C++.
C does not require explicit conversion on assignment of void pointers to variables of concrete type.
C has different rules regarding const propagation.
C has something called the “implicit int rule,” which, although abolished with C99, appears some times and needs to be considered.
The C preprocessor has some features the C++ preprocessor does not have.
The C language has two styles of function definition, K&R-style and Stroustrup-style. C++ only has Stroustrup-style.
The lexing rules for C and C++ are different with neither being a subset of the other
C and C++ have different sets of reserved words. This can cause weird errors because an identifier is not allowed in the other language.
While C++ took almost all features from ANSI C (C89), many features were added to C in subsequent standard revisions that are not available in C++.
C++ has a different syntax, even for some parts that aren't new. For example, a ? b : c = d is a syntax error in C but parsed as a ? b : (c = d) in C++.
C guarantees that &*E is exactly identical to E, even if E is a null pointer. C++ has no such guarantee.
In C, a string literal initializing an array of characters can initialize an array that is at least as long as the string without the trailing \0 byte. (i.e. char foo[3] = "bar" is legal). In C++, the array has to be at least as long as the string including the trailing \0 byte.
In C, a character literal like 'A' has type int. In C++, it has type char.
C has a special rule to make type punning through unions to be legal. C++ lacks this language, making code such as
```
union intfloat {
    int i;
    float f;
} fi;

fi.f = 1.0;
printf("%d\n", fi.i);
```
undefined behaviour.

Is C# a superset of C?

In a word, No.

What subset of C is supported by Verifiable-C?

Indeed, using Verifiable C one first uses CompCert's parser/typechecker to transform C into Clight, so it's not really about "What's in C but not in Clight", it really is about "which features of C are not supported." Page 9 of the reference manual says, basically:

Goto is not supported in Verifiable C (but CompCert supports goto).
Struct-copy (by struct assignment, struct parameters) is not supported in Verifiable C (but I think it's supported in CompCert)
Only structured switch statements (no Duff's device in either VC or CompCert)
Can't cast pointers to integers then do arithmetic on the result.

Those are the main limitations.

What prevents C++ from being a strict superset of C?

The elephant in the room: the following is valid C but not valid C++.

int typename = 1;

Substitute your favorite C++ reserved word.

When will using C subset of C++ be bad?

I ask mostly in performance

I would say that this is the wrong metric to use. Many C++ compilers share their codebase with C compilers. That is, if a given block of code is valid C and valid C++ (with the same semantics in both languages), the object code produced by the C compiler is likely to be comparable to – if not the same as – that produced by the C++ compiler (ignoring C++ name mangling).

A better metric for "bad" is robustness. The differences between C and C++ are more than syntax. C++ is object-oriented, using a different mindset than C. Given a piece of code that happens to be valid in both languages, the style will often reveal which language it was written as. Thanks to object-orientation, C++ code promotes more robust practices than exist in C (whereas C has a better focus on raw speed). Perhaps the simplest such practice to grasp is RAII.

So the question of "bad" should not focus on the object code, but on the source code. What will your colleagues on this project think of your coding style? You might be better served by learning C++ philosophy before worrying about learning all of the Boost and STL APIs. (There is overlap in what you would learn, so the distinction is not cut-and-dried. Please allow me this bit of exaggeration to make a point.)

finding subsets dicretely c

Ah because you don't cover the LSB or the 0th element. for (j = (n-1); j >= 0; j--) You missed the =.

Also you have to know if j-th bit is set in i or not.

And instead of pow you can simply use (1<<n)[Equivalent to 2^n]

Your code is not readable. I will post the pseudocode.

for ( int i = 0; i<= (1<<numOfSetElmts)-1; i++)
{
     //print Subset-i
     for(int pos = 0; pos<=n-1;pos++)
       if( i&(1<<pos) )
         print Set[pos]
}

Why am I not using `pow`?

The pow function is implemented by an algorithm and uses floating point functions and values to compute the power value.

So power of floating point to the power n is not necessarily multiplying it repetitively n times. As a result you end up with some errors and execution is a bit slower too.

Bitwise is faster?

Yes it is. Even if modern implementation are making changes to the architecture as a whole but still you won't lose the performance by using bitwise. Most of them it will have better performance than addition operation, if not equal.

Where Is C Not a Subset of C++