81–90 of 114 posts
Earlier quoted context omitted.
I am hoping this isn’t an implication that C is legacy and C++ is the modern and the future. :-)
C is a niche language and C++ is about to hit the wall as companies abandon it for languages like Go and Rust.
Earlier quoted context omitted.
Not that I've worked in a lot of places, but everywhere that I've worked that uses C at all treats it this way. Writing new C code is considered a no-no.
As a view into a different part of the industry, when I was writing code for cheap embedded processors, it was C code all the way.
struct point { int x; int y; };
int main() { struct point p = { .y = 0, .x = 0 }; }
error: designator order for field ‘point::x’ does not match declaration orderEarlier quoted context omitted.
C is a niche language and C++ is about to hit the wall as companies abandon it for languages like Go and Rust.
You're high. In industry C and C++ are very widespread. Go and Rust are ... not. You'll have an easier time finding a job that requires FORTRAN than one requiring Rust, and Go is only a bit more popular.
I love that roughly 35 years after its creation we're still arguing about what c++ is or is not in relation to C. I'm looking forward to the debates and blog posts of my grandchildren on Perl 6 vs Perl 5
Nearly everything that is mentioned in this blog is a subject of change / addition to the latest C standard, code named C2x. They are in discussions to introduce the following in C: * nullptr * auto * __has_include * make false and true first-class language features * constexpr and lots of other goodies [1]. https://gustedt.wordpress.com/2018/11/12/c2x/
"Add a type aware print utility with format specification syntax similar to python" Now thats exciting
Several of the examples shown as valid C are not. For example, this: const int foo = 1; int* bar = &foo; *bar = 2; is said to have undefined behavior, but in fact the initialization of `bar` is a constraint violation, requiring a diagnostic. (Some compilers will issue a non-fatal warning, which is allowed by the C standard but IMHO is unfortunate.) Another example: it says that this: const size_t buffer_size = 5; int…
I haven't been able to find anything in the C11 standard about the initialisation of bar being a constraint violation. In 6.7.3, the only constraints for type qualifiers listed are for _Atomic and restrict. Could you let me know where you got the information you talk about here from? I could be missing part of the standard.
6.5.16.1p1 says that, for pointers, "the type pointed to by the left has all the qualifiers of the type pointed to by the right".
In this case, the right operand is a pointer to a const-qualified type and the left operand is a pointer to a non-const-qualified type.
(Without this restriction, you could silently discard const qualification just by assigning or initializing a pointer, which would largely defeat the purpose of const.)
Earlier quoted context omitted.
> Are they trying to make C literally become the same as C++ except classes and templates? As a C programmer, aren't classes, templates, and exceptions the things that have classically differentiated C and C++?[0] I don't see anything obviously objectionable about nullptr[1], auto, __has_include, or constexpr. (I don't have a ton of experience with them, either.) I'll admit I don't really grok what "make false and tr…
> This means that it cannot be used safely in portable incantations of variadic functions that expect pointer arguments. Why only variadic functions? The answer to that may make my next question obsolete, namely: Wouldn't only C++ complain about this? In C, isn't the input to anything coerced to the data type it will represent, in actual complete disregard of the input type?
For variadic functions, the compiler doesn't know the parameter type.
So to print a null pointer, you need to do this:
printf("NULL = %p\n", (void*)NULL);
printf("null pointer = %p\n", (void*)0);
What is in that intersection depends on which C and C++ dialect pair your intersect.
E.g. a newer C++11 dialect has "long long", so if intersected with C99, "long long" is in the dialect. If we intersect C++ older than C++11 with C, or C older than C99 with C++, then we don't have "long long".
(Except as a conforming extension from a compiler, which we could detect with a configure script and use anyway.)
The thing is that the intersection languages are basically fully fledged C: you can easily develop in them and do everything you'd want from C, if you're willing to live without a few frills here and there like C99 designated initializers, and variable length arrays (dropped from being required in C in C11) and whatnot.
If you require complex numbers, that could get hairy.
A long-time C90 programmer will not find anything amiss, though.
Earlier quoted context omitted.
> Are they trying to make C literally become the same as C++ except classes and templates? As a C programmer, aren't classes, templates, and exceptions the things that have classically differentiated C and C++?[0] I don't see anything obviously objectionable about nullptr[1], auto, __has_include, or constexpr. (I don't have a ton of experience with them, either.) I'll admit I don't really grok what "make false and tr…
> This means that it cannot be used safely in portable incantations of variadic functions that expect pointer arguments. Why only variadic functions? The answer to that may make my next question obsolete, namely: Wouldn't only C++ complain about this? In C, isn't the input to anything coerced to the data type it will represent, in actual complete disregard of the input type?
This works:
void f(char *p);
f(0); /* integer literal auto promoted to pointer */
void f(...);
f(0); /* assume type of function is void f(int) */Earlier quoted context omitted.
Yes, but only for constants of type int. For example, this is valid: enum { ANSWER = 42 }; But C enumeration constants are always of type int, so you can't define a constant of some other integer type this way.
It's worse than that. The type of a C enumeration is implementation defined. It must cover the full range of defined values, but it definitely doesn't have to be 'int'. (§ 6.7.2.2 (4)): > Each enumerated type shall be compatible with [ed: one of] char, a signed integer type, or an unsigned integer type. The choice of type is implementation-defined but shall be capable of representing the values of all the members of…
For example, given:
enum foo { this, that, the_other };
enum foo obj;
In C++, the constants are of type "enum foo", which can also be referred to as "foo".