Is C faster than C++? Or does C++ have too much utility over C?

Is C faster than C++? Or does C++ have too much utility over C?

Attached: c-and-c.jpg (600x315, 46K)

Other urls found in this thread:

youtube.com/watch?v=WLDT1lDOsb4
twitter.com/SFWRedditVideos

they're the same speed

C++ is faster in some situations.

As always, it depends on how you use each one that determines its speed. One is not inherently faster than the other.

The abstractions that C++ (STL/STD, boost) uses have some overhead. Obviously it's rather convenient to be able to use these established libraries, but if you really want performance you can try C. You probably won't notice a huge performance improvement on a decent desktop or server, but it'll be night and day on embedded or otherwise resource constrained platforms.

I suspect C++ might be slower to compile because of the amount of header-based stuff in the standard library, but at runtime there should be virtually (ha) no difference.

In practice, C++ could be even faster if you do something stupid in your own C implementation of, say, a container that is already present and implemented in the C++ standard library by people who really know what they're doing. I suspect you can optimize overhead away using C for a specific task, but then you can probably still do the same in C++ while being able to opt to use higher-level facilities where they aren't considered overhead.

++C is faster than C++ on older compilers. But that should be optimized out. But C is obviously faster since you aren't doing any operations.

This is all correct in my experience. I'd say for large applications where you're using containers heavily, C++ is generally faster. The STL is extremely efficient, but I'm not sure how exactly.

C's compile time is much faster than C++
but running speed is pretty much the same

Since C is mostly a subset of C++, C++ must be atleast equal in speed to C. Most C++ features slow it down, but theoretically some could speed it up. You can always ignore those features and write C++ as C.
The issue is that C strongly discourages using the heap. Indeed embedded code and safe code should avoid dynamic memory allocation wherever possible. If you need the heap, you can still use it (unlike, say FORTRAN which has no heap). Whereas every object in C++ is on the heap. This slows it down and is more unsafe.

>wanting speed and utility
say no more!

Attached: Julia_prog_language.png (1914x986, 50K)

Most performance boost cones from the compiler optimization. Unless you truly know what you are doing, the difference will be negligible.

lolwut

>meme language of the week

Is there even a straight up C compiler anymore? Both Clang and GCC are C++ compilers.

You can always overload your new and delete operators and choose your own allocation strategy though, there are examples of this as well as some custom container implementations based on it in Doom 3's source code

I'm a newbie using compilers, buuut... in some compilers you'll get an error if you use C++ features in .c files, so I'm guessing you can compile plain C by using a .c extension.

>Both Clang and GCC are C++ compilers.
incorrect
I don't know about Clang, but GCC is a C compiler. g++ is a C++ compiler
giving a .cpp file to gcc will produce errors

C is a sperg programming language, C++ is much more usable in the real world

Some people say that the C++ being a superset is actually overstated, and that compilation on C vs C++ can be heavily different for various situations.

It doesn't have anything with the extension of the file. you can feed it a .html extension if you want. what matters is the contents of the file
file extensions only matters to microsoft's c compiler because microsoft people are retarded

>You can always overload your new and delete operators and choose your own allocation strategy though

Learning this is when I went from "ahhh this kinda sucks" when first learning C++ to "nevermind this is badass"

Doesn't C++ fuck up productivity by pushing a heavy OOP'ing style?

Having a large standard library available is a far bigger boon to productivity than heavy-handed OOP is a detriment.

You can still by-pass it, only use OOP if you really need it.

I guess this is what we're getting at.
If you really just want to write C++ as C, is there any compiler/linker/performance base benefit to just using C?

Not really, the most OOP it pushes is having container objects you can call functions from, which feels more intuitive to me than having to pass the objects themselves as arguments to functions that exist by themselves in the universe.

Buuut it doesn't push you to use any OOP shit in your own code at all.

You're right. I thought this probably because we were using Code::Blocks in university, and this physics student was getting errors trying to build C++ code he found in a .c file, so I told him to just make the extension .cpp and it worked. It was probably an IDE thing, actually is what matters.

Attached: sorttime.png (605x340, 8K)

Why doesn't anyone ever update the C libraries?

C++ does have the ability to perform return value optimization, so you can just return a large struct instead of having to return it via a pointer passed in by the caller. Whereas in C, naively returning large structs will result in a copy each time.

