Why would anyone do this

Why would anyone do this

Attached: 331315145134.png (1080x618, 197K)

Other urls found in this thread:

lysator.liu.se/c/pikestyle.html
twitter.com/SFWRedditGifs

Don't see the problem

abc

> they wrote a function to free the string
> still forgot to call it and leak memory

Epic fail x3

> inb4 the OS frees all your shit when you return from main

Just because the OS expects you to be a retard doesn't make it ok to be a retard

because they're stupid enough to program something like this in C instead of C++

>literally the only use case for c with classes
>implement it in c instead

The question is, why wouldn't you use C++ for OO instead of trying to do your own?

Attached: cpp_desu.jpg (1440x810, 155K)

It's completely fine in this scenario it's obviously demo code.

you guys realize that any non-trivial C program uses data encapsulation and contructors/destructors like in the OP?

not saying the code in the OP isnt retarded since it's reinventing the wheel and has a memory leak, but that kind of data-encapsulation most certainly does not warrant use of sepples.
if you think it does you are not qualified to program in sepples (or any other language, for that matter)

meant to quote
not

>any non-trivial C program uses data encapsulation and contructors/destructors
yes, and it does so in a much less clear way. In cpp you have namespaces and classes, so if you have a big project you can just call A::doStuff() and B::doStuff()
In C instead you need to have a million initializers that you can unsafely call from anywhere in the program, and pass pointers everywhere to accomplish the same thing

Seems dumb to me, why not just store the length before the string itself instead of before a pointer to the string. Pointless indirection on every operation.

>Be Jow Forums
>despise C++ because it's too complex
>meme C because it's so simple and pure
>but shill C++ over rust because fuck sjws
>and secretly use C++ instead of C when shit needs to get done
Why are you this tsundere, Jow Forums?

Attached: 6gfg78d7h.jpg (1440x900, 327K)

>A::doStuff() and B::doStuff()
A__doStuff() and B__doStuff()

>In C instead you need to have a million initializers that you can unsafely call from anywhere in the program, and pass pointers everywhere to accomplish the same thing
nah, normal OOP is pretty standard in C and can be done cleanly.
the real advantage sepples has are templates and polymorphism, but most sepples niggers dont even know that

I mean, do you really think projects as complex as the linux kernel or openGL could exist at all if you need to use sepples for everything except trivial hello_world shit?

c and c++ are nearly interchangeable
rust syntax is just shit

>unsigned length and only 16 bit regardless the unavoidable 16 bit offset for alignment
>casting malloc
>allocated fixed-sized handle
>abort on failed malloc
>strdup, strlen
>free has memory leak
fucking kek

guys i'm noob.
Aren't you supposed to free the data filed also?

>projects as complex as the linux kernel or openGL
many of those are written in C because they started in the 90s, when c++ compilers were uncompliant crap

I use C++ when I need to. I'd take C a million times over sepples for file handling, but if I need to use data structures I'd much rather use std::queue, std::vector, etc. than implement my own.

Attached: yes_man01.jpg (1280x1024, 203K)

linux is written in C because it's a fucking kernel, lmao
anything that needs to interact closely with hardware and needs to be very performant and produce predictable assembly should be written in C.
are there actually kernels written in sepples? haha

if you need predictable assembly you program in assembly, like the kernel does in critical places.
however, not all the kernel is hardware interaction, there are some "higher-level" things like process handling or filesystem support.

>Symbian OS
>IOKit (part of MacOSX and iOS)

Java programmer that wants to retrofit OOP onto C.

>Everyone needs string functions like OP
>Call it bloated when implemented

literal bullshit, if it was for some 2 byte unicode encoding it would be ok, but in this case, he uses strdup and strlen which would only work with null terminated C strings, so there's no reason to have a fucking struct with a len field, because you can get this information with strlen anytime you want.

Using a uint16_t for string length? Yeah that is pretty fucked up.
At least it's not as bad as C strings though.

Sorry but the OS freeing all process memory upon process destruction has got absolutely nothing to do with assuming the user is retarded or not.

It's almost as if Jow Forums is more than one person!

>linux is written in C because it's a fucking kernel, lmao
I'm writing a kernel in C++17. There's nothing stopping you.

are you sure?

Attached: botnet.png (529x219, 36K)

Any resources to learn how to write good C? I've not written a lot of C, but I were always writing similiar. The problem with C is that there is a lot of badly written code everywhere so...

read practice of programming
read this lysator.liu.se/c/pikestyle.html

uh uh kiddo, you're still going to need C-features in order to implement all the details required to run the stl and features

>nearly interchangeable
are you daft

The only reliable way to improve your code is ironically by coding. Like an artisan refines his skills after years and years of experience, programming isn't anything different.
Having good knowledge about cs theory is one thing, but if you wanna git gud you have to make your hands dirty.

Anything really does, for example try to implement your own c library, it teaches you really a lot.

Ok?

unsure, I've learned by reading djb's, OpenBSD's and Plan 9's codebases, not against any book

enjoy your O(n) strlens faggot

>enjoy your O(n) strlens
>implying you can do it in less time
Come on, dude, this is some low level bait and I probably just fell for it.

#include
#include
// for main
#include
#include

#define INIT_CAP 1

struct string {
int len;
int cap;
char *data;
};

int
string_allocate(struct string *str)
{
char *tmp;
if ((tmp = malloc(sizeof(char) * INIT_CAP)) == NULL)
return -1;
str->data = tmp;
str->len = 0;
str->cap = INIT_CAP;
return 0;
}

void
string_free(struct string *str)
{
free(str->data);
str->len = 0;
str->cap = 0;
str->data = NULL;
}

