C++

I pointed out that you called C++ "unnecessary" in the same post where you said you prefer Python which is about as wrong as anyone could ever be about anything since Python couldn't even exist if without the C++ program that serves as its interpreter.
>Is that supposed to show that C++ is somehow less complex, or python more complex?
No, it's supposed to mean exactly what I wrote, which is that you're calling something unnecessary that's literally necessary for the other thing you said you like using in that same post. It's like if you wrote:
>Cows are unnecessary, I prefer eating hamburgers and drinking milk.

do you even English user?

"unnecessarily complex" is a totally different concept than just "unnecessary". Go back to grade school and read more books.

>Whoever you ask will say they prefer Java/python/newer languages over C++.

Stop asking /g/ ffs.

>Yet almost all advanced programs in game cheating and software in general are coded in c++. How come.

Because C++ is the language of smart people.

>do you even English user?
Well first of all, you meant to write "unnecessarily complex" because you were using it as an adverb, so glass houses / stones.
>"unnecessarily complex" is a totally different concept than just "unnecessary".
Second of all, the difference between "unnecessarily complex" and "unnecessary" doesn't really have anything to do with your problem here. Let me show you with this updated analogy:
>Cows are unnecessarily complex, I prefer eating hamburgers and drinking milk.
Your point is still wrong whether you phrase it as "unnecessarily complex" or as "unnecessary" because if it really didn't need to be as complex as it is then Guido van Rossum could've just picked a language that was less complex to write his interpreter for the Python language you like. And he didn't pick a language that was less complex. Do you know why he didn't pick a language that was less complex? Do you think he just wanted to use a needlessly complicated language because he prefers wasting his time on unnecessary details? You're wrong in the most blatant way possible, I don't know why you're even bothering to try pretending otherwise.

>The difference between "unnecessarily complex" and "unnecessary" doesn't really have anything to do with your problem here.
>Your point is still wrong whether you phrase it as "unnecessarily complex" or as "unnecessary"
I guess that's a no, you don't English.
Because if you did, you would've read my point about ABSTRACTION. I.e. the thing you do, in order to simplify things, remember? OF COURSE the language he wrote it in would be at least as complex, that's how ABSTRACTION works, idiot.

>if it really didn't need to be as complex as it is then Guido van Rossum could've just picked a language that was less complex to write his interpreter
You're conflating so many things here, I can't even.
Do you even know what Turing Completeness is? Guido could've written his language in whitespace or brainfuck for all anybody cares (and increased the complexity of maintaining it in the process), but it still has nothing to do with the maintenance/usage complexity of the language he created, only of the language he's using to write it. Nevermind that much of Python is actually written in a subset of Python itself anyway, which you don't seem to be aware of.
You're conflating usage complexity, with feature complexity, and computational complexity; all totally different kinds of complexity!

>And he didn't pick a language that was less complex. Do you know why he didn't pick a language that was less complex?
Gee, maybe because he was already confortable with the language he chose? Maybe because there weren't nearly as many options of languages to use back then? Maybe because he wanted to use a popular language in order to have more community support for it? Maybe other languages weren't performant enough at the time to run an interpreted dynamic language?

>Do you think he just wanted to use a needlessly complicated language because he prefers wasting his time on unnecessary details?
Because clearly none of the other reasons I stated exist. The ONLY, ONE TRUE plausible reason, is some bs about complexity.

>You're wrong in the most blatant way possible, I don't know why you're even bothering to try pretending otherwise.
I like that, I'm keeping that one because it applies so perfectly to you.

>And it's definitely not "messy,"
It's incredibly messy. It's almost a monument to how messy something could be.

When it's not a plethora of objective flaws it's a fever dream of inconsistent rules, effects and edge cases.

It's not "unnecessarily complex." If it were Guido probably wouldn't have picked it as the language to write his interpreter in. It is exactly complex enough to do a good job as a tool for accomplishing important tasks like making the Python language you like exist in the first place. Turing completeness is an inane non-argument here, that's like saying you could "technically" clean up the Exxon-Valdez oil spill with a toothbrush.

