C++ hate

why to people hate using CRT or STL
how exactly not using them gives more control. please explain

Attached: images.png (225x225, 2K)

Other urls found in this thread:

blogs.msdn.microsoft.com/jonathanh/2005/05/20/optimizing-managed-c-vs-native-c-code/
twitter.com/SFWRedditGifs

How about amount of specializations you need to at least be familiar with to use STL effectively? Applies to whole C++.

Attached: Screenshot-72.png (798x485, 26K)

Slow performance of STL containers probably

oh and also vectorshit

It's too complex for no reason.
The performance gain compared to Java has largely been a myth for a good decade. This might have been true between 1998 and 2005.

One day C++ developers will realize that the reference counting they use with RAII is the same slow shit used by Perl, PHP, Python, Tcl, etc. The theory about C++ is that it provides optional features, and you can define your own allocators, etc. The thing is, in practice everyone uses those "optional", slower-than-C features, and most people don't really bother writing their own allocators, etc.

In the Java world, memory allocation and freeing is much faster (allocating is basically incrementing a pointer, and freeing memory is amortized by being done as a batch). And you have a just-in-time, profile-guided compiler that can inline stuff more aggressively than an AOT compiler.

It's also much faster to compile and has a much more comprehensive standard library. And better support for actual object-oriented programming (proper encapsulation, etc.)

>proper encapsulation
huh?

You have compile-time encapsulation (i.e. the compiler will generate an error if you try to access private stuff), but at run-time every object has to be aware of the layout of everything they interact with (which is why you generally have to recompile everything if you change data structures).

In Java, if I have a class Foo with a single public method bar(), that's all the rest of the code needs to know. They don't care whether you have 1 or 50 member variables, nor in which order they are declared, etc.

That sounds dumb. Why is C++'s attempt bad again?

I am sorry but I disagree with your opinion.
lets take for example the std::string. comparing it to our lovely char array/pointer, std::string is more efficient, safer, has nice methods and lets not mention the operator overload ( += ).
another example would be the std::vector comapred to creating C arrays. std::vector is safer, again has nice getters/setters and just cleaner.
also may I ask why people not using C++ try/catch..? C++11
as it has tons of advantages, cleaner code stack unwinding which is really cool. :p

blogs.msdn.microsoft.com/jonathanh/2005/05/20/optimizing-managed-c-vs-native-c-code/

>A line-for-line translation of the original C++ code into C# ran 10 times faster than the C++ code.
>It took five different optimizations (one of which introduced a bug) for the C++ code to match the speed of the unaltered C# code.
>After Raymond's sixth optimization, his C++ code finally beat the C# code — because the runtime got down to where the 60ms startup overhead of the CLR made a difference!
>To accomplish this, Raymond had to:

>Write his own file/io stuff
>Write his own string class
>Write his own allocator
>Write his own international mapping

>retards use badly programmed shit instead of implementing it themselves
>it turns out to be slow
WEW

You have all that in Java, and it's faster.

99% of C++ developers use the standard libraries (or Qt) without re-implementing their own string classes, allocators, hash tables, etc.

And the more you actually implement that stuff, the more your code starts looking like C with classes. Look at the source code for OpenJDK for example. Technically it's C++, but in fact it's much closer to C.

care to explain..? what java has to do with C++ and how on earth its faster than C++.
java being executed in JVM( vm ). its already slower than C++.

And 99% of developers are shit. There's a reason why us here on Jow Forums love C.

I can't see how this is a bad thing.
You don't need to memorize these things, you just use it.
Say there were only one constructor.
It would be easier to implement, but it would be harder to use.
Implementing your own string class is not that hard in c++ but I don't see strings as being inefficient.

better yet, look at something like jsf++, a subset of c++ which is "safe" enough to make it reliable. considering the use case where failure means millions of dollars in hardware and valuable personnel dropping out of the sky. it's also basically C.

>compares std::vector to C array
>doesn't understand why everyone is avoiding exceptions like a plague they are
Is this the power of hobbyist C++ developers?

Its the power of an indian.

>understand
instead of memeing (which btw shows your lack of knowledge)m you haven't given 1 reason why not to use std::string or cpp vectors while I gave you several. please don't bother to leave comment if you don't know, this question meant for people with knowledge. have a good day sir

p.s. nobody here still havent left a valid answer to my question. std::string / vectors are efficient, secure, nicer, cleaner and they're part of C++ lib, why people hate STL so much, performance can be optimizied by the compiler. also depends on the code :p

Raii and reference counting have nothing to do with each other though. In the enterprise world where everything is just another shitty database wrapper, even python is acceptable because of how io bound everything is. Java (nor c#) simply can't compete in either simulation or processing and they never will as long as the garbage collectors stop the world.

>non-managed programs don't spend any time cleaning up

Attached: smugadoka.jpg (492x492, 117K)

As I see it, exceptions are an external way to handle segfaults.
Segmentation faults are the worst possible error message as you have no information at all why it happened. The best method of understanding it is recreating it in a debugger so you can get a traceback (see what lead to the collapse).
If the exceptions is not caught, it still behaves like a segfault but you get an error message.
In this regard, it is just a better segfault.
When catching the exception, you get to (often) gracefully recover.
Obviously, it is better to never get in a situation that crashes the application or throws an exception and everyone should do that if possible.
But if you write a library, you can't predict what people do with your code. In this regard, exceptions are better.

Nobody said that, turbonigger

name 10 cases when you'll actually need an custom allocator

just having exceptions turned on can slow down your program significantly

>turned on
What does that even mean?

means that our script kiddie steve vbnet lover thinks he knows about C++.