Objective reasons to dislike C++?

Currently learning C++ because a couple of frameworks I need for a project are written in it.

I got a couple of books ('Tour of C++' and 'Effective Modern C++') to start getting up to speed.

Was wondering, for those of you that dislike the language, what are you reasons for disliking it? What are the greatest weaknesses? What are your experiences.

Attached: what_this.jpg (2350x3900, 891K)

Other urls found in this thread:

hboehm.info/gc/
libcello.org/
twitter.com/NSFWRedditImage

Not knowing the libraries off the top of my head, having to look up what does what and get mad when something very specific from another language library isn't in the C++ standard.

Generally, C++ is really just an extended version of C, and nothing prevents you from just using like an improved C with a few C++ features here and there.

IMO the main issue with C++ is the complexity of it. In C you could make a struct for some data that is grouped together. What about C++? Struct? std::pair? std::tuple or a class? Something else maybe?

It's hard, complicated, lacks modern features

So lots of options for achieving the same goal. I guess that would require learning the tradeoffs of each option, which is a lot of extra studying. Fair enough.

>It's hard, complicated, lacks modern features
What do you find hard and complicated about it?

Could you give some examples of modern features that you wish C++ had?

just libraries, automatic garbage collection, etc, things that would kinda defeat the point of the language really
i mean, it's not bad, it has it's place but it's not good to learn it or practice it because it's rare to actually need it anywhere.

>automatic garbage collection

With smart pointers and move semantics there really isn't a need for GC

>automatic garbage collection
You can link against a garbage collector and either redefine the new operator or make your own malloc-like function.
hboehm.info/gc/
Also as another user said if it's not ultra performance critical the reference counting smart pointers in the standard library should be sufficient.

Header files and their consequences.
The fact that they started as a superset of C instead just making it syntactically superficially similar which worked for other languages as well.
Several features being half-assed.
Tons of metaprogramming features with more to come like metaclasses that combined together STILL ARE NOT AS POWERFUL as a proper macro system and also lead to way worse error messages.
The standard library being shitty here and there.

I can think of plenty of companies that use C++:
microsoft, cisco, mathworks, valve, mozilla, etc...

C++ has three great weaknesses:

It's unbelievably enormous, there's about five different styles for doing everything you can think of, meaning there might not be much common ground between different C++ code you read.

It's unbelievably enormous, meaning it's very difficult for you or anybody else (i.e. people you might want to hire/work with/contract) to learn it and be able to understand all the code they might conceivably see or need to write.

A lot of the features are very "dangerous", meaning they make it possible to write undebuggable unmaintainable crap (just think what you could achieve with preprocressor macros + raw pointers + operator overloading + template metaprogramming if you were trying to be malicious).

because sometimes its easier to understand the disassembly than then actual c++ code

>Header files and their consequences.
What are the consequences that you dislike?

>Several features being half-assed.
Which ones specifically?

Thanks user.

The build system

Jow Forums just repeats memes and follows linus because they worship linus tech tips. There are no valid criticism of C++17.

>There are no valid criticism of C++17.
There is no reflection support. I am sick to death of writing mappings between config file keys and data structure members or mappings between enums and their string representations.
Also concepts didn't make it in so the error messages are still insane. Making one mistake with a template class in a five line program can produce a three hundred line error. That's insane.

>What are the consequences that you dislike?
Slow compile times. Unnecessary separation. Annoying to deal with without further tools. A proper symbolic inclusion system will always win. See also >Which ones specifically?
Most of them. For example, look up how they gradually completed compile time execution and type inferrence from C++11 to C++17.

#pragma once
solved.

STL wasn't rewritten with new features and so is riddled with confusing API full of lifetime scoping caveats and bad error handling
header files
no good package management
no good build tool

That literally solves none of the problems mentioned.

>hard, complicated
Not really complicated if you restrict yourself to very specific subset of it. This is not the case in the industry though where you will work with a codebases spanning 2 decades and 4 standards, (ab)using every single feature C++ has. Every library/framework will use different subset of C++ too, so unless you do 99% of code in-house, you simply will have to deal with that bullshit.
>features i wish C++ had
In order of importance:
Functors or modules
Ability to force most features to not be used (as of now, you have to rely on static analyzers that do a shitty job of catching it)
GADTs
Dependent types (linear)
Pattern matching (dependently typed)
Refinement types
Starting with GADTs, none of the subsequent features are realistic to ever get into C++ because its type system is too weak. But all of those would help tremendously with writing good software.

Shit syntax

Here's an objective reason: Objective-C

there's too fucking much of it

As a C++ developer, my biggest gripe is the "discovery" of template metaprogramming and the standard committee's decades of refusing to adopt necessary and convenient features (i.e. concepts, reflection) which people had to resort to TMP to solve, resulting in disastrously messy libraries.

a million ways to do things horribly wrong

std::enable_if_t

>structs

Attached: 1523921595697.jpg (1403x790, 131K)

