What makes C better than C++?

What makes C better than C++?

And what are the best C++ books?

Attached: 318C847D-501E-4309-A08F-66A75C2F9429.jpg (266x400, 10K)

Other urls found in this thread:

cpppatterns.com/patterns/rule-of-five.html
twitter.com/SFWRedditGifs

C++ makes it easier to write shitty code as it has many abstractions that make code easier to write at the expense of performance
On the other hand you have to know what you're doing in C or you'll be making a lot of stupid mistakes

lmao spoken by someone who has never written c or c++ in their life. Its literally the opposite.
c is simple and has barely any complexity to it, and c++ is filled with complex language features like move semantics etc that makes it hard to do simple shit.

If you're writing procedural code, use C, if you're using object orientation then you use C++
Both have their specific uses.
There is no x programming language is better than the other. Programming language is only as good as the programmer and to what is required to accomplish the task at hand. Just like choosing hand tools versus power tools.

this

>What is zero-overhead abstraction

Kind of a meme and hard to get right.

i cant give (You) text of best C++ book here:
C++ is shit, only namespaces is ok

Attached: MARKETING.png (886x304, 54K)

make copy of function for every type combination is not zero-overhead abstraction

I use C with C++ templates.
Best of both worlds.

>C++ makes it easier to write shitty code
Paradoxically, C++ also makes it easier to write formally correct code because it has stricter types, RAII wrappers and superior error handling than C.

You shouldn't do that, unless you need custom copy functionality to manage manually allocated resources.

cpppatterns.com/patterns/rule-of-five.html

Not really, I mean take Eigen or any decent linear-algebra library. Template-meta-programming (TMP) is used to generate expression trees, so you can have long chains of operations on matrices (e.g. E = A * B / (C + D)) condensed into a single loop which can even be unrolled if need be without creating any temporaries. I don't see how you could do that in C.

Thanks not how templates work. Concrete functions are only created when the template is instantiated. So if you only need foo(T var) to work with int and float, only 2 functions will be generated the same as you would have needed in C. The linker strips out all unused functions (which does slow link times, but once again this doesn't happen except with the most convoluted examples).

To clarify, the linker only strips out functions that have been instantiated, and for the given example only 2 instantiations would have been created (T = float & T = int).

I wish C++ would introduce modules, instead of relying on the archaic compilation steps with pre-processing and file inclusion, compiling compilation units individually and linking it all in the end. This is unironically what is holding sepples back.

Left: souless
Right: souless
Fuck chinks

>If you're writing procedural code, use C++, if you're using object orientation then you use C++
C++ doesn't force you to use OOP and you get a lot of other shit for free too.

I'm a noob who has only done a bit of C and has never touched C++.

But it's my understanding they're used for very different things. C is used for low-level shit, like kernels. C++ is used for applications, including video games for their game logic.

C, I would assume, allows for better low-level optimisation. But when you're making an application, C (with its lack of OOP) would be too impractical, and take too long, and be too much of a bitch. You need something more powerful that can get the job done quicker.

I know this is a basic bitch answer that you could get with two seconds of googling, but you asked, so that's my answer. Every language has different advantages and is best-suited to different situations.

>procedural code
I wish people would stop calling it this meme word. It's not a separate concept, it's just structured programming. You write the same way in most OO languages too, only you use "this" or "self" and member variables and functions a bit more. It's literally just structured, imperative programming. OOP is also "procedural programming".

They're coming in C++20.

Its tough for C++ to advance though, there's millions of lines of C++ code running at major firms and breaking backwards compatibility will never happen. I remember there being problems with some module related proposals due to the C++ standard not being able to define what a file is (related to some weird IBM filesystem).

I guess obscure platforms can be tricky. I've worked a little with C (not C++) on VxWorks in my current job, and it has no concept of dynamic loading, so everything (fucking everything) is statically loaded on boot, meaning that if you don't declare all your private functions as static, they are exposed for everyone. AFAIK there are no plans to support C++11 or newer on VxWorks though, but I'm just saying that there are a shitload of weird platforms out there, and if they also happen to sit on the committee like IBM does, then we're all fucked.

Speaking of committee fuckups, the reason the widechar abomination exists in C is because of Microsoft. Where every other OS implemented UTF-8 support, they insisted on their weird 16-bit encoding thing that never took off. Now that it's in the standard, it can never be taken out, even if Microsoft has finally left the C committee (there was no reason they should have been in it to begin with, seeing that Microsoft never made a C compiler that supported anything newer than ANSI C).

God damned, I hate these literal boomers holding everything back.

C and C++ performance (assuming your using -fno-rtti & -fnoexceptions (on non-x86 systems)) are at worst equal as most C code will compile as C++ (C++ is a superset of C90). No C feature past C90 really improves performance except restrict, which is supported in all major C/C++ compilers as a non-standard extension. Otherwise there are features that help C++ be more performant. A stricter type system in C++ helps the optimizer (unions can be used for type-punning in C but are UB in C++). Template meta-programming and operator-overloading can be user in unison to create highly-optimized routines using expression-trees that would be impractical to create in C. This is especially important when you're writing a library and can't foresee all possible uses of your library. A practical example of this is comparing BLAS routines and C++ linear algebra libraries. For common operations like daxpy or dgemm C++ libraries will simply call into a BLAS library which has the routine implemented in platform-specific assembly that's heavily optimized. Where C++ wins is when you need to do some series of operations that aren't directly supported as a BLAS routine. Here C++ can be used to generate (at compile-time) a heavily optimized fused operation which can often beat chaining together many disparate BLAS routines. Outside of linear algebra, another common use of this idiom is parser-generators. Modern C++ parser libraries like boost::spirit::x3 can generate parsers comparable to hand-written application specific parsers. So overall in theory C and C++ performance is equal but in real life C++ can often end up being faster than C (if its not just copy-paste the C implementation into your C++ code-base)

Please space your posts out a bit, that condense wall of text is overwhelming. Don't listen to the underaged faggots that automatically say "muh reddit spacing".

you sound like you've never written a line of code C lol

My bad.

Assuming your using a GCC based tool-chain (Clang probably supports this too), I'm pretty sure you can use the -fvisibility=hidden option which makes all functions non-exported by default and then mark the functions you want to export with:
__attribute__(visibility("default"))


It's kind of like the DLL experience without all the other DLL related retardation.

>My bad.
Appreciate it user.

>Assuming your using a GCC based tool-chain
Not on VxWorks, no. We use the licensed Windriver compiler. But a pretty nice GCC feature, thanks anyway.