I know that C is meant only as a little step forward from assembler. But it was also fine to introduce arrays (which are also not a thing in asm where you only operate on pointers). So why not also add a datatype for THE ONE THING that is used almost everywhere?
There are thousands of useful things one could argue about if they would make sense in the language or not (and in the case of C I would be totally fine with saying “no” to all of them). But strings IMO are not just some fringe feature that is used here and there. They are mission critical across the board and far too important to be left for libraries.
arrays (which are also not a thing in asm where you only operate on pointers)
I’m afraid that’s wrong. Arrays are definitely an asm thing. An array is just a pointer to the first object of consecutively stored objects. You add n*size_of_stored_type to the pointer and you get the nth object
They are mission critical
Do you have an example? I know that many products abandon having control over what is executed because that’s cheaper money/developer-time wise and leverage the power of CPU. So instead of securely comparing a string once and then using enum(int) in further code, use string comparison all the time. But that’s a design problem, not technical one
Basically every program that deals with some form of user input will come across strings. Be it to print something to the screen, write something to a file, read something from a file, read something from the user interface (even if it’s stdin). Even most non-user-facing tools (daemons, drivers, etc) have to deal with strings often enough, even if “just” for something like writing log or debug entries.
For me it’s hard to come up with any application where I don’t need strings sooner or later. Typically sooner than later.
Do you separate that? I mean if the idea is to use C only outside of user interaction, then maybe. But is this a realistic scenario? If I write my whole application/library in C, user interaction is part of the application nonetheless. Maybe not what you consider “mission critical” from a program-reliability standpoint. But still mission critical from a user-experience standpoint. Because the whole application is worthless, if it cannot be used.
I know that C is meant only as a little step forward from assembler. But it was also fine to introduce arrays (which are also not a thing in asm where you only operate on pointers). So why not also add a datatype for THE ONE THING that is used almost everywhere?
There are thousands of useful things one could argue about if they would make sense in the language or not (and in the case of C I would be totally fine with saying “no” to all of them). But strings IMO are not just some fringe feature that is used here and there. They are mission critical across the board and far too important to be left for libraries.
I’m afraid that’s wrong. Arrays are definitely an asm thing. An array is just a pointer to the first object of consecutively stored objects. You add
n*size_of_stored_typeto the pointer and you get the nth objectDo you have an example? I know that many products abandon having control over what is executed because that’s cheaper money/developer-time wise and leverage the power of CPU. So instead of securely comparing a string once and then using enum(int) in further code, use string comparison all the time. But that’s a design problem, not technical one
Basically every program that deals with some form of user input will come across strings. Be it to print something to the screen, write something to a file, read something from a file, read something from the user interface (even if it’s stdin). Even most non-user-facing tools (daemons, drivers, etc) have to deal with strings often enough, even if “just” for something like writing log or debug entries.
For me it’s hard to come up with any application where I don’t need strings sooner or later. Typically sooner than later.
But this is high level. You shouldn’t rely on strings or user input down in the mission critical part of the program
Do you separate that? I mean if the idea is to use C only outside of user interaction, then maybe. But is this a realistic scenario? If I write my whole application/library in C, user interaction is part of the application nonetheless. Maybe not what you consider “mission critical” from a program-reliability standpoint. But still mission critical from a user-experience standpoint. Because the whole application is worthless, if it cannot be used.