>Maybe other languages weren't performant enough at the time to run an interpreted dynamic language?
AKA It isn't "unnecessarily complex." It's exactly as complex as it needs to be to do what it does.

>yet it's the language that operating systems are made with.
The only operating system made with C++ is Windows. And it's a terrible piece of software with an endless amount of bugs and broken features.

Linus Torvalds refuses to use C++, the entirety of Linux is written in pure C.
It's like building a house entirely with a chisel and he's entirely right to do so because the alternative (a table saw) is a lovecraftian nightmare that makes producing something secure and consistent on this scale virtually impossible.

No, it's unecessarily complex. The features it has are rotten to the core with arbitrary, confusing and unpredictable side effects.

There's another language called Rust that 5 years into development has basically eliminated all of this.

>It is exactly complex enough to do a good job
That's a really naive oversimplification. Nothing is "exactly complex enough" for anything, it's either got the necessary features to handle a task, or not. Complexity is an emergent property of the commination of features some tool has, not some baseline quality that makes a tool magically able to handle a job.

So not only are you conflating types of complexity, but also conflating the causality that makes complexity emerge in the first place. Not surprising, but it is telling that you didn't acknowledge anything about you conflating things. Perhaps because the argument is going over your head?

>that's like saying you could "technically" clean up the Exxon-Valdez oil spill with a toothbrush.
That's the worst analogy I've ever heard. Abraisive mechanisms like toothbrushes aren't even meant to suck things up, much less oil, all they do is spread it around. In order for your analogy to have made any sense at all, you would have to be able to at least clean up a small bit of olive oil from a table top using a toothbrush and no soap, but good luck with that.

This is trivially refuted with other less complex languages that are equally as fast, like OCaml or D. Hell, even Java is about as fast as C++ now, and none of those are nearly as fragmented as C++.

And asm**

It has also eliminated much of the flexibility that makes it easy to do many things in C++ that are very hard in other languages.

>clearly doesn't know rust

>mfw retards on this board think C is low level

>He doesn't know what low level means.

c++ is a feature rich language, i think most of the people who tote it to be "complex and messy" feel they need to know every single dusty corner of c++ to be proficient with it, this is not the case.

>People call c++ obsolete and "complex and messy".
Literally who? Web devs, java pajeets?

Lol no it's not the mainline interpreter for Python is called CPython for a reason.

>mfw a retard posts on Veeky Forums
For the record, I've done assembly, I've designed processors for FPGA, and I've designed PCBs to put the fucking FPGA on, C is low level

And I guess you think that the varieties of ASM aren't massively abstracting individual machine architectures even more greatly?

>muh advanced game cheats

Fuck off op

>Hur durr lets argue about what low level means

"Low level" is a relative phrase you fucking niggers.

>2017
>Veeky Forums shitposts are more eloquently written than presidential statements

>And it's definitely not "messy,"
As someone who writes (and likes to write) c++ every day, it is very messy. Starting with stuff about ~10 different initialization types (value, default, direct, copy, default, list, aggregate, zero, constant etc), Koenig lookup, auto rules, SFINAE and general TMP hell, most vexing parse and some overload resolution rules. Try explaining why you need perfect forwarding, which entails a talk about reference decay and value categories (glvalue, prvalue and others). Move semantics are damn great, though.

Oh right, forgot about allocators in std (does anyone even use them?)

Python is a language.
CPython, a Python Interpreter, is written in C. Not C++

With c++ you do much of the busywork yourself, with java/python you ask a negro to do most of it for you. Depending on the job and your ability to do it, either of the languages may be a good choice. The usual argument for C++ is that it allows you to optimize some things in a way that interpreted/VM languages don't. Additionally, a launguage that compiles to machine code is a necessity for the interpreted/VM solutions to work in the first place. How C++ fares against other languages of this type is a topic for a whole other thread. Comparing C++ to java or python is like comparing a set of garage tools to the facilities required to make those tools.
Does everyone need to have a forge so they can make their own hammers? Probably not.
Could anyone even have a hammer if forging wasn't a thing? Definitely not.

idk lol i do everything with haskell

