Return Styles: Pseud0ch, Terminal, Valhalla, NES, Geocities, Blue Moon.

Pages: 1-

I have memory leaks.

Name: Anonymous 2010-01-17 9:51

I have memory leaks... I don't know the cause of it, but I suspect it has something to do with the calloc prostitute I slept with. I'm going to the doctor later to have a my memory analyzed. Lets hope it's nothing terminal.

Name: Anonymous 2010-01-17 10:04

I don't know how you can have memory leaks.  Almost the first, more likely the second, thing I was taught in C++ was about memory leaks, their causation and how to prevent them.

Name: Anonymous 2010-01-17 10:08

Can't you just run dtrace?

Name: Anonymous 2010-01-17 10:32

LEAK MY ANUS

Name: Anonymous 2010-01-17 12:07

You should probably see a doctor about that.

Name: Anonymous 2010-01-17 12:19

Doctor valgrind may help you

Name: Anonymous 2010-01-17 15:19

>>2
cause
Programming in C++?

how to prevent them
Not programming in C++.

Name: Anonymous 2010-01-17 19:34

>>2
Memory management in C is not difficult, even in multi-threaded contexts. You just need to be properly disciplined; let the code exhibit strong proper ownership semantics. Every alloc should be immediately matched with a free so the code is easily auditable. Have thin messaging pipes between threads, erlang-style, instead of mutexes and shared objects everywhere. This is not hard. Comments like "this object is freed by x" or "you should free the returned value" is an indication of bad design. Never return an allocated object with the expectation of it being free()d; instead let the caller allocate it first and pass you the pointer to initialize it, or otherwise wrap alloc+init together and destroy+free together so that the caller code is again symmetric.

Memory management with exceptions in sepples, conversely, is very fucking difficult. A big reason why this is probably the case is because sepples programmers are shitty; they don't understand how important proper object ownership is, so unless you architected the system yourself, the thing is a memory management nightmare. They do stupid fucking shit like wrap everything in shared_ptr and hand them about willy-nilly. Then they wonder why the code is slow and why they still leak when they have reference cycles. I have worked on projects like this in industry before; it's horrible.

I really hope that move semantics fixes this problem in sepplesox. unique_ptr looks very, very good, especially since it obsoletes the boost pointer containers, and move semantics will make it possible to return big data structures by value without performance considerations. Less pointers about is always a good thing.

Name: Anonymous 2010-01-17 20:35

>>8
instead let the caller allocate it first and pass you the pointer to initialize it,
Sometimes that's fine, but other times I think this complicates things, let's say you're calling a complex function that reads some user input of unspecified size and generates a large complex nested, maybe even cyclic structure from it. Are you going to query that function for all the needed sizes and how to build the object? I think it's easier, faster and safer to have the function allocate the object for you, and give you a free/destroy function which you can use to deallocate the object and all its children, without needed knowledge about the internals of the object and thus preserving encapsulation. Most high-level languages work like this. While it may be true that such languages tend to have garbage collectors, nothing prevents you from calling the destroy function manually once you no longer need the object. If non-local transfer of control happens, things do get a lot more hairy, but not by too much (try{}finally{}, UNWIND-PROTECT, dynamic-wind or similar should be used for cleanup).

Name: Anonymous 2010-01-17 20:55

instead let the caller allocate it first and pass you the pointer to initialize it
So instead of having the allocation done in the function that creates the object, you now need an allocation call (of the proper size too) at each point the function is called? You just made the code more inefficient, duplicated, and even harder to maintain.

Name: Anonymous 2010-01-17 23:36

>>9
I think it's easier, faster and safer to have the function allocate the object for you, and give you a free/destroy function which you can use to deallocate the object and all its children, without needed knowledge about the internals of the object and thus preserving encapsulation.
Isn't this what I said? Or did you stop reading half-way through my post? Here's the relevant part:
or otherwise wrap alloc+init together and destroy+free together so that the caller code is again symmetric.
So yes, if you want to make a function call that returns to you an allocated object that builds such a tree, you should have a matching function call that destroys the tree. The whole reasoning behind it is symmetry and encapsulation; you can audit the fact that the tree is properly managed simply by looking at the matching init and destroy calls.

