🔒 Locked 🎮 Unity

C++ Thread class - develop one?

Started by Tsumuji Sep 19, 2006 at 8:05 AM 8 replies 2.3k views

Original Post

Sep 19, 2006 at 8:05 AM

I was thinking in develop a class that handle the thread stuff for me, so my app will work something like in Java. I think this is a good idea. Searched in goole and found a exemple from codeproject.com, but only work in win32. How to get to work in my linux system?


// define the interface
struct IRunnable {
  virtual void run() = 0;
};

// define the thread class
class Thread {
public:
  Thread(IRunnable *ptr) {
    _threadObj = ptr;
  }
  void start() {
    // use the Win32 API here
    DWORD threadID;
    ::CreateThread(0, 0, threadProc, _threadObj, 0, &threadID);
  }
  
protected:
  // Win32 compatible thread parameter and procedure 
  IRunnable *_threadObj; 
  static unsigned long __stdcall threadProc(void* ptr) {
    ((IRunnable*)ptr)->run();
    return 0;
  }   
};

snk_kid

Sep 19, 2006 at 8:09 AM

It's never a good idea to try to copy java-based soluations exactly in C++, there is always a better way to do it for C++ and as such there already is check Boost.Thread.

MaulingMonkey

Sep 19, 2006 at 8:35 AM

Here's how you get it to work on Linux:

#include <boost/bind.hpp>#include <boost/scoped_ptr.hpp>#include <boost/thread.hpp>// define the interfacestruct IRunnable {  virtual void run() = 0;};// define the thread classclass Thread {    boost::scoped_ptr< boost::thread > t;public:  Thread(IRunnable *ptr) {    _threadObj = ptr;  }  void start() {    t.reset( new boost::thread( boost::bind( & IRunnable::run , ptr ) ) );  }};

Raghar

Sep 19, 2006 at 8:54 AM

re snk_kid

While Java has a lot of behind the scenes you don't know about, saying anything writen in C++ is possible to do in noticably better way than Java is wastly incorrect.

I looked into that link you provided. When I'd compare it to JavaDoc documentation, and Java tutorial combination, it would be really bad resource to start with multithreaded programming.

Java enforces programmer into expecting preemptive multithreaded model (with hopefully low granularity), and forces him to modify his application acordingly. This allows OS kernel to do its work correctly, thus it isn't living from fear that programmer would use another "bright" idea, or undocumented service of OS, and vaporize all other OS programs and important OS services.
I somehow missed this contract in the boost.thread documentation.

snk_kid

Sep 19, 2006 at 9:12 AM

Quote:
Original post by Raghar
While Java has a lot of behind the scenes you don't know about, saying anything writen in C++ is possible to do in noticably better way than Java is wastly incorrect.

Quite clearly you've misinterpreted what I wrote.

MaulingMonkey

Sep 19, 2006 at 9:51 AM

Quote:
Original post by Raghar
re snk_kid

While Java has a lot of behind the scenes you don't know about, saying anything writen in C++ is possible to do in noticably better way than Java is wastly incorrect.

But that's not what he said at all. He's just saying that if you're going to pretend C++ is Java and directly clone everything, you might as well code in Java where Java's idioms are, you know, directly supported by the language.

He's advocating translating into more appropriate idioms for the C++ language when implementing a C++ solution. This is common sense level stuff. The same logic can be applied in reverse:

"It's never a good idea to try to copy Java-based solutions exactly in C++, there is always a better way to do it for C++"
"It's never a good idea to try to copy C++-based solutions exactly in Java, there is always a better way to do it for Java"

These two statements can coexist.

Tsumuji

Sep 19, 2006 at 1:52 PM

I tried a little more and I was abble to translate the code above. I think is a good approach:

#include <pthread.h>struct Runnable {	virtual void run() = 0;};class Thread {	public:		Thread( Runnable *ptr ) {			_threadObj = ptr;		}		void start() {			pthread_t threadID;			pthread_create( &threadID, NULL, Thread::threadProc, _threadObj );		}		protected:		Runnable *_threadObj;		static void* threadProc(void* ptr){			(( Runnable* )ptr)->run();			return 0;		}};

So, I declare my own class derivating from the Runnable:

class MyObject : public Runnable {	public:		virtual void run(){			std::cout << "Thread complete." << std::endl;		}};

and instantiate the classes and run them:

	MyObject *obj = new MyObject( );	Thread *thread = new Thread( obj );	thread->start();

What do you people think? Is a good code? What can be optimized or implemented for better compatibility or anything?
I looked the boost.Threads. I'll try this one later.

Aldacron

Sep 19, 2006 at 3:14 PM

Quote:
Original post by MaulingMonkey
But that's not what he said at all. He's just saying that if you're going to pretend C++ is Java and directly clone everything, you might as well code in Java where Java's idioms are, you know, directly supported by the language.

He's advocating translating into more appropriate idioms for the C++ language when implementing a C++ solution. This is common sense level stuff. The same logic can be applied in reverse:

"It's never a good idea to try to copy Java-based solutions exactly in C++, there is always a better way to do it for C++"
"It's never a good idea to try to copy C++-based solutions exactly in Java, there is always a better way to do it for Java"

These two statements can coexist.

I think there's a definite distinction to be made here. There is nothing language-specific about an API or a class interface. Of course, some interfaces can be implemented in one language more easily than in another. Java's Thread class can be implemented perfectly well in C++ without using any Java idioms. What you don't want to be doing is programming C++ solutions like you would program Java solutions. There's a tremendous difference between implementing an interface and copying an implementation.

As for reinventing wheels, reusing code, yadda, yadda... Boost is a great solution for some real world applications and would eliminate the need to implement your own thread class, sure. For a learning exercise, not so much. Besides, not everyone wants to be on the Boost bandwagon.

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.