Blog Archive

Last day for comments on the C++0x FCD

Thursday, 17 June 2010

The BSI deadline for comments on the C++0x FCD is tomorrow, Friday 18th June 2010. The ISO deadline is 26th July 2010, but we have to write up comments for submission in the form required for ISO, which takes time.

If you have a comment on the FCD, please see my earlier blog post for how to submit it to BSI. Help us make the C++0x standard as good as it can be.

Posted by Anthony Williams
[/ cplusplus /] permanent link
Tags: C++, C++0x, WG21, FCD
Stumble It! | Submit to Reddit | Submit to DZone

Comment on this post

If you liked this post, why not subscribe to the RSS feed or Follow me on Twitter? You can also subscribe to this blog by email using the form on the left.

Enforcing Correct Mutex Usage with Synchronized Values

Friday, 28 May 2010

My latest article, Enforcing Correct Mutex Usage with Synchronized Values has been published on the Dr Dobb's website.

This article expands on the SynchronizedValue<T> template I mentioned in my presentation on Concurrency in the Real World at ACCU 2010, and deals with the problem of ensuring that the mutex associated with some data is locked whenever the data is accessed.

The basic idea is that you use SynchronizedValue<T> wherever you have an object of type T that you wish to be protected with its own mutex. The SynchronizedValue<T> then behaves like a pointer-to-T for simple uses.

Read the article for the full details.

Posted by Anthony Williams
[/ news /] permanent link
Tags: mutex, cplusplus
Stumble It! | Submit to Reddit | Submit to DZone

Comment on this post

If you liked this post, why not subscribe to the RSS feed or Follow me on Twitter? You can also subscribe to this blog by email using the form on the left.

just::thread C++0x Thread Library V1.4 (FCD Edition) Released

Thursday, 06 May 2010

I am pleased to announce that version 1.4 (the FCD edition) of just::thread, our C++0x Thread Library has just been released.

With the release of the "FCD edition", just::thread provides the first complete implementation of the multithreading facilities from the Final Committee Draft (FCD) of the C++0x standard.

Changes include:

• New promise::set_value_at_thread_exit, promise::set_exception_at_thread_exit, and packaged_task::make_ready_at_thread_exit member functions to defer unblocking waiting threads until the notifying thread exits
• New notify_all_at_thread_exit function for notifying condition variables when the notifying thread exits
• The wait_for and wait_until member functions of future, shared_future and atomic_future return a future_status enum rather than bool to indicate whether the future is ready, the wait timed out, or the future contains a deferred async function
• The destructor of the last future associated with an async function waits for that function to complete.
• New ATOMIC_VAR_INIT macro for initializing atomic objects
• The callable object for a packaged_task is destroyed with the packaged_task rather than being kept alive until the future is destroyed

Purchase your copy and get started with the C++0x thread library NOW.

As usual, existing customers are entitled to a free upgrade to V1.4.0 from all earlier versions.

Posted by Anthony Williams
[/ news /] permanent link
Tags: multithreading, concurrency, C++0x
Stumble It! | Submit to Reddit | Submit to DZone

Comment on this post

If you liked this post, why not subscribe to the RSS feed or Follow me on Twitter? You can also subscribe to this blog by email using the form on the left.

"Concurrency in the Real World" slides now available

Monday, 19 April 2010

The slides for my presentation on "Concurrency in the Real World" at the ACCU 2010 conference last week are now available.

The room was full, and quite warm due to the air conditioning having been turned off, but everything went to plan, and there were some insightful questions from the audience. I've thoroughly enjoyed presenting at ACCU in previous years, and this was no exception.

I covered the main pitfalls people encounter when writing multithreaded code, along with some techniques that I've found help deal with those problems, including some example code from projects I've worked on. As you might expect, all my examples were in C++, though the basic ideas are cross-language. I finished up by talking about what we might hope to get out of multithreaded code, such as performance, additional features and responsiveness.

There's a discount on my just::thread library until Friday 23rd April 2010, so if you're doing concurrency in C++ with Microsoft Visual Studio on Windows or g++ on linux get yourself a copy whilst it's on offer and start taking advantage of the new C++0x thread library.

Posted by Anthony Williams
[/ news /] permanent link
Tags: concurrency, multithreading, c++, ACCU
Stumble It! | Submit to Reddit | Submit to DZone

Comment on this post

If you liked this post, why not subscribe to the RSS feed or Follow me on Twitter? You can also subscribe to this blog by email using the form on the left.

