>>31
C is supposed to be portable assembly and it serves it's purpose very well.
Not again... Murk loar.
I do not need to murk loar, i've read that thread.
It's mostly opinions by people who never tried to learn or understand C.
Python, lol
Python is good for what it is, same applies for any language.
O(n) strlen
Any function that checks the length of a string is O(n). it cannot be less.
what you say? length() in std::string?
Well you know how length() operates.. a `string' holds it's size and when it gets resized, the size changes as well.
Therefore, length() is O(1).
``
Ah'' you might think ``
that means length() is so faster than strlen() correct?''
The answer is yes but the function that changes the `size' of the string when it resizes is O(n).
And if you found length() to be faster from your tests, consider the following
char buf[1024] = "Hello, ";
size_t n;
n = strlen(buf); /* n == 7 */
strcat(buf, "World\n"); /* where we should do strcpy(buf+n, ..) */
n = strlen(buf); /* we re-strlen the "Hello, " part. */
That does not happend in case of std::string and whatever resize operation it has.
So is C++'s std::string faster than C's? No. The above code is considered awful, with proper code it'd be of the exact same speed (in theory)
You think Haskell or Lisp or whatever language you came from is better? It might be in theory, but a lisp/haskell implementation cannot be faster than a C one. (If both implementations are perfectly implemented)
Because nothing is perfect, sometimes using lisp or haskell or python is faster; that's because it's harder to write shitty code or do a mistake or something redundant in such languages.
shitty quality functions like strcpy, strtok, etc.
strcpy and strtok shitty? Why is that? Also, what is `shitty'?
Don't go about array bound checks and null terminator crap, please.
Strings in C are terminated with a '\0'. Therefore any str*() function is not shitty.
One could claim the concept is shitty, but the functions are perfect.
If you don't like a certain implementation move to another, and if you can't find a decent one write one yourself.
Yes, exactly. It makes things useful and portable.
I will agree about the portability, it is a pain in C.
I often find myself spending hours to write portable code for a VT100 terminal and a pre-ANSI compiler. It's a pain; however having a huge library would not solve this problem. C is portable assembly, assembly is a pain.
what else do you want?
Well, let's see until now you mentioned
1) lack of proper unicode support -- a part of me agrees but i do not care
2) shitty quality functions -- you are wrong
3) binary unsafe strings -- you are wrong again, strings are terminated with '\0' what you are asking for does not make any sense.
4) portability problems -- shoulnd't be a problem with proper C. I'd complain about the time it takes to write proper C rather than the portability problems.
So you have only one valid point (unicode) everything else is either incorrect or not focused in the real problem.
You should spend some more time learning and writing C code, then you will realize C's real problems.
I'll await for your reply.