Thread 106865259

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.

>>106865259 (OP)
Just use unsigned char, mongoloid. Alternatively you can use an onion.

just use mimalloc

>>106865299
>Just use unsigned char
Doesn't work the other way around.

>>106865259 (OP)
u wot m8?

>>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.

>>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.

>>106865259 (OP)
lmao rules always get violated, and that's fub
what kind of haskell cuck are you

>>106865259 (OP)
>strict aliasing
It's a meme ignored by everyone.

>>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.

>>106866791
Can you show me some standards-compliant Ada and PL/I code implementing a fully generic allocator backed up by statically allocated storage?

>>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;

>>106868153
Why would an Ada program need to re-implement something that is built in?

>>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

address is not some abstract shit
address is an integer number
this is basis concept of computers

>>106865259 (OP)
>arena
>look inside
>memory pool

C++
retards hit wall cose can find the door
lets make a hole for em!

C++
retards hit wall cose can find the door
lets make a hole for em!
too many holes everywhere- building collapses

>>106870042
>can
cant

>another thread full of low IQ posts.
Fuck sake.
>>106869953
This is wrong. You're retarded and don't know C.

>>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.

>Arenas are the new hot programming meme.
for retarded C++ retards

>>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.

>>106869935
Talk is cheap. Show me the code.

>2025
>falling for the multics/ada/pli bait
https://yarchive.net/comp/pl_i.html

>>106865259 (OP)
>Just use error check nigga

>>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.

>>106865259 (OP)
Man how the fuck do I keep up with all these things? So many features and paradigms and shit.

>>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.

>>106869953
Yes, it is

>>106872005
7/10 bait

>>106871986
>reading comprehension

>>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

>>106872134
>can cast char* to anything
No you can't, retard. Only the opposite is true.

>>106872277
can cast anything* to anything
also >>106869953

>>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.

>>106872134
Casting onions in C is not strict aliasing, chud, that is only in C++.

>>106871986
That's what rust does

>>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.

>>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.

>>106865259 (OP)
Just use pools of typed values while wondering who the fuck cares, problem solved.

>>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.

>>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.

>>106875413
This works fine, but you can't technically "recycle" that memory for objects of other types without using -fno-strict-aliasing.

>>106876505
What is the declared type of memory returned by mmap?

>>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++,

>>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.

>>106876674
undefined, mmap is not standard C

>>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

>>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.

>>106876516
>most productive day was throwing away 1000 lines of C code.
So he's finally admitting that C was a hoax after all?