C++ threading could be so simple...

  • Permalink
  • submit to reddit
  • Email
  • Follow


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! ]

0
Reply kian.karas.dev (1) 1/10/2010 11:15:53 AM

See related articles to this posting

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! ]

0
Reply Davis 1/10/2010 8:40:57 PM

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! ]

0
Reply Klaus 1/10/2010 8:40:58 PM

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! ]

0
Reply Piotr 1/11/2010 9:32:44 PM

> 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! ]

0
Reply Kian 1/12/2010 12:01:35 AM

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! ]

0
Reply Thiago 1/12/2010 12:07:51 AM

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! ]

0
Reply Kian 1/12/2010 12:09:26 AM

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! ]

0
Reply Davis 1/12/2010 2:15:31 AM

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! ]

0
Reply Davis 1/12/2010 2:15:48 AM

> 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! ]

0
Reply Kian 1/12/2010 8:08:34 PM

> > 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! ]

0
Reply Kian 1/12/2010 8:08:38 PM

Kian Karas 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.
> 
..........
> 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;
>    }
> }
> 
......

This is pretty inefficient.
I think this would be better:
virtual void produce() {
     // ... some blocking mechanism, like io,
      // process data then
     _queue.push_back(make_message(&foo,42));
     // ...
}
void consume() {
      while(auto_ptr<MessageBase> msg = _queue.get()) // blocks only if
locked by other thread
       msg->dispatch();  // executes the call to 'foo(42)'
  }

in base Thread class:

int Thread::run()
{
	while(!shutdown())
         {
             produce(); // waits for data
             consume(); // performs work
         }
   return 0;
}
In this way you can avoid condition variable in _queue.get() which
adds large overhead because threads have to sleep twice, producer on
io stream, consumer on condition variable...
With this approach you can get 40k requests per second instead just
4k , for example on cygwin, windows...

Greets

-- 
      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

0
Reply Branimir 1/13/2010 3:02:37 AM

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! ]

0
Reply Davis 1/14/2010 4:19:58 AM
comp.lang.c++.moderated 10597 articles. 7 followers. Post

12 Replies
327 Views

Similar Articles

[PageSpeed] 36

  • Permalink
  • submit to reddit
  • Email
  • Follow


Reply:

Similar Artilces:

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 >...

C/C++ Threads in Tandem
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 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...

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...

Simple C++ problem
Hi 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 hang
Hi, 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...

[cpp-threads] Thread support in C
http://jupiter.robustserver.com/pipermail/cpp-threads_decadentplace.org.uk/2005-August/000585.html regards, alexander. ...

C/C++ Multi-Threaded Programming Debugging
What 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 encryption
Hi, 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 encryption
Hi, 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 ...

A Simple Proof that C(N) = C(R)
A Simple Proof that C(N) = C(R) Cantor's Anti-Diagonal Proof is missing an assumption of complete lists An, Em, LIST(m) = ANTI(LIST(n)) where ANTI is any invertible digit swap function applied to real numbers. e.g. ANTI( Expansion ) = Flipped <=> Ad, Flipped[d] = (Expansion[d] + (base/2)) MOD base -for even bases e.g. in base 10 ANTI (0.123123123...) = 0.678678678.. ANTI (0.678678678...) = 0.123123123.. The proof proceeds in base 2, ignoring dual representation e.g. ANTI ( 0.000111.. ) = 0.11100.. THEOREM: Using the Assumption of complete lists, the ANTI function applied to th...

[New to C] Creating a simple animation using C.
Hi, I am new to the C programming language and programming in general. I am writing a simple roulette program. I have everything working so far but it seems a little plain. What I would like to do, but I have no idea how to do, would be to create a simple animation each time the roulette wheel is spun. Something like this. 1 2 3 4 5 6 7 8 9 10 11 31 12 30 13 29 14 28 15 27 16 26 17 25 24 23 22 21 20 19 18 Well it would actually be number 1 -3...

Simple RTDX host application with C/C++ #2
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 Welding of two small C/C++ Programs, But How??
Hi everyone, I'm a newbie to C/C++ and I need some help with a minor C program. My assignment is to take two programs and mesh them together. The 1st program I wrote compiles and works fine. The 2nd program is to add to the 1st program with an if_then_else statement, and it's code is also correct as well; I just don't know how to or where to put it into the rest of the 1st program to make it work as one. I've tried to modify it but I get compiler errors. I look forward to any help some kind soul can provide. The code with both pieces is below. Thanks, Basil Fawlty ...

[c++-pthreads] C++ and POSIX Threads Mailing List
There has been a fair amount of discussion on the GCC mailing list about possibe ways of integrating POSIX threads with ISO C++. The key question to date has been how to deal with thread cancellation. People have asked questions like: * Should cancellation throw an exception? * What happens if the exception is caught, and not rethrown? * What happens if the exception violates an exception-specification? * What should be done about the fact that ISO C++ says that C library functions like "printf" never throw exceptions? Much of the GCC discussion can be found ...