Has any one language done more damage than this piece of shit?

>>61470734
I work with C and I agree. C is godawful and archaic, but you can't get around using it because it's 1) pretty much industry standard since everyone use it, including tonnes of open source software project and 2) for low-level stuff it works beautifully because it's basically just a portable and easier maintained assembly.

>>61470734
> smart people (like me)
Brainlet detected.

What do you need a bool type for all it is is a bit with a explicit nameing convention. Bools are Bloat.

Do you have shit for brains? C wasn't designed to be a high-level language and if you don't need it you can just use Java with your friend Pajeet.

>>61470734
>>61470784
>lack of a distinct bool type
C has had a "proper" bool type for 18 years.

>>61470734
Other languages do have null-terminated strings and a lack of a bool type. They just pretend otherwise, by having a fancy string type and 32-bit bools. C doesn't cover up the details.

>What is "sage"?
>Entering "sage" (by itself) into the [Options] field while replying will cause the thread not to bump to the top of the page. Contrary to popular belief, a sage is not a downvote, and should not be used as one. "sage-bombing" or announcing that you've saged a thread may result in a ban.

Useful knowledge for this kind of shitpost.

>>61470784
Actually, bools are not bloat. C++ having a bool type means that for example std::vector<bool> template specialisation can be implemented as a bitmap.

>>61470787
Explain how it's less "high level" to have the string length in a prefix byte instead of terminate with a 0

Literally the same amount of memory.

>>61470811
>Limiting strings to 256 characters
>Substrings and iteration with pointers no longer works
That is not an acceptable tradeoff.

>>61470811
It's not about memory efficiency, it's about O(1) vs O(n) for a bunch of string operations.

>>61470802
Using bloat the language as an example why its not bloat.

>>61470802
Don't forget function/method overloading.
Cfags just miss the point of type systems.

>>61470824
Right. With a prefix, string length becomes O(1). it's O(n) with a null terminator.

>>61470825
He is correct though. It also allows other optimisations, such as compressing bool members in a struct to bitfields.

>>61470833
C actually has function overloading, though.
It's honestly a pretty useless feature most of the time, in any language.

>>61470811
switch to c++ and use std::string

>>61470787
C was literaly a "high level language" when it was created due to its portability but the meaning of "high level" has changed since then.

>>61470820
That guy is an idiot.
Having a length field actually allows more efficient substrings, and does not get in the way of pointer iteration at all.

File: cpp.png (23KB, 360x405px) Image search: [Google]

23KB, 360x405px

>>61470734
There is another way.

>>61470802
vector<bool> is a terrible idea, like most template specializations.

>>61470843
>It also allows other optimisations, such as compressing bool members in a struct to bitfields
No C compiler would ever think of doing this. Struct member layout is extremely important and it's not something they will fuck with unless explicitly told.
Also, C has had _Bool since C99, you fucking mouthbreathing retard.

>>61470833
Also very true. Especially painful when dealing with NULL vs nullptr.

>>61470834
Exactly.

>>61470845
>C actually has function overloading, though.
No?

>>61470799
>Other languages do have null-terminated strings
No they don't, idiot.

>>61470864
>>C actually has function overloading, though.
_Generic can be used to implement function overloading.

>>61470845
>C actually has function overloading, though.
You're talking about C11's Generic macros?

>>61470845
It's only useless if your type system sucks.

>>61470787
Java and c# both are shit at memory management though. C++ is the only one that gives you full control

>>61470890
This.
C++ is literally the best language for both high level and low level development.

>>61470861
>Struct member layout is extremely important
Which is why they are compressed into bitfields. when possible, in order to fit into the nearest alignment boundary rather than scaling upwards.

>Also, C has had _Bool since C99, you fucking mouthbreathing retard.
Where did you get the impression that I didn't know this?

Also, _Bool is a bitfield if you use GCC.

>>61470875
Very simplistic macro magic, but yeah, for sure. I forgot about C11 for a second. Anyway, you need strong typing in order to differentiate functions.

