If you really want safe code there are tools for formally verifying C. >but formal verification takes too long
Formal verification is the only way to write safe code. If you didn't write a spec for all your functions, and you didn't prove that those functions match their specs, your program by definition has undefined behavior. Or you can just be content with the fact that your code has bugs, and try to decrease the number of bugs to a tolerable level.
That is not what UB is. The compiler prevents anything that would cause UB. The only way you can have UB in a Rust program is by doing retarded shit with unsafe.
lmk when you can make a linked list in rust without it screaming and pissing everywhere >unsafe rust
then what's the fucking point of your stupid language?
Yes there is. It's called compile time reduction by hiding implementations. But you'd only know that if you had ever worked on a real project (btw almost no one uses anything newer than c++17).
in b4 >virtual calls are slow
devirtualization and lto are things homosexuals
the problem is that c is too simple. to do anything useful requires you to think about the specifics. take this idea to the extreme and sprinkle in some math, you get haskell. however, take this idea to "features that require 0 cost" and you get C++. take C++, remove its retardedness, you get rust.
rust is well designed through and through, the fact that so many people are seething about it here is enough to say something significant - nobody seethes over rust as hard like they do haskell.
if you ask "why is rust good?", then ask yourself "why is c++ good?" and remove the bad parts about c++. more abstractions at zero runtime cost, RAII to prevent you from forgetting to free stuff, iterators to allow you to combine iteration in meaningful ways at zero cost, etc. taking this idea even further and removing the stuff that makes c++ so highly prone to bugs you get rust, where you prevent buffer overflows and weird aliasing rules and copy constructors and implicit copy constructors and all that garbage
rust is only considered by trannies
and because of today's sick tolerance nobody says firm "No"
everyone knows rust will soon die on its own
and then it will quietly be purged from any Linux interest
pic very related
rust is dead
> Soon die
Rust is barely even marketed right now, and is growing fast. Its kept alive by virtue of how much people hate the alternatives. Sorry to say, its not going anywhere.
>take this idea to "features that require 0 cost" and you get C++
The main problem with C++'s "abstractions" is not that they are supposedly zero cost (after all some abstractions actually are zero cost, not just in C++), it's that they are so leaky that they aren't abstractions at all. The standard library is badly designed and the language itself isn't very good at building powerful abstractions, despite what Bjarne claims.
Take std::vector: breaking its invariants is extremely easy, all it takes is a "direct" insertion via the subscript operator. This doesn't work because inserting elements in such a way doesn't update the internal counter, therefore size() will return the wrong value.
Now, you could say "don't use subscript operators, use push_back". Which is correct, but this basically means that you have to have to be aware of the internals of the vector object at all times. But isn't removing need to worry about implementation details the main point of abstraction in the first place?
std::vector is just one example. the standard library (and many codebases) are full of these non-abstractions. They just overcomplicate the overall structure of the program while not providing an actual reduction in mental overhead.
A leaky, badly designed abstraction is worse than no abstraction at all.
>a "direct" insertion via the subscript operator.
std::vector has no such feature. This OOB access is explicitly UB; the standard library is free to assume or assert index < size() in the indexer's implementation.
tl;dr read the fucking manual.
You are just proving the point even further. You have to be so aware of the internals that it defeats the point of abstraction in the first place.
1 year ago
Anonymous
It has nothing to do with the internals. You use [] to access an element, and push_back for insertion. You can't use [] to access an element that doesn't exist, that won't work in any non-retarded language/library, not even Rust.
1 year ago
Anonymous
That means you have to be aware of the internals. You have to pay even more attention to it than a plain array, which is ridiculous considering that it's meant to be a more general abstraction.
I really don't understand the point you're trying to make here. std::vector is not a good abstraction.
1 year ago
Anonymous
>std::vector is not a good abstraction.
It actually is though. But feel free to stay wrong.
1 year ago
Anonymous
You have to be aware of the internals to use it => it's a bad abstraction. Stop coping.
1 year ago
Anonymous
You don't. But you already knew that. >muh cope
I accept your concession.
>Take std::vector: breaking its invariants is extremely easy, all it takes is a "direct" insertion via the subscript operator. This doesn't work because inserting elements in such a way doesn't update the internal counter, therefore size() will return the wrong value
The reason for this is because the subscript operator is supposed to be a fast way of doing things if the operator can make guarantees that the index is valid, if you had to update the size of you inserted after the end you’d literally have to implement a check for every call to [] defeating its purpose.
>you’d literally have to implement a check for every call to [] defeating its purpose.
That's what the at() method does.
Again, you have to worry that the subscript operator may not be valid precisely because it leakily abstracts over a plain array. At this point, you'd be better off just using a dynamic array.
>waaaaah this extremely convenient class has a caveat so it's baaad and nobody should use it!!!11!
I am so glad people like you have no impact on the professional world.
what does it have that changes the game? c is beyond simple, it's literally human-readable low level language. what does rust ***actually*** have that makes it useful for any task?
because its explicit. if its getting used everywhere, then there's something wrong with the program design. I've seen libraries that do this, almost always there are alternatives with much simpler APIs that are faster as well because the design they created conforms better to borrow checker rules
> human-readable low level
Your assembly output ends up looking nothing like C, not even in the slightest. C is miles and miles above the machine in terms of abstraction.
your brain is minuscule. If you’ve ever actually written and compared code implementing the same things in assembly and in C or C++ structures like loops look almost identical
C is a flawed and badly designed language (even by the standards of the time).
Nevertheless, it's still better than C++. C++ doesn't solve any of the problems of C while adding even more issues on top. The latest standards made the overall situation even worse, causing additional fragmentation and bloat.
The only reason it's still used at all is legacy codebases existing and past successful marketing (just look at how it sells itself even in the name: C++, C, but better).
Both languages should be avoided whenever possible. But if I have to choose between C and C++, I choose C every time.
you homosexuals larp as C/C++ programmers because you know you can't actually build anything in languages people actually use and build stuff on, so you just printf on main and run you little terminal programs for the rest of your life
you will never be a programmer
you will never get a job
I am a C/C++ programmer, and I know for a fact a pajeet can never replace me.
Can you say the same? Hardmode: no larping as some genius that 10 pajeets can't replace.
Never heard of military embedded systems using C# or Java. Rust is too bloated and too much involved in progressive bullshit to be picked up by firms like the one I work for.
>Never heard of military embedded systems using C# or Java
I was thinking more of business/enterprise software >Rust is too bloated
normally you hear the opposite, that C++ (or just STL?) is too bloated and Rust is lean for embedded. Do you use STL at your job?
I have some talks bookmarked about embedded C++, but is embedded too different from 'normal' yet high-performance C++ (desktop) development? To me at first glance, they both seem quite similar for the most part.
I feel like the general feeling tend to air on the side of C++ if your writing your own code. C if the code is going to have to be maintained and modified by different people.
Fucking based.
Also, is there a way to learn HolyC without Temple OS. Is there a compiler for it that I'm not aware of or it's only exclusive to the OS? I want to write programs using the language. Heard it beats C and C++ in every way.
CPU Instructions?
Still using Instruction Set Architecture X86 from the 80s.
Why should the language changed, if its all the same on low level assembly code.
Used sensibly C++ provides a lot of useful, language, facilities over C. The destructor being perhaps the most useful. But there are some costs and complications.
The standard library is a mixed bag of worms and the committee have no sense of ergonomics. But there's a lot in there that can be employed without too much pain and a lot that can be ignored.
The C++ community is the worst part. They are mostly fucktards who relish in a mis-guided and unwarranted belief they are superior to other developers and that the current C++ way (it keeps changing over the decades I've used it) are the one-true-way (much like the Rust proponents) and are often quick to disregard complaints about its obvious failings.
All that said, C++ can be useful in place of C if you're willing to disregard the bullshit.
I think that far fewer people would hate C++ if its proponents admitted the presence of flaws when pointed out.
Instead, you always get snarky remarks of the form "you just don't get it", which leads to people just hating the language even more.
C++ is the same basic shit as C but then they take bloat and ++ it. They add a bunch of useless shit that slows down the compiler, and using it will multiply the slowness further and lower performance. But for monkeys that have no ability to do logic reasoning, it's helps as they can replace logic with abstractions and syntax, which is pure memorization.
>all numeric data is encoded as double or long int everything else is std::string with an encoding/decoding rule >set, tuple, vector, and map are the only used containers >runtime polymorphism is solved by 1 level deep virtual classes
Boom C++ is piss easy to use and you can do 99.5% of the stuff you need to do
C++ is great in moderation, but it never stays that way.
Full C++ style code bases, are impossible to understand or maintain, so much complex behavior hidden behind innocent looking statements, so much OO boilerplate, with getters and setters and other OO masturbation that does not do anything but obscure the actual logic. There is also the extreme bloat, c++ code is 20% faster than C but 500% bigger binary.
I use C++ as my main language, but wish it was never invented, its like an addiction which you know is bad for you, but you can't go back to living without it.
See, people like you at least are honest. Just because you happen to use C++, maybe even as your primary programming language, doesn't mean you can't recognize its obvious flaws. I prefer other languages, but I will openly admit that they are flawed and could be improved.
The thing that drives me insane the most about C++ is not even the language itself, it's the fanboys who insist that it's perfect and those who have anything against it "just don't get it".
Now, while this is technically an appeal to authority and says nothing about the language itself, the fact that many competent and influential programmers publicly expressed dislike for C++ shows that even people who are more than capable of "getting it" can end up hating it.
Writing big programs in C is unfeasible for your average asshat coder.
C++ makes it easier to reduce damage done by each individual asshat coder with architecture enforced on syntax level.
C is about as small as any language where you can properly build abstractions can be. If you look at "char *" or "char arr[]" and say "string", then it'll suck for you and you'll make it suck for everyone else.
C++, with all its flaws both real and imagined, is more accessible, but still too low level for the average programmer to feel comfortable with. If you don't understand C, you're probably a terrible C++ programmer.
Most people should use a higher level language than either because it's too much to ask for them to appreciate the power and pitfalls that lower-level languages expose them to.
I wonder how much C++ hate is results from differences between different groups' standards. Imo the language itself is fine.
I worked with one absolutely beautiful modern C++ codebase (which was just adding C++20 Concepts as I was leaving); standards were enforced, pre/post-conditions were clear, and things were very explicit, either via code or doxygen comments. The program structure was clear. Testing was thorough.
The current C++ codebase I work in is rather ugly. A mix of C and C++, as there are some mallocs and raw new's/delete (which could be RAII'd away). There are (unncessary) macros everywhere, some even just all lowercase letters. Lack of consistency. Things done, seemingly without any reason. Repeated code. Hardly any tests. Things often break on release and it means that us developers actually spend at least half the time just running shit and looking at it to check/guess if it's not broken. Certain abstractions hinder understanding. But my complaints here really have nothing to do with the language.
inb4 >language features
nigga wtf does this dumb bullshit even mean
there's no "features" in programming, it's a fucking list of instructions for the processor
whatever this shit means, it's not a "feature", it's a distraction from what you're actually doing
the former.
>be me israelite
>I read right to left
C++ is superior.
i can't help retarded people, sorry.
booba
Boobs are bloat
This.
They literally get cancer.
genuinely based
>C#
lol. good joke. shilling for dead windows-only language.
Werks just fine on my Linux machine.
>C#
>Werks
Indeed, it does.
It's always Rust, unless you're a boomer or a neet pretending to be a boomer.
based
If you really want safe code there are tools for formally verifying C.
>but formal verification takes too long
Formal verification is the only way to write safe code. If you didn't write a spec for all your functions, and you didn't prove that those functions match their specs, your program by definition has undefined behavior. Or you can just be content with the fact that your code has bugs, and try to decrease the number of bugs to a tolerable level.
this, rust literally doesnt have a spec, how can it claim to be safe. every line of rust code is undefined behavior.
That is not what UB is. The compiler prevents anything that would cause UB. The only way you can have UB in a Rust program is by doing retarded shit with unsafe.
lmk when you can make a linked list in rust without it screaming and pissing everywhere
>unsafe rust
then what's the fucking point of your stupid language?
Reminder that assembly is in the top 20
Time to roll up your sleeves boy
C to LARP as a ""simplicity"" loving unix greybeard, C++ for grungy real world projects
>LARP as a ""simplicity"" loving unix greybeard
I want to be this unironically.
greybeards gatekeep, they have life-long jobs, and they get paid very well for doing nothing.
you're already worthless, so halfway there
C++ without virtual methods and STL
You mean C++ with only completely abstract base classes for interfaces and no multilevel inheritance and lots of stdlib
No point for interfaces when there is function overloading and parametric polymorphism with templates and concepts.
Yes there is. It's called compile time reduction by hiding implementations. But you'd only know that if you had ever worked on a real project (btw almost no one uses anything newer than c++17).
in b4
>virtual calls are slow
devirtualization and lto are things homosexuals
>bypass language features for the sake of muh fast coompilation
You might as well use C at this point and enjoy faster compile times and better tooling support.
based retard.
C++ but without the stupid C++ spaghetti code bloated OO trash, basically write C++ like C while still using the good parts of C++ to enhance it.
> Crap vs Crap++
hard choice
C
/thread
Python
They're both obsolete. We have Rust now.
rust is a joke.
it will be dead in a year or two, just like all those 'killer-languages' in the last 10 years that nobody even remembers now
>gets unironically considered for usage in the linux kernel
>calls it dead
seethe, cnile
the problem is that c is too simple. to do anything useful requires you to think about the specifics. take this idea to the extreme and sprinkle in some math, you get haskell. however, take this idea to "features that require 0 cost" and you get C++. take C++, remove its retardedness, you get rust.
rust is well designed through and through, the fact that so many people are seething about it here is enough to say something significant - nobody seethes over rust as hard like they do haskell.
if you ask "why is rust good?", then ask yourself "why is c++ good?" and remove the bad parts about c++. more abstractions at zero runtime cost, RAII to prevent you from forgetting to free stuff, iterators to allow you to combine iteration in meaningful ways at zero cost, etc. taking this idea even further and removing the stuff that makes c++ so highly prone to bugs you get rust, where you prevent buffer overflows and weird aliasing rules and copy constructors and implicit copy constructors and all that garbage
rust is only considered by trannies
and because of today's sick tolerance nobody says firm "No"
everyone knows rust will soon die on its own
and then it will quietly be purged from any Linux interest
pic very related
rust is dead
> Soon die
Rust is barely even marketed right now, and is growing fast. Its kept alive by virtue of how much people hate the alternatives. Sorry to say, its not going anywhere.
>Rust is barely even marketed right now
What planet are you on? Rust is the most heavily shilled programming language that exists right now.
>take this idea to "features that require 0 cost" and you get C++
The main problem with C++'s "abstractions" is not that they are supposedly zero cost (after all some abstractions actually are zero cost, not just in C++), it's that they are so leaky that they aren't abstractions at all. The standard library is badly designed and the language itself isn't very good at building powerful abstractions, despite what Bjarne claims.
Take std::vector: breaking its invariants is extremely easy, all it takes is a "direct" insertion via the subscript operator. This doesn't work because inserting elements in such a way doesn't update the internal counter, therefore size() will return the wrong value.
Now, you could say "don't use subscript operators, use push_back". Which is correct, but this basically means that you have to have to be aware of the internals of the vector object at all times. But isn't removing need to worry about implementation details the main point of abstraction in the first place?
std::vector is just one example. the standard library (and many codebases) are full of these non-abstractions. They just overcomplicate the overall structure of the program while not providing an actual reduction in mental overhead.
A leaky, badly designed abstraction is worse than no abstraction at all.
joel used to be cool and informative, now its just a cringefest
literally who
>a "direct" insertion via the subscript operator.
std::vector has no such feature. This OOB access is explicitly UB; the standard library is free to assume or assert index < size() in the indexer's implementation.
tl;dr read the fucking manual.
You are just proving the point even further. You have to be so aware of the internals that it defeats the point of abstraction in the first place.
It has nothing to do with the internals. You use [] to access an element, and push_back for insertion. You can't use [] to access an element that doesn't exist, that won't work in any non-retarded language/library, not even Rust.
That means you have to be aware of the internals. You have to pay even more attention to it than a plain array, which is ridiculous considering that it's meant to be a more general abstraction.
I really don't understand the point you're trying to make here. std::vector is not a good abstraction.
>std::vector is not a good abstraction.
It actually is though. But feel free to stay wrong.
You have to be aware of the internals to use it => it's a bad abstraction. Stop coping.
You don't. But you already knew that.
>muh cope
I accept your concession.
>Take std::vector: breaking its invariants is extremely easy, all it takes is a "direct" insertion via the subscript operator. This doesn't work because inserting elements in such a way doesn't update the internal counter, therefore size() will return the wrong value
The reason for this is because the subscript operator is supposed to be a fast way of doing things if the operator can make guarantees that the index is valid, if you had to update the size of you inserted after the end you’d literally have to implement a check for every call to [] defeating its purpose.
>you’d literally have to implement a check for every call to [] defeating its purpose.
That's what the at() method does.
Again, you have to worry that the subscript operator may not be valid precisely because it leakily abstracts over a plain array. At this point, you'd be better off just using a dynamic array.
>waaaaah this extremely convenient class has a caveat so it's baaad and nobody should use it!!!11!
I am so glad people like you have no impact on the professional world.
Even if that were true, it wouldn't change the fact that most classes in the standard library are plain bad abstractions.
You're free to make a serious attempt at a relevant post next time.
They are great, and you are nitpicking minor flaws, flaws which still leave them being much better than suffering through the use of C.
You have nothing interesting to say, I doubt you even use C++.
>no u r dum
>no they r great
>t. never used memcpy on a vector's data()
what does it have that changes the game? c is beyond simple, it's literally human-readable low level language. what does rust ***actually*** have that makes it useful for any task?
unironically the borrow checker
whats the point if you have to wrap everything in Rc and RefCells anyway?
because its explicit. if its getting used everywhere, then there's something wrong with the program design. I've seen libraries that do this, almost always there are alternatives with much simpler APIs that are faster as well because the design they created conforms better to borrow checker rules
>almost always there are alternatives
what are those exactly?
Using the C FFI, for example
They require static analysis to be a part of the compilation process. That's all
> human-readable low level
Your assembly output ends up looking nothing like C, not even in the slightest. C is miles and miles above the machine in terms of abstraction.
Less miles than most other languages, though.
your brain is minuscule. If you’ve ever actually written and compared code implementing the same things in assembly and in C or C++ structures like loops look almost identical
C is a flawed and badly designed language (even by the standards of the time).
Nevertheless, it's still better than C++. C++ doesn't solve any of the problems of C while adding even more issues on top. The latest standards made the overall situation even worse, causing additional fragmentation and bloat.
The only reason it's still used at all is legacy codebases existing and past successful marketing (just look at how it sells itself even in the name: C++, C, but better).
Both languages should be avoided whenever possible. But if I have to choose between C and C++, I choose C every time.
Luckily you are unemployed and have no effect on the real world
Even if that were true, it would be completely irrelevant to the discussion.
you homosexuals larp as C/C++ programmers because you know you can't actually build anything in languages people actually use and build stuff on, so you just printf on main and run you little terminal programs for the rest of your life
you will never be a programmer
you will never get a job
BASED
A
S
E
D
LARP
I am a C/C++ programmer, and I know for a fact a pajeet can never replace me.
Can you say the same? Hardmode: no larping as some genius that 10 pajeets can't replace.
only when they decide to kick you out and replace the code with java/C#. Dont know if that ever happens
Never heard of military embedded systems using C# or Java. Rust is too bloated and too much involved in progressive bullshit to be picked up by firms like the one I work for.
>Never heard of military embedded systems using C# or Java
I was thinking more of business/enterprise software
>Rust is too bloated
normally you hear the opposite, that C++ (or just STL?) is too bloated and Rust is lean for embedded. Do you use STL at your job?
I have some talks bookmarked about embedded C++, but is embedded too different from 'normal' yet high-performance C++ (desktop) development? To me at first glance, they both seem quite similar for the most part.
C#
assembly
I feel like the general feeling tend to air on the side of C++ if your writing your own code. C if the code is going to have to be maintained and modified by different people.
ADA
vs HOLY C
Fucking based.
Also, is there a way to learn HolyC without Temple OS. Is there a compiler for it that I'm not aware of or it's only exclusive to the OS? I want to write programs using the language. Heard it beats C and C++ in every way.
TempleOS is open, you learn in about 6 month everything you need to do everything you want with this operating system.
Dead boomer language vs dying boomer language
why is c++ by far the best language for game hacking if it's dying?
>Muh gaems
>Muh hacking
What's it's market share vs what it was ten years ago
C is the best language to describe our world(in objects).
40 years ago I'm sure this was true boomer
Nothing has changed.
I'm sure you think that boomer
Accept it, c++ is dying and rust is bleeding it
That's cool, but what is the market share? What % of new programs are written in c++ today vs in 2011
You are stupid as hell.
Not an argument
Seethe
Higher market share than c++
>Higher market share than c++
Lol.
you're actually delusional
>market share
>FOSS
>market
>unlimited supply
enjoy your shit language that will die in <4 yrs
Nobody gives a shit about Rust.
CPU Instructions?
Still using Instruction Set Architecture X86 from the 80s.
Why should the language changed, if its all the same on low level assembly code.
1. pajeet
2. webnagger
3. tranny
4. webnagger
5. pajeet advanced
6. pajeet 2
7. idk
8. idk again
9. c sharp chads
10. bash chads
11. c++ king chad demigods
Used sensibly C++ provides a lot of useful, language, facilities over C. The destructor being perhaps the most useful. But there are some costs and complications.
The standard library is a mixed bag of worms and the committee have no sense of ergonomics. But there's a lot in there that can be employed without too much pain and a lot that can be ignored.
The C++ community is the worst part. They are mostly fucktards who relish in a mis-guided and unwarranted belief they are superior to other developers and that the current C++ way (it keeps changing over the decades I've used it) are the one-true-way (much like the Rust proponents) and are often quick to disregard complaints about its obvious failings.
All that said, C++ can be useful in place of C if you're willing to disregard the bullshit.
Well said.
I think that far fewer people would hate C++ if its proponents admitted the presence of flaws when pointed out.
Instead, you always get snarky remarks of the form "you just don't get it", which leads to people just hating the language even more.
>mortar vs bricks
Burger fingers typed this post
C++ but without all the crud and readable syntax i.e. Nim
What is the difference between C and C++ is C++ just C with more stuff will C programs compile with a C++ compiler?
Yes but also no but usually yes except when no
What the fuck dose that mean?
YES BUT PERHAPS NO HOWEVER POSSIBLE ALTHOUGH CONSIDERING EVERYTHING POTENTIALLY NO AND YET EVEN WITH ALL THAT SAID IT MAY IN FACT BE DOABLE
C++ is the same basic shit as C but then they take bloat and ++ it. They add a bunch of useless shit that slows down the compiler, and using it will multiply the slowness further and lower performance. But for monkeys that have no ability to do logic reasoning, it's helps as they can replace logic with abstractions and syntax, which is pure memorization.
Objective-C
golang
>all numeric data is encoded as double or long int everything else is std::string with an encoding/decoding rule
>set, tuple, vector, and map are the only used containers
>runtime polymorphism is solved by 1 level deep virtual classes
Boom C++ is piss easy to use and you can do 99.5% of the stuff you need to do
go
C has better tools.
I HATE EXCEPTIONS
>Oh you want to install this text editor?
>Here you go, also take these, and these, and these...
C++ can fuck right off.
visual c++ is a different programming language you nignog
there is no debate, both have their own legitimate use cases, kill yourself
C for small programs written for fun.
C++ for large projects.
PROGRAMMING FOR ANYTHING OTHER THAN TO PLEASE AND ENTERTAIN GOD IS naggerLICIOUS
most of you fags have 0 knowledge of C++ and it shows lmao
Nobody knows C++ well.
C++ is great in moderation, but it never stays that way.
Full C++ style code bases, are impossible to understand or maintain, so much complex behavior hidden behind innocent looking statements, so much OO boilerplate, with getters and setters and other OO masturbation that does not do anything but obscure the actual logic. There is also the extreme bloat, c++ code is 20% faster than C but 500% bigger binary.
I use C++ as my main language, but wish it was never invented, its like an addiction which you know is bad for you, but you can't go back to living without it.
See, people like you at least are honest. Just because you happen to use C++, maybe even as your primary programming language, doesn't mean you can't recognize its obvious flaws. I prefer other languages, but I will openly admit that they are flawed and could be improved.
The thing that drives me insane the most about C++ is not even the language itself, it's the fanboys who insist that it's perfect and those who have anything against it "just don't get it".
Now, while this is technically an appeal to authority and says nothing about the language itself, the fact that many competent and influential programmers publicly expressed dislike for C++ shows that even people who are more than capable of "getting it" can end up hating it.
Why not just pick a language that has it all?
>JS
>Safe
Writing big programs in C is unfeasible for your average asshat coder.
C++ makes it easier to reduce damage done by each individual asshat coder with architecture enforced on syntax level.
When I google some libraries, they are all written in pure C.
Why do I have to google some wrappers for them?
I just might not use C++
I'm pretty sure that most C libraries have built-in C++ wrappers because you can use the preprocessor to check if you're using C or C++.
Oh, nice.
C is about as small as any language where you can properly build abstractions can be. If you look at "char *" or "char arr[]" and say "string", then it'll suck for you and you'll make it suck for everyone else.
C++, with all its flaws both real and imagined, is more accessible, but still too low level for the average programmer to feel comfortable with. If you don't understand C, you're probably a terrible C++ programmer.
Most people should use a higher level language than either because it's too much to ask for them to appreciate the power and pitfalls that lower-level languages expose them to.
I failed to receive this message because the constructor threw an exception
I wonder how much C++ hate is results from differences between different groups' standards. Imo the language itself is fine.
I worked with one absolutely beautiful modern C++ codebase (which was just adding C++20 Concepts as I was leaving); standards were enforced, pre/post-conditions were clear, and things were very explicit, either via code or doxygen comments. The program structure was clear. Testing was thorough.
The current C++ codebase I work in is rather ugly. A mix of C and C++, as there are some mallocs and raw new's/delete (which could be RAII'd away). There are (unncessary) macros everywhere, some even just all lowercase letters. Lack of consistency. Things done, seemingly without any reason. Repeated code. Hardly any tests. Things often break on release and it means that us developers actually spend at least half the time just running shit and looking at it to check/guess if it's not broken. Certain abstractions hinder understanding. But my complaints here really have nothing to do with the language.
inb4
>language features
nigga wtf does this dumb bullshit even mean
there's no "features" in programming, it's a fucking list of instructions for the processor
whatever this shit means, it's not a "feature", it's a distraction from what you're actually doing