Am 25.08.2012 21:23, schrieb James Kuyper:
???
The claim was that use of C was a necessity, not just a convenience. C
doesn't have constructors, and designated initializers are only a
convenience feature that don't do anything that can't already be done
using ordinary initializers - they just make it more convenient.
How would you do
unsigned char errVector[] = { [EINVAL] = true, [ERANGE] = true, };
enum { maxNeeded = sizeof(errVector), };
in C++ ?
???
A compound literal doesn't do any thing that can't be done with an
explicitly declared and named temporary object. Again, it's just a
convenience feature.
E.g you can't easily declare named temporaries in function-like
macros, and you can't easily protect named temporaries from accidental
use elsewhere in your code.
You can easily use anonymous temporaries in both languages for
that, but not with a common syntax.
Convenience is all that higher programming languages bring, no?
- no consistent way of passing dynamically sizes multi-dimensional
arrays to functions
???
int func (double *array, rows, cols)
{
// to access column c of row r:
array[r*cols + c]
VLAs are also just a convenience feature - the don't do anything that
can't be done less conveniently by other methods.
sizeof *array is a very convenient feature, and much less error prone
than copying the size expression all over your code.
Well again, yes for convenience I can explicitly declare a variable
that holds the size of *array, invent a naming convention for such a
thing as sizeof_array or so. I prefer to have a language (or library)
feature for that. Both C and C++ provide that feature but with
completely different syntax.
It might just be jealousy on my part - I've never been paid to program
in an environment where I was permitted to use either designated
initializers or VLAs; I've regretted having to work within those
restrictions, but never had any trouble working around them, so the
claim that a lack of support for those features renders C++ unusable
strikes me as quite laughable.
Have your laugh, I was not saying that. I was saying that the
intersection of those two languages is not very convenient to use. C++
has its own features that replaces them, more or less. (For designated
initializers there is not really a replacement, since C++ always
forces you to initialize in declaration order.)
Could you explain the relevant differences? There are things prohibited
in C++ unions that aren't even meaningful in C unions, but I'm not aware
of anything that C unions allow you to do that couldn't also be done in
C++. I'm willing to believe that I might have missed something, but you
need to be more specific.
AFAIK C++ got stuck with the initial wording that has been corrected
for C. In C++ reading another member that was written to is UB. In C
it is perfectly valid unless you happen to encounter a trap
representation for the read-type. Type punning is basically what
unions are made for in C. If you use unions for type punning the
compiler can arbitrarily decide to throw up on you, since this is UB,
anyhow.
There are significant subtle differences between the two languages with
respect to inlining.
subtle? I don't think that there is a valid use of that feature in the
intersection of C and C++ that covers all use cases. Either you may
encounter multiple symbols or the day you compile for debugging a
symbol is missing.
However, the supposed "necessity" of programming in
C as a result of those differences would be much clearer with a
sufficiently specific example.
I didn't say that there is necessity. I said that there are strong
forces that push you to chose a side.
Jens