File: 2017-07-20-232112_644x468_scrot.png (12KB, 644x468px) Image search: [Google]

12KB, 644x468px

>>61470909
>Which is why they are compressed into bitfields
No. They aren't you fuckface.
Go compile some structs with bools in C and look at its size. No compiler is going to do that.
That is the sort of shit that breaks ABIs.
>Bool is a bitfield
Only if you explicitly set it as a bitfield.

>>61470927
_Generic IS strongly typed.

>>61470945
Make a generic expression that is able to differentiate between NULL and 0 please., I'm genuinely curious.

This has been an issue with C++ forever:

#include <cstdio>

void foo(void* p)
{
    puts("hello");
}

void foo(int i)
{
    puts("gentoo");
}

int main()
{
    foo(NULL);
    foo(0);
    return 0;
}

>>61470996
>Make a type expression that matches values
Why don't you ask a question that isn't fucking stupid?

>>61470945
Still does retarded shit like this.

#include <stdio.h>

void overloaded_c(char c)
{
    printf("char");
}

void overloaded_i(int i)
{
    printf("int");
}

#define overloaded(X) _Generic((X), \
              char: overloaded_c, \
              int: overloaded_i  \
              )(X)

int main()
{
    overloaded('x');
}

C++'s type system might suck but it least makes a token effort to patch over these holes.

>>61471008
>I can't do what's asked
Guess C doesn't have so strong typing after all then. Thought so.

>>61471008
The fucking stupid thing here is that NULL is not a pointer type, it's an integer type.

C++ has solved this with nullptr, which is of type nullptr_t which is a pointer type that implicitly converts to all other pointer types.

>>61471031
>Hurr durr, I'm a retard
Please learn the semantics of C before you try to criticise it.

>>61471008
nullptr doesn't have this problem.

>>61470734

>he's starting his computer, booting an OS that's written in C
>he's opening his browser, written in C
>he's going on a certain website, on a server written in C
>then his JavaScript implementation (written in C) opens up a dialog box
>he's writing a post about how bad C is

OP, I don't even..

>>61471037
>_Generic IS strongly typed
You made the claim, retard.

>>61471037
>wants function overloading
>thinks a char literal being an int isn't retarded

>>61471033
>The fucking stupid thing here is that NULL is not a pointer type, it's an integer type.
In C, it's definitely a pointer type.

>>61471038
>>61471032
nullptr is just stupid shit to patch over the fact that C++ doesn't have automatic void * conversions.

>>61471048

#include <stdio.h>

#define type(v) _Generic(v, void *: "stupid", int: "fuck")

int main()
{
    printf("%s\n", type(NULL));
    printf("%s\n", type(0));
}

stupid
fuck

>>61471037
I know C's semantics, and I'm telling you that they're fucking stupid.

>>61471044
>hurr how can you criticize capitalism when you WEAR CLOTHES

This is what you sound like right now.

"We can do better" doesn't mean "I'm going to ditch everything and shit in the woods now."

>>61471063
Why are you relying on implementation defined behavior?

>>61471077
I'm not. The standard definitely says NULL is defined to be (void *)0.
It's just that it's underlying bit representation may not be zero.

>>61471063
>nullptr is just stupid shit to patch over the fact that C++ doesn't have automatic void * conversions.
No, it's "stupid shit" to deal with the fact that implicit void* casting weakens type safety.

And great example, now do it with a char literal or with a void* pointer type and an int* pointer type.

>>61471090

#include <stdio.h>

#define type(v) _Generic(v, void *: "you're", int *: "still", int: "stupid")

int main()
{
    int n;
    printf("%s\n", type(NULL));
    printf("%s\n", type(&n));
    printf("%s\n", type(0));
}

you're
still
stupid

>>61471102
I meant to change the 0 to a char literal. The results don't change, though.

>>61471087
The cast may or may not be there. Its implementation defined.

>>61471102
Fucking retard CIA nigger

#include <stdio.h>

#define type(v) _Generic(v, int: "stupid", char: "fuck")

int main()
{
    printf("%s\n", type('x'));
}

