C++ hatred

Why is C++ hated so much here in /prog/? Many good software are written in C++.

I'm aware that there are some problems in the language and it is considered "hard" to master it, but why do so many people hate it? What harm has it done?

Software can be written much quicker when using some scripting languages like Python. Software can be writte slightly quicker when using some managed language like Java. But when using those languages, the resulting program will require more resources to run. So there is place for C++.

For example, I bet the web browser of 99% people browsing /prog/ is written in C++. It's not perfect language, but it is the best language for complex program with relatively small CPU and RAM requirements.

What the hell is this!

I have observed that most C++ haters hate it because they are incompetent programmers.

Most of the competent haters are LIPTH faggots, or C dinosaurs.

>>362
I'm going to eat you, just you wait.

______________________
< what did he call us? >
 ----------------------
\                             .       .
 \                           / `.   .' "
  \                  .---.  <    > <    >  .---.
   \                 |    \  \ - ~ ~ - /  /    |
         _____          ..-~             ~-..-~
        |     |   \~~~\.'                    `./~~~/
       ---------   \__/                        \__/
      .'  O    \     /               /       \  "
     (_____,    `._.'               |         }  \/~~~/
      `----.          /       }     |        /    \__/
            `-.      |       /      |       /      `. ,~~|
                ~-.__|      /_ - ~ ^|      /- _      `..-'  
                     |     /        |     /     ~-.     `-. _  _  _
                     |_____|        |_____|         ~ - . _ _ _ _ _>

>>364
I rawr'ed.

>>355
That should be http://dis.4chan.org/read/prog/1325441698/32

What is it about C++'s syntax that people hate so much?

>>367
3/10
What syntax? I can overload almost every operator! Fuck your syntax!

>>367
That's what you have a problem with? Provided you follow conventions, I don't see what the issue is.

What is convention in a language that uses bitshift operators for IO in the base language? Should "string" << 3.0f be a concatenation per convention? It would seem to be the behavior that would satisfy the principle of least surprise best, cout << "string" << 3.0f prints the string and number in succession after all... By extension 3 << 2 really should result in "32"?

Operators in C++ can be overloaded, which means that the "<<" operator is not the bitshift operator in every case, for the same reason the "+" operator can mean "concatenation" in some cases. Curiously, people go apeshit about "bitshifting" file objects but they don't speak a word about "summing" strings.

Whether overloading operators is good, it is a matter of personal opinion. The fact is that C++ is not the only language which implements it (Python also does, IIRC), but C++ has surely acquired some permanent critical target status due to no apparent reason than mere butthurtism.

The choice of the "<<" and ">>" operators for I/O have a rationale (which the committee has released, but probably no one has ever read it). One good reason for using (or abusing) operators is that it becomes easier to chain I/O calls:


std::cout << "Hello, " << "World!" << std::endl;

instead of something like:


std::cout.write("Hello, ");
std::cout.write("World!");
std::cout.write(std::endl);

which verticalizes the code too much. One could vouch for:


std::cout.write("Hello, ").write("World!").write(std::endl);

but, besides it being yet more verbose, it's less intuitive (in my opinion) than to use any sort of operator, which is expected to be used in associative contexts.

It's a matter of taste. I don't think choosing operators for this task are an spectacular design choice, but I don't see many problems with them, either. One thing I think is very bad are the "manipulators" (std::hex and such). These are indeed very bad design choices in my opinion.

Just remember: when blindly criticizing C++ operators, take a look around. Look at Haskell operators, for example. Be amused for a while. You'll see that the world is much more dark and horrible than what mommy has told you, yet C++ inherits all the debt.

>>370
What if x << y << z = (x << y) << z) and (x << y) << z != x << (y << z)? After all, << is not commutative either.

>>371
Why didn't they just invent another operator?