March 2010 C++ Standards Committee Mailing

Thursday, 08 April 2010

The March 2010 mailing for the C++ Standards Committee was published last week. This is the post-meeting mailing for the March 2010 committee meeting, and contains the C++0x Final Committee Draft, which I blogged about last week.

There are 6 concurrency-related papers (of which my name is on two), which I summarize below:

Concurrency-related papers

N3057: Explicit Initializers for Atomics

This paper proposes new initializers for atomic variables, providing a means of writing code which can be compiled as either C or C++. e.g.

void foo()
{
    atomic_int a=ATOMIC_VAR_INIT(42); // initialize a with 42
    atomic_uint b;                    // uninitialized
    atomic_init(&b,123);          // b now initialized to 123
}

N3058: Futures and Async Cleanup (Rev.)

This is a revision of N3041 to resolve many of the outstanding issues with futures and async. Mostly it's just wordsmithing to tidy up the specification, but there's a few key changes:

• Defined behaviour for the wait_for() and wait_until() member functions of std::future, std::shared_future and std::atomic_future when used with std::async and a launch policy of std::launch::sync. The return value is now a value of the new std::future_status enumeration, and can be std::future_status::ready if the future becomes ready before the timeout, std::future_status::timeout if the wait times out, or std::future_status::deferred if the future comes from a call to std::async with a launch policy of std::launch::sync and the function associated with the future hasn't yet started execution on any thread.
• The wording for std::async adopts the same wording as std::thread to clarify the copy/move and perfect forwarding semantics of the call.

N3069: Various threads issues in the library (LWG 1151)

This is a revision of N3040, and highlights which operations through iterators constitute accesses and data races, and explicitly allows for synchronization by writing and reading to/from a stream.

N3070: Handling Detached Threads and thread_local Variables

This is a hugely simplified replacement for my previous paper N3038. Rather than creating contexts for thread_local variables, this paper proposes new member functions for std::promise and std::packaged_task to allow the value to be set at the point of call, but threads waiting on associated futures to be woken only after thread_local variables have been destroyed at thread exit. This means that you can now safely wait on a future which is set in such a fashion when waiting for a task running on a background thread to complete, without having to join with the thread or worry about races arising from the destructors of thread_local variables. The paper also adds a similar mechanism for condition variables as a non-member function.

N3071: Renaming launch::any and what asyncs really might be (Rev.)

This is a revision of N3042 proposing renaming std::launch::any to std::launch::sync_or_async. This paper was not approved.

N3074: Updates to C++ Memory Model Based on Formalization

This is a revision of N3045. This paper proposes some changes to the wording of the memory model in order to ensure that it means what we intended it to mean.

Other Papers

There's several non-concurrency papers in the mailing as well as the standard set (working draft, agenda, issues lists, etc.). The most significant of these in my view are the following 3 papers. Check the mailing for the full set.

N3050: Allowing Move Constructors to Throw (Rev. 1)

This paper adds the new noexcept keyword to C++. This is used in place of an exception specification. On its own it means that the function does not throw any exceptions, but it can also be used with a boolean constant expression where true means that the function doesn't throw, and false means that it might. e.g.

void foo() noexcept;        // will not throw
void bar() noexcept(true);  // will not throw
void baz() noexcept(false); // may throw

If a noexcept exception specification is violated then std::terminate() is called.

The primary benefit from the boolean-constant-expression version is in templates, where the boolean expression can check various properties of the template parameter types. One of the things you can check is whether or not particular operations throw, e.g. by using the new has_nothrow_move_constructor type trait to declare the move constructor for a class to be noexcept if its class members have non-throwing move constructors:

template<typename T>
class X
{
    T data;
public:
    X(X&& other)
        noexcept(std::has_nothrow_move_constructor<T>::value):
        data(std::move(other.data))
    {}
};

N3053: Defining Move Special Member Functions

This proposal ensures that user-defined classes have move constructors and move assignment operators generated for them by the compiler if that is safe. Explicitly declaring a copy or move constructor will prevent the implicit declaration of the other, and likewise for copy and move assignment. You can always request the default definition using the = default syntax.

This means that lots of user code will now be able to readily take advantage of move semantics with a simple code change or even just a recompile. This can potentially be of major performance benefit.

N3055: A Taxonomy of Expression Value Categories

