Old thread: What are you working on, Sup Forums?
/dpt/ - Daily Programming Thread
first for C++
C++ is garbage, mate.
>casts your malloc
third for anime will save programming
Just checking out previous winners of the Obfuscated C Contest. Pic related is the full source for a minecraft visual demo.
fuck off cancer
FUCKING CAPTCHA FUCK GOOGLE FUCK HIROSHIMOOT FUCK DPT
>What are you working on, Sup Forums?
More opengl shaders for image glitching script.
nth for haskell is the best scripting language
On my game codepen.io
Rewrite it in Vulkan.
Spoiler: the game is a red box and some grey ones.
>c++
>malloc
>using new unironically
You sound like the kind of "person" who also uses classes and relies on constructors.
checked
>using new
back into analysing anime images with trueskill + tag data
my original program had tons of linear searches and unnecessary copying and was just generally bad so im rewriting it and hopefully alot more mainainable this time too
and more ambitions to make the program more usable as an actual collection manager and image viewer instead of just a crude statistical measuring / game thing
i'm kind of proud of it, but I know it's also shit
nice quads
what's bad about new ?
It's in sepples (and not C), so it's obviously shit.
delete new int[5]; is undefined behavior.
for a good reason, it has absolutely no purpose or meaning
So is
int *p = new int[5];
some_fn(p);
delete p;
You may not like it but this is what peak performance looks like
int main()
{
long nc = 0;
import core.stdc.stdio : getchar, printf, EOF;
while((getchar() != EOF))
++nc;
printf("%ld\n", nc);
return 0;
}
Just add some green boxes that you have to break by jumping on them to get to the next level, and a highly-abstract plot, and you've got yourself an indie blockbuster
Which learning path would benefit me more in the current job market - JS + React or Python + Django?
>it has absolutely no purpose or meaning
Which means it should be a compilation error, you drooling plusmonkey. There's no sane reason for it to be undefined behavior, or for there to be a separate delete operator for arrays, but this is what you get from a language designed by a retarded gnome.
gj m8
type safety is bad
If C++ were its own language instead of a half baked C derivative, it could have distinguished pointers to arrays and pointers to individual objects and thus avoided this confusion.
iterators and concepts
but malloc is not typesafe
>Just add some green boxes that you have to break by jumping on them to get to the next level, and a highly-abstract plot, and you've got yourself an indie blockbuster
wrote it down
Is int* x = {2, 5, 2}; dynamic in C? What type of structure is this?
>If C++ were its own language instead of a half baked C derivative, it could have distinguished pointers to arrays and pointers to individual objects and thus avoided this confusion.
Hey, guess what? C doesn't need a separate `free` for dynamically allocated arrays, because there's no actual difference. It's just a block of memory. The same is true of C++. There is no rational justification for the way C++ works.
ty
>Is int* x = {2, 5, 2}; dynamic in C?
Pretty sure that's just a compile error.
i assume it sets x[0] = 2; x[1] = 5; x[2] = 2;
thats cool what is the output supposed to look like?
free doesn't invoke destructors, delete does and it relies on static type information to do this. delete[] would not exist if the type system inherited from C did not conflate two entirely different types of data.
C++ sucks because it's built on the back of C.
>What is the output supposed to look like
That is based on what filters are applied. Here is one with all of the filters I have so far.
The script takes a list of shaders that it loops through to post process the imported image. I wrote it so I can write shaders that do different things and apply them in different orders.
Eventually I want to have some effects that can mimic VHS tape looking glitches or other glitchy types of effects. I would also like to be able to output webm or gif versions of animated glitch filtered images.
>free doesn't invoke destructors, delete does and it relies on static type information to do this.
Are you seriously stupid? The array vs. pointer issue has nothing to do with static type information.
wrong image
fuck microsoft
free is a procedure that take an address while new is a polymorphic operator. comparing them is stupid
Yes, it does. delete is overloaded on the type of its operand so it can invoke the correct destructor, but that's not enough to distinguish between pointers to arrays and plain pointers which have different destructors. The implementation of this feature is now botched because of the poor type system.
Whats the most responsibility you've taken on writing code?
I've written code for:
>huge refrigerators for supermarket warehouses
>small cold shelves for supermarkets
>cash machines in shops
>arcane machines and other gambling machines
>an elevator
Typical /dpt/ droolers...
void kys1(Foo *foos) {
delete[] foos;
}
The only different between deleting a single Foo and an array of Foos is in how many times you have to call the Foo destructor. As you can see, C++ uses runtime information, rather than static type information, to figure out how many times it needs to call the Foo destructor anyway.
Do programming socks really work?
Yes, but people are using them wrong. You are meant to brew tea out of them, not actually wear them.
Using new is very old style C++. New C++ is all about smart pointers.
I don't see what that has to do with anything. You still have the artificial distinction between delete and delete[].
JS noob here, how do I use D3JS from node where there is no DOM to select from? Or is there?
Say I just want to feed it a text file to visualize, can I do that? How?
New is bad because you risk forgetting to release resources. In the words of Bjarne Stroustrup:
>The main problems with free store are:
>1. Leaked objects: people use new then forget to delete the allocated object.
>2. Premature deletion: People delete an object that they have some other pointer to and later use that other pointer.
>3. Double deleteion: an object deleted twice, invoking its destructor (if any) twice.
>As alternatives to using "naked" news and deletes, I can recommend two general approaches to resource management that avoid such problems.
>1. Don't put objects on the free store if you don't have to; prefer scoped variables.
>2. When you construct an object on the free store, place its pointer into a manager object, (sometimes called a handle) with a destructor that will destroy it.
Using manager objects are very useful with exceptions where if an exception occurs, the object will automatically get deallocated without you having to handle it manually.
>I don't see what that has to do with anything
That's because you're a literal retard, so let me reiterate:
The only difference between deleting a single Foo and an array of Foos is in how many sub-blocks the destructor is called on. C++ already uses runtime information to figure that out. Ergo it could use runtime information to figure out if to call the destructor once for a single Foo, or N times for an array of N Foos. If it knows which destructor it has to call (which it does), then it knows the size of a single object of the class to which that destructor belongs. If it knows the size of the memory block it has to free (which it does), then (in conjunction with the previous bit of information) it knows how many elements it needs to call said destructor on. There is no significant practical reason for there to be a separate delete operator for arrays.
I wrote some software for an autonomous data collection module for a remotely controlled subsea vehicle. It basically pulled a bunch of telemetry from a bunch of subsystems and would run the data probing on the subsea pipeline automatically and send the rov pilots maneuver instructions. risk of failure was delaying a drill rig's schedule, which would result in ~$1mil/day costs.
Once I finish my masters I'll be working on guidance software like in your pic or control algorithms for landing craft.
Traps are shit, go fuck yourself.
cute boy
what about
delete arr
vs
delete arr[0]
>There's no sane reason for it to be undefined behavior
The reason why it is undefined behavior is all thanks to C not having proper arrays, you dumb baka.
The runtime information describing the size of the array you're referring to is only inspected if you're using delete[] and only created on new[]. If you were to change C++ so that this hidden array size cookie were created on new and inspected on delete (thus collapsing delete and delete[]) together you'd be incurring additional overhead on regular allocations, which is clearly undesirable.
>If it knows the size of the memory block it has to free (which it does), then (in conjunction with the previous bit of information) it knows how many elements it needs to call said destructor on.
allocators like malloc are free to overallocate. The capacity of the chunk can not be used to determine the size of the array. The array size must be stored separately.
>delete arr
>vs
>delete arr[0]
What about it? Your second line implies `arr` is an array of pointers, so in the first case, no destructors have to be called at all, and in the second case, the logic outlined in my previous post applies to the element `arr[0]`.
>it is undefined behavior is all thanks to C not having proper array
See for a detailed explanation for why you're retarded.
Yes.
>you'd be incurring additional overhead on regular allocations, which is clearly undesirable.
Funny, because that's exactly what C++ does to allow for virtual methods.
>allocators like malloc are free to overallocate
They're also free to store arbitrary metadata about allocated blocks. None of this is relevant because nothing in the C++ standard says you have to use "allocators like malloc".
First of all, using type information for the number of items is completely reasonable.
If you want that information to be static, then use std::array.
Secondly, there's this thing called overhead, which is why operator delete exists.
If you know you only have 1 object (usually is the case), you can use operator delete with none of the RTTI overhead.
Anyway, as other people in this thread have said, operator new and delete are old C++98 things.
Nowadays we use smart pointers and std::array which have none of these problems. Now go away.
c++ will never be good because it carries so much cruft from pre c++11
so much potential lost
cant wait for 2050 when we maybe have rangev3 (without range algorithms) a gimped split version of std and std2, gimped concepts, and coroutines which is litteraly like a 50 line gcc extensions hahahaa
>First of all, using type information for the number of items is completely reasonable.
Irrelevant. I wasn't arguing anything about the reasonableness of it.
>If you know you only have 1 object (usually is the case), you can use operator delete with none of the RTTI overhead.
You clearly didn't understand a single thing I said.
>c++ will never be good because it carries so much cruft from pre c++11
There's nothing forcing you to use the old stuff, you know.
Unless of course if you're implementing the standard library.
All of C++'s problems are thanks to C, so blame C for being such a shit language.
On the other hand. As a result, C++ is pretty flexible and can do a lot of things, as long as you know what you're doing.
>You clearly didn't understand a single thing I said.
And you're just picking ancient things to whine about which
1. is all C's fault.
2. has been obsoleted already.
>1. is all C's fault.
This moronic view has already been disproved.
>2. has been obsoleted already.
Irrelevant. The discussion was about yet another design flaw of C++.
it holds the standard itself back because of backwards compatibility as well as the comitties ridiculously conservative attitude
Are you referring to vptrs? I'm not sure what that has to do with allocators or new other than being something that contributes to the size of an object.
>They're also free to store arbitrary metadata about allocated blocks.
An allocator is not concerned with what it's being used for. There's no reason why the allocator should be required to store the logical/requested size of a chunk, something the client is already aware of.
>None of this is relevant because nothing in the C++ standard says you have to use "allocators like malloc".
Tightly coupling new[] to an allocator which has overheads that are pointless in any other circumstance runs contrary to the idea of new, which can be overloaded at will to drop in any other allocator.
Goodnight /dpt/
>This moronic view has already been disproved.
No it hasn't.
If C had proper array types, operator delete[] wouldn't need to exist without adding extra RTTI overhead.
>Irrelevant. The discussion was about yet another design flaw of C++.
We know it's a design flaw (which is rooted in C), that's why it's OBSOLETE you dumb fuck.
No one uses it anymore except for stdlib implementers, so yes it's of course relevant to this """discussion""".
Stop whining about obsolete things that have already been solved.
And it's not even an issue if you're not a dumbfuck who doesn't know what you're doing.
depends on what you need.
"the best tool for the job"
what happen to foos's elements?
They get もう死んでる'd
>Are you referring to vptrs? I'm not sure what that has to do with allocators or new
Nothing. Just an illustration of how inherently weak your argument is, even if all alternatives did incur a tiny bit of memory overhead per allocation (which I severely doubt, and so far you haven't proven).
>There's no reason why the allocator should be required to store the logical/requested size of a chunk
No one said anything about requiring the allocator to store the logical/requested size of a chunk.
>Tightly coupling new[] to an allocator which has overheads that are pointless
>which has overheads that are pointless
Unsubstantiated.
>that are pointless
Cool opinion. Personally, I find that there is some point in having a language design that isn't pure and unadulterated broken shit.
>which can be overloaded at will to drop in any other allocator.
This is the only semi-valid argument made by your side so far: yes, it does put additional requirements on the allocator. I guess if you genuinely believe that freeing allocator implementations from this additional burden (as if people regularly implement their own allocators and that complicates it so much) justifies shitty language semantics, then maybe to you this design choice may seem reasonable. Anyone can take a glance at C++ and see where this sort of logic leads in the long run.
Re-reading K&R with betterC in mind.
// ex 1-9
int main()
{
int c;
import core.stdc.stdio : getchar, EOF, putchar;
while ((c = getchar()) != EOF){
if (c == ' '){
putchar(c);
c = getchar();
if (c == EOF) return 0;
else while (c == ' '){
c = getchar();
}
}
putchar(c);
}
return 0;
} // " t e s t"
Shit tier fortran clone
>even if all alternatives did incur a tiny bit of memory overhead per allocation (which I severely doubt, and so far you haven't proven).
They provably do.
itanium-cxx-abi.github.io
new[] allocates an additional size_t for a cookie, which is only ever used on a delete[] operation to determine how many elements are to be deleted. Your suggestion seems to be to always allocate this cookie when using new, and to always use this cookie when using delete so delete is identical to delete[].
>No one said anything about requiring the allocator to store the logical/requested size of a chunk.
Then what metadata are you suggesting the allocator store?
>I guess if you genuinely believe that freeing allocator implementations from this additional burden (as if people regularly implement their own allocators and that complicates it so much) justifies shitty language semantics
I already described how none of this is necessary if the type system is strong enough. You can have stronger and simpler semantics without it coming at the cost of efficiency. C++ doesn't have this because it based itself on C.
>All the downsides of C with none of the benefits of C
What is the actual fucking point of programming in "C" with a bloody nigger'ing GC??
How do I stop the cookie monster from eating my array cookies?
>They provably do.
Then provide proof.
>new[] allocates an additional size_t for a cookie
What `new[]` does is irrelevant. Your claim seems to be that you can't keep track of the number of elements in a block unless you store the logical size of every allocated block.
>Your suggestion seems to be to always allocate this cookie when using new
I never suggested this. My first example did have a flaw in that it assumed an allocator that doesn't over-allocate, which you pointed out, and my response was that an allocator can store arbitrary meta-data; the only requirement is that it should be possible to keep track of how many elements are in a block. For instance, if the allocator already keeps flags for every block, it could have an array flag at no extra cost, and only store the number of elements for blocks with the flag set.
>I already described how none of this is necessary if the type system is strong enough.
Static typing information doesn't solve this unless you disallow deleting an array through a pointer to its first element. In any case, that's not what the argument was about.
>benefits of C
ROFL
It has about 1 benefit (if you don't consider C++): performance.
Why is mysql so slow? I need to insert 290k rows and it is only going at about 50/second this will take fucking forever
D with betterC, with LDC and GDC will go through the same performance optimizations as Clang or GCC. It has the same memory model as C.
>openly supporting C++, D or Rust
Why is this allowed?
+ plus GC
You have no clue what you are on about, which is pretty normal for /dpt/
Not your safe space
c++ barfs into caches like a drunken college freshman. even on modern systems, profiling c++ cache behavior makes me want to murder the garage troll that created it. when working with embedded systems, many of which still use 8 and 16 bit processors with tiny caches, c becomes mandatory.
The board has rules against extremely low-quality and off-topic shitposts, though. So again, why is it allowed?
>I can abuse objects with means C++ is bad!
C++ isn't about OOP m8. You're just looking at shit code.
I provided you the proof, the C++ ABI specifies exactly how the number of elements in a new[] array is tracked.
>For instance, if the allocator already keeps flags for every block, it could have an array flag at no extra cost, and only store the number of elements for blocks with the flag set.
Okay, I'm beginning to see what you're getting at here. The allocator stores an extra bool which determines whether it's storing the result of a new or a new[], and then delete will test the bool to determine if it's referring to the result of a new or new[]. Then it can take the appropriate behavior.
If that's right then it's better, but it's still adding another branch in every call to delete.
>Static typing information doesn't solve this unless you disallow deleting an array through a pointer to its first element. In any case, that's not what the argument was about.
It's what the whole argument began over. If C++ used Foo* to refer to a Foo and Foo(*)[] to refer to an array of Foos, then the choice between delete and delete[] could be resolved at compiletime for no additional overhead. This has been my point the entire time.
Because it's not of low-quality or off-topic shitpost that's why.