>Dependent types (linear)
They are awesome, but are there any practical languages besides Rust that implement them? I guess ATS is borderline-practical.

Rust has dependent types. I only know of two languages with linear dependent types- coq and agda. Neither is popular, but at least to me, coq is pretty practical (moreso than haskell).

There are none. Only brainlets dislike C++.

>Rust has dependent types
wat

Dependent types are not the same as linear dependent types.

>currently learning
There's your problem. Try building something complex. It's a pleasure to learn, but a pain in the ass to develop in.

>There are no valid criticism of C++17.

Attached: 1522818181386.png (1478x10000, 2.86M)

>there should be only muh autistic way of doing everything

Debugging it is a nightmare. Especially STL containers.

Why are you complaining about std::pair and std::tuple those are not even language features, but simply classes you could have written yourself. Get a grip.

Attached: 9ab3195f348c4f33107f963052af621800b34e54afb44036e0ddc1154af94158.jpg (480x720, 81K)

>>automatic garbage collection
>he is too stupid to use smart pointers and RAII

This. Fuck the committee and fuck the abomination that is boost.

Attached: 1505402690114.jpg (500x500, 49K)

Attached: 1524068489259.png (2154x1316, 173K)

>g++ has unreadable error messages, therefore c++ is shit
No, it just means that gcc is shit.

Nice try, applel shill.

Attached: Screenshot from 2018-04-19 15-28-08.png (1934x1067, 124K)

Wrong screenshot

Attached: Screenshot from 2018-04-19 15-29-02.png (3840x2160, 654K)

Bjarne has a stupid hairstyle

>>g++ has unreadable error messages
This is one of the worst memes ever to exist. Apple shills are quite clever for establishing this.

C++ has functors

C++ is powerful so it terrifies pajeets and soyboys

>auto main() -> int
why

>no match for operator

What does the arrow after the function mean? What's it called?

Never seen that before.

Trailing return types. It's useful in other circumstances, but here it's pointless.

What said
its the same as int main()

Thanks, it's interesting, looks like it was added in C++11.

So it's just an optional way of declaring the return type (unless you are returning a lambda, then it's mandatory)?

>It's useful in other circumstances
When would you use it? Is it more than just a style choice?

Not mandatory for lambdas in most cases

More symbols will be in scope after the rest of the function declaration has been completed, so you can use them.
auto add(X x, Y y) -> decltype(x + y);
Foo::Bar Foo::baz();
auto Foo::baz() -> Bar;

That's actually really cool, thanks user.

>it's obvious what that means.
No it doesn't, autistic faggot. Neck yourself next time you try and apologize for garbage like this.

The way STL is implemented, shit error messages will keep coming up no matter what.
In fact forget STL. The problem is in C++'s shitty type system in fact. You need a massive language re-design and get rid of duck-typing in general.

Why must pointers and things in C/C++ be so strange and inconsistent?

Attached: Untitled.png (687x495, 69K)

retarded compilation errors.

try this code
struct x struct zv

Read right to left and it becomes obvious desu

I see nothing inconsistent in the example you posted.

This.

Because C was retarded and C++ had to keep it that way for compatibility.

>its a brainlet is afraid of pointers episode

The operator's arguments are mismatched. It tells you as much. If you can't figure out what you did wrong after being told what the error is, that's your problem.

Pointers are fine, C declaration syntax was a blunder though.

It is a very lost language with no thought to design. They slap as much as possible on it without thinking.

This picture gives me dysphoria. Please delete.

Attached: 150004573306.png (461x444, 275K)

>this

Attached: v2-93d88a4e8213d5c3300ab190b5dc9644_r.jpg (1567x879, 1.03M)

int* a, b; only give me one pointer and I must use int *a, *b; to have two. It's so fucking retarded.

template using ptr = T*;

ptr a, b;
The power of sepples.

that's actually reasonable.
it means the type of (*a) and (*b) is int

Does this work?

>The operator's arguments are mismatched
That's not what the actual problem is you utter idiot.

I think they just called "linear types".

*they're

Yes, it is.
You defined an operator

Never mind C++. Just use C and Cello.
libcello.org/

Mistakes inherited from C and retarded naming in STL.
I'm still mad at
int a, *b;

How is it reasonable? int* and int are different types.

>The compiler bitches that there's no operator

void foo(Bar bar, Baz baz);

foo(Baz{}, Bar{});

>hurr durr why won't it compile it's the language's fault

>I got owned: the post
Now consider suicide.

>because it's rare to actually need it anywhere.

dumb nibba alert

Linear types, dependent types and linear dependent types are all different in most type theories. This is why CS sucks, there's too much ambiguity so unless we decide which type theory we will use to discuss this, there's no point in talking about it. Even when you read papers on Rust, there are multiple inequivalent type theories being used in them so what's said in one paper doesn't apply for other papers and so on.
C++ has something called functor, which isn't anything like a functor.

>Objective reasons to dislike C++?
all features over C - useless shit

Attached: item_3847.154.500.jpg (500x392, 27K)