>>61471126
That has literally nothing to do with _Generic.

>>61471129
>_Generic doing the retarded thing is nothing to do with _Generic

>>61471044
And they all have endless bugs and exploits.
Your point?

>>61471129
No, it has to deal with the fact that typing in C is weak.

#include <cstdio>

void foo(char c)
{
    puts("stupid");
}


void foo(int i)
{
    puts("fuck");
}


int main()
{
    foo('x');
    foo(0);
    return 0;
}

$ g++ overload.cpp && ./a.out
stupid
fuck

>>61471149
_Generic is doing precisely the right thing.

>>61471153
That has nothing to do with typing strength, you retarded fuck.
In C, character constants are typed as ints. In C++, they aren't.

>>61471154
>the right thing

Implying

>>61471166
See >>61471158, fuckface.

>>61471174
>character literals are integers
>the right thing
Wow, C autists are really going off the rail with this one.

>>61471158
That's fine as long as your language is weakly typed and lacks overloading, but as soon as you introduce overloading it completely fucks the semantics.
This is why C++ turned char literals into chars, and deprecated use of an integer literal as a macro for pointers. In any language where types are important, defining a constant to have a different type to the thing it representsis utterly braindead.

>>61471158
>In C, character constants are typed as ints.
Because C is weakly typed and it doesn't really matter.

>In C++, they aren't.
Because C++ is strongly typed and overloading wouldn't work if it wasn't.

