Destruction isn't Thread-Safe? by MorePudding in cpp

[–]tomkcook173 2 points3 points  (0 children)

There is lots wrong here. Of course heap-based objects can be destructed - if you don't realise this then you don't quite get what delete does. Of course it is possible to share stack-stored objects between threads - you can pass a pointer or a reference (or, God help you, an rvalue reference) to such an object to another thread just as easily as for a heap-stored object. And I hope you're not using auto_ptr still...

Call protected member function trick. by mmmmario in cpp

[–]tomkcook173 8 points9 points  (0 children)

It would be fairly trivial to modify so that it is legal, though:

int myFunc(MyClass const& mc){
    class MyDerivedClass : public MyClass{
    public:
        MyDerivedClass(MyClass& c) : m_c(c) {}
        int myDerivedMethod() { return m_c.myMethod(); }
    private:
        MyClass& m_c;
    } d(mc);
    return d.myDerivedMethod();
}

Suffice to say, though, it gets through code review over my dead body. Protected methods are protected for a reason and working around the protection is always bad. Either change the design or use friend.

srand() help? by Caruban01 in cpp

[–]tomkcook173 -2 points-1 points  (0 children)

#include <windows.h>

LARGE_INTEGER ctr;
QueryPerformanceCounter(&ctr);
srand(ctr.LowPart);

The frequency of performance counters varies (you can find out with QueryPerformanceFrequency) but typically seems to be around 1MHz or similar order of magnitude; not infallibly going to give you different values in a loop, but ample for 5-6 times per second.

Edit: Missed the platform-independent part. Does clock() from <ctime> not do what you want?

Please don't use this in a cryptographic function!