← Home ← Back to /g/

Thread 106865259

51 posts 14 images /g/
Anonymous No.106865259 [Report] >>106865299 >>106865416 >>106865948 >>106865948 >>106866020 >>106866194 >>106866791 >>106869935 >>106869983 >>106870225 >>106871986 >>106872005 >>106872029 >>106872134 >>106872656 >>106875413
Arenas are the new hot programming meme.

Despite this, you can't implement an arena backed up by a statically allocated buffer in C and C++ without violating strict aliasing rules.
Anonymous No.106865299 [Report] >>106865410
>>106865259 (OP)
Just use unsigned char, mongoloid. Alternatively you can use an onion.
Anonymous No.106865373 [Report]
just use mimalloc
Anonymous No.106865410 [Report] >>106865880
>>106865299
>Just use unsigned char
Doesn't work the other way around.
Anonymous No.106865416 [Report]
>>106865259 (OP)
u wot m8?
Anonymous No.106865880 [Report]
>>106865410
>programming language committee introduce an anti-feature
>we all agree on breaking it
May the people in the committee is not as smart as you think.
Anonymous No.106865948 [Report]
>>106865259 (OP)
>Arenas are the new hot programming meme.
>new
How ?
>>106865259 (OP)
>without violating strict aliasing rules
Honestly, they get violated pretty often. See struct sockaddr.
Anonymous No.106866020 [Report]
>>106865259 (OP)
lmao rules always get violated, and that's fub
what kind of haskell cuck are you
Anonymous No.106866194 [Report]
>>106865259 (OP)
>strict aliasing
It's a meme ignored by everyone.
Anonymous No.106866791 [Report] >>106868153
>>106865259 (OP)
Ada 95 had that feature with storage pools and even older languages had it like PL/I AREA allocation which had it in the 60s. C/C++ are at least 30 years behind the times, sometimes 50 or 60 years behind, but people want to pretend C and C++ trannies are "genius" for doing a worse version of something people did decades ago and then going WE WUZ KANGZ by pretending they invented it.
Anonymous No.106868153 [Report] >>106868281 >>106869112
>>106866791
Can you show me some standards-compliant Ada and PL/I code implementing a fully generic allocator backed up by statically allocated storage?
Anonymous No.106868281 [Report] >>106871579
>>106868153
They're part of the language. You don't have to implement the allocator because the developer of the language implementation does it.
DCL XXX AREA(10000) STATIC;
Anonymous No.106869112 [Report] >>106871579
>>106868153
Why would an Ada program need to re-implement something that is built in?
Anonymous No.106869935 [Report] >>106871594
>>106865259 (OP)
>you can't implement an arena backed up by a statically allocated buffer in C and C++ without violating strict aliasing rules.
I can
Anonymous No.106869953 [Report] >>106870215 >>106872100 >>106872603
address is not some abstract shit
address is an integer number
this is basis concept of computers
Anonymous No.106869983 [Report]
>>106865259 (OP)
>arena
>look inside
>memory pool
Anonymous No.106870026 [Report]
C++
retards hit wall cose can find the door
lets make a hole for em!
Anonymous No.106870042 [Report] >>106870116
C++
retards hit wall cose can find the door
lets make a hole for em!
too many holes everywhere- building collapses
Anonymous No.106870116 [Report]
>>106870042
>can
cant
Anonymous No.106870215 [Report]
>another thread full of low IQ posts.
Fuck sake.
>>106869953
This is wrong. You're retarded and don't know C.
Anonymous No.106870225 [Report]
>>106865259 (OP)
>Arenas are the new hot programming meme.
..For the last 30 years. I learned about these in school and I'm out of training.
Anonymous No.106870259 [Report]
>Arenas are the new hot programming meme.
for retarded C++ retards
Anonymous No.106871579 [Report] >>106874134
>>106868281
Then? How do you actually use it? How do you use it for multiple types? How do you allocate and reclaim storage on it?

So far, it's no different than declaring a static unsigned char array in C.

>>106869112
Maybe because the built-in solutions are often not good enough.
Anonymous No.106871594 [Report]
>>106869935
Talk is cheap. Show me the code.
Anonymous No.106871868 [Report]
>2025
>falling for the multics/ada/pli bait
https://yarchive.net/comp/pl_i.html
Anonymous No.106871986 [Report] >>106872113 >>106873789
>>106865259 (OP)
>Just use error check nigga
Anonymous No.106872005 [Report] >>106872105
>>106865259 (OP)
Arenas are indeed a trendy concept in programming these days. But let's not forget that Lisp, the greatest programming language ever created, has been utilizing arenas and pool allocators since its inception. Lisp's dynamic typing and nature of allocating memory in chunks makes arenas a seamless fit. In fact, Lisp's approach to memory management with its garbage collector and dynamic allocation is fundamentally superior to C and C++'s manual memory management which is plagued by issues like pointer arithmetic and strict aliasing.