This paper nails down the true distinctions between lvalues, rvalues and rvalue references. It provides a new set of names to identify the distinct categories of values in C++ — lvalues and rvalues we already have, but now there's xvalues, prvalues and glvalues too. This categorization allows for better specification of when things can bind to lvalue references or rvalue references, when the compiler can eliminate copies or moves.

Please comment on the FCD

The purpose of the C++0x Final Committee Draft is to get comments prior to publication to ensure the final C++0x standard is as defect free as possible. This opportunity is only available for a limited time, so please comment on the FCD.

Posted by Anthony Williams
[/ cplusplus /] permanent link
Tags: C++0x, C++, standards, concurrency
Stumble It! | Submit to Reddit | Submit to DZone

Comment on this post

If you liked this post, why not subscribe to the RSS feed or Follow me on Twitter? You can also subscribe to this blog by email using the form on the left.

Sign up for a 50% discount just::thread FCD edition

Wednesday, 07 April 2010

I'm in the process of updating our C++0x thread library for VS2008, VC10, g++ 4.3 and g++ 4.4 to incorporate the changes to the C++0x thread library voted into the C++0x FCD. I'll be writing a blog post with more details in due course, but the big changes are:

• Functions for postponing notification of threads waiting on a std::future until the thread that set the value on the std::promise or ran the std::packaged_task has exited.
• A similar facility for notifying a std::condition_variable at thread exit.
• Defined behaviour for the wait_for() and wait_until() member functions of std::future when used with std::async and a launch policy of std::launch::sync.
• Changes to the initialization of atomic variables.

Existing customers will get the new version as a free upgrade, but the rest of you can get a 50% discount if you subscribe to my blog by email. Just fill in your name and email address in the form below and be sure to click the confirmation link. You'll then receive future blog posts by email, along with an announcement and exclusive discount for the FCD edition of just::thread when it's released.

If you're reading this via RSS and your reader doesn't show you the form or doesn't allow you to submit your details, then please go to the web version of this blog entry.

If you've already subscribed by email then you don't need to subscribe again, you'll automatically receive the discount code.

Please sign me up to receive blog posts by email and an exclusive discount on just::thread.

Name:

Email:

We respect your email privacy

Posted by Anthony Williams
[/ news /] permanent link
Tags: concurrency, threading, C++0x, just::thread
Stumble It! | Submit to Reddit | Submit to DZone

Comment on this post

If you liked this post, why not subscribe to the RSS feed or Follow me on Twitter? You can also subscribe to this blog by email using the form on the left.

C++0x Final Committee Draft Published - Please Comment

Friday, 02 April 2010

Earlier this week, the Final Committee Draft (FCD) of the C++0x standard was published. This means that C++0x is now in the final stages of bug fixing and wordsmithing before publication. If all goes to plan, the draft will move to Final Draft International Standard (FDIS) early in 2011, and will be a new standard by the end of 2011.

The publication of the FCD means that the draft standard has now been officially put up for review by the national standards bodies of ISO's member countries. The British Standards Institution is one of several national bodies that is actively involved in the standardisation of the C++ language. The panel members of the C++ Committee of the BSI, IST 5/-/21, are currently compiling a list of comments on the FCD. We intend to submit these as the BSI's National Body comments, aimed at getting issues with the FCD addressed before it becomes the new international standard for C++.

We're welcoming additional comments, and would like to provide a channel for anyone who may be interested in the C++0x Standard, but not able to be fully involved in the standards process, to submit comments. Note that not all comments — regardless of whether they are submitted by panel members or non-members — will go forward.

Here is some guidance on what we are looking for:

• Suggestions for how to improve the clarity of the wording, even if that's just by adding a cross-reference to a relevant paragraph elsewhere;
• Comments that identify any under/over specification; and
• Comments highlighting inconsistencies or contradictions in the draft text.

Comments should be specific and preferably should include suggested updated wording (and if you need help formulating updated wording we can provide it, within reason) — the C++ standards committee is working to a very tight schedule in order to get C++0x out as soon as possible, and comments without wording (which therefore require more work from the committee) are more likely to be rejected.

The time for adding/removing features has now passed, so comments should focus on improving the draft as it stands rather than suggesting new features.

Owing to the time scale for submission to BSI and ISO, comments need to be submitted by Friday 18th June 2010.

If you have any comments, feel free to post them in the comment section of this blog entry, or email them to me. I will forward all appropriate suggestions to the rest of the BSI panel (whether or not I agree with them).

Posted by Anthony Williams
[/ cplusplus /] permanent link
Tags: C++, C++0x, WG21, FCD
Stumble It! | Submit to Reddit | Submit to DZone