>>61471183
>>61471184
Stop changing the fucking subject.
I only said _Generic is strongly typed (it won't do any automatic conversions).

>>61471200
And I'm saying _Generic was a mistake because C's type system makes it do stupid shit.

>>61471200
>I only said _Generic is strongly typed
And that was moving the goalpost, the post you replied to (namely >>61470927) talked about strong typing in C++.

>>61471200
>I only said _Generic is strongly typed
And what's the fucking point of that when it the result is inconsistent and counterintuitive because the rest of the language sucks balls in regards to defaultly typing everything as int?

>>61471218
No, _Generic serves its purpose. I'm pretty sure it's just there so they didn't have to rely on "compiler magic" for <tgmath.h>, not add a billion new functions for <stdatomic.h>, and they thought they may as well give the same power to programmers.

>>61471250
>putting lipstick on a pig

>>61471234
What inconsistent behaviour? _Generic matches exactly what it says it does.
Also, nobody really gives a shit about char literals. They are very rarely used, except for when matching characters in a string.
When was the last one you passed one into a function.

>>61471272
That last sentence was supposed to be a question.

>>61471272
>Y-you don't need it anyway
How about passing a null pointer to a function, you apologist fuck?

>>61471250
It's funny how Cniles will defend a feature that's even more botched in its implementation than anything in C++ simply because it isn't C++.

>>61470802
>vector<bool> for a bitmap
why not just use any integer
and if you are really fucking crazy about your bitmap
use a fucking array or vector of said integer type

>Literally not an argument
Not an argument

>>61470734
Learning C as a first language fucked me up. Things I thought were common between all programming languages like vectors, string manipulation, memory handling, etc. turned out to just be "a C thing". I wish I had just learned Java or Python first.

>>61471363
You understand that a bitmap has the benefit of being able to compact at least 8 values into a byte, right?

>>61471363
>array or vectors of integers rather than a bitmap
Great idea, lets bloat memory to hell and beyond. People have 16 GB, just use it all!!

>>61471669
accessing a bitfield is going to be so much less efficient than a plain array of bool that memory concerns are basically irrelevant.

>>61471642
you must've never seen python and java benchmarks, on modern hardware at that

>>61471748
>accessing a bitfield is going to be so much less efficient than a plain array of bool that memory concerns are basically irrelevant.
Accessing an array means looking up a memory address and fetching a cache line, potentially evicting something important from the cache. In worst case. In the absolute worst case (this is also true for a bitmap mind you) you might even have to wait for a memory fence just to change a single bool. Bitoperations and masking and or-ing is completely negligible compared to memory loads and stores.

>>61471199
C is typed as strongly as it needs to be folks, it's a systems language get over it.

C++, and I don't know it much, but just looking at the manual, it's an application language - which means types are important.

C - types are handy references is all.

>>61471925
We agree.
The problem is not with C's type system but the _Generic macro. Any feature like _Generic which makes decisions based on types does not belong in a weakly typed language like C.

>>61471956
Sorry haven't encountered _Generic

Sounds horrid and I won't ever touch it.

fwiw I C malloc-less so I use it basically as a glorified assembler. OS calls are verboten, except for debugging of course

>>61471925
Being a systems language is not a valid excuse to have a shitty type system and shitty abstraction support.

>>61472083
Assembly has no notion of types.
C is fine for what it is.

>>61472083
Why the fuck do you need abstraction?

>>61472102
C is not assembly.

And what, are you saying that any language that compiles to assembly must not have types? you're fucking retarded.

>>61472023
>malloc-less
>OS calls are verboten
>glorified assembler
What the fuck are you writing in C? An OS? Very small libraries?

>>61472105
Productivity.
Safety.

Basically just things C programmers don't know.

>>61472083
The wanna be java/c# programmer has spoken.

Be yourself, friendo

>>61472122
Actually, I program Rust, not sepples aka mutant C on steroids.

>>61470734
Is OPs pic really a good book or just a meme?

>>61472134
Don't pretent to be me, fucking faggot Rust programmer.
I program in the best programming language on earth: C++.

>>61472110
Compiling target is not the same as source grammar or intended use case you fuck knuckle

>>61472136
It's a good book if you want to learn the very basics while at the same time learning about the mindset of the people who made it, but don't expect to learn idiomatic C from it.

>>61470734
>unlike SEVERAL MILLION other people, I have trouble with C
>but I am the smart one, and C is stupid
Hmm...

>>61472111
Sounds like embedded systems to me.

>>61472147
Are you replying to the right person? Your post makes no sense.

>>61472111
Ah. Yeah. A chess engine.

Not exactly my retirement grease,

But still, it keeps me going.

>>61472163
>>61471925
>says that C is intended as a systems language
>says that C++ appears to be an application language
>ties his own hands with arbitrary restrictions to make a simple chess engine.

>>61472160
All languages ultimately compile to assembly.

whether the compiler wants types or not is up to the compiler.

Why do Cfags think that being a systems language is a valid excuse to not have a proper type system?

>>61472195
>t. Rust programmer

>>61472190
And? I fucking know that, retard.
Can you read properly? No I don't think you can.

You obviously don't understand the point of types, otherwise you wouldn't be defending C's type system.

>>61472202
More like a C++ programmer

>>61472195
Because C is a portable assembly language.

>>61472134
Not sure I need to reply but since the C written platform I'm typing on allows it, I will

>>61472202
I'm a C++ programmer.
Why do you assume I program in Rust?

>>61472195
>Why do Cfags
>implying a single shitposter completely represents his language of choice

>>61470870
Macro 10
BCPL
COBOL

>>61472208
C's type system is made to not get in the way.

>>61472214
No it isn't.
People who say that are fucking retarded.

>>61472227
Every C fanboy I've seen is a retarded as him, though.

>>61472240
>No it isn't.
Yes it is.

>People who say that are fucking retarded.
No u.

>>61472221
Because you shitpost like one.

>>61472234
Sounds an awful lot like weak typing then.

>>61472261
Calling out C programmers retardation for thinking that just because you're writing a kernel, you don't need a type system is "shitposting like a Rust programmer"?
Good type systems are just as important in low level code as they are in high level code.

>>61472234
Yes, this.

>>61472240
go to sleep, you are drunk. Then boot your copy of Eclipse and do whatever the fuck it is that makes you happy.

>>61472277
It is.

>Bool

What?

>>61472305
>Damage control

>>61472294
>Calling out C programmers retardation for thinking that just because you're writing a kernel, you don't need a type system is "shitposting like a Rust programmer"?
C programmers are aware of the limitations of C, you're confusing programmers with meme masters and professional FizzBuzzers on /g/.

>Good type systems are just as important in low level code as they are in high level code.
I don't disagree, I'd prefer C++ over C any day, but most days I'm limited by choices already made in the past by other people.

I actually saddens me that we never got a true C 2.0.

C99 is the best language we have right now.
I just wish we could have C with the syntax of D 2.0 but without all the OOP/C++ nonsense.

>>61472338
Pssst, it's called Go. It's even made by many of the same people involved with C.

>ITT: Idiots not understanding the concept of picking the right tool for the job.
C has its uses, and if you're so butthurt about lack of features, move to C++, or any other language. The fact you can't recognize where you shouldn't use C (pretty much any higher level enviroment) shows your ignorance.

>>61472353
Both C and Go are a joke.

>>61472353
>GC
>no macros

>>61472357
>C has its uses
Does it?

>Userspace applications
C++ does it better
>System libraries
C++ does it better
>Kernels and drivers
C++ does it better
>Embedded
C++ does it better
>Safety critical systems
C++ does it better (and Rust arguably does it better than C++)

Tell me, where does C have it's uses? Because I'm not seeing them.

>>61472401
It has its use in stopping people from using C++.

>>61472373
Don't forget,
>No generics

>>61472410
So it's use is in making everything worse?

>>61472373
>macros are good

>>61472401
As mentioned above, it's weakly typed. If you have the skill to use it to your advantage, I guess you could create a much faster program than with C++. Though I don't know of any other uses other than limiting the user to a much smaller library. C++ is pretty much C + a lot of other functionality, would have to look up the differences to see if/why C>C++ in some situations.

>>61470734

Okay.

https://software.intel.com/sites/default/files/managed/39/c5/325462-sdm-vol-1-2abcd-3abcd.pdf

Here's the 4800 page specification for x86_64 and the intel developer's manual. It contains the entire information of everything the CPU can do and the 32 different registers inside it.

Using only this your mission is to make a program that can take natural, human readable text like

if (weAreGood) then_do_stuff(theseParams)

and turn it into binary that can run on one of these machines.

>>61472319
Thanks for literally nothing

>>61472373
#MACROS ARE SATANS DICK IN YOUR CODE (Do you really want that in your code ?)

>>61472465
Weak typing is objectively shit in all situations.
Any "optimizations" you can do with weak typing can be done better with strong typing.

>>61472421
97% of what I use in C++, is just C.
I'm not saying that because it's a superset, there's just nothing in C++.

What would ideally fix C?
Maybe get rid of header files and give me a macro in the language for array size.
Maybe add a little bit of struct happenings from D.
An int32 and int16 type?
Another rand() because people don't shutup about "muh pure randomness" or whatever.

That's it.

>>61472465
C++'s type system is easy to subvert. Any of the implicit conversions in C can be made explicit in C++ - you simply have to make your intention clear.
Very few things are only possible in C.

>>61472503
>97% of what I use in C++, is just C.
You're doing C++ totally wrong, then.

>>61472470
You can install Eclipse on my virtual Windows 10 Professional AWS instance.

>>61472401
>>Userspace applications
>C++ does it better
More people know C than C++ in the open source and free software community. Consequently, loads of projects from ffmpeg to gcc that technically could have been written in C++, but are written in C simply because more people know it.

I know "more people knowing it" isn't a technical argument, but if you want your project to get contributions, you have to deal with existing communities.

>>System libraries
>C++ does it better
It arguably doesn't, due to the fact that different C++ compilers have different ABIs. It's not impossible to cross-compile C++ and make a stable ABI that can be invoked from other sources, but it requires special handling. C, on the other hand, being a portable assembly, produces an incredibly minimal and consistent ABI by default, which is why a lot of people make C libraries such as libssl, libpcap etc.

>>Kernels and drivers
>C++ does it better
When you develop kernels and drivers, you rarely start from scratch and you usually have to deal with existing code. All the major OSes today are written in C and extending those or writing drivers for those usually means that you have to work with a C-based SDK. Of course, you can write C++ kernel modules for Linux for example, but it requires you to bootstrap a C++ runtime within the restrictions of an LKM and generally it's a giant pain and you'd spend all your time doing this instead of actually writing code that controls your physical device.

>>Embedded
>C++ does it better
"Embedded" can mean anything from an ARM processor running a Linux/tinybox set-up to a small uC with 4K ROM size. C++ is suited for the former, but in the latter, you really need to spare all your resources.

>>Safety critical systems
>C++ does it better (and Rust arguably does it better than C++)
And Ada does it better than both.

Don't mistake me for someone who loves C, I fucking hate working with C and would prefer C++ over C any day if I were the sole decision maker.

>>61472512
There are plenty of valid ways to write C++, it just depends on what you're doing.

>>61472512
This.

>>61472512
But that's exactly it. You don't 'do' C++ because it hurts you in the end.
It's just those concepts, those modelling views.

I see people's C++ and I just think what the fuck are they doing?

You'll always see in the end, that good C++ is basically just C.
Virtual functions, default encapsulation, multiple inheritance, new and delete.

I'm past the point of bashing the language for laughs, I genuinely just want people to stop.
It's enough.

>>61472520
>but in the latter, you really need to spare all your resources.
Hence C++ is suited for it.
I don't know where you got the idea that you can't spare resources as much in C++ as in C.

All your other arguments are just the industry preferring C over C++.
And the ABI is not really C++'s fault. It's because none of the compiler vendors can decide on one ABI.
C doesn't have a standard ABI either, it's just that every vendor has decided on a defactor standard ABI for C.

>>61472604
A lot of C++ is about hiding allocations behind safe abstractions, but if you're that limited for resources then you really shouldn't be hiding anything.
You should through every STL container right out of the window if you're writing for an embedded system.

>>61472622
*throw

>>61472520
You've said that twice now mate.

"I hate C, but have to C"

I love C. What do you hate about C ? You profess a love for Ada. It's very type heavy, but I guess (heck it's been a while) compilable to whatever target you want. Do you like Ada for your sake ? Or for the fact that it might prevent fuckups made by noobs ?

