Articles & Books

January standards papers mailing available

The between-meetings standards papers mailing is now available. It includes the spring meeting agenda, updated issues lists, and a number of new papers including at least one that came through the public std-proposals forum. (Update: Please also direct discussion about these papers to that forum.)

 

WG21 Number Title Author Document Date Mailing Date Previous Version Subgroup Disposition
SD-1 2013 PL22.16/WG21 document list Clark Nelson 2013-01-15 2013-01      
SD-2 ISO WG21 and INCITS PL22.16 membership list Clark Nelson 2013-01-11 2013-01      
SD-3 SC22/WG21 (C++) Study Group Organizational Information Herb Sutter 2012-10-04 2012-09      
SD-5 WG21 and PL22.16 (C++) Joint Mailing and Meeting Information Herb Sutter 2010-09-20 2012-09      
2013-01
N3493 Compile-time integer sequences Jonathan Wakely 2013-01-11 2013-01   Library Evolution  
N3494 A proposal to add special mathematical functions according to the ISO/IEC 80000-2:2009 standard Vincent Reverdy 2012-12-19 2013-01   Library Evolution  
N3495 inplace realloc Ariane van der Steldt 2012-12-07 2013-01   Library Evolution  
N3496 AGENDA, PL22.16 Meeting No. 60, WG21 Meeting No. 55, April 15-20, 2013 -- Bristol, UK Stephen D. Clamage 2013-01-02 2013-01      
N3497 Runtime-sized arrays with automatic storage duration (revision 4) Jens Maurer 2013-01-01 2013-01 N3467 Core  
N3498 Core Issue 1512: Pointer comparison vs qualification conversions (revision 2) Jens Maurer 2013-01-07 2013-01 N3478 Core  
N3499 Digit Separators Lawrence Crowl 2012-12-19 2013-01 N2281 Core  
N3500 New assert variants Olaf van der Spek 2012-11-28 2013-01   Library Evolution  
N3501 C++ Standard Core Language Active Issues, Revision 82 William M. Miller 2013-01-14 2013-01 N3480 Core  
N3502 C++ Standard Core Language Defect Reports and Accepted Issues, Revision 82 William M. Miller 2013-01-14 2013-01 N3481 Core  
N3503 C++ Standard Core Language Closed Issues, Revision 82 William M. Miller 2013-01-14 2013-01 N3482 Core  
N3505 Filesystem Library Proposal (Revision 4) Beman Dawes 2013-01-12 2013-01 N3399 Filesystem  
N3506 A printf-like Interface for the Streams Library Zhihao Yuan 2012-12-26 2013-01   Library Evolution  
N3507 A URI Library for C++ G. Matthews, D. Berris 2013-01-11 2013-01 N3484 Networking  
N3508 Any Library Proposal (Revision 2) B. Dawes, K. Henney 2013-01-11 2013-01 N3390 Library  
N3509 Operator Bool for Ranges Olaf van der Spek 2012-12-19 2013-01   Library Evolution  
N3510 std::split(): An algorithm for splitting strings Greg Miller 2013-01-10 2013-01 N3430 Library Evolution  
N3511 exchange() utility function Jeffrey Yasskin 2013-01-10 2013-01   Library Evolution  
N3512 string_ref: a non-owning reference to a string, revision 2 Jeffrey Yasskin 2013-01-11 2013-01 N3442 Library Evolution  
N3513 Range arguments for container constructors and methods, wording revision 2 Jeffrey Yasskin 2013-01-11 2013-01 N3456 Ranges  
N3514 A Proposal for the World's Dumbest Smart Pointer Walter Brown 2012-12-19 2013-01   Library Evolution  
N3515 Toward Opaque Typedefs for C++1Y Walter Brown 2013-01-11 2013-01   Evolution  
N3516 C++ Standard Library Active Issues List (Revision R81) Alisdair Meredith 2013-01-15 2013-01 N3473 Library  
N3517 C++ Standard Library Defect Report List (Revision R81) Alisdair Meredith 2013-01-15 2013-01 N3474 Library  
N3518 C++ Standard Library Closed Issues List (Revision R81) Alisdair Meredith 2013-01-15 2013-01 N3475 Library  
N3519 Feb 5, 2013 SG1 Teleconference Announcement and Agenda Hans Boehm 2013-01-11 2013-01   Concurrency  
N3520 Critical sections in vector loops Robert Geva 2013-01-11 2013-01   Concurrency  
N3521 convert() utility function Jeffrey Yasskin 2013-01-12 2013-01   Library Evolution  

 