>>10
So instead of having the allocation done in the function that creates the object, you now need an allocation call (of the proper size too) at each point the function is called? You just made the code more inefficient, duplicated, and even harder to maintain.
What? I've done none of those things. As I said, you solve code duplication by wrapping alloc+init together and destroy+free together. Exposing init and destroy, however, allows you to e.g. stack allocate or field allocate the object, so such code can be made much more efficient.

Name: Anonymous 2010-01-18 5:23

>>9

You can allocate memory inside of an initializing function in c and hand it back with the caller. The fact that you need to know what you're doing to do it, forces programmers to realize they have allocated memory floating about.

Name: Anonymous 2010-01-18 6:32

>>8
Every alloc should be immediately matched with a free so the code is easily auditable.
This "immediately" of yours provoked my curiosity. Is that a specific C-coders' "immediately" that means "couple of screens later, maybe in two or three places in case of multiple exits, maybe with gotos to the cleanup code from everywhere instead"?

Name: Anonymous 2010-01-18 6:59

freeing memory is like doing chores. you don;t want to do them and its not fun, but you'll do them when its really essential - eg your program is leaking a shit ton of memory.

people that free memory really enthusiastically are like people that tidy their rooms all the time and like clean kitchen floors for fun.

Name: Anonymous 2010-01-18 7:15

>>14
Or you could hire a maid to do the cleaning for you!

Name: Anonymous 2010-01-18 7:23

Too bad that it's hard to find a maid willing to clean the houses of so-called `C' types, as they aren't tagged/marked properly, which makes it harder to tell garbage from useful data.

Name: Anonymous 2010-01-18 12:39

>>14-16
lol'd

but >>14 is a hippie

Name: Anonymous 2010-01-18 15:27

>>15
And then hax her anus

Name: Anonymous 2010-01-18 15:36

>>16
try the fat, smelly, neckbearded ones. they usual get the job done and give head too.

Name: Anonymous 2010-01-18 16:23

>>16
This will be fixed after we have replaced scientists with artists.

Name: Anonymous 2010-01-18 19:20

>>20
And artists with mental cases? And mental cases with programmers?

Name: Anonymous 2010-01-18 19:38

>>20
Oh good.  There would die the last shreds of anything consistent in computers, programming or otherwise.  I can hardly wait until the processor which works on a language of kelly-green jelly beans.

Name: Anonymous 2010-01-19 3:43

>>21
mental cases = programmers

Name: Anonymous 2010-01-19 13:46

Memory leaks? My memory is fine. I can't remember the last time I forgot something!

Name: Anonymous 2010-01-19 22:47

>>23
Thats you're opinion. If the programming community all act's like /prog/ then your correct.

Name: Anonymous 2010-01-20 3:34

>>24
lol'd

Name: Anonymous 2011-02-04 12:00

Name: Anonymous 2013-08-31 6:55


Reviving the VN thread: anything VN related goes.

After having finished ML series right after reading through Muramasa, I decided to change the pace and started reading LOVELY x C^TION. The "datesim" part's implementation is underwhelming. Can't really say much about the story since I just started reading it a few hours ago, but I'm already in love with Amagase. Moe overload

Name: Anonymous 2013-08-31 7:40


 You know who wasn't stupid? The guy who invented the pet rock.

Name: Anonymous 2013-08-31 8:25


Is anyone willing to explain the story of Umineko as simply put as possible?

Name: Anonymous 2013-08-31 9:11


I made a big mistake bringing Marisa with me. There aren't any partner spellcards on the floor (only in secret rooms, but I have found only one). I prepared her to do massive damage with spellcards, so she sucks at one-on-one battle.
Don't change these.
Name: Email:
Entire Thread Thread List
All trademarks and copyrights on this site are owned by their respective parties. All comments and posts are the responsibility of their own posters.
- Tinychan + 2ch Mode -