Home » Blog » Tags » intermediate

intermediate

C++ Core Guidelines Checkers available for VS 2015 Update 1--Andrew Pardoe and Neil MacIntosh

By Adrien Hamelin | Dec 7, 2015 01:31 AM | Tags: intermediate experimental

Coding well in C++ is becoming easier:

C++ Core Guidelines Checkers available for VS 2015 Update 1

by Andrew Pardoe and Neil MacIntosh

From the article:

Back in September at CppCon 2015 Neil announced that we would be shipping new code analysis tools for C++ that would enforce some of the rules in the C++ Core Guidelines. (A video of the talk is available here: https://www.youtube.com/watch?v=rKlHvAw1z50 and slides are available on the ISOCpp GitHub repo.)

Quick Q: C++ regex: Conditional replace

By Adrien Hamelin | Dec 7, 2015 01:28 AM | Tags: intermediate c++11

Quick A: Use regex_token_iterator

Recently on SO:

C++ regex: Conditional replace

Use regex_token_iterator


#include <regex>
#include <string>
#include <sstream>
#include <set>
#include <map>

std::string replacer(std::string text) {
    std::string output_text;
    std::set<std::string> keywords = { "foo", "bar" };
    std::map<std::string, int> ids = {};

    int counter = 0;
    auto callback = [&](std::string const& m){
        std::istringstream iss(m);
        std::string n;
        if (iss >> n)
        {
            if (keywords.find(m) != keywords.end()) {
                output_text += m + " ";
            }
            else {
                if (ids.find(m) != ids.end()) {
                    output_text += "ID" + std::to_string(ids[m]) + " ";
                }
                else {
                    // not found
                    ids[m] = counter;
                    output_text += "ID" + std::to_string(counter++) + " ";
                }
            }
        }
        else
        {
            output_text += m;
        }
    };

    std::regex re("\\b\\w*\\b");
    std::sregex_token_iterator
        begin(text.begin(), text.end(), re, { -1, 0 }),
        end;
    std::for_each(begin, end, callback);
    return output_text;
}

 

Quick Q: Why destructor disabling the generation of implicit move functions?

By Adrien Hamelin | Nov 27, 2015 01:45 AM | Tags: intermediate c++11

Quick A: Because it means that your class is handling a ressource, thus the compiler cannot know how to move.

Recently on SO:

Why destructor disabling the generation of implicit move functions?

"The Rule of Zero" is in fact about something else than what special member functions are generated and when. It is about a certain attitude to class design. It encourages you to answer a question:

Does my class manage resources?

If so, each resource should be moved to its dedicated class, so that your classes only manage resources (and do nothing else) or only accumulate other classes and/or perform same logical tasks (but do not manage resources).

It is a special case of a more general Single Responsibility Principle.

When you apply it, you will immediately see that for resource-managing classes you will have to define manually move constructor, move assignment and destructor (rarely will you need the copy operations). And for the non-resource classes, you do not need to (and in fact you probably shouldn't) declare any of: move ctor/assignment, copy ctor/assignment, destructor.

Hence the "zero" in the name: when you separate classes to resource-managing and others, in the "others" you need to provide zero special member functions (they will be correctly auto-generated.

There are rules in C++ what definition (of a special member function) inhibits what other definitions, but they only distract you from understanding the core of the Rule of Zero.

For more information, see:

Overload resolution -- Andrzej KrzemieĊ„ski

By Marco Arena | Nov 19, 2015 09:51 AM | Tags: intermediate

An introduction to function template specialization, function (template) overloading, argument dependent lookup (ADL) and overload resolution:

Overload resolution

by Andrzej Krzemieński

From the article:

This post is an introduction to another one that I intend to write in the future...

Breaking all the Eggs in C++ -- Scott Meyers

By Felix Petriconi | Nov 13, 2015 02:08 PM | Tags: intermediate

Scott Meyers takes a deeper look into uninitialized memory in his recent blog post.

Breaking all the Eggs in C++

by Scott Meyers

From the article:

If you want to make an omelet, so the saying goes, you have to break a few eggs. Think of the omelet you could make if you broke not just a few eggs, but all of them! Then think of what it'd be like to not just break them, but to replace them with newer, better eggs. That's what this post is about: breaking all the eggs in C++, yet ending up with better eggs than you started with.

NULL, 0, and nullptr

NULL came from C. It interfered with type-safety (it depends on an implicit conversion from void* to typed pointers), so C++ introduced 0 as a better way to express null pointers. That led to problems of its own, because 0 isn't a pointer, it's an int. C++11 introduced nullptr, which embodies the idea of a null pointer better than NULL or 0. Yet NULL and 0-as-a-null-pointer remain valid. Why? If nullptr is better than both of them, why keep the inferior ways around?

Backward-compatibility, that's why. Eliminating NULL and 0-as-a-null-pointer would break exiting programs. In fact, it would probably break every egg in C++'s basket. Nevertheless, I'm suggesting we get rid of NULL and 0-as-a-null-pointer, thus eliminating the confusion and redundancy inherent in having three ways to say the same thing (two of which we discourage people from using).

Cheerp 1.1 - C++ for the Web with fast startup times, dynamic memory and more speed!--Leaning Tech

By Adrien Hamelin | Nov 7, 2015 05:42 AM | Tags: web intermediate

If you want your C++ code to run on the web, there is Emscripten, but there is also Cheerp:

Cheerp 1.1 - C++ for the Web with fast startup times, dynamic memory and now, more speed!

by Leaning Technologies Ltd.

From the article:

Cheerp is a C++ compiler for the Web platform. Roughly a year ago we released Cheerp 1.0 with the promise of making C++ a first class language for the Web, with full access to DOM and HTML5 APIs (including WebGL) and great performance. At that time, we could only partially meet that promise.

With our early adopters starting to use Cheerp on real world, large scale applications, we were proud to see that Cheerp could indeed be used to seamlessly integrate C++ code into HTML5 apps. But we also realized that the performance of the compiled code was disappointing on real codebases.

As an example, our first benchmarking result on our first large-scale (~1M sloc) customer code was around forty times (40x) slower than native. Not only was this result disappointing, but it also was much worse than what we were expecting based on our internal benchmarks.

One year later, after significant effort focused on performance optimizations, we are here today to announce Cheerp 1.1...

The Variant Saga: A happy ending?

By Axel | Nov 6, 2015 04:32 PM | Tags: intermediate experimental efficiency

Variant is like a union, only it tells you what it currently contains, and it will barf if you try to get something out of it that is does not currently contain. It's the type safe sibling of the union:

variant<double, string> v = 42.;
double d = get<double>(v);

I had proposed a variant many moons ago (N4218). After many discussions it seemed that the committee cannot agree on what the ideal C++ variant would look like. I will resolve this cliffhanger -- but before doing that let me introduce you to some of the key discussion points.

An ideal variant will always contain one of its alternative types. But look at this code snippet:

variant<string, MyClass> v = "ABC";
v = MyClass();

The second line will destroy the old value contained in the variant and construct the new value of a different type. Now suppose that the MyClass construction threw: what will the variant contain? What happens when you call get<1>(v)? What happens when the variant gets destroyed?

We either provide the strong exception guarantee (the variant would still contain the string) -- but this requires double buffering, as for instance boost::variant does. Or we could restrict the alternative types to only those that are nothrow_move_constructible. Or we make this a new state -- "invalid, because the variant has been derailed due to an exception thrown during type changing assignment". Or we say "you shouldn't write code that behaves like this; if you do you're on your own", i.e. undefined behavior. The committee was discussing what to do, and so was The Internet. There are other design decisions -- default construction, visitation etc -- but they are all insignificant compared to how to deal with the throwing, type-changing assignment.

I have tried to present the options and their pros and cons in P0086. In short: it's incredibly difficult and fragile to predict whether a type is_nothrow_move_constructible. And double buffering -- required for a strong exception guarantee -- kills the quest for an efficient variant. But efficiency is one of the main motivations for using a discriminated union.

After the second Library Evolution Working Group (LEWG) review in Lenexa, we got P0088R0: a design that was making this invalid state extremely rare. But if it happened, access to the value would result in undefined behavior. This caused a vivid reaction from the committee members. And from The Internet. Hundreds of emails on the committee email lists. Many many smart and convincing blog posts.

In the end, different parts of the committee strongly supported different designs -- and vetoing other designs. Massive disagreement. So when we came to our C++ Standards Meeting in Kona, it was immediately clear that we needed to expose this to the full committee (and not just LEWG). The expectation was that we would declare variant dead, and keep it locked away for the next five years. At least. (An I would have time to water my fishes again.)

So back to the cliffhanger. On the full committee, Monday evening stage in Kona were David Sankel and I. We presented (and represented) the different design options. While we were discussing with the committee members, live and uncut and on stage, David and I realized that we could make it happen. "The Kona Kompromise": similar to P0088R0, but instead of undefined behavior when extracting the value of such a zombie variant it would just throw!

The Kona Kompromise means that we don't pay any efficiency for the extremely rare case of a throwing move. The interface stays nice and clean. A variant of n alternatives is a "mostly" an n-state type. It offers the basic exception guarantee at no relevant performance loss. It is a safe vocabulary type for every-day use, also for novices. The vast majority of the committee was convinced by this idea. Almost everyone in the room was happy!

Do we have a std::variant now? Not yet. But we are a giant leap closer: variant is now under wording review with the Library Working Group (LWG); I will publish a new revision in the Kona post-mailing (P0088R1). This will get re-reviewed in Jacksonville, first week of March. Once LWG gives the green light, the full committee can vote variant into a Technical Specification (TS) as std::experimental::variant. Now that a large fraction of the committee has expressed its consent (happiness, even!), I expect that this will be in the TS called Library Fundamentals, v3. It might or might not make it into C++17 -- that depends mostly on how quickly I manage to bring P0088 into an acceptable state, and how quickly we will gain use experience with variant.

So there is one thing I'd really appreciate your help with: std::experimental::variant will show up in library implementations near you, likely in their first releases next year. It would be fantastic if you could try it out, and as importantly: give feedback, on the public forums or by contacting me directly ([email protected]). Your feedback will tell us whether the design decisions we took are the right ones, for instance regarding default construction, visitation, performance, and especially converting construction and assignment. As they say here: Mahalo!

Axel Naumann, CERN ([email protected])

 

6 topics on starting and running a User Group

By Meeting C++ | Nov 6, 2015 03:17 AM | Tags: intermediate community basics

I posted an update on my founding C++ User Groups article from 2 years ago:

6 topics on starting and running a User Group

by Jens Weller

From the article:

Almost two years ago I blogged about founding C++ User Groups, since then I have learned a lot more on the topic, and I want to share that experience with you in this blog post. While my focus here at Meeting C++ is C++, this post is more on the topic of a User Group, so its also useful to you, if you want to start a user group on something else. Yet, I might strive away into C++ lands in this post...