i know that C is used everywhere, populated by GNU/Linux community,

File: 1488048860312.png (12KB, 420x420px) Image search: [Google]

12KB, 420x420px

>white """""people""""" attempting to dance

>>61029142
That man knows how to have a good time

>>61029211
Fuck off, nigger

>>61029142

https://www.youtube.com/watch?v=EW-uwNivPvw

>>61029653
White people has no culture.

>>61029142
>some embedded system programmers still tend to flinch of C++

That's only because they don't understand the language, or how it gets compiled to machine code.

Some C++ features introduce extra run-time overhead, and some don't.

No embedded system programmers should have any problem with C++ features that don't generate larger or slower code (over what the equivalent C code would generate).

The ONLY exception is if they are concerned that they might need to port the code to a platform that doesn't have a C++ compiler -- which was a valid concern 20 years ago, but is very rarely a realistic concern anymore.

A whole bunch of C++ features like constructors, namespaces, overloaded operators, etc. are absolutely free -- there's no way the equivalent C code could ever be more efficient. Obviously, things like std::string and std::vector are both larger and slower than C strings and arrays -- and if speed and size are important, then don't use them.

Clearly, if I was packing and unpacking bytes in a communication protocol, I would absolutely not use std::string or any other STL feature. But if I was programming a touchscreen GUI interface for an embedded system, I might consider using std::string for its nice features (overrun protection and automatic buffer management).

It's not really that hard to learn which features to avoid and under what circumstances to avoid them. It all becomes obvious once you see how the C++ features are compiled to machine code. Any embedded systems programmer with more than about 5 years of experience should know all that anyway. Seriously, how hard is it to occasionally compile with "g++ -S" and take a peek at the assembly code to see how each language feature is implemented?

>>61029142
>is it going to be as fast/faster than C?

C was specifically designed to have a very fast, natural translation to machine code. I actually can't think of any language feature in C that could be redesigned for faster or smaller machine code.

In fact, a lot of the complaints against C are because it focuses "too much" on fast machine code at the expense of ease of programming.

To take one example of many -- C uses the longjmp() function, which is pretty much the fastest possible way to exit out of several call levels at one time -- at the expense of possibly skipping over necessary clean-up code. When other languages implement SEH, they almost always solve the "clean-up code" problem, which ends up generating bigger and slower code -- as compared to C's dirt-simple longjmp() approach.

C's design style was basically: design it in the way that generates the fastest, smallest machine code. So obviously it's not going to have garbage collection, or array-bounds-checking, or anything like that. When you have a language designed that way, it's pretty hard to beat for performance. It's generally acknowledged that if you want anything faster than C code, then you need to drop down to assembly language.

>>61030537
duuuude, I actually know that C folks are morons claiming that C++ has overhead by default and its not removable, I asked about Go

>>61029986
at least they are people.

>>61029211
No one dancing there is white. And what is white anyway? What is not black? Fuck off nigger

File: 14534484454.jpg (10KB, 280x210px) Image search: [Google]

10KB, 280x210px

So this... is the power... of loonix

File: 1498162895195.jpg (80KB, 600x594px) Image search: [Google]

80KB, 600x594px

>>61029142
FREE AS IN MONEY

>>61029142
>golang
I don't like google botnet

Go is slower because it adds extra abstractions ontop of c and has garbage collection. A garbage collected language is always slower by default then a non garbage collected language

>>61029142
>maybe some day it will catch up with C.
Who knows. If you need a language faster than Go today, there's Java (HotSpot). If don't mind the JIT warm-up time and the RAM usage, just use Java.
>built-in concurrency
Go definitely wins this one, but Java is a close second thanks to http://docs.paralleluniverse.co/quasar/.
>slices
Java has generic Lists, Streams and a bunch more.
>platform independent code (in most cases)
Yep.
>packaging system
Go's is pretty bad. Maven does everything properly.
>many web packages
Java has tons more of every kind of package. The average quality is higher, too.

>>61029142
Do you think the Stallman wants to fuck gnus?

>>61029142
still slow

>>61029142
And it has to beat Java first in terms of speed

>>61029142
rms dances so weird

>>61030537
>std::vector is slower than built in arrays
use std::array for built in arrays. even then, performance difference will be incredibly small
>STL
standard library pls

>>61029986
>>61029211

F A L S E F L A G
A
L
S
E

F
L
A
G