Announce: Third Annual European LLVM Conference

By Eric Niebler | Jan 16, 2013 01:03 PM | Tags: None

For many of our readers, LLVM and Clang will need no introduction. LLVM is a modular compiler toolchain, and Clang is an LLVM front-end for the C family of languages. They're both implemented in C++. Together, they're taking the C++ toolchain in new directions. Be a part of the action at this just-announced developer conference in April in Paris. (Does it get better?) From the announcement:

Announcements

We are pleased to announce the third European LLVM conference on April 29-30 2013 in Paris, France. This will be a two day conference which aims to present the latest developments in the LLVM world and help strengthen the network of LLVM developers. The format will be similar to that of the previous meetings held in London but with more time for presentations and networking. The meeting is open to anyone whether from business or academia, professional or enthusiast and is not restricted to those from Europe -- attendees from all regions are welcome.

This meeting is about 8 days after the ISO C++ standardization meeting in Bristol, UK. Twofer, anyone? The full announcement gives all the details.

Continue reading...

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

By Herb Sutter | Jan 15, 2013 01:40 PM | Tags: None

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):

• Robert Seacord: The CERT C Secure Coding Standard (720 pages)
• Robert Seacord, David Svoboda, et al.: The CERT Oracle Secure Coding Standard for Java (744 pages) -- the authors report that an additional second companion volume is due later this year.

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.

POCO 1.4.6 released, 1.5.1 development release now available

By Blog Staff | Jan 14, 2013 04:41 PM | Tags: None

POCO versions 1.4.6 (stable) and 1.5.1 (development preview) are now available. Version 1.5.1 is a preview of the next major stable 1.6.0 release planned for this spring.

Here is the short note in its entirely. The links take to you the original announcement.

Releases 1.4.6 and 1.5.1 Available

Stable release 1.4.6 brings some bugfixes and minor enhancements. See the CHANGELOG for the details. This is planned to be the last release in the 1.4 series.

Development release 1.5.1 is a major step towards the next stable 1.6.0 release planned for this spring. See the CHANGELOG for what’s new.

Get the source code from the download page or directly from GitHub.

Update from the Ranges Study Group

By Eric Niebler | Jan 14, 2013 11:04 AM | Tags: intermediate experimental

In December, we announced the opening of the SG9 (Ranges) mailing list. Since then, the activity on it has been nothing short of amazing, and the discussion is of a markedly high quality. Ranges promise a improvement in usability, power, and safety for the STL. If you have ever wanted to see how the C++ Standardization Committee crafts the future of C++, sidle on over to the Ranges group and learn about the future of the STL from many of the people who have helped shape it since its inception. Watch tomorrow's C++ take shape today, and maybe help shape it yourself.

Read the list archives here, or sign up to get the blow-by-blow here.

P.S. You can start using (one implementation of) Ranges today over at Boost (see Boost.Range's docs).

Site updates: StackOverflow highlights, blog tags and comments, and more

By Blog Staff | Jan 13, 2013 03:15 PM | Tags: None

Over the holidays we've made several improvements to isocpp.org. Many are behind the scenes where most readers won't notice, but here are a few that a more visible. We hope you find them useful.

Home page: Highlights from StackOverflow and StackExchange

Today, we added a new home page feature: Selected highlights from StackOverflow's [c++] and [c++11] tags, and from Programmers.StackExchange's [c++11] tag. We are pleased to endorse these sites as a premier place for question-and-answer discussion about modern C++ -- if you have a question about C++, you can probably already find the answer there, or post a new question and get a high-quality answer quickly. Please note: StackOverflow and StackExchange are for Q&A only, and actively discourage "discussion" styles -- for discussion about the Standard, see the Forums accessible from this site.

SO and SE are high-traffic sites, and many of our readers may only have time to consume a shorter "highlights reel" summary each day. That's why our home page shows an "auto-curated" filtered subset of the SO and SE traffic, selecting highlights from each feed using criteria that we can adjust over time. However, for those interested in following the full flow of questions on StackOverflow or StackExchange, we also provide a handy RSS link for each feed that lets you directly subscribe to the corresponding full feed. In the future, if there's interest, we might also consider providing our own custom RSS feeds for those who want to follow our custom filtered versions of the higher-volume SO and SE feeds.

Blog Tags

Each blog entry is now tagged, so you can more easily find the kind of content that interests you.

Here are the tags we're using initially:

• basics: General information useful to anyone using C++, including programmers coming to C++ for the first time.
• intermediate: Information that assumes you have a working familiarity with C++ and are ready to dig a little deeper.
• advanced: Information for C++ experts that assumes you know C++ pretty well, want to make the most of it, and aren't afraid to "lift the hood" from time to time to take full control.
• experimental: Material that isn't about Standard C++ today, but about what it could be -- including articles talking about future language and library extensions, and even prototype compiler implementations of future language features.

Sometimes posts will have multiple tags, when they point to material that covers useful information at more than one level. For instance, "Panel" style videos often range widely over many useful topics, and may include a lot of generally useful information appropriate to all levels while also including some pretty advanced parts of interest to experts. The goal is that if you're looking for, say, "intermediate" material, then following that tag will deliver only those items that have significant intermediate content, even if some parts may be more basic or advanced.

When you read a post, you'll see the tag(s) listed near the top. You can click on any tag to see what else has been posted with that tag. Over the next few days, we'll be adding an easy way to drill into each tag without going to a blog post first.

Blog Comments

You can now edit your own blog comments. Also, formatting control has been improved, with some more improvements coming. As always, including a nicely-formatted code block in your comment is as easy as wrapping it with <pre> and </pre>.

And More

We've also made many more improvements under the covers, and will have more to show you in the coming weeks and months. Stay tuned.

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

By Blog Staff | Jan 13, 2013 04:48 AM | Tags: basics

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

By Blog Staff | Jan 12, 2013 10:07 AM | Tags: None

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

By Blog Staff | Jan 11, 2013 10:14 AM | Tags: intermediate basics

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?

By Blog Staff | Jan 11, 2013 10:04 AM | Tags: intermediate basics

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();

 

[...]

Quick Q: C++ template typedef -- StackOverflow

By Blog Staff | Jan 11, 2013 09:46 AM | Tags: basics

In the "look how simple this is now in C++11" department, this just in on SO:

C++ template typedef

I have a class

template<size_t N, size_t M>

class Matrix {

    // ....

};

I want to make a typedef which creates a Vector (column vector) which is equivalent to a Matrix with sizes N and 1. Something like that:

typedef Matrix<N,1> Vector<N>;

Which produces compile error. The following creates something similar, but not exactly what I want:

template <int N>

class Vector: public Matrix<N,1>

{ };

Is there a solution or a not too expensive workaround / best-practice for it? Thanks in advance!