Comment on this post

If you liked this post, why not subscribe to the RSS feed or Follow me on Twitter? You can also subscribe to this blog by email using the form on the left.

just::thread C++0x Thread Library V1.3.2 Released

Thursday, 25 March 2010

I am pleased to announce that version 1.3.2 of just::thread, our C++0x Thread Library has just been released.

This release is the first to feature support for the Microsoft Visual Studio 2010 RC for both 32-bit and 64-bit Windows.

There are also a few minor fixes to the future classes, and a new implementation of mutexes and condition variables on linux with lower overhead.

Purchase your copy and get started with the C++0x thread library NOW.

As usual, existing customers are entitled to a free upgrade to V1.3.2 from all earlier versions.

Posted by Anthony Williams
[/ news /] permanent link
Tags: multithreading, concurrency, C++0x
Stumble It! | Submit to Reddit | Submit to DZone

Comment on this post

If you liked this post, why not subscribe to the RSS feed or Follow me on Twitter? You can also subscribe to this blog by email using the form on the left.

February 2010 C++ Standards Committee Mailing

Tuesday, 23 February 2010

The February 2010 mailing for the C++ Standards Committee was published last week. This is the pre-meeting mailing for the March 2010 committee meeting and contains a new working draft.

There are 5 concurrency-related papers (of which my name is on one), which I summarize below:

Concurrency-related papers

N3038: Managing the lifetime of thread_local variables with contexts (Revision 2)

This is my paper on creating contexts for thread_local variables. The use of such contexts allows you to control when variables that are declared as thread_local are destroyed. It is a revision of my previous paper N2959; the primary change is that contexts can now be nested, which allows library code to use them without having to know whether or not a context is currently active.

N3040: Various threads issues in the library (LWG 1151)

This paper by Hans Boehm seeks to address LWG issue 1151. The key issue is to ensure that it is clear which operations may constitute a data race if they run concurrently without synchronization.

N3041: Futures and Async Cleanup

The adoption of multiple papers affecting futures and std::async at the same C++ committee meeting meant that the wording ended up being unclear. Detlef Vollmann kindly volunteered to write a paper to resolve these issues, and this is it.

Unfortunately, I think that some of the wording is still unclear. I also dislike Detlef's proposal to force the wait_for and wait_until member functions of the future types to throw exceptions if the future was created from a call to std::async with a launch policy of std::launch::sync. My preferred alternative is to change the return type from bool to an enumeration with distinct values for if the future is ready, if the wait timed out, or if the future holds a deferred function from std::launch::sync that has not yet started. This would be similar to the current behaviour of std::condition_variable::wait_for and std::condition_variable::wait_until, which return a std::cv_status enumeration value.

N3042: Renaming launch::any and what asyncs really might be

This is another paper from Detlef Vollmann proposing renaming std::launch::any to std::launch::any_sync. His rationale is that future revisions of the C++ standard may wish to add values to the std::launch enumeration for additional types of async calls that should not be covered by std::launch::any. Personally, I think this is a non-issue, and should be covered as and when such values are added.

N3045: Updates to C++ Memory Model Based on Formalization

Following attempts to create a mathematical formalization of the memory model it became clear that some cases were unclear or ambiguous or did not guarantee the desired semantics. This paper proposes some changes to the wording of the memory model in order to ensure that it means what we intended it to mean.

Other Papers

There's several non-concurrency papers in the mailing as well as the standard set (working draft, agenda, issues lists, etc.). The most significant of these in my view is N3044 which proposes compiler-defined move constructors and assignment operators. Check the mailing for the full set.

Posted by Anthony Williams
[/ cplusplus /] permanent link
Tags: C++0x, C++, standards, concurrency
Stumble It! | Submit to Reddit | Submit to DZone

Comment on this post

If you liked this post, why not subscribe to the RSS feed or Follow me on Twitter? You can also subscribe to this blog by email using the form on the left.

The difference between struct and class in C++

Sunday, 21 February 2010

I've seen a lot of people asking about the differences between the use of the struct and class keywords in C++ lately. I don't know whether there's an influx of C++ programmers due to the upcoming C++0x standard, or whether I've just noticed people asking questions that haven't caught my eye before. Whatever the reason, I'm writing this blog entry as something I can point to the next time someone asks the question.

Declaring and defining user-defined types

