C++ threading could be so simple...

I will appreciate some feedback on these thoughts:
Threads with undeterministic communication (semi-random input/output)
are usually (and best) implemented with some kind of message loop.
However, this gives the headache of having to maintain a switch that,
based on a message ID, cast's the generic base class to a concrete
message. It also means that you have to define the messages and give
them members to convey the needed information.
This is usually quite trivial: To keep the switch as small as
possibly, you would probably use the message ID to cast the message,
extract the members and call a function that handles that specific
message (passing it the members of the message).
This means that you could might as well send the receiving thread a
functor. The receiving thread should simply expose an interface (e.g.
a few functions - possibly members of an abstract class). The calling
thread could then send a functor (in a generic message with a 'virtual
void dispatch()' function) that have the address of the function (and
its arguments) to be executed in the context of the receiving thread:
int foo(int); // Event to trigger in thread B
class MessageBase { public: virtual void dispatch() = 0; };
template</* ... */>
class Message : public MessageBase { /* ... */ };
template</* ... */>
MessageBase* make_message(/* ... */);
void thread_a() {
// ...
thread_b_queue.push_back(make_message(&foo, 42));
// ...
}
void thread_b() {
while (true) {
MessageBase* msg = thread_b_queue.get(); // Blocking call
msg->dispatch(); // Thread 'b' executes the call to 'foo(42)'
delete msg;
}
}
Using futures/promises, it will even be possible for thread_a() to get
the value returned from the call to 'foo()'. The promise shall simply
be passed to the Message object.
You can find a working example (sorry but there is not a Makefile)
here: http://cvs.savannah.gnu.org/viewvc/gptm/examples/example01/?root=gptm
The 'library' is stored as a project on Savannah: https://savannah.nongnu.org/projects/gptm/
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