>>61472569
>There are plenty of valid ways to write C++
Right.
It's just that the C way of writing C++ is the most incorrect way to write C++.

>>61472643
If you're trying to write a kernel in C++, it should look a lot like it would if it were C. But a high level userspace application should not.
You pick the right set of tools for the job.

>>61472641
Which Eiffel was supposed to be even better at btw. Not that I ever used it, but it had the whole contract thing

>>61472601
>because it hurts you in the end.
No it doesn't. Using C hurts you.

>and I just think what the fuck are they doing?
Because you don't understand C++.

>You'll always see in the end, that good C++ is basically just C.
Wrong. C++ code that is just mostly C is the worst C++ code.

>Virtual functions
Infinitely better than function pointers in structs.

>multiple inheritance
Nothing wrong with it if you only multiple inherit from abstract virtual base classes

>new and delete.
Deprecated. Use smart pointers.

>>61472604
>I don't know where you got the idea that you can't spare resources as much in C++ as in C.
Memory use for code is going to be significantly higher when you have routines that are invoked as part of the RAII process. This is the very reason why most embedded C++ toolchains have their own reduced (and non-standard) version of STL containers for example.

>All your other arguments are just the industry preferring C over C++.
Well, yeah. That's the world we live in.

>And the ABI is not really C++'s fault. It's because none of the compiler vendors can decide on one ABI.
That's not entirely true, it's also because the C++ committee wants C++ to be a lot like C and have the success C has (of being the first language ported to a new architecture), and therefore they impose very few limitations and restrictions on how the ABI is supposed to look like.

