Home » Blog » 2015 » September » Bjarne Stroustrup announces C++ Core Guidelines

Bjarne Stroustrup announces C++ Core Guidelines

By Blog Staff | Sep 21, 2015 09:00 AM | Tags: None

This morning in his opening keynote at CppCon, Bjarne Stroustrup announced the C++ Core Guidelines (github.com/isocpp/CppCoreGuidelines), the start of a new open source project on GitHub to build modern authoritative guidelines for writing C++ code. The guidelines are designed to be modern, machine-enforceable wherever possible, and open to contributions and forking so that organizations can easily incorporate them into their own corporate coding guidelines.

The initial primary authors and maintainers are Bjarne Stroustrup and Herb Sutter, and the guidelines so far were developed with contributions from experts at CERN, Microsoft, Morgan Stanley, and several other organizations. The guidelines are currently in a “0.6” state, and contributions are welcome. As Stroustrup said: “We need help!”

Stroustrup said: “You can write C++ programs that are statically type safe and have no resource leaks. You can do that without loss of performance and without limiting C++’s expressive power. This supports the general thesis that garbage collection is neither necessary nor sufficient for quality software. Our core C++ guidelines makes such code simpler to write than older styles of C++ and the safety can be validated by tools that should soon be available as open source.”

From Stroustrup’s talk abstract:

In this talk, I describe a style of guidelines that can be deployed to help most C++ programmers... The rules are prescriptive rather than merely sets of prohibitions, and about much more than code layout... The core guidelines and a guideline support library reference implementation will be open source projects freely available on all major platforms (initially, GCC, Clang, and Microsoft).

Although the repository was not officially announced until today, it was made public last week and was noticed: CppCoreGuidelines was the #1 trending repository worldwide on GitHub on Friday, and is currently the #1 trending repository worldwide for the past week, across all languages and projects.

Stroustrup also announced two other related projects.

Guideline Support Library (GSL): First, the C++ Core Guidelines also specifies a small Guideline Support Library (GSL), a set of common types like array_view and not_null to facilitate following the modern guidelines. An initial open source reference implementation contributed and supported by Microsoft is now available on GitHub at github.com/Microsoft/GSL. It is written in portable C++ that should work on any modern compiler and platform, and has been tested on Clang/LLVM 3.6 and GCC 5.1 for Linux, with Xcode and GCC 5.2.0 for OS X, and with Microsoft Visual C++ 2013 (Update 5) and 2015 for Windows. This is both a supported library and an initial reference implementation; other implementations by other vendors are encouraged, as are forks of and contributions to this implementation.

Checker tool: Second, the C++ Core Guidelines are designed to be machine-enforceable wherever possible, and include many rules that can be checked by a compiler, lint, or other tool. An initial implementation based on Microsoft’s Visual Studio will be demonstrated in several talks at CppCon this week, including Herb Sutter’s Day 2 plenary session tomorrow morning. This implementation will be made available as a Windows binary in October, with the intention to open source the implementation thereafter. This too will become a supported tool and an initial reference implementation open to others; other implementations by other vendors of compilers, linters, and other tools are encouraged.

A number of other CppCon talks will go deeper into the related topics, notably the following talks by speakers who collaborated on the Guidelines effort:

Herb Sutter: Writing Good C++14 by Default (Tue 10:30am)

Gabriel Dos Reis: Large Scale C++ with Modules: What You Should Know (Tue 2:00pm)

Neil MacIntosh: More Than Lint: Modern Static Analysis for C++ (Wed 2pm)

Neil MacIntosh: A Few Good Types: Evolving array_view and string_view for Safe C++ Code (Wed 3:15pm)

Gabriel Dos Reis: Contracts for Dependable C++ (Wed 4:45pm)

Eric Niebler: Ranges and the Future of the STL (Fri 10:30am)

(and more)

If you’re at CppCon this week, watch for those talks. If you aren’t, like last year’s event, CppCon 2015 is again professionally recording all talks, and they will be freely available online about a month after the conference.
 

Add a Comment

Comments are closed.

Comments (10)

2 0

Gennadiy Rozental said on Sep 22, 2015 12:29 AM:

Hear, hear! I've been thinking about something similar recently. Instead of inventing all these "simple", "safe" languages we should just learn to use modern C++ properly.

One thing I missed from reading PDF: why would anyone want to use not_null<T*> instead of T&? IMO the policy should be: use T& if you want to pass non null pointer/reference parameter and T* if it is optional and can be null. I might even prefer optional<T&> to T* (semantic is clearer IMO), but I am not greedy - if T* is never array and never owning we can stick with it ;o)
0 0