On Jan 10, 4:15 am, Kian Karas <kian.karas....@gmail.com> wrote:
> I will appreciate some feedback on these thoughts:
>
> Threads with undeterministic communication (semi-random input/output)
> are usually (and best) implemented with some kind of message loop.
> However, this gives the headache of having to maintain a switch that,
> based on a message ID, cast's the generic base class to a concrete
> message.
It isn't necessarily so bad. For example, see http://dlib.net/pipe_ex_2.cpp.html.
In it, a thread reads different types of messages out of a pipe and
deals with each without needing to know about any message ID numbers
or switches. Although, it must be pointed out, the underlying library
does essentially have switches and ID numbers. But you can hide all
of that from the user.
>
> You can find a working example (sorry but there is not a Makefile)
> here:http://cvs.savannah.gnu.org/viewvc/gptm/examples/example01/?root=gptm
>
> The 'library' is stored as a project on Savannah:https://savannah.nongnu.org/projects/gptm/
>From what I can see you have a nice way of executing a function in
another thread but I think it would be even better if the user didn't
have to perform pointer casts and deal with raw pointers. Why not use
some smart pointers or some other kind of object to encapsulate some
of these things?
Cheers,
Davis
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Kian Karas schrieb:
> I will appreciate some feedback on these thoughts:
>
> Threads with undeterministic communication (semi-random input/output)
> are usually (and best) implemented with some kind of message loop.
I think not! A thread can have a message handler which is not a loop.
Some OS have a "handler" which will be called on every incoming message.
"Dispatching" the message via a switch statement is error prone and
expensive. It is much simpler to call a message function which calls the
correct handler function direct. This could simply be done by using
virtual functions inside the message. This keeps information in the
class itself and is base of object oriented programming.
> However, this gives the headache of having to maintain a switch that,
> based on a message ID, cast's the generic base class to a concrete
> message. It also means that you have to define the messages and give
> them members to convey the needed information.
Why the system should not send well formed message objects? Why I should
destroy all information to a enum or int and have a union data field
when it is much simpler to send the object or a pointer to the object?
> This is usually quite trivial: To keep the switch as small as
> possibly, you would probably use the message ID to cast the message,
> extract the members and call a function that handles that specific
> message (passing it the members of the message).
>From my point of view a cast shows always a design problem if the data
that should casted is local to the application. If there is some data
coming from the "outside world" via IO-streams, a factory for objects
should be the solution. But please not with a switch. The "standard"
factory implementation uses registered object generator functions stored
in some container types. Maybe the construction is done by Clone/Copy
functions or other trivial solutions, maybe based on a static construct
function.
> This means that you could might as well send the receiving thread a
> functor. The receiving thread should simply expose an interface (e.g.
> a few functions - possibly members of an abstract class). The calling
> thread could then send a functor (in a generic message with a 'virtual
> void dispatch()' function) that have the address of the function (and
> its arguments) to be executed in the context of the receiving thread:
>
Maybe a message could "be" a execution message which is called by the
receiving thread, yes. But this is only one type of message and not as
universal as it sounds :-)
Can you give me an idea why I should make an int from an object, send
the int and some data in a "message" and reconstruct an object in an
receiving thread? A lot overhead I think. Other libs/os use pointers to
messages which allow to send a message to multiple threads/tasks to keep
overhead small.
> int foo(int); // Event to trigger in thread B
>
> class MessageBase { public: virtual void dispatch() = 0; };
>
> template</* ... */>
> class Message : public MessageBase { /* ... */ };
>
> template</* ... */>
> MessageBase* make_message(/* ... */);
>
> void thread_a() {
> // ...
> thread_b_queue.push_back(make_message(&foo, 42));
> // ...
> }
>
> void thread_b() {
> while (true) {
> MessageBase* msg = thread_b_queue.get(); // Blocking call
> msg->dispatch(); // Thread 'b' executes the call to 'foo(42)'
> delete msg;
> }
> }
>
> Using futures/promises, it will even be possible for thread_a() to get
> the value returned from the call to 'foo()'. The promise shall simply
> be passed to the Message object.
>
If a message object is an execution message it could call also a
callback function to transmit the return value of the message execution.
Each type of message can "decide" that in a total exclusive way with a
trivial common interface. Simply using the operator()() on every
execution message.
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Kian Karas wrote:
> Threads with undeterministic communication (semi-random input/output)
> are usually (and best) implemented with some kind of message loop.
> However, this gives the headache of having to maintain a switch that,
> based on a message ID, cast's the generic base class to a concrete
> message.
The switch-base approach is wrong: you must know all your
msg_ids in advance and must update the implementation when
the set grows, which is error-prone. It doesn't work if the new
msg type comes from, say, a plugin.
For that reason I have implemented a message type-based
dispatcher, which dispatches the call to the best matching
handler, which can be a function, a method ora a delegate.
The term "best matching" means that the dynamic type of the
first actual parameter is closest to the handler's static parameter
type in terms of inheritance depth. For instance:
class B { virtual ~B(); };
class C : public B {};
int handle_B(const B&, float) { return 0; }
int handle_C(const C&, float) { return 1; }
dynamic_dispatch<int (const B&, float)> dd(&handle_B); // one must
// always provide a default handler
dd.attach(&handle_C); // register a handler for C, the call may be
located in a plugin
C c;
const B& b = c;
auto r = dd(b, 0.0); // handle_C will be called
However, it uses GCC's cxxabi.h to traverse the list of base classes
of a given class (via casting std::type_info to something else), so,
strictly
speaking, it is not a C++0x program. But, since the only compiler I'm
interested in is GCC, this is a non-issue. I also use this "design pattern"
in many other places, e.g. exception remapping.
> This is usually quite trivial: To keep the switch as small as
> possibly, you would probably use the message ID to cast the message,
> extract the members and call a function that handles that specific
> message (passing it the members of the message).
A message is not the correct place to store its handling details
information.
Best regards
Piotr Wyderski
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

