Really? Do you have what it takes?
Yes, it does compile.

Everything

I dont get it, whats different/strange here? .-.

vector.data() will give the pointer to what you just initialised, delete will clear the data it points to, so after this you should be left with an empty vector
if im not mistaken

@azuredivay who owns that memory?

@Demolishun the process that was spawnned..?

nigga just answer 💀

AHH u mean, the vector wont be pointing to anything? is that the joke? ._.

coz delete would deallocate the memory assigned for its data?

I guess the joke is that delete is for stuff allocated on heap with "new", but the thing that is deleted here is allocated on the stack.

Thanks for the C++ PTSD flashbacks, btw!

Also, what kind of maniac sets his IDE to show whitespace as little dots? It‘s honestly making me aggressive just by looking at it! 😂

@Lensflare the data in a vector is heap.

@azuredivay

Of course it's gonna compile.

The delete will only free the memory for the first element, but it will likely crash anyway when that vector goes out of scope and its destructor tries to free an already partially freed block...

Or!

Fun shenanigans could happen if something else allocates an int in the heap and it gets that same address...

@CoreFusionX really? .-.
isnt it sequential memory block? as long as the 1st thing it's pointing to is null (which is what Delete would do here) wont C++ ignore the rest? i.e., the "someData" would hold a null pointer, which isnt a rare occurrence
And if the address space is assigned to something else, it'll overwrite it so I dont see it causing any big issue

At this point it's faster to type it n test eh -.-

@azuredivay

So, by all means, do.

Some misconceptions need clearing up first, though.

Bear in mind much of this stuff is implementation dependent, and when so, I'll mark it with (ID).

Is vector a sequential block of memory? No. A vector has a stack part (usually three pointers, ID), and an allocation in the heap for its contents.

Does delete set the deleted pointer to null? No. For all it cares, it *could*, but it's (ID) and most don't. You also have the aliasing problem to contend with.

data() returns a pointer to the beginning of the heap allocated storage, but how this storage is allocated is (ID), and can even be custom if you have a custom allocator!.

malloc/free, new/delete and new[]/delete[] each do their own (ID) bookkeeping, and mixing them is undefined behaviour.

Double deletion, which would happen when the vector went out of scope, is undefined behaviour.

And as always, when we are in UBland, *pray* that you get a crash, cuz that's best case scenario :).

What exactly happens in this scenario is very ID, but from what I know of most STLs, default allocator is just operator new, in which case, the whole vector storage would be freed, but should you do it in say, data() + 2, chaos will ensue.

Moral of the story: Fun academic discussion, but do not try this at home!

@CoreFusionX I would say it is heaps of fun!

@CoreFusionX This is fascinating and terrifying.

The amount of bullshit that you need to know and keep in mind about memory management in C++ is absurd!

@Lensflare

Not really. All you gotta know it's that if you want an array-like container, use std::vector, and if you need a pointer to something just use std::shared/unique/weak_ptr (depending on how you wanna deal with ownership) and call it a day.

Modern C++ devs should never use new/delete.

It just so happens that many C++ devs didn't get past the "C" part XD.

All in all, the bottom line is *know what you are doing*.

Even if you run with a language provided safety net, your code will always be better if you know what you are doing, and being able to go elbow deep in these things is just another tool in your belt.

As I always say, learning to drive with a MT lets you drive an AT later. The other way around... Heaps of fun... And flaming metal.

Examples of usefulness of this kind of knowledge come in stuff like small string optimization and other such compiler/STL tricks that give C++ the same speed as C while actually being safe if you aren't a dumbass, but yeah, they are aimed to be transparent to your everyday dev.

@CoreFusionX

"Modern C++ devs should never use new/delete."

I don't know how you could use Qt that way.

@CoreFusionX
My last contact with C++ was before the time that std::shared/unique/weak_ptr was added officially. I think it was before C++11.
And back then, new and delete was the standard. It’s crazy how a language feature that seems so fundamental can completely be replaced by a standard lib level feature.

@Lensflare so I was curious about a "modern" c++ project. I figure a well tested and modern game engine like Godot. Well, they have completely redefined new/delete and have custom allocator macros too. These all use malloc and free. I am guessing there are very good reasons to do this, but it certainly isn't getting rid of new and delete. They support multiple platforms including phones. It seems it has ref counting built into the allocators. Not sure how that is being used. Sure is interesting though.

@Demolishun

Game engines tend to use custom allocators, particularly in ECS systems to ensure all entities of a given type are allocated next to each other, to promote cache locality, and to prevent actual allocations (which are mighty slow) mainly.

@Lensflare

It's the burden of C++.

In order to maintain ABI compatibility, they must keep many things that shouldn't be used nowadays, that's why more and more things move towards the STL with each new standard.

(And the STL implementations are behemoths of buried brilliance)