So it's more a portability issue than anything.

>C doesn't have a standard ABI either, it's just that every vendor has decided on a defactor standard ABI for C.
Yes, because it is so simple. But C is very successful in that it is the first language ported to a new architecture. This is partly due to it's simple ABI.

>>61470734
C has stood the test of time, when other lesser languages have come and gone. OP is a faggot.

>>61472702
>>Virtual functions
>Infinitely better than function pointers in structs.
It seriously depends.
The only thing I have against passing function pointers is the horrific syntax.

>>61472641
>What do you hate about C ?
Weakly typed, unsafe, no sane exception or error handling, no collection types in the standard library, near impossible to do any form of generic programming in it, etc.

>You profess a love for Ada.
I did no such thing, I don't even know much Ada. I simply stated a fact about safety critical systems, Ada is a language that is tailored for these because it includes a level of correctness guarantees in its semantics no other language I've seen have.

>Or for the fact that it might prevent fuckups made by noobs ?
This is never a bad thing, to be honest. No language should make it easy to make mistakes. "It is designed to not get in the way" is a lousy argument for this.

I'm not saying that C++ is extremely better than C on this point though, there are A LOT(!!!) of gotchas in C++ too. But on the other hand, C++ has a lot of built-in safety C simply doesn't ahve.

>>61472643
This is the problem.
It's not about the code. It's not about the "correct" way.