> From what I can see you have a nice way of executing a function in
> another thread but I think it would be even better if the user didn't
> have to perform pointer casts and deal with raw pointers. Why not use
> some smart pointers or some other kind of object to encapsulate some
> of these things?
If you look at the library (my links in first comment), the user need
*not* do any casts. He need not handle any pointer either (except
those he might wish to pass to the destination thread as argument to
the function in the destination thread - e.g. foo() ).
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Hi Kian,
I agree with you.
I use to use queue of messages pretty similar of this pattern you have
written here.
One difference is that I decided to hide the message concept then I
have something like this:
//to post messages..
MessageQueue<ClassX> queue;
queue.Post(&X::Func, 10.0);
//to dispatch messages
queue.Delivery(x); // x.Func(10.0) is called
I also did some optimizations inside the queue like to recycle the
memory of dispatched messages.
On Jan 10, 7:15 am, Kian Karas <kian.karas....@gmail.com> wrote:
> I will appreciate some feedback on these thoughts:
>
> Threads with undeterministic communication (semi-random input/output)
> are usually (and best) implemented with some kind of message loop.
> However, this gives the headache of having to maintain a switch that,
> based on a message ID, cast's the generic base class to a concrete
> message. It also means that you have to define the messages and give
> them members to convey the needed information.
> This is usually quite trivial: To keep the switch as small as
> possibly, you would probably use the message ID to cast the message,
> extract the members and call a function that handles that specific
> message (passing it the members of the message).
> This means that you could might as well send the receiving thread a
> functor. The receiving thread should simply expose an interface (e.g.
> a few functions - possibly members of an abstract class). The calling
> thread could then send a functor (in a generic message with a 'virtual
> void dispatch()' function) that have the address of the function (and
> its arguments) to be executed in the context of the receiving thread:
>
> int foo(int); // Event to trigger in thread B
>
> class MessageBase { public: virtual void dispatch() = 0; };
>
> template</* ... */>
> class Message : public MessageBase { /* ... */ };
>
> template</* ... */>
> MessageBase* make_message(/* ... */);
>
> void thread_a() {
> // ...
> thread_b_queue.push_back(make_message(&foo, 42));
> // ...
>
> }
>
> void thread_b() {
> while (true) {
> MessageBase* msg = thread_b_queue.get(); // Blocking call
> msg->dispatch(); // Thread 'b' executes the call to 'foo(42)'
> delete msg;
> }
>
> }
>
> Using futures/promises, it will even be possible for thread_a() to get
> the value returned from the call to 'foo()'. The promise shall simply
> be passed to the Message object.
>
> You can find a working example (sorry but there is not a Makefile)
> here:http://cvs.savannah.gnu.org/viewvc/gptm/examples/example01/?root=gptm
>
> The 'library' is stored as a project on Savannah:https://savannah.nongnu.org/projects/gptm/
>
> --
> [ Seehttp://www.gotw.ca/resources/clcm.htmfor info about ]
> [ comp.lang.c++.moderated. First time posters: Do this! ]
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Sorry if I have been unclear. My point is *exactly* that having a
message loop (in the OS, thread library or the user code) to dispatch
the messages based on an ID and a cast operation has a lot of
disadvantages.
> Maybe a message could "be" a execution message which is called by the
> receiving thread, yes. But this is only one type of message and not as
> universal as it sounds :-)
It is universal! Please see the example I referenced in my first
comment. If you have a library with functor & bind support (e.g. c++0x
C++ standard library), you can have *any* type of function called at
the destination thread without having to define any message types in
the client code.
Binding the arguments to the function yields an object for which you
can call "operator()()".
If your destination thread defines a different type of base message
(e.g. struct MyMsg { int id }; ), you simply define *one* new message
type that encapsulates the MessageBase (called MessageIf in the
library I have given links to) and allocates an ID for that (needs
only be done once): struct MyMsgX { int id; MessageBase* msg };
> Can you give me an idea why I should make an int from an object, send
> the int and some data in a "message" and reconstruct an object in an
> receiving thread? A lot overhead I think. Other libs/os use pointers to
> messages which allow to send a message to multiple threads/tasks to keep
> overhead small.
It might not have been clear from my example, but sending a pointer to
a message is exactly what I intend (that's what make_message()
returns).
> If a message object is an execution message it could call also a
> callback function to transmit the return value of the message execution.
> Each type of message can "decide" that in a total exclusive way with a
> trivial common interface. Simply using the operator()() on every
> execution
Yes, adding that feature could be useful.
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

On Jan 11, 5:01 pm, Kian Karas <kian.karas....@gmail.com> wrote:
> > From what I can see you have a nice way of executing a function in
> > another thread but I think it would be even better if the user didn't
> > have to perform pointer casts and deal with raw pointers. Why not use
> > some smart pointers or some other kind of object to encapsulate some
> > of these things?
>
> If you look at the library (my links in first comment), the user need
> *not* do any casts. He need not handle any pointer either (except
> those he might wish to pass to the destination thread as argument to
> the function in the destination thread - e.g. foo() ).
>
I see that your library doesn't force the user to use pointers. But
what I mean to say is, it would be nice if, in addition to the tool in
the example program you linked to, you also had something for creating
the initial thread and calling ThreadScopeIf::run().
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