so much this

It is an ill defined word that changes depending on context.
Compared to Haskell, C is low level, compared to designing the circuits yourself it isn't.

cpp is vile shit. i prefer older languages like lisp tho. Really not that many programs are actually written in c++.
harmful.cat-v.org/software/c /linus
harmful.cat-v.org/software/c

nice reading comprehension budy

that's pretty terrible. depending on how the os/hardware does memory management, won't malloc sometimes return a valid pointer even when the requested chunk of memory is bigger than the physical memory?

I'm probably in a minority, but QSAM and COBOL were easier for me than C (granted when I learned C it was a very small lecture thrown into a hard assignment)

it's easy to write sloppy C code. the language is so small you can learn it pretty quickly if you have previous coding experience. not as easy to write good C though.

C code is pretty much string functions and printfs mixed in with some integer arithmetic and structs to hold your variables/pointers.

the difficulty comes from C's lack of built-in functionality/features and of course manual allocation and freeing of memory.

C++ is a great language imo, and usually the better tool for the job.

I don't manually allocate memory. I only create variables.

half the larpers in this thread complaining about C++ probably couldn't write airtight C if their life depended on it.

>the difficulty comes from C's lack of built-in functionality/features and of course manual allocation and freeing of memory.
Not true at all.

The real difficulty from C comes from the fact that you are writing code that can deal with out-of-memory conditions in a non-catastrophic way. If you are writing C without that constraint, you can make everything a shitload easier (you can just have a `string` typedef, and functions like `string string_concat(string a, string b)` that behave pretty close to what you do in other languages). And conversely, most higher level languages, even C++, come crashing down as soon as out-of-memory is something you need to be able to cope with.

C is not annoying because it is a low-level language. Hard-ass paranoid crazy-prepared code is annoying in any language, and C is annoying because it is a language optimized for that use case.

>The real difficulty from C comes from the fact that you are writing code that can deal with out-of-memory conditions in a non-catastrophic way.

ah, i see what you're saying. yes, i've never really had to write code with complex memory-related logic. that's something of a special case though.

In terms of language, yes it is. But in terms of how you use it, it is not -- the way you actually use C++ has little to do with the way you actually use C.

C++ can be seen as an extension of C that sacrifices all the focus on design that makes sense when memory may not be available. A + operator on strings doesn't really work if memory might not be available, for example -- it needs to be able to report OOM conditions, which means the API is not suited for that constraint. (Theoretically C++ has std::bad_alloc for this, but in practice very little C++ code is written to such a standard, and I for one would not even rely on the standard library to behave correctly in this situation. And as soon as you are writing C++ code that DOES deal with std::bad_alloc correctly, it immediately becomes almost as painful as writing C.)

>Whoever you ask
people on /g/ are not "whoever you ask". go outside some time.

interesting. is this typically even a concern for most userspace software though?

>ah, i see what you're saying. yes, i've never really had to write code with complex memory-related logic. that's something of a special case though.
I am not talking about complex memory-related logic.

I am talking about the situation that, whenever you want to do something as basic as concatenate strings, you need to (1) malloc the new string, (2) check whether it succeeded, and (3) do something sensible if it failed.

Which means that every time you want to concatenate strings, you need to think carefully about the consequences. Whereas in C++, you just write `std::string a = b + c;` without a second thought. That is not because C is painful -- rather, your code becomes painful because in your C code you care about OOM-situations, whereas in your C++ code you don't, and your program will just happily crash on OOM.

I am claiming that if you don't actually care about the OOM option, you could very easily write C in a style that gets rid of 80% of the pain. But the C standard libraries, and nonstandard libraries, are generally not written that way, which makes this approach quite limited in practice.

You could make a dialect of C that is *exactly the same language*, except that all library APIs are designed around the assumption that malloc() doesn't fail; and that dialect would be much nicer to write in than standard C, for those cases where in reality you don't care about OOM. I think that dialect gets you halfway to C++ already -- half the reason that C++ is less annoying than C lies in this fact, I think.