>>371
Pick one:
std::cout.write("Hello, ").write("World!").write(std::endl);
std::cout.write("Hello, ").writeln("World!");
std::cout.write("Hello, ", "World!", std::endl);
std::cout.writeln(Hello, ", "World!");

>>373

This is a good point. I'm sure the committee has thought on that possibility. My guess is that they would not change the core language because of a library issue. After all, how would syntactically be this operator? What would be its meaning outside an I/O context?

>>371
I work with some ex Oracle weenie who thinks overloading operators in C++ is the greatest thing since control top pantyhose.

>>371
Just remember: when blindly criticizing C++ operators, take a look around. Look at Haskell operators, for example.
Haskell operators work, unlike C++'s. They don't need to be associated with a class, and they don't need friends to write cout << "Hax" << " my " << "anus";.
That's because they're simply variables, they're not supposed to be a -> b -> c functions, for some a, b, c.
(<<) :: Handle -> [Char] -> IO ()
(<<) = hPutStrLn
cout = stdout
endl = "\n"
main = cout << ("Hax" ++ " my " ++ "anus" ++ endl)

>>370
"cout << "string" << 3.0f" doesn't concatenate anything, though. It's called the insertion operator for a reason. It writes, or "inserts", "string" to the stream, which returns the cout instance, so then you can write 3.0f to the stream.

>>377
C++ operators don't need to be associated with a class, and they don't need to be friends. They're normal functions, which respect the normal access control for members, as any function would.

I don't see why C++ operators "don't work", put apart what the average emotionally-based, highly subjective opinion against them claims.

Wondered what the fuck is a << operator in C++? Now wonder what the fuck a ++ or a >@> in Haskell is. That's the point.

>>379
I hope you get to work with someone who exchanges >> and << in classes you need to use or that the ostream operator is uses ().

>>380
Conventions, conventions, conventions. Any decent team will establish them, although you'd think that it would go without saying, considering that << is the insertion operator and should only be used for inserting, >> is the extraction operator and should only be used for extracting, and () is for function objects. There's no need to put a restriction on operators. It's not the same as weak typing, where the lack of restrictions can lead to errors even if you're trying to be sensible.

>>380

I hope you get to understand that someone who exchanges >> and << is mind-crippled and C++ is not designed to fix bugs buried deep inside the human brain.

>>379
C++ operators don't need to be associated with a class,
Can I write template<typename A, typename B> int operator+(A x, B y) { return 0; }?
This is a serious question, I don't know.

Now wonder what the fuck a ++ or a >@> in Haskell is. That's the point. That's the point.
I might as well wonder what the fuck is a vasnprintf or strtok. That's not the point.
Let me clarify one thing, I'm not one of those retards that think of cout << "something" as a bitshift to a file. I'm one of those retards that think that C++ operator overloading is an ugly hack.

And you still need friends to make cout << "something" and cout << 12 work.

>>383
Yes, operator functions can be free functions.

You don't need friends, since you don't need to access it.

>>382
Wouldn't it be wonderful to have a language that automagically discards that mind-cripple as the mind-cripple it actually is instead of compiling? I must be dreaming, there cannot be in any way such a language.

I meant you don't need to access its members, sorry.

Also, how is operator overloading an ugly hack?

>>383
vasnprintf doesn't exist as it wouldn't offer any extended functionality over vsnprintf.

strtok is just what it says it is, it extracts tokens from strings.

i always hated how C functions would write to a global static buffer.

just throwing that out there

>>383

Yes, you can write them as free function, and as templates as well.

Why do you think it is an ugly hack? Operators are simply member methods or free functions. If one can overload methods and functions, why can't them overload these operators?

Being able to overload them does not mean you must overload them in every situation. But there are many legitimate uses. Think, for example, if you had a class to represent a mathematical vector. You could, for example, overload operator * in order to make it work as a vectorial multiplication, and as a multiplication with a scalar. The correct one would be used depending on the context. In the end it's just syntactical sugar, really.

Again, you don't need friend for operating with cin, cout or any other class. You only need them if you need to access any private members. If you do, then you're either violating encapsulation (revealing an object's state) or actively developing an internal/library function (which inspects the object's state nevertheless).


#include <iostream>

class C {
public:
    C(int x = 0): x(x) {}

    int getX() const { return x; }

private:
    int x;
};

std::ostream &operator <<(std::ostream &stream, const C &c) {
    stream << c.getX();
    // If c.x was accessed directly, 'friend' would be needed.
    return stream;
}

int main(void) {
    C c(10);
    std::cout << c << std::endl;
}

friend declarations semantically bind the involved classes/functions into a "package" visibility (similar to Java). They're not intended to be used indiscriminately. They're intended to be used within the same library/package to give related (but otherwise different) classes another channel of communication, yet avoiding this channel to be exposed to the public.

The class should always expose in its public interface everything necessary to operate it, so that friend is not needed outside the package or library. This is not specific to C++, it's common OOP stuff.

>>385

How can the language determine what is and what is not a mind-crippled design?

If you ever find a solution for that, please share. (Really.)

Either way, it is not easy, nor the purpose of C++ or any language that I know, to prohibit the programmer of doing stupid things.