Don't change C. Don't make a better C. C is the perfect C.
For this I suffer some loss of safety and correctness but gain the ridiculous amount of power from throwing off the shackles of not being trusted near any of that RAM stuff...
Are today's software developers too lazy to learn and understand their programming languages? Is C insecure because software developers can't be bothered to take care about memory management? After moving to Rust will they start complaining about how cumbersome writing code is and ask for an AI doing their job?
The only thing I can imagine is that even in embedded systems multi-core architectures could become the norm where functional languages have clear benefits. But on the other hand it's hard to believe that relatively simple single-core micro-controllers will go away any time soon.
Long story short: C is here to stay.
@cfbsoftware: I have considered Oberon actually. There's a lot to like about it. But I think Wirth went a bit too far with it. He removed so much that some things are even clunkier to express than with C.
Also, all low-level stuff is supposed to be handled by the SYSTEM module - which is an approach that Wirth always cherished - but it does make writing portable low-level stuff very clunky.
I have looked at other similar languages such as Component Pascal, Modula-3, etc. All are interesting in their own way, but, not quite there. At least for me. though.
One thing I often mention and that those languages have: support for modules. This is good. I f*cking want modules.
However, C and especially C++ deserve to be regarded as the new COBOL
01 SALES-INPUT-DETAIL.
05 SALES-NUM-IN PIC 9(4).
05 SALES-NAME-IN PIC X(20).
05 SALES-REGION-IN PIC 9.
05 QUOTA-CLASS-IN PIC X.
05 COMM-CLASS-IN PIC 9.
05 YTD-SALES-IN PIC 9(6)V99.
05 YTD-RETURNS-IN PIC 9(5)V99.
05 CURR-SALES-IN PIC 9(5)V99.
05 CURR-RETURNS-IN PIC 9(4)V99.
05 FILLER PIC X(25).
01 SALES-REPORT-DETAIL.
05 FILLER PIC X(7) VALUE SPACES.
05 SALES-NUM-OUT PIC 9(4).
05 FILLER PIC X(5) VALUE SPACES.
05 SALES-NAME-OUT PIC X(20).
05 FILLER PIC X(5) VALUE SPACES.
05 SALES-REGION-OUT PIC 9.
05 FILLER PIC X(10) VALUE SPACES.
05 QUOTA-CLASS-OUT PIC X.
05 FILLER PIC X(10) VALUE SPACES.
05 COMM-CLASS-OUT PIC 9.
05 FILLER PIC X(5) VALUE SPACES.
05 YTD-SALES-OUT PIC $$$$,$$9.99.
05 FILLER PIC X(5) VALUE SPACES.
05 YTD-RETURNS-OUT PIC $$$,$$9.99.
05 FILLER PIC X(5) VALUE SPACES.
05 CURR-SALES-OUT PIC $$$,$$9.99.
05 FILLER PIC X(5) VALUE SPACES.
05 CURR-RETURNS-OUT PIC $$,$$9.99.
05 FILLER PIC X(9) VALUE SPACES.
Current standard is utterly stupid because it allows arbitrary padding of structs for performance reasons, but does not allow reordering.
Current standard is utterly stupid because it allows arbitrary padding of structs for performance reasons, but does not allow reordering.
What disallows reordering?
struct { int n; .... } S;
&S shall be equal to &S.n, if I'm not mistaken.
As discussed in 6.2.5, a structure is a type consisting of a sequence of members, whose
storage is allocated in an ordered sequence, and a union is a type consisting of a sequence
of members whose storage overlap.
Within a structure object, the non-bit-field members and the units in which bit-fields
reside have addresses that increase in the order in which they are declared. A pointer to a
structure object, suitably converted, points to its initial member (or if that member is a
bit-field, then to the unit in which it resides), and vice versa. There may be unnamed
padding within a structure object, but not at its beginning.
If printf format specifiers are your major problem with C, then either you are an expert or you don't know how little you know
Current standard is utterly stupid because it allows arbitrary padding of structs for performance reasons, but does not allow reordering.What disallows reordering?
int main(void)
{
struct S { int a,b; } s;
&s.a < &s.b; // <- this comparison is well-defined and shall evaluate to 1
}
Most don't realise that until recently it was impossible to write a threading library in C!
I quite like C as it is actually, but if there's one thing that comes to mind that I'd change, it would be to give it the ability to pass arrays to and from functions. Having learned Python first that is something that caused me some grief coding in C.
I thought that Python was intended to suppliment C for the reasons that the OP mentioned.
I quite like C as it is actually, but if there's one thing that comes to mind that I'd change, it would be to give it the ability to pass arrays to and from functions. Having learned Python first that is something that caused me some grief coding in C.
I thought that Python was intended to suppliment C for the reasons that the OP mentioned.
Python is primarily a scripting language, it's an interpreted language that is designed to be quick and easy to implement but it is not really suitable for embedded development. Yes there is Micropython but nobody is going to use that for serious embedded work.
Using C without tools like Valgrind (like bd139 has said), cppcheck or splint is not using C.
It is "programming by poking".
To point out one flaw in paf’s comment: PHP is never the right language. That’s like using a marrow to hammer in nails. The nails keep winning. Apart from that I agree with the rest of the comment