Your no. 1 priority is data. It's the simplest transformations and mapping the problem space as close as you can to the hardware.

And then alongside that, you have comprehension of the code, how it's working.
If you're keeping it all simple, then that's easy.

And the simple subset of C++, is just C pretty much.

>>61472676
>If you're trying to write a kernel in C++, it should look a lot like it would if it were C
No, it shouldn't have to. That's just stupid and you have a very closed mind to how a kernel should "look".
You think that it's somehow bad or even impossible to write a kernel using only C++ features and idioms, you're just plain wrong.

>>61472755
I feel like you'd like this talk.
https://www.youtube.com/watch?v=rX0ItVEVjHc

>>61472705
>Memory use for code is going to be significantly higher when you have routines that are invoked as part of the RAII process
You have absolutely no idea what you're talking about.
Do C programmers just not free their resources?

>hur dur what is inlining

>>61472794
>You have absolutely no idea what you're talking about.
I work as an embedded programmer, so yeah, I kinda do.

The very existence of special purpose, minimal, embedded STL implementations proves my point.

Also, inlining is worse for the ROM footprint you fucking dolt, because of instead of creating a single routine invoked/called from multiple places, you duplicate code all over.

>>61472835
>Also, inlining is worse for the ROM footprint you fucking dolt, because of instead of creating a single routine invoked/called from multiple places, you duplicate code all over.
This is also why you want to use templates very sparingly in any program with a small footprint e.g. a template.

>>61472702
The fact that you're bringing up smart pointers and advocating for multiple inheritance, as well as function pointers in structs shows me you've fallen for the C++ lies.

And that's alright, I'm not going to criticise you because I was there once. Shit, everyone is at one point.

I'm not shiting on C++ as a C purist/elitist, I'm shitting on it because I worked with it, it was my language for a time, I was a C++ elitist.

You don't need to do that stuff.
You don't need to be calling new and delete every 17th line and fragmenting your data accesses and the heap as well as cache pre-fetching.

Your functions, they don't need to be inside a class. They don't need to be.
You don't need to be initializing classes just to call functions.

Virtual base classes, or pure interfaces whatever you want to call them, they're the bane of C++.
Maybe you say you want to leverage polymorphism through them.
How many times states are you really going to go through with it?
I guarantee it's not going to be more than 5, in which case just use a switch.
It's more performant, and it's easier to read.

>>61472835
>because of instead of creating a single routine invoked/called from multiple places, you duplicate code all over.
Just like how you put a call to free() whenever you need to free something.
RAII doesn't add any overhead whatsoever. It just automatically puts in those calls so you don't have to do it manually.

You don't understand C++ or RAII. Some embedded programmer you are.

>>61472851
*e.g. a kernel

>>61472874
You dont call free and malloc in an embedded environment where you have limited ROM, EEPROM and RAM you huge fucking retard. Raii on the other hand, is invoked on stack allocated resources. You are a fucking moron

no one is going to win this argument Gödel proved it.

