Home » Blog » Categories » Articles & Books

Articles & Books

C++ Core Guidelines: Profiles--Rainer Grimm

By Adrien Hamelin | Sep 11, 2019 11:43 AM | Tags: community

To continue in the next one.

C++ Core Guidelines: Profiles

by Rainer Grimm

From the article:

Informally, profiles are a subset of rules of the C++ core guidelines for specific concerns such as type safety, bounds safety, and lifetime safety. Thanks to the guideline support library, they can be checked...

Cppcon-Tool Time 2019--Jon Kalb

By Adrien Hamelin | Sep 11, 2019 11:41 AM | Tags: community

Will you attend?

Tool Time 2019

by Jon Kalb

From the article:

Similar to tech labs at some other events, we’re offering the opportunity for anyone, from an author/creator, to a vendor, to a super-user, to represent a tool (app, library, framework, or service) and run their own table answering questions or showing demos...

C++17 - The Complete Guide now complete and available -- Nicolai M. Josuttis

By Nico Josuttis | Sep 10, 2019 11:43 PM | Tags: c++17

A new the latest book by Nicolai M. Josuttis is now complete and available.

C++17 - The Complete Guide

by Nicolai M. Josuttis

About the book:

The book is a full description of all language and library features that were introduced and modified with C++17.

It contains plenty of examples and many hints from using these new features in practice.

It is availble at your local book store or here.

 

 

Quick Q: Removing item from vector, while in C++11 range 'for' loop?

By Adrien Hamelin | Sep 6, 2019 11:00 AM | Tags: c++11 basics

Quick A: it is not possible

Recently on SO:

Removing item from vector, while in C++11 range 'for' loop?

No, you can't. Range-based for is for when you need to access each element of a container once.

You should use the normal for loop or one of its cousins if you need to modify the container as you go along, access an element more than once, or otherwise iterate in a non-linear fashion through the container.

For example:

auto i = std::begin(inv);

while (i != std::end(inv)) {
    // Do some stuff
    if (blah)
        i = inv.erase(i);
    else
        ++i;
}

Quick Q: How do C++ class members get initialized if I don't do it explicitly?

By Adrien Hamelin | Sep 5, 2019 11:41 AM | Tags: basics

Quick A: default constructors are called if available, otherwise there is no initialisation.

Recently on SO:

How do C++ class members get initialized if I don't do it explicitly?

In lieu of explicit initialization, initialization of members in classes works identically to initialization of local variables in functions.

For objects, their default constructor is called. For example, for std::string, the default constructor sets it to an empty string. If the object's class does not have a default constructor, it will be a compile error if you do not explicitly initialize it.

For primitive types (pointers, ints, etc), they are not initialized -- they contain whatever arbitrary junk happened to be at that memory location previously.

For references (e.g. std::string&), it is illegal not to initialize them, and your compiler will complain and refuse to compile such code. References must always be initialized.

So, in your specific case, if they are not explicitly initialized:

    int *ptr;  // Contains junk
    string name;  // Empty string
    string *pname;  // Contains junk
    string &rname;  // Compile error
    const string &crname;  // Compile error
    int age;  // Contains junk

fixing c++ with epochs -- Vittorio Romeo

By Vittorio Romeo | Sep 3, 2019 11:25 AM | Tags: None

This article proposes a mechanism to allow seemingly backwards-incompatible changes to C++'s syntax while actually maintaining backwards compatibility, leveraging the isolation of upcoming module units. The idea is similar to Rust's "Editions" mechanism. The post explains how the feature would work and how C++ would benefit from it.

fixing c++ with epochs

by Vittorio Romeo

From the article:

Imagine that you have been designing a programming language for over 30 years and that it gradually became widely used across the globe. Some of the decisions you made at the beginning were excellent and contributed to the success of your project. Some others, however, were not the best: over the years you and your users realized that the world would have been a better place if those choices you made eons ago were slightly different. [...]

What if I told you that I could fix all of your problems? Even better, what if I told you that backward-compatibility will never be broken and that migration to newer versions of your language could be automated?