The primary use of both the struct and class keywords is to define a user-defined type. In C++, such a user-defined type is termed a "class" regardless of which keyword is used in the definition. The choice of keyword is in one sense arbitrary, since the same features and facilities are available whichever keyword is used — there is only one semantic difference which we shall look at shortly. The following two class definitions are thus equivalent in all respects apart from the names of the classes:

struct type_a
{
private:
    int data;
public:
    type_a(int data_):
        data(data_)
    {}
    virtual void foo()=0;
    virtual ~type_a()
    {}
};

class type_b
{
private:
    int data;
public:
    type_b(int data_):
        data(data_)
    {}
    virtual void foo()=0;
    virtual ~type_b()
    {}
};

As this little example shows, you can have constructors, destructors, member functions, private members and even virtual member functions in a class declared with the struct keyword, just as you can with a class declared using the class keyword. Though this example doesn't show it, you can also use the struct keyword to declare classes with base classes.

You can even forward-declare your class using one keyword and then define it with the other, though compilers have been known to complain about this usage:

struct foo;
class foo {};

class bar;
struct bar {};

So, what of the minor semantic difference then? The change is in the default access specifier for members and base classes. Though classes defined using either keyword can have public, private and protected base classes and members, the default choice for classes defined using class is private, whilst for those defined using struct the default is public. This is primarily for backwards compatibility with C: the members of a C structure can be freely accessed by all code so in order to allow existing C code to compile unchanged as C++ the default access specifier for members of a class declared with struct must be public. On the other hand, private data is a key aspect of the encapsulation aspect of object-oriented design, so this is the default for those classes declare with class.

C doesn't have inheritance, but the default access specifier for base classes varies with the keyword used to declare the derived class too. It is public for classes declared with struct and private for those declared with class just the same as for data members. You can still override it with an explicit specifier in both cases.

Let's take a quick look at some examples to see how that works:

struct s1
{
    int a; // public
private:
    int b; // private
protected:
    int c; // protected
public:
    int d; // public again
};

class c1
{
    int a; // private
private:
    int b; // still private
protected:
    int c; // protected
public:
    int d; // public
};

struct s2:
    s1, // public
    private c1, // private
    type_b, // public again
    protected foo, // protected
    public bar // public again
{};

class c2:
    s1, // private
    private c1, // still private
    type_b, // private again
    protected foo, // protected
    public bar // public
{};

As far as declaring and defining user-defined types in C++, that is the only difference; in all other respects, classes declared with struct are identical to those declared with class.

C Compatibility

We touched on this a bit earlier: classes declared with the struct keyword can be compiled as C if they don't use any features that are C++ specific. Thus the following is both a valid C++ class and a valid C structure:

struct c_compatible
{
    int i;
    char c;
    double d;
};

It is therefore common to see struct used in header files that are shared between C and C++. Since non-virtual member functions don't affect the class layout you can even have member functions in such a type, provided they are hidden from the C compiler with a suitable #ifdef:

struct baz
{
    int i;

#ifdef __cplusplus
    void foo();
#endif;
};

Templates

There is one place where you can use the class keyword but not the struct one, and that is in the declaration of a template. Template type parameters must be declared using either the class or typename keyword; struct is not allowed. The choice of class or typename in this case is again arbitrary — the semantics are identical. The choice of keyword does not impose any semantic meaning, any type (whether a built in type like int or a user-defined type like a class or enumeration) can be used when instantiating the template in either case.You can of course declare a class template with the struct keyword, in which case the default access for the members of the template is public.

template<class T> // OK
void f1(T t);

template<typename T> // OK
void f2(T t);

template<struct T> // ERROR, struct not allowed here
void f3(T t);

template<class T>
struct S
{
    T x; // public member
};

That's all folks!

These are the only concrete distinctions between the uses of the struct keyword and the class keyword in C++. People also use them for documentation purposes, reserving struct for C-compatible classes, or classes with no member functions, or classes with no private data, or whatever their coding standard says. However, this is just documentation and convention rather than an inherent difference: you could use struct for all your classes, or class for all your classes except those that are shared with C.

Posted by Anthony Williams
[/ cplusplus /] permanent link
Stumble It! | Submit to Reddit | Submit to DZone

Comment on this post

If you liked this post, why not subscribe to the RSS feed or Follow me on Twitter? You can also subscribe to this blog by email using the form on the left.

More recent entries Older entries

Design and Content Copyright © 2005-2025 Just Software Solutions Ltd. All rights reserved. | Privacy Policy