Boost logo

Boost :

From: Darin Adler (darin_at_[hidden])
Date: 2001-10-10 12:13:19


on 10/9/01 12:33 AM, helmut.zeisel_at_[hidden] at helmut.zeisel_at_[hidden] wrote:

>>>> 2) For some reason, "thrd" is parsed as a function pointer,
>>>> not as an object of class boost::thread.
>
> GCC 3.0.1 reacts in a similar way as VC++.

As should a any compiler that wants to conform with the standard.

> In addition, writing
>
> boost::thread thrd=thread_alarm(secs);
>
> gives the error message
>
> "conversion from `thread_alarm'
> to non-scalar type `boost::thread' requested"
>
> on GCC 3.0.1 and a similar error message under VC++.

Right. That's because of the explicit keyword used in boost::thread's
constructor. It means that you can construct a boost::thread, passing a
boost::function as the parameter to the constructor, but you can't do
something that looks like assignment with a type conversion (even if it's
really construction, not assignment).

A way to think about the purpose of the explicit keyword is that it's there
to make sure that construction and type conversion aren't confused. What you
are doing looks like assignment, and is therefore not allowed. You can't
"convert the thread_alarm function into a thread".

> What I do not understand, however, is why
> the two-line version
>
> thread_alarm fct(secs);
> boost::thread thrd(fct);
>
> and the "pointer" version
>
> boost::thread* thrdp= new boost::thread(thread_alarm(secs));
>
> work.
>
> Why is the conversion from thread_alarm to boost::thread
> found in the latter cases?

Because in both of these cases, the construction of the boost::thread object
looks like construction, not assignment.

A workaround for people who don't like the two-line version is to use a
second set of parentheses:

     boost::thread thrd((thread_alarm(secs)));

The parentheses makes this something that couldn't be a function
declaration, but it's still fine as an object definition. I personally find
this a bit too obscure, and prefer the two-line version.

    -- Darin


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk