can't you write c++ code just like its c and ignore anything exclusive to c++ anyway?
what's with the anti-c++ seethe? i don't get it.
 Nothing Ever Happens Shirt $21.68 |
 |
Nothing Ever Happens Shirt $21.68 |
do you have any advantages over c++
can't you write c++ code just like its c and ignore anything exclusive to c++ anyway?
what's with the anti-c++ seethe? i don't get it.
Nothing Ever Happens Shirt $21.68 |
|
Nothing Ever Happens Shirt $21.68 |
C++ is like a range
You have C, C with classes, C with classes and generics, C with ... ..., and finally unreadable garbage.
As time goes on, most C++ programmers tend towards unreadable garbage because the language will add every random thought the committee has and never remove anything because of "backwards compatibility"
C has been very consistent, and most C projects mainly differ on standard and style, but the code itself remains readable.
Damn that is fpbp.
I'll add this: "you can implement the same solution in C++ as C" is technically correct, but that's not what people do. They use objects and libraries of objects and frameworks of objects. Sometimes it's beneficial to sit down with plain old C and think about the solution. C tends to force you into more efficient solutions.
c++ adds a ton of complexity
and if youre of the visualizing type its much easier to see everything as raw pointers
another thing is that C-ultists *need to be good at interfacing (since youre writing everything from scratch in C)
so volens nolens C users become good at code and language ergonomics.
and C++ wasnt designed with that in mind it seems. + the decades of design by commitee...
C on the other hand, by design or accident, offers just the right degree of abstraction visualizing types like and thrive in.
also since it very simple syntactically its easy to build analysis tools generate code or even extend the language
and finally since its widely accepted as being the right dose, and being well known and well established, it is used for things like cuda and opencl so its also a gateway drug for serious compute w/o having to deal with shaders directly
midwits get filtered by templates and decide to stick to their beginner's language indefinitely. The only thing they ever manage to accomplish is to rewrite fizzbuzz a million times.
>needs formalized iterators, constructors etc
lol
youre the rust of the 90's Black person
and like rust you end up coding c anyways wherever any amount of speed matters.
midwit response. templates are tools that can be used to make your C code slower, or they can be used to make it faster. how to do one or the other comes with knowledge and understanding. Just because you can't program c++ properly doesn't mean others can't.
yeah but you drop the iterators and the rest of the bloat
nice deflection. but you gotta do better scrub
Basically no reason to use C over C++ for most projects. Even if you don't like modern C++, there's a lot to gain simply by using templates and constexpr.
>Templates are le hecking slow
They are compile time only, so that is cope. Only way they could be slower is if you are incompetent and use templates where there is no reason to use them, possibly bloating executable size.
C++ is at least as fast as C, if not faster, if you are competent.
>C++ is at least as fast as C, if not faster, if you are competent.
duh. not only you can pass straight up C to the compiler but you can write asm in both.
BUT
you cant have the same degree of speed using high level abstractions, thats just how it is
and thats exactly why you can pass C to the compiler. or inline asm. or write C++ but use raw pointers where performance matters
>you cant have the same degree of speed using high level abstractions, thats just how it is
`std::sort` is faster than qsort.
*facepalm
go back to cs 101 anon. or do a bootcamp or something
cant help you rn, i gotta do the groceries, theyll close the supermarket in one hour and im not baked enough to be in patient teacher mode yet
feel free to come back in an hour or so.
and hopefully you will have the grace to google "definition of algorythm" and "definition of abstraction" until then.
its like with crabs.
>my language is so safe
yeah but it comes with runtime cost
what if your code is 2% input and everything else is computing?
why should i have all the red tape in the way? why should i even fill my head with that?
with c++ tho, its just that i dont like the interfacing. and it outweights generics which are the only thing i would take advantage of (at the scale of max 5% less code to type)
(and my memory objects are wild. i just dont have use for standard solutions)
What runtime cost are you talking about? I'm talking about using C++ in a Data-Oriented Design way, making use of templates and constexpr, trying to minimize the use of the heap as much as possible.
nah, that part was about rust
but yeah i dont say that you cant do a good job in c++
im saying that since C is so simple, you can just tune out and read the code without actually reading.
you dont really register individual letters, or the syntactical symbols, but see the whole keyword as one symbol
(thats why C-ultists are also anal about code formatting. a different syntax throws off our reading of the code)
i mean... i can be baked af and still do a good job in C.
C++... other high level languages... python... not so much.
>im saying that since C is so simple, you can just tune out and read the code without actually reading.
>you dont really register individual letters, or the syntactical symbols, but see the whole keyword as one symbol
>(thats why C-ultists are also anal about code formatting. a different syntax throws off our reading of the code)
This is why I get sick of a billion different features in languages. At some point it makes the code less readable and harder to maintain.
its the same pain, brother
python is the perfect example:
at its core its dead simple
but you have so many inbuilts and that youre constantly looking up things in the manual
and when you factor in that proper use of python passes through a heavy use of libraries, the surface of the problem literally squares...
I agree. Yeah, it's not hard to write slow code in C++ because of the overuse of STL containers which require use of the heap. But if you know how to use it well, then it's a lot easier to write fast code quickly.
depends on the code
depends on the person i guess
recently i was working heavily with strings
an easy optimization is to allocate the strings in multiples of 8 so that you can utilize the whole width of the data bus while losing on average somewhere around 3-5 bytes per individual allocation
BUT it opens a whole lot of optimizations, like, for starters you divide the search for null termination (or any char for that matter) by 8
correct me if im wrong, but that precludes using everything the STL could create, no?
and since its not written with 8-byte bound strings it doesnt leverage a whole class of optimizations you can use otherwise, no?
bc in C, with this simple trick i can throw sting.h into the can, kek
Literally every step container that could allocate does it through user provided allocator. Implement for 69 bytes aligned allocator, typedef a new type and you are good to go - everything else just werks. As for searching for null terminator - it's such a c moron problem.
really, with how i code (and admittedly, im still learning) i end up using homebrew libs for everything save for basic output, error handling and obviously syscalls
actually, now that i think of it
i could just write a shim over malloc and force it to allocate in multiples of 8.
i think.
and if that werks i could just youse string.h as is
but yeah, i still wont have bus width opti
BUT at least i could use string.h-originating strings in my program without any further cost
heh, that sounds lie something useful to know
()
>i could just write a shim over malloc and force it to allocate in multiples of 8.
Just divide the length by 8, process that much of the string in 8 byte chunks, and then process any remaining bytes 1 char at a time. You don't need to redefine malloc which could have potential side effects you're not aware of. Just integer divide and % the remainder.
a) i can do that but what if your strings/patterns are on average < than 8?
b) libc c already does that, no?
but yeah... side effects, youre right.
there might be a way to maybe redefine malloc just within the scope of string.h and its lib
and maybe its side-effectless...
maybe. kek
wont prevent me from shimming malloc tho
esp i have the distinct impression that i saw a vid on israelitetube where a guy does exactly that in the process of demonstrating how malloc works
i never needed to explore that kind of shenanigan, but again
this shit comes handy
recently i learned how to write self modifying code in C so in absolute, i already know how to do it the dirty way (i learned it recently)
(and its fricking trivial bro, i never imagined you could make C do and, and epecially how fricking simple it is)
Templatized code vs the handwritten equivalent has no performance difference as far as I know.
Templates (static polymorphism) really shine when compared to inheritance and virtual functions (dynamic polymorphism) because the compiler knows upfront what all the types are and can make all sorts of contextual optimizations accordingly. People often talk about the performance penalty of virtual functions in terms of dynamic dispatch, vtable lookup, and function pointer deference. While these concerns are factual, they are negligible when compared to the true cost of dynamic dispatch which is actually the forsaking of all the compile optimizations that static polymorphism capitalizes on.
C++ templates are so horrifically crippled, using them is suffering. Things that should be simple are either almost impossible requiring extreamly complex contortions, or totally impossible.
fair, but they're a dream when you've gotten good at c macros.
you are the biggest midwit of all for thinking that tolerating complexity makes you intelligent
>The only thing they ever manage to accomplish is to rewrite fizzbuzz a million times.
Why does fizzbuzz live rent free in your head?
>or they can be used to make it faster
Please demonstrate how your templates allow you to be faster than just using C.
>Please demonstrate how your templates allow you to be faster than just using C.
Sure, loop fusion through expression templates for linear algebra.
How do you achieve that in C?
You have avoided the demonstration.
I quoted a claim to make things faster, not how to make things possible. Any other advantage you present is irrelevant.
To defend the claim, please post code written in C. Then post code, that does the same thing, that is faster with templates, that could not have been faster with C alone.
>expression templates
> yeah, well use this C++ specific feature then!
Please demonstrate how your expression templates allow you to be faster than just using C. You can do this by posting C code. Then posting the same code, but with expression templates, and faster.
Uh no, buddy boy, that's not how it works.
I'm telling you "here's a C++ library that achieves loop fusion through expression templates (eigen)". Now you show me how you do that in C. If you don't understand expression templates or what loop fusion is, say so.
>I quoted a claim to make things faster, not how to make things possible. Any other advantage you present is irrelevant
Loop fusion is about making things faster. It's trivial to make gemm functions in C and compose them by successive calls, but it's gonna be slower because you have to materialize every single intermediate result.
That is precisely how demonstrations work, you barely literate monkey. You're far dumber than a midwit, as a midwit at least, could usually understand simple directions. If you believe you have a way to make things faster, then you can show it by posting both versions. Here I go again, explaining how to demonstrate to a simpleton:
1.) Post C code
2.) Post C++ code which highlights how templates have made it faster.
Stop trying to abuse the fallacy of shifting the burden of proof, moron. It's not going to work.
>burden of proof
the most midwit concept of all. you could google any of the things anon listed and make yourself more knowledgeable. Instead you're trying to assign him homework like some undergrad professor.
>the burden of proof is the most midwit concept of all.
Lacking a basic understanding of fallacies does not place you above the midwit. It places you below them, nitwit.
You're dumb m8. What would me posting C code prove? You would complain that it's not written well enough.
As for the C++ code:
constexpr int pb_size = 1000000;
MatrixXd m1 = MatrixXd::Random(pb_size, pb_size);
MarrixXd m2 = MatrixXd::Random(pb_size, pb_size);
MarrixXd m3 = MatrixXd::Random(pb_size, pb_size);
volatile MatrixXd result = (m1 * m1 + m2) * m3;
Looking forward to your C implementation of a matrix library that performs as fast, since you seem to have very clear ideas about burden of proof.
nta, but
>What would me posting C code prove?
thats how the process of supporting a claim works, you goof
you post your process so that it can be peer reviewed
what do they teach you in schools nowadays?
>thats how the process of supporting a claim works, you goof
No it's not. It's not on me to proce the efficiency of C. If you claim you can do as well in C, you're the one who has to demonstrate it. It's simple enough for a child to understand.
>No it's not. It's not on me to proce the efficiency of C
no it isnt, indeed.
because the claim was its INefficiency.
also, arent intrinsics gonna beat any syntactical solution you could cook up?
I don't see any C code in those posts so I'm not gonna read them.
Burden of proof, remember?
im not that anon, you disagreeable goof
thats what nta means. Not That Anon
>im not that anon
Then stop talking? Either support a claim or shut up.
my claim is that intrinsics are faster than portable syntax.
turbo-duh, you goof.
do you want a proof for that one too?
>my claim is that intrinsics are faster than portable syntax.
A trivial statement that nobody contested. I'm gonna assume we disagree on the implications of that statement, but I'll let you dig your own hole.
>A trivial statement that nobody contested
fricking hopefully
or maybe not
if anybody did it would have made outing them as midwit so much less work-intensive.
bc i genuinely only heard about gimm before this discussion
its gonna take me a couple hours or more to concoct something passable
(im self taught. i learned how to write self modifying code before i wrote my first library. sometimes its not the most efficient approach, but certainly its the most interesting one)
correct me if im wrong (bc i dont wanna code the right program for the wrong assignment)
gimm is generalized matrix multiply-
an algo that does genertalized matrix multiplication, right?
bc it seems that google is throttling my search shit or something
the only mentions of gimm i had was in the opencl context
and when i went beyond- no more relevant search results... (i work with opencl too. it deliberate throttling would explain why i dont get results in other contexts)
>>>GEMM
disregard previous post, im distracted.
also yeah
now i get the thing
so all i could do is optimize hardware-wise
i could pack your operations in intrinsics. big fricking deal
youre gonna make me learn intrinsics, now, arent you?
Not sure we're on the same page here, so let me explain. Writing an efficient gemm (i.e. matrix multiplication) using intrinsics and proper tiling and returning through registers is a complex problem in itself, but it's perfectly doable in C. I'm talking about something completely orthogonal. Where the problem arises is when you're trying to do composition, as in my C++ example above.
Instead of
volatile MatrixXd result = (m1 * m1 + m2) * m3;
you could write something in C like
volatile double *result = cblas_dgemm(CblasRowMajor, cblas_dgemm(CblasRowMajor, m1, m1, m2, etc.), m3, etc.);
Or, with intermediate variables for clarity:
double *inter = cblas_dgemm(CblasRowMajor, m1, m1, m2, etc.);
volatile double *result = cblas_dgemm(CblasRowMajor, inter, m3, etc.);
The problem here is you need to fully compute the result of the first cblas_dgemm call (even if it's unnamed) before you can pass it to the second call. Which means a lot of moving memory around, and missed optimization opportunities.
Whereas the C++ eigen example will compute the result matrix directly in one go, through the use of expression templates.
yeah but you can inline all of it and call it a day.
it depeds on the processor and such
but on modern hw instructions space is hardly a problem, in most of cases. i think.
again, im no authority in the matter.
(i do my shit and its good but i cant tell you how to do yours better)
>yeah but you can inline all of it and call it a day.
That doesn't solve the issue at all!
You still perform each matrix multiplication sequentially.
It's called "loop fusion" because what happens is, schematically (for two successive additions)
naive solution:
for (int i ...)
for (int j ...)
inter[i][j] = m1[i][j] + m2[i][j];
for (int i ...)
for (int j ...)
result[i][j] += inter[i][j] + m3[i][j];
with loop fusion, the code gets transformed into:
for (int i ...)
for (int j ...)
result[i][j] = m1[i][j] + m2[i][j] + m3[i][j];
all of it is syntactic sugar doe
if you wanna be anal you can use C's vla's to store data for really large matrices
you literally cannot do that in c++
>all of it is syntactic sugar doe
lol, no
show me how to do it in C.
You don't understand expression templates.
>show me how to do it in C.
i would have to write a benchmoorker i am not sure i even could, reliably, to test how much cache is available
OR
to spend n times the time to write something that would probe your cpu the right way
its all based on cache
and the difference would be in how much i could fit in yours
No, no, tiling optimizations are not the point here. We're always talking about matrices too large to fit in cache anyway.
I'm not asking how to micro optimize a single operation, but how to perform automatic loop fusion. It's a question about code structure, not CPU arch.
yeah
but then were talking syntax
->syntactic sugar vs syntactic sugar
thats my point
You do not understand. It's not syntactic sugar, it's composability.
which is syntactic sugar.
or you pointer to function.
or you longjump.
or you duplicate code
and since C is caveman-tier its a one week work to implement generics in c99
>syntactic sugar
syntactic sugar for what? Show me the tbhgared C library that can achieve this.
any.
your code
if you use c libs youre using it for the wrong purposes.
i see where youre coming from.
but what if theres no libs for what you do?
->then you use C and write a lib someone will use in a higher level language
accept pepole are diferent, autist
im of the creative type
its often easier and less hassle to write a framework i need than to learn one thet i could use.
i mean- its moot
if youre really hardcore you inline asm and thats it
or you outsource this kind of shit to a gpu like a normal person
>if youre really hardcore you inline asm and thats it
That is entirely irrelevant to what I'm talking about. The entire point of having a composable linalg library is that you can write low-level optimized functions (with inline asm and other optis) and compose them.
completely relevant bc thats what inline does
except you have to do all the legwork so to speak. no?
>bc thats what inline does
No it doesn't. Inlining will just prevent a function call, not fuse loops. It's time to calm down and reevaluate your position.
you fuse loops by hand its trivial as frick
have a glass of water
>you fuse loops by hand
lol, ok frick off
you zoomershit you
wheres the craftsmanship?
(cont.)
akshually
ill make it a rhetorical question.
the craftsmanship resides in mastering all the complex systems you deal with in c++.
its more or less the same job
just with complexity shifted from one place to another
and i dont think it was a good trade in the end, with each layer of abstraction, the increase of complexity is exopnential
im sorry anon
but C is mathematically unavoidable
even if your endgoal is rust
bc your higher level objects interact with eachother
and how can you reduce all that?
->common denominator
->lowest level until it becomes more complex bc representation
-->C
and once you taste freedom
i can assure you
in whatever language youre gonna work with:
youre gonna feel like missing a limb
in any case
i dont have one whole day to spend on this, anon
prove the contrary
its just as good.
>prove the contrary
>its just as good
Not a single C linalg library in production. Not a one. It's all Fortran or C++.
bc no one cares bro
you dont use C for its libs.
you use C bc you write your own
(cont.)
bro, i respect your art
and the difficulty of it is the exact reason i avoid it
>Whereas the C++ eigen example will compute the result matrix directly in one go, through the use of expression templates.
I don't think you understand how C++ works at all
speaking of which im pretty sure cuda has a handle just for that
->does gpu count?
->where does c/c++ end?
You haven't supported your claim yet either, moron.
Are you going to take your own advice?
You don't have to answer. We know what kind of subhuman you are.
I have provided the problem and the C++ code to solve it. As soon as you provide your C code I'll be happy to write the benchmark.
also:
keep this thread alive
i guess ill be writing a gemm this evening...
i didnt even know what this was before now but i know a thing or two about C code
i wanna have a go at it.
ill be back in around 1hr
>Burden of proof, remember?
Yes, the burden of proof is on the person who has claimed that templates made code faster, which has not yet been done.
You keep mentioning the term burden of proof, as you try to ignore, essentially using a term you do not understand, in a dumb attempt to escape and appear smarter than you actually are.
>It's not on me to proce the efficiency of C
When you claim that something is made faster, then it is absolutely on you to show the thing that isn't as fast, moron. By the way, it was never claimed that it could have been done as well, moron, and claiming some victory if it isn't done is the fallacy of appealing to ignorance.
Don't bother trying to pretend like you are capable of determining what is simple or not. At this point, I wouldn't be surprised if you were dumber than most children.
>You would complain that it's not written well enough.
Write it well then, moron.
>What would me posting C code prove?
Because to claim that something is faster, you would need to show the thing that isn't as fast. Holy fricking shit you actually have a turd for a brain. An actual, unironic, unexaggerated moron out in the wild!
>Looking forward to your C implementation of a matrix library that performs as fast, since you seem to have very clear ideas about burden of proof
The burden of proof is still on you, smoothbrain. When you claim something is faster, you need to compare two speeds. By asking for the other half of your demonstration, you are once again commiting the fallacy of shifting the burden of proof right after you were told about and acknowledged it! Even a child would have learned it by now, but you, with your learning disability, are having trouble.
Your next step is to write code in pure c, to the best of your ability, which does the exact same thing.
>Because to claim that something is faster, you would need to show the thing that isn't as fast.
An you'll just say HURRR YOU DIDN'T WRITE IT FAST
You can b***h and moan and go into contorsions if you want to, but the simple fact remains: you support C in this matter, I support C++. I provide the C++ code, you provide the C code. A child could understand this. So why can't you?
>Cniles so fricking incompetent they can't fricking provide code to multiply matrices together
It's been a fricking our since I posted my example. What does it say about C groupies that you can't write matrix multiplications and additions in one hour?
Fricking nocoders
Just so you know, you're not the one who's right
the point is convoluted af doe
theres a failure at communication on your part to be mentionned too
js
even irl softskills are not to be underestimated...
https://github.com/vectorclass/version2
tempaltes are for midwits that get filtered by macros.
(in whisper)
(bro i myself cant do this shit its 7th dan black belt C)
How don't you get macros
i never needed em.
im self taught.
But macros are useful for personal projects
I have a "library" that's just a header full of useful macros
inline directive covers 90% of the cases a macro would be beneficial, no? i write for desktops btw
I find it's about 80% (along with basic things for naming compile-time constants). For the other cases, you need access to symbols in ways that you haven't got in an inline. In more complex cases, you might be able to delegate to an inline for most of the work but need a macro to wrap it into a nice API surface.
unironically; duly noted
since im the prime consumer of my libs i never thought that way
Macros were the original generics, and they have less overhead
also i am somewhat in the process of writing a something that would map C code
based on variables and their interactions
which means its a half step removed from enforcing types in C with an external tool
but also one half step removed from that (in turn) from generics
thats why i talked about C extensibility
(the more i use it (5 years now), the more i love this language)
Just use C with C++ with strings, vectors and maybe cin and cout. Frick it's not hard.
I work in a C codebase with a few C++ files and I ran into this issue where C++ wouldn't compile C definitions in a header file where it used static in the array brackets (for compile time bounds checking). I had to throw that useful safety feature (from C mind you!) away because C++ couldn't understand it, even from extern "C". Frick C++.
Compile the C stuff as a library then link it
That's not the problem, it's including a C header file in C++.
jeez in my pants, make a prototype for c and one for cpp then
he's talking about the header
There's a bunch of modern C features C++ doesn't have, like VLA types, or compound literals.
>VLA types
didnt we have these since a while already?
(cont.)
topkek
C++ doesnt have vlas bc a bunch of people are total fricking pansies
>nah the syntax for the type confuses me
>and i want my sizeof to be applicable or i dont want vlas at all
>(which you have to parametrize in a way or another tho. but apparently keeping track of one number is too difficult for some people)
and vlas are "modern" C 99
fricking lmao
C++ bros
explain yourselves
im still in shock
vlas have two extremely powerful applications:
a) its how you define a stack buffer which you know the size only at runtime
b) its how you declare legally structures whose size is deciddable only at runtime
its extremely powerful and both are entirely worth the slightly complex-er syntax and sizeof not being applicable on vlas
(btw, abt structs: you put a vla w/o parameter at the end of your struct, and when you malloc you add the space needed. then you can access the vla like an array)
Why doesnt it say creator++
There are C compilers that are formally verified. No C++ compiler can do that because there are too many "features"
I'd stay in C++ 11 or 14, since those bring nice features like move semantics and some much needed smart pointers, ranges and so on.
>does c have any advantages over c++
stable ABI
C has a few useful features, such as non-crippled designated initializers.
As for why C++ is hated.
C++ is terribly designed, its like a giant toolbox full of seemingly useful tools, but when you start using them you realize that they are all slightly malformed and only partially usable. Programming C++ is to live in a state of constant suffering, where things that should be simple are like getting blood from a stone. I would rather do without than try to use half baked features that are only sometimes useful.
you can compile with no wrapper libraries.
all neet snons who haven’t produced anything of value will tell you c is the greatest thing ever but in reality there is no reason to use c msybe only if there is no c++ compiler for your platform
even for small sloc projects c++ optimisation far outweighs any manual c moronic frickery.
C++ is a cancer that turns your code into incomprehensible trash. Not once in my life have a found a C++ project that was easy to understand, there are so many getters and setters and helper objects and other nonsense, that the functionality is hidden behind layers of useless nonsense. Every C project on the other hand, one can jump straight in and understand and modify it.
>Every C project on the other hand, one can jump straight in and understand and modify it.
C++ is obviously worse but lol, lmao
C is incredibly easy to understand, for the most part all functionality is visible (aside from macro abuse), and functions have their full names, so its easy to see what refers to what rather than with methods where its not immediatly clear what actual function is being called.
lad you got no fricking idea how spaghettified an older C codebase can be, and a LOT of C software still in use is quite old. greenspun's tenth law and all that. and that's not even getting into shit like language extensions.
Do you larpers ACTUALLY believe this?
>t. filtered by pointers
Your mom is pointing her mouth at my dick if you know what I mean.
That would be vaguely true if constness was more than a vague suggestion in C. As it stands, any function can have unbounded side effects, and it always fricks up new contributors to a codebase left at some point.
There aren't a lot of non-trivial codebases that are "easy to understand" in any language.
Look at the unholy macro shit you have to do to replace templates in C tensor codebases: https://github.com/foss-xtensa/nnlib-hifi5/blob/master/xa_nnlib/algo/kernels/cnn/hifi5/xa_nn_conv2d_depthwise_f32.c
And I'll tell ya you'll get way more unreadable error messages with this.
C is a much simpler language than C++
If you prefer simplicity in the language (but perhaps more complexity in your code) then C makes sense.
If you want the language to do more of the work (but beware of the many extra traps!) then C++ might be a better choice.
Fricking up is easy in C++ and it has features that make it much harder to use than it should be. (Implicit bool conversions are the ones that cause me the most grief.)
C++ is a language best described as a collection of power tools. If used correctly, it will boost your productivity and yield excellent code. If not - you are going to blast your limb off.
The biggest problem with C++ devs is the "have hammer -> find nail" mentality regarding the tools provided. Like - you _can_ use inheritance. But having multilevel deep hierarchies is probably a bad idea. You an use templates to metaprogram, but having entire source files of angle bracket babble is probably a bad idea.
c book is like 400 pages
c++ book is 2958 pages
It's more lightweight and more efficient.
That's not exactly a benefit though in comparison to C++'s benefits. The libraries in C++ and string handling are better by massive margins.
>can't you write c++ code just like its c and ignore anything exclusive to c++ anyway?
You can if you are too moronic to understand C++.
A lot of us programmers don't understand the basic libraries in our operating system.
Windows libraries are quite powerful and efficient especially when used with C.
The one thing that is the bane of existance in C programming is those fricking strings. By good God the first thing a person should do when moving to C is making a string library which has no fricking out of bounds bullshit occuring. The second thing you should do is fix arrays so you can operate at a higher level with less focus on low level logic.
>C++
>std::string
>std::vector
Then do everything else the same as you would in C.
Unless you are a terminal IQfy nocoder there is no reason to ever use C for a new project, not even for embedded. Just the fact that C++ has eigen, boost, opencv, tensorflow, ros etc. means that unless your project is fizzbuzz you will have to use C++ or call a C++ library.
>not even for embedded
Man, it's an uphill battle. Plenty of old timers see C++ as "that thing for OOP". Got shut down by my boomer director when I proposed we extended our compiler to support C++ because "in my experience C++ leads to slower binaries".
>slower binaries
how can a binary be slow
#include <chrono>
#include <iostream>
#include <thread>
int main()
{
std::this_thread::sleep_for(std::chrono::seconds(300));
std::cout << "Hello, World!n";
}
compile and execute the above hello world program and you will understand how a binary can be slow.
What's great about C++ is that it employs the principle of seperation of concerns. So it can be enormous and complex but due to it's multilayered nature this just makes it more powerful.
At the top layer is modern C++ with STL, which is essentially a garbage collected OOP language which basically feels like C#/Java. This is where your dime a dozen C++ code monkey lives.
Then more of a side layer you have all the template metaprogramming shit. This is where library writers and experts lives. The average C++ dev can honestly get by with never learning any of this stuff and still find jobs, get hired and get work done. But the library writers and the experts write generic code and that boosts the productivity of all us monkeys a million fold. There should be a team of library writers at every decent sized company.
Then at the very bottom layer of the language you have all the esoteric language features and of course just raw C where you can frick around with bits and bytes and memory and also inline asm. Again, the typically C++ dev never needs to worry about this, but the devs that do worry about it can build abstractions around these things to enable the less experienced monkey devs to be productive with them.
>separation of concerns
The language is full of non-orthogonal and mutually dependent features: std::initializer_list is a standard library class, yet it has special support built into the language. RAII is impossible without exceptions. And so on.
C++ is the antithesis of a language with "separation of concerns", the only way to avoid nasty surprises is to know it in its entirety, which is unfeasible.
I remember a post here in IQfy that said that c++ is probably the most popular esoteric lang
Out-of-order designated initializers are reason enough to prefer C to Sepples.
C++ ABI is unstable
>c++ bad because.... it's too difficult....
literally yes.
t. 140+ iq.
bc cognitive overhead is a thing.
Midwits love complexity!
he says c++ can be just as safe as rust
is he wrong?
no.
bc rust is not safe, only safe-ish.
but in absolute you can be just as safe with C,
once you factor in the fact that the simpliicity of the language makes extending it trivial... ish
(extending the lang like with generated garbage collection)
thats a checkmate, init?
the ace in the hole
you can map, extend, generate C code relatively easily.
you could do so in rust and c++...
...but you would be generating C, only expressed in rust, or c++, wouldnt you?
and the mapping part would be an utter pain in the ass
all in all
yeah, use your oop where it makes sense, i am also partial to it to be honest
when i was in school and i had to write a wolf3d clone in C i fell back on oop principles
but now i have an internal norm, i dont need oop anymore.
moreover: the lack of it provides flexibility like outlined above
C is the perfect dose when you know what you do and what you want.
>perfect
no, thats not true. theres improvements that could be made
but its the best solution on the market.
in some cases, C is the rational thing to do.
[unintentional samegayging]
c++ can do everything you would use c for including firmware and more that would never use c for like literally any modern application, so c-cultists get assblasted
>assblasted
>so much so that feels compelled to make a thread
wait
its a sepplesthread, no?
on an STM32 micro controller for firmware engineering class
>>auto-generated C code is literally hundreds of files initializing hand crafted C libraries, downloaded libraries for every electronic component
-python code is literally 100x smaller for an ESP32 or arduino
It's simply mind boggling how much C boilerplate is required please explain this. YES I KNOW IT'S FRICKING FASTER WOW LITERALLY MICROSECONDS FASTER THEN MICROPYTHON