On Jan 11, 5:09 pm, Kian Karas <kian.karas....@gmail.com> wrote:
> Sorry if I have been unclear. My point is *exactly* that having a
> message loop (in the OS, thread library or the user code) to dispatch
> the messages based on an ID and a cast operation has a lot of
> disadvantages.
>
> > Maybe a message could "be" a execution message which is called by the
> > receiving thread, yes. But this is only one type of message and not as
> > universal as it sounds :-)
>
> It is universal! Please see the example I referenced in my first
> comment. If you have a library with functor & bind support (e.g. c++0x
> C++ standard library), you can have *any* type of function called at
> the destination thread without having to define any message types in
> the client code.
> Binding the arguments to the function yields an object for which you
> can call "operator()()".
>
I think Klaus has a legitimate point. For example, what if the
receiving thread has private state that should be modified when
certain messages are received? Since this state is not in the scope
of the sending thread you will be unable to create a functor that
knows how to modify it. This seems to be a limitation but maybe I'm
just not thinking about it in the right way.
-Davis
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

> I see that your library doesn't force the user to use pointers. But
> what I mean to say is, it would be nice if, in addition to the tool in
> the example program you linked to, you also had something for creating
> the initial thread and calling ThreadScopeIf::run().
Yes, that part of the library dealing with thread creation is
missing.
The library should be updated to use c++0x (threads, futures,
functors, binders etc.).
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

> > Sorry if I have been unclear. My point is *exactly* that having a
> > message loop (in the OS, thread library or the user code) to dispatch
> > the messages based on an ID and a cast operation has a lot of
> > disadvantages.
>
> > > Maybe a message could "be" a execution message which is called by the
> > > receiving thread, yes. But this is only one type of message and not as
> > > universal as it sounds :-)
>
> > It is universal! Please see the example I referenced in my first
> > comment. If you have a library with functor & bind support (e.g. c++0x
> > C++ standard library), you can have *any* type of function called at
> > the destination thread without having to define any message types in
> > the client code.
> > Binding the arguments to the function yields an object for which you
> > can call "operator()()".
>
> I think Klaus has a legitimate point. For example, what if the
> receiving thread has private state that should be modified when
> certain messages are received? Since this state is not in the scope
> of the sending thread you will be unable to create a functor that
> knows how to modify it. This seems to be a limitation but maybe I'm
> just not thinking about it in the right way.
The intended use of the library is:
1) The 'serving' thread (destination) offers an interface in the form
of a (possibly member) function.
2) Using the library, the 'client' thread (source), will post a
message composing a pointer to the function (including possibly object
and arguments).
3) The destination thread dispatches the message (which will call the
functor - but this is library code).
// server.h
class Server {
public:
void start(int);
int stop();
};
// client.cpp
Server& server = /* ... */
// Start server synchronously (call_sync() returns when start()
returns)
call_sync(server_ctx, make_functor(server, &Server::start, 123));
/* Do some stuff ... */
// Stop server asynchronously (call_async() returns as soon as message
is posted on queue */
future<int> result;
call_async(server_ctx, make_functor(server, &Server::stop), result);
/* Do some stuff while waiting for stop() to return */
// Wait for result (if not already present)
int val = result.get();
The private state is implemented in the Server class and modified by
Server::start() and Server::stop(). You simply define and implement
the 'serving' thread as if it was not threaded! It is not the message/
functor that is sent to the serving thread that knows and modifies the
state, it is the functions defined in the serving thread.
You need only expose the functions that other threads can call - just
like sequential programming. Also the definition of the functions need
not use any synchronization objects for this to work - the library
takes care of this before dispatching the message.
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

