October 2014

N4154: Operator assert -- David Krauss

A new WG21 paper is available. If you are not a committee member, please use the comments section below or the std-proposals forum for public discussion.

Document number: N4154

Date: 2014-09-30

Operator assert

by David Krauss

Excerpt:

The assert macro has never behaved much like a real function, and for the foreseeable future, it will look and smell like an operator. The way the macro is specified by C precludes it from providing optimization hints in production mode, but allows it to execute arbitrary side effects in debug mode. Adding assert as a keyword and built-in operator would have benefits but essentially no downside.

This will resolve LWG DR 2234 and 2413.

Ranges in C++: Counted Iterables and Efficiency -- Eric Niebler

New in Eric's series on ranges for C++:

Ranges in C++: Counted Iterables and Efficiency

by Eric Niebler

From the article:

I’ve been hard at work fleshing out my range library and writing a proposal to get range support into the standard. That proposal describes a foundational range concept: Iterable. An Iterable is anything we can pass to std::begin() and std::end() to get an Iterator/Sentinel pair. Sentinels, as I described here earlier this year, make it possible for the Iterable concept to efficiently describe other kinds of ranges besides iterator pairs.

The three types of ranges that we would like the Iterable concept to be able to efficiently model are:

  • Two iterators
  • An iterator and a predicate
  • An iterator and a count
The Iterator/Sentinel abstraction is what makes it possible for the algorithms to handle these three cases with uniform syntax. However, as Sean Parent pointed out here, the third option presents challenges when trying to make some algorithms optimally efficient. Back in February, when Sean offered his criticism, I promised to follow up with a blog post that justified the design. This is that post.

Quick Q: Should I prefer non-member std::begin and std::end? -- StackOverflow

Quick A: Yes.

A classic on SO, just re-asked yesterday:

When to use std::begin and std::end instead of container specific versions

Are there any general preferences or rules that explain when container specific versions of begin and end should be used instead of free functions std::begin and std::end?

It is my understanding that if the function is a template whereby the container type is a template parameter then std::begin and std::end should be used, i.e.:

template<class T> void do_stuff( const T& t )
{
    std::for_each( std::begin(t), std::end(t), /* some stuff */ );
}

What about in other scenarios such as a standard / member function where the type of container is known? Is it still better practice to use std::begin(cont) and std::end(cont) or should the container's member functions cont.begin() and cont.end() be preferred?

Am I correct in assuming that there is no benefit in performance by calling cont.end() over std::end(cont)?

ACCU 2015 Call for Papers

ACCU 2015 is now putting together its program, and they want you to speak on C++. ACCU has long had a strong C++ track, though it is not a C++-only conference. If you have something to share, check out the call for papers. 

Call for Papers

ACCU 2015

We invite you to propose a session for this leading software development conference...

The Call for Papers lasts 5 weeks and will close at midnight Wednesday 5th November 2014. Remember, remember, the 5th of November...

N4152: uncaught_exceptions -- Herb Sutter

A new WG21 paper is available. If you are not a committee member, please use the comments section below or the std-proposals forum for public discussion.

Document number: N4152

Date: 2014-09-30

uncaught_exceptions

by Herb Sutter

Excerpt:

This paper is a revision of N3614 to implement EWG direction in Bristol.

...

This paper proposes a new function int std::uncaught_exceptions() that returns the number of exceptions currently active, meaning thrown or rethrown but not yet handled.

Insights into new and C++

I've written down some basic thinking on new and new standards:

Insights into new and C++

by Jens Weller

From the article:

Every now and then, I've been thinking about this. So this blogpost is also a summary of my thoughts on this topic, dynamic memory allocation and C++. Since I wrote the blog entries on smart pointers, and C++14 giving us make_unique, raw new and delete seem to disappear from C++ in our future code...

Quick Q: How can I call a function only one? -- StackOverflow

Quick A: std::call_once.

Recently on StackOverflow:

Standard library function for running a function only once

Is there some standard library function/class the behaviour of this lambda expression:

void some_func(int some_arg, float some_other_arg){
    static int do_once = ([](){
        // will be run once upon first function call but never again
        return 0; // dummy return value
    })();
    // will always run
}

t feels like such a hack to write this, but I can't think of another way of doing this other than simply calling the function in main, but what I'm actually doing depends upon template parameters and I need to keep it as generic as possible.

For context: I register a function with atexit for every different template parameter, but only once: the first time it is called.

GEANT4: Forecasting the future -- Monica Friedlander

A widely-used C++ program you might never have heard of: Physicists and other scientists use the GEANT4 toolkit to identify problems before they occur.

GEANT4: Forecasting the future

By Monica Friedlander

From the article:

Physicists can tell the future -- or at least foresee multiple possible versions of it. They do this through computer simulations. Simulations can help scientists predict what will happen when a particular kind of particle hits a particular kind of material in a particle detector. But physicists are not the only scientists interested in predicting how particles and other matter will interact. This information is critical in multiple fields, especially those concerned about the effects of radiation.

At CERN in 1974, scientists created the first version of GEANT (Geometry and Tracking) to help physicists create simulations. Today it is in its fourth iteration, developed by an international collaboration of about 100 scientists from 19 countries. Anyone can download the system to a personal computer, use C++ programming language to plug in details about the particle and material in question and find out what will happen when the two meet.

GEANT4 is used in some of the most advanced accelerator experiments in the world, but its user base has grown beyond the particle physics community...

Quick Q: Do smart pointers help replace raw pointers? -- StackOverflow

Quick A: Yes, smart pointers replace owning raw pointers, and you should prefer smart pointers in new code. Raw pointers and references are still appropriate to pass parameters down a stack.

Recently on SO:

C++ 11 Smart Pointer usage

I have a question about smart pointers in c++ 11. I've started to have a look at C++ 11 (I usualy program in c#) and read some thing about smart pointers. Now i have the question, does smart pointers completely replace the "old" style of pointers, should i always use them?