>>61472893
You don't even need to call free or malloc in a normal desktop environment.

>>61472893
RAII is all about heap allocation. A vector uses its destructor to avoid leaking the heap array pointer it owns.
C doesn't need RAII to avoid leaking memory in pure-stack structs.

>>61472935
On a desktop environment I would use C++ because it's a lot nicer to work with. On a micro controller with 4K ROM and 1-4K RAM I would use C

>>61472862
>You don't need to do that stuff.
Of course you don't, but it's better if you do.

>You don't need to be calling new and delete
You shouldn't be calling new or delete at all. Use smart pointers.

>Your functions, they don't need to be inside a class. They don't need to be.
Obviously, but it's better to group your data and functions together.

>You don't need to be initializing classes just to call functions.
Of course, that would be terrible design if your just using classes for the sake of classes.
You should obviously have a good reason why you're using a class.

>I guarantee it's not going to be more than 5, in which case just use a switch.
That's terrible design.
I'm not some OOPfag who over uses objects and polymorphism to oblivion.
There are design situations where polymorphic objects are just simply much better, and when you do need polymorphism, abstract virtual base classes are infinitely better than structs of function pointers.

>It's more performant, and it's easier to read.
Wrong and wrong.


I am the opposite of you. I started in your position, I was a C elitist who had pretty much the same attitude as you.
But slowly I realized that strong type systems and good abstractions are important in a language, for both productivity reasons and safety reasons (although I'm not that big on safety, unlike Rustfags).

>>61472893
If your constructor/destructor does nothing, no code will be emitted. You should know this.

>>61472938
RAII isn't used only for memory, but also for stuff such as lock_guards. Which are nice features when you throw exceptions, but can get in your way when you'd rather have explicit control

>>61472967
If you don't use any C++ features (as in you don't use RAII), why use C++ at all?

>>61472967
>better to group your data and functions together
have you ever written performant multithreaded code? having your state information in one place is a good idea (tm)

>>61470734
every language has null terminated strings.
that's how they are stored in memory

>>61470734
The early adopters and even Ken Thompson agreed it had some flaws. These were supposed to be corrected in Java, which failed. Then corrected in C++, which failed too though latest C++ is a vast improvement.

C is fine as a target, meaning you have some kind of safe memory system that uses C APIs. C is not fine by itself wide open to some network

>>61473176
Most languages use size-tagged strings.

>>61473169
Nah man put that inline function in-between the two lists that I'm going to traverse inside that class that inherits from the other class with the update function to traverse them both.

>>61473129
?
I do use C++ features.
I use most of them, In fact I try to use as little C as possible.

>>61473176
t. retard

>>61473176
NULL subverts types, plenty of languages do not use it like Scala. NULL is considered the worst mistake in CS generally

>>61473198
Do you think that putting a function between 2 data members actually splits the two data members apart?
Fucking retard, methods are not data. If you have a single int and a billion non-virtual methods inside a class, the size of the class will be the size of a single int.

>>61473243
Yeah, NULL is.
nullptr isn't though.

There is literally nothing wrong with null pointers. Stop spouting stupid memes.

>>61473243
a null char is not the same as a null pointer
null pointers fucking suck anyway, optimized optional types are better

>>61473250
so when you have multiple threads trying to use the data in your class that also have functions on that data what do you do? litter the code with mutexs and think that it will be performant? (this kind of) OOP is shit.

>>61473290
Use an atomic type, obviously. like std::atomic.
This isn't any nicer in C, and it's not OOP.

>>61473200
Then your post makes no sense at all.

>>61473381
No, it does.
I don't think you understood it correctly.

>>61473381
And I don't know what made you think I don't use RAII.
I certainly use RAII.

>>61472835
>because of instead of creating a single routine invoked/called from multiple places, you duplicate code all over.
>what is CALL [label goes here]?

>>61473664
The exact opposite of duplicate inline code.

>>61470734
It's a PDP-11 assembler on steroids, it's not a real programming language.

Dumb rust shills, when will they learn that C is way better then their she language?