Why would anyone code anything bigger than tictactoe without using OOP...

if you keep studying harder you can get better at C

Yeah, C requires some discipline. But the fact that it has stood the test of time while Pascal and Fortran and others are now passé indicates that it's doing something right. And projects like Linux demonstrate that your claim is false. C can be used to create large, well organized projects.

Not everyone has been programming for years, nor has significant experience with non OOP languages. It's just a genuine question

Can anybody recommend me a good C++ book?

C will result in a lot more code on your part but C is not very high level when compared to C++ or Java, so C is very fast because it doesn't generate much extra machine code compared to what you've written (again, relative to higher level languages), and you have a lot more control over details like memory allocation

This is the most obvious answer, though Im sure theres other good books out there

Attached: 848e97226d031fb83c5294673fd463e4.jpg (591x722, 54K)

Thank you. I love you.

Attached: 1533524776253.png (598x192, 65K)

It's not even about incompetence, it's just that it was so heavily pushed in academia and by other programmers that it's become this monolithic, unquestionable truth to use OOP. OOP objectively does not solve the problem it was designed to solve, and all the nonsense built on top of it is busy work used to bandaid over the issues.
The simplicity, elegance and modularity of a procedural/functional approach just haven't been beaten yet.

This is a terrible book. Learn C first and then slowly apply different parts from C++ until you are no longer comfortable using more. Trying to learn all of C++ is just a waste of time (most of the features are anti-features. Don't use them).

>This is a terrible book
Why? I've never read it, but it has pretty good reviews and I've heard it's good for beginners and people who have been using CPP for a while

Here's what I know:
>STL
>All about classes
>Operator overloading
>Rule of 5
>RAII
>Generics/templates
>Polymorphism + Inheritance

Is this enough to stop digging into the C++isms and go about my life?

I wish academia focused as much on functional programming as it did oop, but I feel like certain things do lend themselves more to oop, such as game development

forgot:
>exceptions
>namespaces

>operator overloading
Wow you are such a genius, teach me.

don't be a faggot, just asking a question

Only retards don't use OOP
Don't worry, cs undergrads who wank about FP and dont learn OOP dont get hired

So I've mispoken, I have an older version of the book, and it showed when I read it. It was stuck in this weird place of being too technical for someone new to systems programming and too abstract to be easily comprehensible.

Go about your life and try to use those features. You'll find a lot of them just more effort than they're worth. Also don't use inheritance. The last thing you want to deal with in the middle of a tough problem is wrangling a topsy turvy inheritance hierarchy.

>such as game development
Even though it might seem like a perfect match it generally isn't. Games use Entities and large tables of them. When you structure things in an OOP way you tend to break down functionality of the game to the smallest level (being the object). That means that if you want to have the object interact with another object in any meaningful way you need to have it store a reference to it, or to fetch it from the object tree at runtime (it can't be passed to the update function of the object because the interface is fixed, if you use inheritance). You start to find that with all of the interconnected things going on in a game that your classes end up being bloated messes touching almost everything else in the game in highly mutable ways. Techniques were developed to address this, but they're almost as bad as the original problem (messages, routed events, etc). That's not even getting into the performance considerations that games have to take very seriously.

Im not the one bragging about something that can be learned in one evening

Who the fuck learns FP and not OOP? That's even worse than learning OOP but not FP.

Learning FP is far easier to start with and will make learnin OOP so much easier later on. Trying to teach yourself OOP right off the bat is stupid as fuck.

>using OOP ever

Thanks

Dude you're fucked in the head, I'm not bragging about anything, I was asking a question.

stfu you were bragging like a gay little faggot

The Linux kernel is the largest c project I can think of and there are a lot of guidelines for contributors. Good programming can easily exist outside of OOP.

>Hmmm guys should i stop learning? I know how to read, I can count up to 100 and i even clean myself when i finish popo.

except linux uses OOP

Absolute noob here, someone explain to me what OOP and FP is and the difference between them
I've read a bit and I'm almost tempted to drop java (which I just had started learning) for haskell

Attached: 1528051141882.png (645x729, 116K)

>drop java for haskell

Attached: 313a2d7d.jpg (961x648, 105K)

lol have you seen a large C++ project compared to a large C project? C's definitely gonna be a mess of macros and such but it's not nearly as much of a clusterfuck as C++ and it's retarded template system (at least retarded when abused)

honestly it's like reading a normal book organized into chapters (C) vs a choose your own adventure book where you have to skip around constantly to understand the story, i think most people would prefer the former

just learn C user, functional programming is a joke

Structs are OOP. C is OOP.

lol no

Functions are Functional. Everything is Functional.

>OOP objectively does not solve the problem it was designed to solve

It does though. It makes polymorphic programming through interfaces without boilerplate possible, and does so fantastically. Have you used Smalltalk or Common Lisp?

Fucking CS grads with their useless fucking academic languages.

>polymorphic programming through interfaces without boilerplate possible
Is this what OOP was intended to solve? I thought it had to do with code reuse, encapsulation and management of state as well as organisation of the code to allow for larger teams.