On Jan 12, 1:26 pm, Kian Karas <kian.karas....@gmail.com> wrote:
> > > Sorry if I have been unclear. My point is *exactly* that having a
> > > message loop (in the OS, thread library or the user code) to dispatch
> > > the messages based on an ID and a cast operation has a lot of
> > > disadvantages.
>
> > > > Maybe a message could "be" a execution message which is called by the
> > > > receiving thread, yes. But this is only one type of message and not as
> > > > universal as it sounds :-)
>
> > > It is universal! Please see the example I referenced in my first
> > > comment. If you have a library with functor & bind support (e.g. c++0x
> > > C++ standard library), you can have *any* type of function called at
> > > the destination thread without having to define any message types in
> > > the client code.
> > > Binding the arguments to the function yields an object for which you
> > > can call "operator()()".
>
> > I think Klaus has a legitimate point. For example, what if the
> > receiving thread has private state that should be modified when
> > certain messages are received? Since this state is not in the scope
> > of the sending thread you will be unable to create a functor that
> > knows how to modify it. This seems to be a limitation but maybe I'm
> > just not thinking about it in the right way.
>
> The intended use of the library is:
> 1) The 'serving' thread (destination) offers an interface in the form
> of a (possibly member) function.
> 2) Using the library, the 'client' thread (source), will post a
> message composing a pointer to the function (including possibly object
> and arguments).
> 3) The destination thread dispatches the message (which will call the
> functor - but this is library code).
>
> // server.h
> class Server {
> public:
> void start(int);
> int stop();
>
> };
>
[snip]
>
> The private state is implemented in the Server class and modified by
> Server::start() and Server::stop(). You simply define and implement
> the 'serving' thread as if it was not threaded!
This is my point. Suppose the start() and stop() functions should
never be called by the main thread. Maybe they aren't thread safe (as
you say, implement them as if they are not threaded). Or maybe there
is some architectural reason why you don't want other threads
executing those functions. In this case it is nice to be able to make
those functions private. However, in your example the calling thread
could make direct calls to start() and stop(). Encapsulation is just
as important for member functions as it is for member variables.
Although, to counter my own complaint. It is easy enough to add a
factory method to Server that does nothing but construct a functor
with the necessary pointer to start() or stop() in it and return a
copy. Or it might create the functor and dispatch it to the thread
itself.
So I relent. This is quite general purpose :)
It would probably be a good idea to have an example program that shows
the case where the server_ctx is a private member and the other thread
only does things like call public member functions that dispatch the
appropriate asynchronous calls to private member functions. This
would preempt the next guy who would otherwise complain about this :)
Cheers,
Davis
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Simple parser for C/C++
Hi
How easy would be make simple parser for C/C++ by tcl ?
I would want to make tcl-script, which searchs all functions/methods and
entry/exit points of functions/methods from C/C++-source file.
I think this should be possible, but i don't know how.
---
Esa
Esa Heikkinen wrote:
> Hi
>
> How easy would be make simple parser for C/C++ by tcl ?
>
> I would want to make tcl-script, which searchs all functions/methods and
> entry/exit points of functions/methods from C/C++-source file.
>
> I think this should be possible, but i don't know how.
For C look at...