It's a major concern for lots of server software. If I overload a webserver with more requests than it can fit in memory, it MUST NOT blow up the entire webserver -- rather, it must handle all incoming requests with error messages, carefully designed not to use any substantial memory, until memory pressure subsides.

This is why lots of server software is still written in C in 2017, whereas user apps rarely are.

>It's a major concern for lots of server software. If I overload a webserver with more requests than it can fit in memory, it MUST NOT blow up the entire webserver -- rather, it must handle all incoming requests with error messages, carefully designed not to use any substantial memory, until memory pressure subsides.

i don't see why you couldn't accomplish this with C++.

See . You CAN do this in C++ if you want, by handling the std::bad_alloc exception correctly. But (1) the majority of libraries for C++ are not written with this in mind, and will blow up something somewhere on std::bad_alloc; and (2) when you write C++ like this, it becomes almost as cumbersome to write as C, for you need to carefully design your code paths in such a way that every other line might blow up on you and you'll need to cope.

Writing C++ that does the sensible thing for each possible case of std::bad_alloc is difficult, and maintaining it is trickier still. Unlike in C, you can't easily see from a chunk of C++ what operations can and cannot throw std::bad_alloc, and it is VERY easy to forget to clean up something you started earlier if a std::bad_alloc happens at an inconvenient time you hadn't thought of.

It's not impossible. But it takes a level of care and discipline that empirically few people can manage -- just like how avoiding buffer overflows is totally possible in C as long as you are perfect and don't fuck up. The language provides very limited help in making sure you never forget to be sufficiently careful.

>But the C standard libraries, and nonstandard libraries, are generally not written that way, which makes this approach quite limited in practice.

i'd like to see a good example of this. i've never done a serious project (>~5k lines) in just C. beyond checking that the pointer returned by malloc is valid, and cleaning up and exiting if not, i don't know how OOM errors are usually handled. i'm sure it's highly dependent on the context, but if there are any good examples i'd be interested in seeing them.

C++ is just C with training wheels, a fluorescent safety flag, dual rear baskets, rearview mirrors, and handgrip streamers. Who needs all that silly shit?

>advanced programs in game cheating
>why does a subject heavily reliant on code injection and and memory manipulation use c++?

>It seems that python works wonders for the basic and small things, but when things getting complicated, then c++ takes over.
for performance (systems, game engines, real time applications, interpreters for higher level languages) you want as much optimization as possible but you really don't want to be fucking around with memory and low level shit if you can avoid it
hence higher level, "safer" languages exist so you don't have to constantly worry about boilerplate and memory issues.

also obviously the best language is whatever industry you're in has the most support for

C++ didn't just add little details, unless you consider the existence of classes a little detail.
If you don't understand why having classes is useful your programs probably aren't very complicated. And if you do understand why that sort of programming is useful and are using C for your work anyway you'll probably end up reinventing C++ to make that sort of pseudo-class organization work.

good to know. but i don't think it's fair to say that the main difficulty of programming in C comes from having the option of handling OOM errors more robustly.

the main difficulty is that it's a small, low-level language.

even if C is more common for programs where you have a specific way OOM errors need to be handled, C is still a general purpose language.

C++ is probably the most complete low level language out there.

It means that you can program anything with it, basically.

I believe most programs will fail miserably when malloc fails. It's one thing to check its return value, it's another to rollback cleanly and do something clever. These cases are almost never tested.

At least, with a std::bad_alloc, RAII will help three all resources. In the end, the program will also fail, but at least the code won't be littered with return value checks that hide all what really matters.

Btw, on most linux systems, malloc almost never fails. The kernel always reserve some memory pages when asked, and only when you access these pages, finds some real RAM. If no memory is available then, some processes are killed.

Source: 10 years of C and C++ dev in non critical applications. It's probably really different when lives are at stake. Hopefully.

Is c++ the ultimate brainlet filter.

>When they tell me they want to C but I give them The D.

What's the best book to learn C++ as a beginner?

Testing op for level of idiocy:

If FOO is First Object Oriented. . .

>Renne Descartes
>69
>That file name

A-user...
That isn't a series number is it? I refuse to believe autism like this exists...

learncpp.com