Home » Blog » Categories »

C++ Modules in VS 2015 Update 1--Gabriel Dos Reis and Andrew Pardoe

By Adrien Hamelin | Dec 4, 2015 01:27 AM | Tags: experimental advanced

Modules in Visual:

C++ Modules in VS 2015 Update 1

by Gabriel Dos Reis and Andrew Pardoe

From the article:

The VC++ team is excited to preview a new feature in VS 2015 Update 1: The first experimental implementation of A Module System for C++, proposed for C++17. That proposal was approved by the C++ standards Evolution Working Group for a C++17 Technical Specification at the Fall 2015 meeting in Kona, Hawai’i. The draft wording for the Technical Specification is under review by the C++ Standards Core Working Group.

 

The most dangerous function in the C/C++ world

By Andrey Karpov | Dec 3, 2015 01:57 AM | Tags: None

Most errors that I see in the projects are related to the usage of this particular memset() function.

The most dangerous function in the C/C++ world

by Andrey Karpov

From the article:

Now I have another interesting observation. Using one or another function, the programmers can make mistakes. That is clear, you may say. But the probability of the error may also depend on the function. In other words, some functions provoke errors, and some don't. And now I am ready to name the function which causes most of the troubles and using which you have the biggest chance of an epic fail.

P0143R0: Wording for Modules -- Gabriel Dos Reis

By Blog Staff | Dec 2, 2015 02:30 PM | Tags: None

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

Document number: P0143R0

Date: 2015-11-30

Wording for Modules

by Gabriel Dos Reis

Excerpt:

This documents provides formal wording for a module system for C++. This document is to be read in conjunction with document P0142R0 “A Module System for C++”. The proposed wording are with respect to WG21 Committee Draft (N4567)

IncludeOS: A C++ Unikernel now free and open source

By Alfred Bratterud | Dec 2, 2015 10:40 AM | Tags: None

The IncludeOS unikernel prototype is now free and open source at GitHub. IncludeOS offers a portable way to run a compiled C++ service directly on virtual x86 hardware; either locally on your Mac or Windows machine with VirtualBox, or in large scale cloud environments running KVM.

#include <os> // literally.

From the home page:

Run your C++ code directly on virtual hardware

IncludeOS aims to be the thinnest, lightest possible layer, between your C++ code and virtual hardware. We provide a bootloader, standard libraries, lots (we hope) of modules, and the build- and deployment system. You provide the service.

IncludeOS is designed for KVM/Linux but previous versions have also been tested successfully on VirtualBox (which again runs on OS X Windows and Linux) and Bochs

It's a prototype -- be patient!

IncludeOS is not production ready -- but we're working hard to become so.

It's a research project

IncludeOS is the result of a research project at Oslo and Akershus University College of Applied Science (hioa.no)

A paper titled IncludeOS: a resource efficient unikernel for cloud services, which presents the first prototype, will appear at IEEE CloudCom 2015

Contributors

IncludeOS was created by @alfred-bratterud, with lots of contributions from @fwsgonzo and others at the NETSYS group at HiOA.

Efficient parameter pack indexing--Louis Dionne

By Adrien Hamelin | Nov 30, 2015 04:12 PM | Tags: c++11 advanced

And you, how do you index your parameter pack?

Efficient parameter pack indexing

by Louis Dionne

From the article:

Recently, I’ve been looking at ways to index into parameter packs with as little compile-time overhead as possible. This is not a new problem, and we know of several metaprogramming techniques to achieve this, some of which offer pretty good compile-times. Most of these techniques are also well documented, for example here and here. So, why write an article about this well-covered topic? Well, I recently decided to cheat and modified the compiler to see how fast we could possibly be. This article summarizes what I found.

C++ User Group Meetings in December

By Meeting C++ | Nov 30, 2015 04:40 AM | Tags: community

The monthly listing of upcoming C++ User Group Meetings on Meeting C++:

C++ User Group Meeting in December 2015

by Jens Weller

From the article:

The montly overview on C++ User Group meetings, this time for December. Meeting C++ is just a few days away, so I'm excited to see that again, so many groups are meeting. Also there are few new user groups worth mentioning! 2 x India (Delhi, Udaipur), Sydney, Beijing, Zürich, Sacramento and Ann Arbor! A new trend seems to be to form learning groups and meet weekly for a in depth C++ tutorial...

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:

Quick Q: const-reference qualified member function

By Adrien Hamelin | Nov 27, 2015 01:41 AM | Tags: c++11 advanced

Quick A: Delete the r-value reference overload of the function.

Recently on SO:

const-reference qualified member function

A temporary can be bound to a const& qualified object and the ref-qualifier effectively qualifies the implicitly passed object (*this). If you want to prevent calls on temporaries but allow lvalues, you can = delete the rvalue reference overload and implement the lvalue version. Using const qualified reference qualifiers for both operators requires just one implemented and one = deleted implementation:

class File {
    // ...
    FILE* _file;
public:
    operator FILE*() const&& = delete;
    operator FILE*() const& { return this->_file; }
    // ...
};

The net-effect is that you can use the conversion only for objects to which you go an lvalue:

int main() {
    File       f;
    File const cf{};

    FILE* fp = f;              // OK
    FILE* cfp = cf;            // OK
    FILE* tfp = File();        // ERROR: conversion is deleted
    FILE* mfp = std::move(cf); // ERROR: conversion is deleted 
}