No, because STL is implemented as a wrapper over libc. If you don't use any of C++'s special features, the result will be exactly the same as compiling with a C compiler, because all C++ related runtime libraries will be optimized away

>hurr default standard sorting algorithm is bad, therefore the whole language is bad

There's even an argument for free functions versus methods.

youtube.com/watch?v=WLDT1lDOsb4

What exactly would that help with? It doesn't have generics or templates.

You mean if the struct has move constructors and the like, or by compiler-based copy elision (or something like that)? This is an area of C++ where I get sooo lost.

It has nothing to do with the algorithm retard. It's literally the same sorting algo in c++

Pretty much the same, c++ tends to lose though because of the oop pajeets that use it.

Wait, STL is a wrapper for libc?

Just a classic code size vs speed tradeoff.

Because qsort() is meant to be generic, it performs a callback to user specified compare function for every compare operation. that's shit and obviously result in waste of speed. furthermore, qsort() is implementation defined, it's speed varies between different libc implementations greatly

In GCC, big part of it is implemented as such, yes.

NVRO has been around for a while. If you return a single variable in a function, the compiler can construct the variable on the callee's stack, and avoid copying the value when returning.

Qsort is not designed to be shit. It has to be because in C it has no way of knowing what is being compared.

So? just don't use it if speed matters to you.
next you are going to tell me blocking I/O is slower in C vs async I/O in C++

>Don't sort things if speed matters to you
OK thanks

Modern C compiler actually can inline function pointers.
Find an implementation of qsort in a header file and you'll get std::sory perf (and code bloat of course)

>I can't roll my own sorting algorithm because reasons

You can write the exact same C code in C++ but it's easier for std::* code to be optimised rather than random C drivel.

>implying anything you could come up with quickly enough to be productive could compete with qsort or std::sort for both small and large inputs

*higher is better

This and /thread

Let me guess. You never went to a university and all your programming knowledge comes from bootcamp?
Sorting algorithms are like the first class of algorithms in any algorithm course.
And if you think qsort() is necessarily implemented as quick sort, you are mistaken.

>quickly enough to be productive
>implying you need to do it more than once if you're smart about it
I bet you don't even shell-sort sub-collections when they reach size ~112 or so

The great thing about C++ is that it does its abstraction in a way the creates zero extra overhead compared to C. The abstraction is purely to make code reusable and more maintainable.

>if you think qsort() is necessarily implemented as quick sort, you are mistaken

That is precisely my point, it's not really trivial

And you think the people who wrote the implementations in the standard libraries didn't go to university?

tcc, 8c, you name it.

C++ can potentially be faster than C, all things being equal, since it provides more information to the compiler. The price to pay for this is longer compilation times, but once it's compiled, your program can be even faster.

>every object in C++ is on the heap
Wrong, user. That's Java.

g++ is some black magic but compile times are much worse

OOP is there if you need it, but it doesn't "push" it.
And using it properly won't "fuck up productivity", dumb teen.

its multi paradigm
you don't have to use oo shiet

More likely youll make some dumb mistake in the diy cpp std lib. and the cost of spending months tracking it down/ future maintenance would outweight raw speed

this, also C++ WAS a superset of C, but it doesn’t cover the C11 standard, and maybe also the C99 standard (I’m not sure about that one).
Considering this plus the fact some features were removed from C++, a legal C program can actually be an illegal in C++.

About the overhead thing, it is still possible to write most of the code in C++, and if you KNOW some C code will be actually faster than some C++ code, it’s still possible to call this C code from C++.
But I agree with you, it’s way easier to fuck up implementing in C something that already exists in C++ and is better.

No, explained GCC’s case, and clang is pretty similar since clang itself is a C compiler and clang++ is a C++ compiler. Try to feed a C++ file to clang and gcc and you’ll have some lovely compiling errors.

sepples can be oop, generic, functional, or imperative.

I like both the generic (see Alex Stepanov's A9 videos), or the functional approaches (like Eric Niebler's ranges).

modern c++ is faster. so much stuff can be optimized at compile time, the result is blazingly fast.

Attached: Ajax and Cassandra.jpg (993x2000, 664K)

C is better if you need to run code on very low memory usage and small disk space. like (dunno shit like arduino). you dont need a shitton of libraries just vanilla C. you code the rest.

based

brainlet