Alan Braggins said on Sep 22, 2015 04:13 AM:

> why would anyone want to use not_null<T*> instead of T&?

You might want something you can increment, or otherwise change what object it points to.
0 0

Andrey Karpov said on Sep 22, 2015 07:40 AM:

BTW: don't forget to check our tips on C++ at www.cpphints.com
The topics are quite allied.
0 0

Gennadiy Rozental said on Sep 22, 2015 10:49 AM:

>> why would anyone want to use not_null<T*> instead of T&?

>You might want something you can increment, or otherwise
>change what object it points to.

No, no. We already agreed that this is not an array. And changing parameter to point something else is not a good practice IMO. If you need logic like this you are better off introducing local variable which points to the parameter or something else.
0 0

Jengerer said on Sep 22, 2015 01:27 PM:

> why would anyone want to use not_null<T*> instead of T&?

As far as I'm aware, using T& for non-null is largely a semantic thing; there's no real guarantee that the reference is non-null (i.e. you can do T* p = nullptr; T& r = *p; on most compilers without complaints). On the other hand, not_null<T*> will actually trigger asserts if it ever becomes null.
0 0

Gennadiy Rozental said on Sep 22, 2015 02:22 PM:

>> why would anyone want to use not_null<T*> instead of T&?

not in a well formed program

> As far as I'm aware, using T& for non-null is largely a
> semantic thing; there's no real guarantee that the reference is non-null
> (i.e. you can do T* p = nullptr; T& r = *p; on most compilers without
> complaints).

this is undefined behavior

> On the other hand, not_null<T*> will actually trigger asserts if
> it ever becomes null.

I did not look how not_null works, but realistically there are only few options:
* compile time check - this require non standard compiler extension, if it is at all possible. And if you can do it for not_null, you can do it for T&
* runtime check - I am not sure many people will want a runtime check on every pointer assignment in their program. Practically this is identical to a policy where we should have a check on every plain pointer dereference.
0 0

Jengerer said on Sep 22, 2015 02:46 PM:

> not in a well formed program
> ...
> this is undefined behavior

Well, I suppose that's part of the point. Maintaining proper assumptions about when pointers are and aren't null can get messy, and bad assumptions can invoke undefined behaviour and bugs that will be silently bypassed by the compiler (and possibly even at run-time). Presumably, not_null is intended to provide some feedback/testability in that regard.

The open-source Microsoft implementation linked above does seem to do the checks at run-time assignment (with a soft assumption that they'll be optimized out by the compiler in the obvious cases). I'm inclined to agree that its usefulness is situational, so I'm not trying to stage a defense here; I'm merely explaining what I understand their purpose to be.
1 0

Gennadiy Rozental said on Sep 22, 2015 03:18 PM:

> I'm inclined to agree that its usefulness is situational,
> so I'm not trying to stage a defense here; I'm merely explaining
> what I understand their purpose to be.

In that case I'd rather recommend using safe_deref function. IOW instead of:



void foo(non_null<T*> ptr);

...

void goo()

{

    T  obj;

    T& ref = obj;

    T* ptr = &obj;

    unique_ptr<T> optr = new T;

    ...

    foo( &obj );

    foo( &ref );

    foo( ptr );

    foo( optr.get() );

}


I'd prefer 



void foo(T& ref);

...

void goo()

{

    T  obj;

    T& ref = obj;

    T* ptr = &obj;

    unique_ptr<T> optr = new T;

    ...

    foo( obj );

    foo( ref );

    foo( safe_deref(ptr) );

    foo( *optr );

}


unique_ptr::operator* can do it's own safe de-reference validation.

IOW In general I expect there will be much more objects, references and smart pointers than bare pointers in modern C++.
0 0

kfsone said on Sep 24, 2015 11:26 AM:

> why would anyone want to use not_null<T*> instead of T&?

Because "The rules are prescriptive rather than merely sets of prohibitions". It seems like we wouldn't want to make it so that the STL, say, can't make use of these tools.
1 0

PedroAreias said on Jan 27, 2016 10:26 AM:

Fortran 90/95 all over again.

Keep the byzantine syntax for legacy and propose an improved syntax.

We also urgently require a deep-copied smart pointer or smart reference. That would definitely end the semantics of reference while maintaining polymorphism underneath.

I have one myself, but prefer to have it in the Standard.

Now new file extensions are needed, perhaps .cpp14 and .hpp14 ?