multithreading with each thread in a separate class instance vs. in a C-style kernel thread calls in C++Other than looking cleaner in the object oriented approach (each
thread's main function in one class) vs. having UINT _ _stdcall
ChildThread (void *args) {...} required declarations for Windows
kernel calls, I'm not sure about the advantages of the first method
compared to the second method. I'm not sure if I have given enough
information on what I'm confused on, but any enlightenment would be
much appreciated. Thanks.
ssylee wrote:
> Other than looking cleaner in the object oriented approach (each
> thread's main function in one class) vs. having UINT _ _stdcall
&gt...

C/C++ Threads in TandemHi all,
Can anyone help me on how I can use threads on my C/C++ programs in
Tandem? Just as I use pthread.h on linux, or types.h and stub.h to use
'thread_create'. I tried searching for these header files on our
tandem machine but have'nt found any...
any thoughts and opinions? many thanks guys and I really appreciate
your help!
Enjoy you Day!!!
On Mar 5, 12:46 am, "mau_infrance" <mau_infra...@yahoo.com> wrote:
> Hi all,
>
> Can anyone help me on how I can use threads on my C/C++ programs in
> Tandem? Just as I use pthread.h on linux, or types.h and...

simple conversion from C to C++can any one translate the following codes into c++ codes, coz i can't run
the "printf" command in Unix and it said it's implicit declaration.
Is it only the two lines with comment need to be re-written??
Thanks a lot
void _display_number(int v, int n){
if(v >= 1000){
int r = v % 1000;
_display_number(v / 1000,n);
printf(",%03d",r); // how to translate that into
std::cout<<...?
}else{
printf("%s%d\n",n ? "-":"",v); // how to translate??
}
}
v...

simple conversion from C to C++can any one translate the following codes into c++ codes, coz i can't run
the "printf" command in Unix and it said it's implicit declaration.
Is it only the two lines with comment need to be re-written??
Thanks a lot
void _display_number(int v, int n){
if(v >= 1000){
int r = v % 1000;
_display_number(v / 1000,n);
printf(",%03d",r); // how to translate that into
std::cout<<...?
}else{
printf("%s%d\n",n ? "-":"",v); // how to translate
}
}
voi...

simple simple simplecalc teacher wants us to solve a problem in matlab :(
I'm still stuck on making a f---ing function.
by function i mean like f(x,y) = x^2 + y^3 - 3*x*y
once i get this i can probably get the rest of the problem lol.
Thanks for your help
"Xavier " <xaviercoble@yahoo.com> wrote in message <hdsso6$10s$1@fred.mathworks.com>...
> calc teacher wants us to solve a problem in matlab :(
> I'm still stuck on making a f---ing function.
> by function i mean like f(x,y) = x^2 + y^3 - 3*x*y
> once i get this i can probably get the rest of the problem lol.
>
&gt...

Threads: incompatibilities between C and C++?Recently I watched a speech made by Hans Boehm on Channel #9 where he
mentioned an incompatibility between C11 and C++11. I think he was
talking about a difference between thread libraries. Does anyone know
what these differences consist of?
MJ
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
On 2012-05-14 18:13:37 +0000, M J said:
> Recently I watched a speech made by Hans Boehm on Channel #9 where he
> mentioned an incompatibility between C11 and C++11. I think he was
> talki...

jython and C-c C-cHow do I get C-c C-c to work with jython? I have the jpython command set to
jython, and I can start the interpreter with C-C ! and then use C-c C-c, but
this is rather frustrating. If I try to use C-c C-c without first starting
the interpreter in another window I get
wrong type argument: sequencep, jpython
Thanks,
Dave Cook
...

Simple C++ problemHi all,
I am tutoring introductory computer science in the Solomon Islands and
we are using C++ as the language of choice (nice). Please note that I
am no way a C++ programmer, but have but I have programmed in most
mainstream languages over the paste 20 years. We are learning HOW to
code, not just C++. The dudes in the class have their final assignment
in a couple of days and we have a simple problem to overcome. The
problem is this:
The program reads in an array of integers which instructs a robot which
direction to go in, in a 20 x 20 grid. The first two integers (read in
from a file) are...

Creating threads in C vs C++Hi,
I'm writing a multithreaded application in C++. I tried to do like C
posix threads and pass an object method. But I got a compilation error:
'argument of type 'void*(myclass::)(void *)' does not match 'void *
(*)(void *)'
I've done lots of multithreaded work in C. But this my first time doing
it in C++. How do I create a thread in C++?
Cheers
John
On Jan 8, 5:36=A0pm, john <j...@nospam.com> wrote:
> Hi,
>
> I'm writing a multithreaded application in C++. I tried to do like C
> posix threads and pass an object me...

simple threading.Thread and Semaphores hangHi,
My application hangs on exit.
I have isoleted this piece of code that reproduces the error: (the time
module is extra and not needed to reproduce)
import threading
import time
def func():
b = threading.Semaphore(value=0)
b.acquire()
a = threading.Thread(target=func)
a.start()
time.sleep(2)
quit()
When SystemExit is raised, nothing happens. Python hangs.
pdb does seem to have problem with this code too:
pdb smth.py
....
(Pdb) Traceback (most recent call last):
File "/usr/bin/pdb", line 1319, in <module>
pdb.main()
Fil...

C/C++ Multi-Threaded Programming DebuggingWhat is the best strategy or advice for C/C++ Multi-Threaded
Programming Debugging on linux and Windows XP?
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
Do as little of it as you can. In other words, expose the least amount
of code to concurency as possible.
Both platforms have debuggers that handle threaded apps fairly well.
And provide various mechanisms for dealing with concurency such as
mutexes, semaphores, etc. If you're building portable code then you'll
need to find a third party libra...

Embedding Ruby Interpretor in threaded C / C++Hi,
Can someone please point me to documentation for embeding Ruby
interpretor in C / C++ (C++ Prefered).
What is the best way do embed Ruby interepretor in C/C++ threaded
program. So that each thread can execute its own assigned set of script.
I have seen that Python doesn't allows this kind of setup. It create a
Global lock and even C/C++ is threaded scripts are executed in python's
thread control. Is it same in Ruby also ?
Thanks,
Yogesh
On Apr 2, 2005 11:59 PM, Yogesh Sharma <ysharma@catprosystems.com> wrote:
> Hi,
>
> Can someone please point me to documen...

How to put a thread into sleep using C/C++?What system call should I call in my C/C++ program to put current
thread into sleep state?
Neo wrote:
> What system call should I call in my C/C++ program to put current
> thread into sleep state?
$ apropos sleep
Tcl_Sleep (3) - delay execution for a given number of milliseconds
Tcl_Sleep [Sleep] (3) - delay execution for a given number of milliseconds
apmsleep (1) - go into suspend or standby mode and wake-up later
nanosleep (2) - pause execution for a specified time
sleep (1) - delay for a specified amount of time
sleep ...

simple c/c++ programming question about encryptionHi,
I have two identical programs that encrypt characters. One is written
in C++, and it works, but the other one is written in C, and it does
not work. I have copied the code below. There is a problem somewhere
in the while loop in the C program. It goes through the code one full
time (and updates the counter) before asking for user input - thus it
updates the counter twice for every one input. Since I'm not so
familiar with C, can anyone explain this to me. The same program works
perfectly with C++, which is why I don't understand this. Any help
would be much appreciated.
Th...

Simple RTDX host application with C/C++Hello everyone,
I want to do a simple console application to send and recieve data from the
DSP.
I've found information in the CodeComposer Online Help... but the examples
are with Visual Basic and I still have some questions.
If i want to use C/C++ to develop a host RTDX application:
1. Which library have I to use?
2. Which header file have I to import?
3. Can I use the functions described in the 'RTDX Exported Interface'
section of the Online Help?
4. How can I start a CodeComposer session in background and load a file to
the DSP?
5. How can I start the DSP from my host appli...

simple c/c++ programming question about encryptionHi,
I have two identical programs that encrypt characters. One is written
in C++, and it works, but the other one is written in C, and it does
not work. I have copied the code below. There is a problem somewhere
in the while loop in the C program. It goes through the code one full
time (and updates the counter) before asking for user input - thus it
updates the counter twice for every one input. Since I'm not so
familiar with C, can anyone explain this to me. The same program works
perfectly with C++, which is why I don't understand this. Any help
would be much appreciated.
Th...

Newbie: parsing simple XML with C/C++I'm looking for simple examples of XML parsing using C/C++ that could
be applicable to both Unix and Windows programming. I am wanting to
parse an XML structure that is basically flat. The Information that I
wish to extract would be held within XML attributes. It is important
that the order of the document be preserved in the parsing process.
Here is a document similar to the type of XML that will be generated.
<collector name="John Tomas">
<cd title="Moon Light City" artist="Fred Ziffle" />
<book title="Hiking Big Bend" autho...

Are there some simple and complete c/c++ source code?Dear all,
I found thme in the internet, but got nothing.
The document of sleepy cat gives me just a little sense.
Can anyone provide some complete c/c++ code,especially including "secondary
index (associate) usage"?
Thanks for your help.
Regards,
cylin.
"cylin" <cylin@avant.com.tw> wrote in message news:<2q7pj7Fsm0i2U1@uni-berlin.de>...
> Dear all,
>
> I found thme in the internet, but got nothing.
> The document of sleepy cat gives me just a little sense.
> Can anyone provide some complete c/c++ code,especially including &q...

Thread pool source (C/C++) for linux?Can anyone point me to some C/C++ source code that implements a thread pool
for posix threads?
I thought the boost libraries included a thread pool class but I can't find
it.
Thanks ,
-Randy
RJGraham wrote:
> Can anyone point me to some C/C++ source code that implements a thread pool
> for posix threads?
>
> I thought the boost libraries included a thread pool class but I can't find
> it.
For an example in C, see:
http://developers.sun.com/solaris/articles/thread_pools.html
Someone else may have a pointer to a C++ class.
-Robert
...

c------->c++ and c++------>cWe can write c program in turbo c++ editor.But reverse is not true why?
i.e The program will not compile if u write c++ program in turbo c
editor
vim wrote:
> We can write c program in turbo c++ editor.But reverse is not true why?
> i.e The program will not compile if u write c++ program in turbo c
> editor
This isn't about C; this is about some editor. Why the fircone should
/we/ know? Ask in a relevant group.
[And /why/, in an editor specialised to some specific programming languages,
would you expect it to compile a /different/ one? Would you expect
turbo perl to compi...