Large C project is 1000 lines though, C++ is actually big

Learn C#

To look like an engineer to the eyes of a businessman. UML diagrams particularly tends to give them a hard-on.

Amen

If you have no experience you don't belong in my project. Low entry barriers only lead to low quality software.

Sure functional programming normally is faster and when you're on your own it often is better.

But the biggest reason as to why it is the go-to standard in programming especially in the industry is about code reuse, organization and readability.

It doesn't matter if you can write a cool recursive function in haskell that uses 50 different instances of λ if the only person understanding the code is you. For a company that is just bullshit since not only another programmer who comes in after you, or has to work with you will need a lot of time to get into it more often than not even you as the programmer yourself will look at your clusterfuck of functional code and have no clue what you were thinking 4 years ago.

Functional programming should mostly be used only if there is no other way and the performance increase that it grants is absolutely needed (e.g. some drivers, trade market stuff, etc.) otherwise the company will lose more money for no reason.

You clearly haven't used either. In CL especially there's less bullshit in the way of you making actual, working code than basically anything else, the only thing holding it back is the lack of current popularity and poor GUI libraries.

But purely in terms of "how good is this at demonstrating what OOP can do", you'd have serious difficulty arguing that the CLOS fails to offer all the flexibility you could want out of an object system. If you actually want to argue why the CLOS is weak or inappropriate to the building of practical systems, be my guest and explain away.

>Is this what OOP was intended to solve?

Basically it is the single problem that it solves and everything else is tangential to that, in the sense that all the other aspects are either already possible in procedural languages as long as this functionality is added, or otherwise just naturally fall out of the extra expressability that OOP naturally provides.

>code reuse

This is possible and made much easier through things like mixins and traits, and so is made easier via the organization that OOP enables, despite the fact the C++ style inheritance is structurally dogshit that shouldn't be promoted for any reason aside from possible efficiency gains.

>encapsulation

Is a good idea, if taken in the sense the programming should be done through Liskov sustainable interfaces that don't lock you into specific behavior or representation, which is a good quality of solid OOP code. Aside from that, breaking things into modules that don't expose behavior can be done in C and a ton of non-OOP systems.

>management of state
Completely up to the programmer. Use databases, in memory arrays and hash tables, dynamic objects with crazy almost arbitrary behavior, neural nets, etc. Tangential to OOP except in that, as I talked about above, programming against Liskov substitute interfaces allows you to swap out specific implementations for others easily, which is the biggest boon it has.

Linux is 25M lines of code in C.

