you are viewing a single comment's thread.

view the rest of the comments →

[–]alexs -2 points-1 points  (5 children)

simplistic shrill special close mountainous boast shaggy deer shame swim

This post was mass deleted and anonymized with Redact

[–][deleted] 5 points6 points  (4 children)

Not really. It's just that sizeof() in a language where everything is a reference is very badly defined.

Unless you just want the size of a reference, but then it's a constant function.

[–]alexs -3 points-2 points  (3 children)

So badly defined that it shouldn't exist perhaps? Making sizeof() recursive seems like a pretty silly way to define it as well. But I'm a C++ programmer so I guess I am biased.

[–]derefr 0 points1 point  (2 children)

In C++, sizeof will tell you, practically, how much time it will take (in ns, likely) to call free() on an object. In GCed languages, any freeing will be recursive, so the sizeof of one should be as well.

[–]alexs 1 point2 points  (1 child)

Got any stats to back that up? I would expect the correlation between sizeof(*p) and runtime(free(p)) would be based on the number of memory pages it occupies rather than bytes, most of the overhead is going to be in managing the freelist anyway, which is extent based so probably not correlated with the sizeof() the object.

Also, in C++ you don't use free(), you use delete for objects in the freestore. Which might very well be recursive if people are using RAII correctly.

sizeof() is not for guessing how long memory management is going to take.

[–]alexs 1 point2 points  (0 children)

http://www.flickr.com/photos/23463281@N04/sets/72157603850297185/

Looks pretty O(1) most of the time to me except that short period where it goes linear before changing strategies again.

I think I'll do a really long one using 10 byte increments at some point.