C++ Sucks

C++ is a horrible language. It's made more horrible by the fact that a lot of substandard programmers use it, to the point where it's much much easier to generate total and utter crap with it. Quite frankly, even if the choice of C were to do *nothing* but keep the C++ programmers out, that in itself would be a huge reason to use C.

>>25
If you were to suddenly redefine it as 32-bit unicode (wchar_t ahoy!), you'd break lots of shit.
Sure, but you can create unichar and make that at least twenty-fucking-one bits by specification. Then add real Unicode functions. Conversion to and from all Unicode Transformation Formats. And Unicode semantics and properties.

If Java or C# is what you want, go use Java or C#.
What the fuck, I'd rather do C. Good languages > C > C# > C++ > Java.

Complex types on the other hand are something that many HPC-oriented compilers have supported for a while, all in their mildly incompatible forms. It's something they basically had to standardize.
I'm all for standarization, but I'm annoyed that they solved this relatively unimportant issue when the rest of the language is a piece of shit close to FUBAR.

I will grant you that they could've finally excised gets() from the standard library. But other than that and perhaps strtok(), shit, I don't see how the C standard library is so bad.
Even if we leave security aside, we have shitty strings (the whole zero-terminated thing is retarded), crappy pattern matching (*scanf), crappy formatting (*sprintf), clumsy numeric/string conversion, quirky/incomplete time library... As I see it, at least 50% of C's standard library is shit, and the other 50% is not 5% of what I wanted it to be.

>>26
Not to mention the fact that there already are decent methods for unicode conversions and such on most all platforms.
#ifdef WIN32
#ifdef POSIX
#ifdef MACFAG
#ifdef NEXT_TIME_MAKE_IT_PORTABLE_GUYS_LOL

>>28
Shit, if all they did was get rid of null-terminated strings and made functions like strncpy the only choice, I'd be happy.
I'd make strings prefixed with allocated length and used length, and automatic logarithmic reallocation. They are automatically "n" as no string function can possibly fuck up, they support lengths up to your platform's pointer size, they have O(1) length, and they're still pretty simple, low-level and fast.

This, however, will never happen due to backwards compatibility.
But you can always say "OK guys, string.h is deprecated but supported for good, now use decent_string.h".

>>29
strncpy is slow as shit, filling the rest of the alloted buffer in with 0's.
And >>25 wondered why is the standard library so shitty.

>>32
Nope. It just means that the C standard library is _small_.
_small_ and _useless_. You have to get anything else to get the job done, therefore its purpose is completely failed.

Can you believe that they actually criticized C stdlib for assuming a files-and-directories view of persistent storage?
It doesn't even standarize a way to handle fucking directories! It's completely POSIX dependent!

Some dissed it for only supporting linear, byte-addressed files; mainframe programmers were used to storing fixed-length records in more setup-heavy files, where the record boundaries were enforced by the OS.
That's actually the good thing about Unix: octet-addressed I/O. These "mainframe programmers" are the ENTERPRISE of old, IBM retards used to their shitty platforms. They can complain all they can, just like Spectrum programmers can complain that C doesn't support line numbers.

Linked lists and string buffers you can do yourself.
I can do the 15190348th incomplete, immature, untested, and probably bugged implementation of the basic data structures I should have at my disposal.

They're just a combination of structs and pointers, and structs, pointers and a len/size combination, respectively.
So? I can do them in assembly as well. They are just a combination of MOV and effective address calculation.

use strlen() and memcpy() and set the damn null byte yourself.
Yeah, or just use ___asm { ... }, am I rite? I bought a computer to make it work for me, not otherwise. Besides, I don't like to take a shit on abstraction — let alone an elemental one such as character strings.

Of course this is neglecting that just one mispredicted branch will cost you about as many cycles as filling in 32 zero bytes would... L2 cache misses are even worse.
OMG OPTIMIZED (read: I don't gib a fuck, if it's not fast enough I buy faster/more hardware and save my time which is more expensive)

That shit doesn't cover half the cases where null-terminated strings rule the skies
PDP-11? No longer in use, thanks.

What I see in these C-hatin' comments is people who don't have experience in using C for reals.
The reason why I hate care about the standard library's shittiness is exactly that: I've worked in real stuff with C, and will probably keep doing so in the future.

_{ed and readability advantages of C but}
and readability advantages of C
readability advantages

AHAHAHAHAHAHA!!!!

(Now you'll claim that I can't do C. Well I can, and I can tell they are a bitch to maintain.)

go back to Java or C#
Who said:
1. I come from Java or C#
2. I see Java or C# as the better alternative to C
3. I even like Java or C#
?
That's like saying, "ok, if you don't like getting your dick cut, go have your arms or legs cut".