if you want a job, learn java.
learning FP (true FP not the milquetoast shit they're bolting onto OOP languages these days) will make you a better programmer but also make you resent everyone else.

Linux sucs

OOP literally fucks everything up. Everything.

Encapsulation fucks up cross implementation and ease of access.
Inheritance fucks up data locality, readability and implementation.
Methods over free functions creates design problems and hurts performance.
Large classes that leverage inheritance hurt when being passed by reference and value.
Objects favour awful design patterns like factories, and leverage heap heavy allocations first and foremost.

Virtual functions hit performance and abstract things too heavily. Maybe you can argue their shallow use for state machines.
Heap heavy per object allocation shit brings smart pointers to the table.
Constructors am delighted destructors can be implicit, offer no return value and further hurt performance when passed and returned through functions, as well as allocating them.

The o my thing people instinctively like about OOP is that classes are a glorified namespace that look good on the screen conceptually.

>Inheritance fucks up data locality,

Attached: brainlet.png (621x702, 56K)

>Why would anyone code anything bigger than tictactoe without using OOP
Because OOP is a terrible choice for large projects due to the inherent unmaintability of inheritance trees. Why are people still pushing the OOP meme when component based design is superior?

>Inheritance fucks up data locality

Attached: 8nRqoXW.png (800x729, 48K)

What's the point of anything other than C? I can imagine anything I want in it.
t. every engineer that is doing something worthwhile other than IT and computing

Where do you brainless assume the inherited data and functions end up

C does not have templates, which means there is no easy way to write reusable code which can work with multiple types. You can do some hackery with void pointers, but that carries a performance overhead. In contrast, templates are handled at compile time and there is therefor no performance overhead to using them.

Libraries and that's it.
You can only abstract so much on top of the assembly. Then you have the c+ case where you take it all too far. Like some sort like Scala CS phd orgy.

Inheritance is implemented using composition dumbass.

inheritance is a ZERO COST abstraction as far as data layout is concerned. The final class stores all the data in the same place. You think it has a bunch of pointers to superclass data?

You still have to compile it and parse it through dynamically.
The idea of generic programming is stupid anyway, you can't write catch all functions, and you're fucked if you do, you just don't know it.

It's easier to be explicit with a simple type trailing identifier on the function name and not have to guess with compiler implementations for doubles and floats and shorts and longs etc.

That's composition, not inheritance. Any language can do that.

template means standardizing
standardizing means potentially sacrificing some points where you could've done your own implementation that would've been faster
like doom did 3d but not 3d
I don't understand what you're trying to say? I'm going to spend more time to write it sure but it's gonna be better.
so some autist said "I'm gonna write my own language but other than C because I'm bored" and non-autistic small minds followed the trend, creating redundant languages, predestining anyone who wants to write software but isn't a professional programmer to create bloated crap pulling libraries with 200 functions for 1 single thing he could've probably written himself and be better

>I think it's better to copy and paste your code, changing only the type than to write a single generic implementation
Okay buddy. Enjoy writing your 100k line hello world program.

You can use template specialization and if constexpr to manually optimize templated code based on the template parameters.

>I don't understand what you're trying to say? I'm going to spend more time to write it sure but it's gonna be better.
A very simple example would be a linked list. The logic of a linked list does not need to change depending on the type of data you are storing. However, in C, if you want to use a linked list with multiple types of data, you have to duplicate almost 100% of the code (changing the type). Your way of doing it would have twice the amount of code and the same exact performance as a templated equivalent.

>twice
That's assuming two supported types. Obviously it scales linearly with the number of types you want to support.

struct linked_list
{
struct linked_list *next;
_Alignas(max_align_t) char data[];
};
you chose the worst possible example for templating, it's easy to make a generic linked list in C.
Instantiating a new function for every type won't gain you very much in terms of the optimizations you can perform using monomorphization but it will cost you a lot in i$ usage.

Templates let you keep track of information at compile time in pretty cool ways. Here is a compile time counter created with templates for example: youtube.com/watch?v=gI6Qtn4US9E

The same place as in where

Oh shit, I meant to post this video: youtube.com/watch?v=lCDA3xaLnDg

if you have Class 1 with members A, B, C and you have Class 2 inheriting Class 1 with members D, E, F then an object of Class 2 will have A, B, C, D, E, F all laid next to each other in memory

I don't believe that works. Can it even reduce from O(2n) to O(n) ?
This is what I wanted to say kinda. I'm not a big programmer but I know quite some C, so why use linked lists when you can just use structs connected with pointers, or better yet, just read/write your custom data type in binary.
As a non-programmer, I think there's a lot of overhead concepts in programming that make the job unnecessarily complex and mean different things.

>that s function in reality is only going to use two types
>Better write it so that it accepts everything!

Template edge cases are hell, especially when you're forced to use them.

as a programmer what you said is complete gibberish
a struct connected with pointers IS a linked list

>Better write it so that it accepts everything
There is literally no reason not to. It's 3 extra words you have to type and it saves you from having to copy/paste the whole thing. Wow, so hard.

>template edge cases are hell
That sounds like gibberish to me. Explain yourself. What is a "template edge case". Are you referring to template specialization? I've never had any problem with it.

>template metaprogramming

Jesus Christ I thought this was a joke.

Oh so I incorrectly understood the first user had implied linked lists were implemented in his language as a premade class. Cool. Are you feeling smart yet?

im just annoyed by the fact that you admit you dont understand something and then say something completely wrong and uninformed anyway

Meanwhile I just compiled a program which compiles and runs some C to generate more C to be used to compile the full program.

>compiled a program whose build process compiles and runs some C to generate more C to be used to compile the full program
fixed

You are obviously not running any sort of for-profit organisation, else you would not afford to stall a project due to unrealistic barriers.
>can be used to create
*to cherrypick code for decades and still end up bathed in unaudited modules (systemD).

Template hell is something like one function that takes two arguments and you throw in a double and an integer. But you reverse the order because templates. Now you have to catch both types based on where the user inserted them. It gets messy.

And that's just basic types. Lord help anyone when vectors and classes and multi inherited classes get involved. Get out while you can.

If you two don't stfu and kiss already

>But you reverse the order because templates.
What? You are going to have to show me a clear concrete example. I've worked with templates my fair share, and I have no idea what you are talking about. Most likely you are trying to use templates to solve a problem not meant for templates.

Exactly. I actually like templates, the problem is people using them as catchall functions.

In the end, cosf() makes more sense than Math.cos() at a glance.

I don't have anything against you being annoyed.
Please be annoyed. Go mad at the people not using exclusively C. Because anyone using anything other than C and using arguments for it like "b-but muh functional, b-but muh oop, b-but preallocating memory is time consuming and pointers are hard" is stupid, pampered and makes compilers puke out bad software.

All for-profit software is extremely low quality so thanks for proving my point.

It's nothing to do with the language

Do you have a shred of evidence to back up that horrible subjective opinion?

>pointers are hard. Let's exclude them from this language all together that I built on top of C
>what the fuck is an instruction pointer register

Existence of such a thing as an antivirus.

So we should all fall to zerodays or we should all be perfectly computer literate? Or do you think linux is flawless?
Linux is yet to prove itself (if ever) as a desktop OS. When normal people start using it and make passwords like "abc" or "1234", then fall to sudo, what will you do? Abstract away admin privileges?

*simple sudo malscript

How about the fact that visual studio, a program made to program on the biggest OS in the world, fucking hangs for a good 7 seconds on my fizzbuzz without fail

We should fix zerodays.