Compiling C is roughly an order of magnitude faster than C++.
There are a couple features that C++ loses out on. One of the most commonly used C++ data structures is the std::vector, which has to resize itself by allocating new memory and copying elements over. In C you could use realloc which possibly doesn't even need to copy anything over, since the OS can in many cases just remap memory pages.

That's actually not even true. Java uses escape analysis to decide whether it would be reasonable to put an object on the stack instead of heap allocate it, which is actually pretty neat.

>fegit

>this_is_bait.webm

What stops you from using realloc with C++?
Besides the same reasons you wouldn't use it in C either.

Attached: 1450659841952.jpg (300x411, 16K)

namespaces, templates, constexpr, smart pointers, move semantics and maybe more

C's qsort is shit because of the forced void * type erasure.

>Is C faster than C++?
sometimes
>Or does C++ have too much utility over C?
C++ has two good things. 1) because you no longer require forward declarations for what's called encapsulation (though this is a bit of a bad joke in reality), C++ code can have better memory locality for code, which can matter when data is access-bound. Largely: physics sims and vidya. 2) You don't need to make your own vtables.

The price you pay for these two features is unreasonably large, even in an industry where it is widely accepted that no benefits exist without costs.

Under normal circumstances, if you need something more expressively powerful than C there's few good reasons to stop at C++ but rather continue to go up to something like lisp, python, java, or heaven forbid haskell or ocaml.

Based and Cpilled

(C++ == C + bloat)

Attached: C vs C++.png (785x678, 463K)

Is this the new flavor of the month language? Last I heard people were all hyped on crystal or whatever.

>faster than
But user, do you mean compile time or runtime functionality?

you mean
++c == c+ bloat

C is ad-hoc everything, so in principle you can make shit at tight as you feel like investing time into, generally at the cost of readability and reusability.

C++ is a virtually true superset of everything above, plus idioms baked in via additional language paradigms and libraries. Also, the language is expanding fucking constantly.

A rough idea of how this works out is as follows: For every 1 mostly correct and performant way that exists to address some problem in C, there are perhaps:
- 100x ways to fuck something up with an unchecked error code, array index, or whatever
- 0.25x ways to do something actually really clever and fast, but usually completely
- ~1x ways to do the good C things in C++ by just using that subset of the language
- 3x-5x ways to do something correct in C++ that is not quite as fast as the C approaches but harder to fuck up
- 20x ways in C++ where you bloat things up via poor design or leak resources
- 0.25x ways in C++ to match or exceed the tuned C with the right algorithm presented to the compiler with a little more context to aid optimization, in a sane and readable way
- 10x ways to make something that executes around the speed of tuned C but is utterly incomprehensible due to being template and/or metaprogramming soup.

C allows you to "do anything", but in practice this boils down to janky preprocessor macro driven techniques to salvage any chance of code reuse and flexibility. C++ provides the opportunity for a smidgen more compiler optimization in theory, but virtually nobody is actually good enough to capitalize on that, and there are fucktons of mediocre programmers who just use the vastly expanded language to find exciting new ways to bloat and/or break shit.

t. professional sepples oldfag

nope. a well written C program runs usually around 20% faster than a well written, C++-like equivalent. Except when you rely on C library calls in critical functions, then using to the C++ template library will be a lot faster. Speed is usually not the most important factor, and it is much faster to work in C++. The standard library of C++ is a little bloated, makes it possible to solve a problem in many different ways, so you usually fix a subset and a style for a project.
kek'd

Wrong
std::sort is not (necessarily) quicksort.
It varies from implementation to implementation.
Usually it is a hybrid algo "introsort"
A comparison of std::qsort to C's qsort is more accurate.

I'm the user whose company moved to Crystal. We're still using Crystal and love it!

GCC is an everything compiler.
If you are talking about what it is written in, it is written in mostly C. They've allowed C++, but there is less C++ than C or Ada.

just use assembly you can theoretically do more with it than with c

We've been thinking about doing this too. We're mostly a Ruby shop right now. Any advice?

>Is C faster than C++?
Runtime?
When using a highly specialized compiler, maybe. When using C++ language features (classes etc), yes.
Compiletime?
definitely.
>does C++ have too much utility over C?
When writing C/C++ you almost always just want speed. If you need a lot of utility you almost always use some higher level language (at least for non-embedded)

C-niles actually believe this.

What's up with the single header meme all of the sudden?

A+

What if i dont have forever.