Comments for Daily C++ http://108leaves.com/dailyc++ Only C++ Mon, 06 Sep 2010 00:24:36 +0000 http://wordpress.org/?v=2.5.1 Comment on To use pthreads with C++ : by Nate http://108leaves.com/dailyc++/?p=5#comment-10 Nate Tue, 09 Sep 2008 23:37:16 +0000 http://108leaves.com/dailyc++/?p=5#comment-10 C++, Isn't that the hardest Programming language out there?!? Even VB is giving me a headache. 0.O C++, Isn’t that the hardest Programming language out there?!? Even VB is giving me a headache. 0.O

]]> Comment on The Monitor pattern vs the Monitor programming construct by admin http://108leaves.com/dailyc++/?p=4#comment-8 admin Tue, 05 Aug 2008 11:30:14 +0000 http://108leaves.com/dailyc++/?p=4#comment-8 Thanks Sachin for your comments. Thats true - guys like Herb Sutter are working hard on this (how to optimize multi-core). These are like short notes - so that I can check them whenever I need to remember something. Thanks Sachin for your comments. Thats true - guys like Herb Sutter are working hard on this (how to optimize multi-core). These are like short notes - so that I can check them whenever I need to remember something.

]]> Comment on The Monitor pattern vs the Monitor programming construct by sachin http://108leaves.com/dailyc++/?p=4#comment-7 sachin Sun, 03 Aug 2008 03:36:17 +0000 http://108leaves.com/dailyc++/?p=4#comment-7 I must say that i am impressed at the level of detail provided above. Please continue writing such articles. Even though we have better faster SMP and Multi-threaded CPU cores, we dont have the coding skills to utilize the power of such hardware. we are just embarking on such grounds (atleast in cases of networking applications). I must say that i am impressed at the level of detail provided above. Please continue writing such articles. Even though we have better faster SMP and Multi-threaded CPU cores, we dont have the coding skills to utilize the power of such hardware. we are just embarking on such grounds (atleast in cases of networking applications).

]]> Comment on To use pthreads with C++ : by Milton http://108leaves.com/dailyc++/?p=5#comment-6 Milton Tue, 29 Jul 2008 12:22:32 +0000 http://108leaves.com/dailyc++/?p=5#comment-6 Hi Samuel, Yes, but if you want write a piece of code without any portability issue then it is advisable that you keep the start function under extern c. Cheers, Milton Hi Samuel,
Yes, but if you want write a piece of code without any portability issue then it is advisable that you keep the start function under extern c.

Cheers,
Milton

]]> Comment on To use pthreads with C++ : by Mukta http://108leaves.com/dailyc++/?p=5#comment-4 Mukta Tue, 08 Jul 2008 21:08:50 +0000 http://108leaves.com/dailyc++/?p=5#comment-4 Hey this was very useful! Thanks , would love to see more posts! Hey this was very useful! Thanks , would love to see more posts!

]]> Comment on To use pthreads with C++ : by R Samuel Klatchko http://108leaves.com/dailyc++/?p=5#comment-3 R Samuel Klatchko Fri, 04 Jul 2008 06:01:41 +0000 http://108leaves.com/dailyc++/?p=5#comment-3 <I>we have to remember that startFunction is a c function - hence no namemangling is allowed there</i> That's not quite correct. Unless you are doing explicit dynamic linking (i.e. dlopen/dlsym), name mangling is not an issue. Provided both the startFunction and the call to pthread_create are both in C++ compiled code, the compiler/linker can handle name mangling. What could cause a problem is the calling convention of C++ functions as opposed to C functions (the calling convention handles issues such as how arguments are passed and the stack is manipulated between the caller and the callee). A C++ compiler is allowed to use a different calling convention for C++ functions and C functions. Since pthread_create() expects the startFunction to use the C calling convention, you can run into trouble. That said, all the compilers I am familiar with (gcc, Intel, Sun) use the same calling convention for C++ and C code. I have successfully had pthread_create() use a non extern "C" function as the start function. That said, you cannot use a member function as it does have a different calling convention (the implicit this pointer). But as long as the function is a static member function or a free function, you do not need to use extern "C". we have to remember that startFunction is a c function - hence no namemangling is allowed there

That’s not quite correct. Unless you are doing explicit dynamic linking (i.e. dlopen/dlsym), name mangling is not an issue. Provided both the startFunction and the call to pthread_create are both in C++ compiled code, the compiler/linker can handle name mangling.

What could cause a problem is the calling convention of C++ functions as opposed to C functions (the calling convention handles issues such as how arguments are passed and the stack is manipulated between the caller and the callee). A C++ compiler is allowed to use a different calling convention for C++ functions and C functions. Since pthread_create() expects the startFunction to use the C calling convention, you can run into trouble.

That said, all the compilers I am familiar with (gcc, Intel, Sun) use the same calling convention for C++ and C code. I have successfully had pthread_create() use a non extern “C” function as the start function.

That said, you cannot use a member function as it does have a different calling convention (the implicit this pointer). But as long as the function is a static member function or a free function, you do not need to use extern “C”.

]]> Comment on To use pthreads with C++ : by Linoleum http://108leaves.com/dailyc++/?p=5#comment-2 Linoleum Thu, 03 Jul 2008 21:38:05 +0000 http://108leaves.com/dailyc++/?p=5#comment-2 <strong>Using pthreads in C++...</strong> The Daily C++ weblog has posted a short piece on using pthreads in C++.... Using pthreads in C++…

The Daily C++ weblog has posted a short piece on using pthreads in C++….

]]>