C and C++'s strict adherence to strict aliasing is just a symptom of their flawed design. They try to enforce type safety through explicit casting, but end up creating more problems than they solve. Lisp, on the other hand, doesn't need such artificial constraints because its macro system and runtime allows for safe and expressive low-level programming. So, while arenas might be a hot meme in C and C++, Lisp has been doing it right all along. Lisp is simply the best, and everyone should be writing in it.
Anonymous No.106872029 [Report] >>106872043
>>106865259 (OP)
Man how the fuck do I keep up with all these things? So many features and paradigms and shit.
Anonymous No.106872043 [Report]
>>106872029
You don't if you aren't an hyper autist teaching at university. In industrie you just pick the right tools for the job and that's it.
Anonymous No.106872100 [Report]
>>106869953
Yes, it is
Anonymous No.106872105 [Report]
>>106872005
7/10 bait
Anonymous No.106872113 [Report]
>>106871986
>reading comprehension
Anonymous No.106872134 [Report] >>106872277 >>106872899
>>106865259 (OP)
This "you can't write malloc in standard c" bullshit has gone on for too long.
union u {int i; float f;} u;
u.i = 1;
printf("%f\n", u.f); //strict aliasing violation, super bad
u.f = 1.;
printf("%f\n", u.f); //fine

int *i = &u.i;
float *f = &u.f;
*i = 1;
printf("%f\n", *f); // le bad
*f = 1.;
printf("%f\n", *f); // fine

char s[4];
union u *p = s; // can cast char* to anything, fine
i = &p->i;
f = &p->f;
*i = 1;
printf("%f\n", *f); // >:( you can't do that
*f = 1.;
printf("%f\n", *f); // cool

char t[4];
i = t; // can cast char* to anything, fine
f = t; // ...
*i = 1;
printf("%f\n", *f); // bad cnile *hits with newspaper*
*f = 1.;
printf("%f\n", *f); // you know the drill
Anonymous No.106872277 [Report] >>106872603 >>106874806
>>106872134
>can cast char* to anything
No you can't, retard. Only the opposite is true.
Anonymous No.106872603 [Report]
>>106872277
can cast anything* to anything
also >>106869953
Anonymous No.106872656 [Report]
>>106865259 (OP)
Aliasing applies to data that is fucking aliased, i.e. you use both pointers of different types. Just having a pointer to an array of bytes is legal.
Anonymous No.106872899 [Report] >>106874806
>>106872134
Casting onions in C is not strict aliasing, chud, that is only in C++.
Anonymous No.106873789 [Report]
>>106871986
That's what rust does
Anonymous No.106874134 [Report] >>106876516
>>106871579
>built-in solutions are not good enough
That's what you get for using a worse-is-better language. You should have used Ada instead.
Anonymous No.106874806 [Report] >>106876505
>>106872277
>Only the opposite is true.
strict aliasing is about aliasing, not casting. If char* can alias anything, it means anything can alias char*.

>>106872899
My point is that unions are not special in c. Read it more closely.
Anonymous No.106875413 [Report] >>106876525
>>106865259 (OP)
Just use pools of typed values while wondering who the fuck cares, problem solved.
Anonymous No.106876505 [Report] >>106876674 >>106876775 >>106877256 >>106877384
>>106874806
>strict aliasing is about aliasing, not casting. If char* can alias anything, it means anything can alias char*.
You can cast any pointer to pointer to signed/unsigned/plain char and it will work as expected.

However, casting an object whose declared type is pointer/array to char (in your example, s) to a pointer of some other type (in your example, union u) and then dereferencing it is UB, regardless of previous writes.

The exception to this rule is for memory that has "no declared type" such as the one obtained by malloc. In that case, writing to it turns that memory into a new effective type for subsequent reads.
Anonymous No.106876516 [Report] >>106878099
>>106874134
Ada is so good that no actual code exists in the wild anymore.

Reminds me of that Ken Thompson quote saying that his most productive day was throwing away 1000 lines of code.
Anonymous No.106876525 [Report]
>>106875413
This works fine, but you can't technically "recycle" that memory for objects of other types without using -fno-strict-aliasing.
Anonymous No.106876674 [Report] >>106877302
>>106876505
What is the declared type of memory returned by mmap?
Anonymous No.106876775 [Report]
>>106876505
>However, casting an object whose declared type is pointer/array to char (in your example, s) to a pointer of some other type (in your example, union u) and then dereferencing it is UB, regardless of previous writes.
Not in C, it's UB in C++,
Anonymous No.106877256 [Report]
>>106876505
In C++ you can construct an object of arbitrary type T on top of a char buffer using placement new. This is the intended purpose of placement new, and the behavior is fully defined as long as you maintain correct alignment and manually call ~T() if necessary before the buffer's lifetime ends. Note that legal access to the T object is through the return value of new, not by casting char* to T* (though I believe the casting version becomes correct if you pass the pointer through std::launder before dereferencing). It is only in C where it is difficult to do this in full generality in a well-defined way, but realistically C programmers can just compile with -fno-strict-aliasing and call it good.
Anonymous No.106877302 [Report] >>106877484
>>106876674
undefined, mmap is not standard C
Anonymous No.106877384 [Report]
>>106876505
it is only UB if the pointer is not properly aligned
that is why you can cast anything to char*, because that will always be aligned
Anonymous No.106877484 [Report]
>>106877302
so we went from saying "you can't implement malloc in standard c because of strict aliasing" to "you can't implement malloc in standard c because mmap is not part of standard c". that seems like an improvement.
Anonymous No.106878099 [Report]
>>106876516
>most productive day was throwing away 1000 lines of C code.
So he's finally admitting that C was a hoax after all?