Sepples Timer Issue

So I have this timer class implementation mostly done with extensive use of boost, bind, etc. It's logically structured as having a default container and containers are available as a type so you can include them with any classes. When the container dies, so do the timers in it. There's a specific timer thread in this application that does all timer operations.

After coding for 5 hours straight, I've no fucking clue what I'm doing and this is likely the last barrier to my code working masterfully.

I have a class that's implemented as a singleton that manages all the resources necessary to it. When I pass resources for it to handle, it works perfectly fine if I only pass resources once before the timer ends. However, if I queue up numerous resources to handle, the timer causes a heap error upon the first completion of the timer which is supposed to spawn another timer that does the same thing.

The only thing I can think of is that I'm doing pointer-to-member functions wrong, but god damn if I can figure out how to do it.

Any anons happen to have advice or questions about things I should be elaborating on? Thanks in advance.

why does your timer class use boost, bind etc?
why is there even a mention of singleton?
do you know how to program? because I don't think you do

>>2
It's far more extensible than timer classes that don't utilize functor capability.

There's a mention of singleton because it's my understanding that there's a difference between an instance of an object's functions and the location of the base object's functions.

Do you know how to program?

>>3
son, I can assure you I know what I'm talking about. it seems to me like you fell into the trap of wanting to convolute your design with as many buzzwords as possible. I've seen it happen to countless grad kids, and I can see it's happened on you.

tell me, was it worth it? you're no segfaulting and leaking memory out the ass. you truly are pitiful.
post your code, so I can look at how foolish you are

Code or GTFO

also what you said about singleton's sense makes no goddamn sense at all.

>>3
son this is like the wild west of programming. you either post your code, or you will get trolled, and i'll make sure of it.

>>4
Oh. Thank you for your assurances, Mr. Anonymous.

>>5
If there's nothing of use by the time I wake up, I'll post some code. I'm well on my way to passing out at the moment.

>>7
It would seem you are too late.

I don't see how the hell are people supposed to help you fix your own bug if you don't post code.

So, tell us why didn't you use a global variable instead of singleton?

>>10
Because
1) That's not good form.
2) This project is much too complicated to have global variables sitting out there.
3) How would I limit a global variable to a single instance? Yeah, exactly. You either have to create duplicate objects by using static so the compiler doesn't whine and bitch or you'd have to do it in a class, which I've done.

>>9
>>5
Seems there was nothing of use, but a night of sleep refreshed me and I was able to fix it. Sorry to distract you from your FrozenVoid wankfest.

Goodbye, tripcode.

>>11
1) That's not good form.
And Singletons are? What is a Singleton but an OOP cludge of a global variable?

2) This project is much too complicated to have global variables sitting out there.
Now you have two problems.

3) How would I limit a global variable to a single instance? Yeah, exactly. You either have to create duplicate objects by using static so the compiler doesn't whine and bitch or you'd have to do it in a class, which I've done.
Anonymous types (inherited from C) are wonderful.

struct {
    int foo;
} bar;

I imagine you'll next bitch about "oh but then I can't pass it around and use it all over my code". No shit -- that'd introduce stamp coupling. Instead, keep that shit in the implementation details and put a function into a namespace like Bjarne intended.

Fuck you Sepples fag.

>>12
I think what he meant in 3) is more retarded than you think: he's not concerned that you might make another instance of the singleton's class, he simply isn't aware that to make a global visible to other compiling units that you have to define it in its own unit and declare it in a header using the extern keyword. You see, he defines "globals" directly in headers and gets around the "multiple definitions of <global>" errors by using static to turn each global into a bunch of duplicate unit-locals.

That level of ignorance was expected, though. People who use design patterns as a security blanket are usually morons.

>>13
Can't be. No one is that stupid. He meant it in a way >>12 interpreted it.

>>14
You overestimate the intelligence of the average ENTERPRISE PROGRAMMER.

>>14
Apparently someone can be that stupid. Read 3) again and see if it doesn't fit what >>13 said perfectly.

Lain.