int
string_append(struct string *str, char *s, int n)
{
if (str->cap - str->len < n) {
char *tmp;
int new_cap = str->cap * 2;
while (new_cap - str->len < n)
new_cap *= 2;
if ((tmp = realloc(str->data, sizeof(char) * new_cap)) == NULL)
return -1;
str->data = tmp;
str->cap = new_cap;
}
memcpy(&str->data[str->len], s, n);
str->len += n;
return 0;
}

int
main(int argc, char **argv) {
struct string str;
if (string_allocate(&str) < 0)
err(1, "string_allocate");

for (int i = 0; i < argc; i++)
if (string_append(&str, argv[i], strlen(argv[i])) < 0)
err(1, "string_append");

printf("%.*s\n", str.len, str.data);
string_free(&str);
}

If you modify the string you have to run strlen again so caching the length is redundant.

strlen is for entry-points only, you should have a control over the string lengths in a good program and never use the string functions otherwise

what a nice security issue I've made, can (You) spot it?
Hint: [spoiler]signness[/spoiler]

The main issue with this code is that `data` is never actually freed. string_new() allocates memory via strdup(), which should be freed via free(), but the only thing that string_free() frees is the memory allocated for the struct itself. I'd say that dynamically allocating memory for a tiny struct like that and passing around a pointer is pretty overkill though when you can pass structs around by value in C just fine.

Another issue is that `if (string == NULL)` is completely pointless as free() already does nothing for NULL. Also better to use `size_t` and `char *` rather than `uint16_t` and `uint8_t *`.

worse performance.
1. it adds another indirection. the string object is a pointer, and data is another pointer.
2. to create a new such string, you need to copy the contents of the char*
3. it's even worse since strdup is linear in the length of the char*, since it has to iterate over the entire contents, and then strlen is also linear, since it also needs to iterate untill the end.

also, it's weirdly designed
4. string_new always allocates on the heap using malloc. there's no function to create a string on the stack without dynamic memory allocation.
5. free_string() is pointless. free(NULL) is a no-op, so you don't need to write a function that checks for that case separately.
6. apparently you're not supposed to create a NULL string. but in that case the program first allocates the memory for no reason at all and then aborts.
7. the length is an int with 16 bits which should be enough for most cases, but it's still weird to specifically ask for 16 bits.

You also need to implement C libraries in order to use these "C-features".

No, C can be used as standalone without any library support or runtime with -nostdlib

You can do that with C++ too. You can't use RTTI or exceptions, but "C++-features" like classes, namespaces, inheritance (basically what you use bare C++ for) are there

>5. free_string() is pointless. free(NULL) is a no-op, so you don't need to write a function that checks for that case separately.
that's not true, the code should be symmetric, how do you know the struct doesn't point to another memory location (which it does in this code) and also should be freed.

the free_string code doesn't free string data, only frees the struct, probably because the author is a retarded codemonkey.

>6. apparently you're not supposed to create a NULL string. but in that case the program first allocates the memory for no reason at all and then aborts.
Now go back and actually read that part of the code

there's absolutely nothing wrong with it and pretty much every C project has to come up with some string functions to make dealing with strings less painstaking

end thyself

TPOP (recommended above, surprisingly) and the unix/inferno/plan 9 codebases. also ioquake3.

if you balk at that, you should see lcc. every string gets put into a hash table, so that instead of using strcmp you can just write "if(s1 == s2)".

>yes, and it does so in a much less clear way
I honestly don't mind avformat_open_input or stbi_image_free.

whoops nvm, i shall leave in shame

>sepplesfag talking about clarity and the pitfalls of having to juggle millions of things
Classic.

That said, namespaces are superior solution in theory, but they get mangled, and mangling isn't standardized for whatever dumb reason which results in dumb shit like extern "C".

1) Dont use typedefs
2) Asterisks go on the name
3) Don't call abort in allocators
4) The string might as well be inside the struct
5) free(NULL) does no harm, so why even check
6) This example does not even use the string it makes

>1) Dont use typedefs
no; fuck spam

You forgot templates.

>If you modify the string you have to run strlen
No you don't.

are you trying to further nauseate everyone?

It'll only nauseate literal retards and I'm fine with that.

you're like a scat fetishist, i simply can't conceive of people who actually like shit like templates

You're also leaking memory, kek.

the actual problem with the string_free is that it doesn't even free the data.

The string_new checks for a nullptr being malloc'd, but doesn't give a shit if strdup returns nullptr

The reason for having strings like this is being able to store any kind of binary data in them - you can't do that with C strings because your binary data could have zeroes in it.

I don't think it does, point to specific issue

Templates are simply syntactic tool which compiler then turns into an ordinary code, are they not? I thought you can use them even without stdlib.

templates are fine for data structures, at the end of the day you don't care about the payloads, why the operation you can do with it.

>Templates are simply syntactic tool which compiler then turns into an ordinary code
Correct
>you can use them even without stdlib.
Correct

The person you're replying to in know way implied that templates couldn't be used without the standard library.

Yeah, guess I failed at reading comprehension.

Don't in C you have to juggle a "million of things" because of the oversimplifications of the language. You're probably troll anyways. Nobody is this stupid.

Yes. In C++, everything is more simple.

Why not use an existing library? You'll probably need one for UTF-8 support anyway.

Quick question? Why do Cniles subject themselves to this pain?

Simpler.
Fucking murrican.

strlen() returns size_t, which is unsigned, but the function takes an int?

not what I meant, if you pass a negative length into string_append, it will get casted into huge positive size_t for memcpy