Quick Q: How to use range-based for with std::map? -- StackOverflow

A common question from the SO archives:

C++11: How to use range-based for loop with std::map?

The common example for C++0x range-based for() loops is always something simple like this:

std::vector<int> numbers = { 1, 2, 3, 4, 5, 6, 7 };

for ( auto xyz : numbers )

{

     std::cout << xyz << std::endl;

}

In which case xyz is an int. But, what happens when we have something like a map? What is the type of the variable in this example:

std::map< foo, bar > testing = { /*...blah...*/ };

for ( auto abc : testing )

{

    std::cout << abc << std::endl;         // ? should this give a foo? a bar?

    std::cout << abc->first << std::endl;  // ? or is abc an iterator?

}

When the container being traversed is something simple, it looks like range-based for() loops will give us each item, not an iterator. Which is nice...if it was iterator, first thing we'd always have to do is to dereference it anyway.

 

But I'm confused as to what to expect when it comes to things like maps and multimaps.

C++11 Rocks: Visual Studio 2012 Edition -- Alex Korban

Alex Korban has written a nice e-book that covers the parts of C++11 available in Visual Studio, including documenting limitations and bugs while still focusing on how using the C++11 features makes code cleaner, safer, and faster into the bargain.

The Visual Studio 2012 edition is now in beta. See the table of contents for what's covered, and a free sample to check out the style.

C++11 Rocks: Visual Studio 2012 Edition

by Alex Korban

Highlights from the description:

Visual Studio 2012 gives you the opportunity to use C++11 features to make your code significantly cleaner and easier to read, and to improve performance as well.

But which features are there? Are they ready for use in production code? ... 

You can master the C++11 features in VS2012 with this book. It’s laser focused on C++11, Visual Studio 2012, and nothing else. You’ll quickly get in-depth knowledge of the stuff you need to know.

You’ll learn easily with tons of examples. I spent a lot of time researching and testing, and as a result the book details many C++11 bugs and cases of non-standard behavior in Visual Studio.

Continue reading...

Are the Java vulnerabilities actually C and C++ vulnerabilities?

You've probably seen the headlines:

[US-CERT] Java in Web Browser: Disable Now!

We've been telling people to disable Java for years. ... We have confirmed that VU#625617 can be used to reliably execute code on Windows, OS X, and Linux platforms. And the exploit code for the vulnerability is publicly available and already incorporated into exploit kits. This should be enough motivation for you to turn Java off.

Firefox and Apple have blocked Java while U.S. Homeland Security recommends everyone disable it, because of vulnerabilities

Homeland Security still advises disabling Java, even after update

Some people have asked whether last week's and similar recent Java vulnerabilities are actually C or C++ vulnerabilities -- because, like virtually all modern systems software, Java is implemented in C and C++.

The answer is no, these particular exploits are pure Java. Some other exploits have indeed used vulnerabilities in Java's native C code implementation, but the major vulnerabilities in the news lately are in Java itself, and they enable portable exploits on any operating system with a single program. Note that this isn't to single out Java; other managed code environments have had similar vulnerabilities reported as well.

Today CERT posted an analysis of the current Java vulnerabilities, written by our own ISO C++ committee member David Svoboda:

Anatomy of Java Exploits

by David Svoboda

Java was exploited recently and last August. The August exploit was patched by Oracle on August 30; this most recent exploit now also has a patch available. Strictly speaking, the vulnerabilities that permitted both exploits are independent; the current exploit attacked code that was unused by the August exploit. Nevertheless, these vulnerabilities were quite similar. This blog post examines the vulnerabilities that permitted Java to be exploited in each case, using the proof-of-concept code exploits that have been published for them in January 2013 and August 2012.

The article demonstrates and comments on how security issues are common to all modern languages. From the conclusion:

While many previous Java vulnerabilities were actually vulnerabilities in the C code of a particular Java implementation, these exploits ran with pure Java -- no underlying C/C++ vulnerability was involved.

This doesn't mean Java is a horrible language any more than vulnerabilities in C and C++ make those horrible languages. Rather, it emphasizes that security is hard in any language or environment, and pretending otherwise is never helpful. For example, CERT publishes secure coding guidlines for various languages (the Java book coauthored by the author of the blog post above, David Svoboda):

And as Svoboda's CERT blog post today noted, many of today's popular attacks aren't language-specific, and:

... injection attacks, such as SQL injection, cross-site scripting (XSS), and command injection, occur in all languages that permit string manipulation.

Just like it isn't enough to think that using C++, which advertises an emphasis on performance, by itself means your code will be fast, it isn't enough to think that using a language that advertises an emphasis on safety means your code will be secure. As Robert Seacord, author or coauthor of both books above, said in email yesterday:

"The fact is that you need to understand the problems in whatever language you are using and diligently apply secure coding practices and principles if you want to have any hope of developing secure systems."

That's a lesson we can all benefit from, no matter which modern mainstream language we use.

Quick Q: When should you make a type non-movable in C++11? -- StackOverflow

So C++11 has these cool move semantics... but when would you not implement move construction and move assignment for your type?

When to make a type non-movable in C++11?

I was surprised this didn't show up in my search results, I thought someone would've asked this before, given the usefulness of move semantics in C++11:

When do I have to (or is it a good idea for me to) make a class non-movable in C++11?

(Reasons other than compatibility issues with existing code, that is.)

Quick Q: What does T&& mean in C++11? -- StackOverflow

This question is so common it immediately got triple-digit upvotes on the question and answer:

What does T&& mean in C++11?

I've been looking into some of the new features of C++11 and one I've noticed is the double ampersand in declaring variables, like T&& var.

 

For a start, what is this beast called? I wish Google would allow us to search for punctuation like this.

What exactly does it mean?

 

At first glance, it appears to be a double reference (like the C-style double pointers T** var), but I'm having a hard time thinking of a use case for that.

When does a constexpr function get evaluated at compile time? -- StackOverflow

Here's a common question about constexpr...

A suggestion: As of this writing the more correct and useful (and simpler) answer K-ballo's, which was not selected as best -- please upvote K-ballo and help approve the pending edit that improves it. Thanks.

When does a constexpr function get evaluated at compile time?

Since it is possible that a function declared as constexpr can be called during run-time, under which criteria does the compiler decide whether to compute it at compile-time or during runtime?

 

template<typename base_t, typename expo_t>
constexpr base_t POW(base_t base, expo_t expo)
{
    return (expo != 0 )? base * POW(base, expo -1) : 1;
}

int main(int argc, char** argv)
{
    int i = 0;
    std::cin >> i;
    std::cout << POW(i, 2) << std::endl;
    return 0;
}

 

In this case, i is unknown at compile-time, which is probably the reason why the compiler treats POW() as a regular function which is called at runtime. This dynamic however, as convenient as it may appear to be, has some impractical implications. For instance, could there be a case where I would like the compiler to compute a constexpr function during compile-time, where the compiler decides to treat it as a normal function instead, when it would have worked during compile-time as well? Are there any known common pitfalls?

Quick Q: Is it still bad practice to return a vector from a function?

 

Here's another FAQ about modern C++11 style, and how C++11 is simpler than classic C++, including that this affects how we design our interfaces to make them simpler and easier to read and use.

However, be sure to read through the comments, because they cover several considerations including when it's safe to start relying on the simpler C++11 semantics as you migrate a code base from C++98 to C++11 and may still have to support C++98 clients for a while.

In C++, is it still bad practice to return a vector from a function?

Short version: It's common to return large objects—such as vectors/arrays—in many programming languages. Is this style now acceptable in C++0x if the class has a move constructor, or do C++ programmers consider it weird/ugly/abomination?

Long version: In C++0x is this still considered bad form?

std::vector<std::string> BuildLargeVector();

...

std::vector<std::string> v = BuildLargeVector();

 

[...]