Stepanov-Regularity and Partially-Formed Objects vs. C++ Value Types -- Marc Mutz

By Giuseppe D'Angelo | Jan 30, 2017 04:43 AM | Tags: basics

Marc Mutz wrote in his recent article about the properties of default constructed object as required by Elements of Programming.

Stepanov-Regularity and Partially-Formed Objects vs. C++ Value Types

by Marc Mutz

From the article:

In this article, I will take a look at one of the fundamental concepts introduced in Alex Stepanov and Paul McJones’ seminal book “Elements of Programming” (EoP for short) — that of a (Semi-)Regular Type and Partially-Formed State.

Using these, I shall try to derive rules for C++ implementations of what are commonly called “value types”, focusing on the bare essentials, as I feel they have not been addressed in sufficient depth up to now: Special Member Functions.

zero-overhead C++17 currying & partial application -- Vittorio Romeo

By Vittorio Romeo | Jan 30, 2017 04:42 AM | Tags: c++17

This article briefly explains the concepts of "currying" and "partial application", then covers the design and C++17 implementation of a generic zero-overheader constexpr `curry` function.

zero-overhead C++17 currying & partial application

by Vittorio Romeo

From the article:

[...] many features introduced in the latest C++ standards allow functional patterns to thrive in your codebase, [...] like currying and partial application. [...] In this article we're going to:

* Introduce and briefly explain the two aforementioned concepts.

* Write a generic constexpr zero-overhead `curry` function in C++17.

* Analyze the generated assembly of the implementation to prove the lack of overhead.

[...]

Given a generic function object `f`, invoking `curry(f)` will return a curried/partially-applicable version of `f`. If `f` is constexpr-friendly, the returned one will be as well. `curry` should not introduce any overhead compared to hand-written currying/partial application.

Istream Idiosyncrasies -- Adi Shavit

By Adi | Jan 30, 2017 04:41 AM | Tags: None

Idiosyncrasies with istreams.

Istream Idiosyncrasies

by Adi Shavit

From the article:

A lot has been written and the vice and virtues of the C++ iostreams library.
While working on Argh, my little C++11 argument parsing library, I ran across some somewhat surprising idiosyncrasies and a few interesting lessons.

Spy your memory usage with operator new--Stefano Saraulli

By Marco Arena | Jan 30, 2017 01:11 AM | Tags: intermediate efficiency

A blog post about overriding operator new to profile memory:

Spy your memory usage with operator new

by Stefano Saraulli

From the article:

When we say "efficiency", we often think "time". The sooner the code does its job, the more it is efficient. What about memory? Granted, today even the lousiest laptop comes with “a bucket load” of RAM which...

Modern C++ Features – decltype and std::declval--Arne Mertz

By Adrien Hamelin | Jan 25, 2017 12:04 PM | Tags: c++11 advanced

Do you use those?

Modern C++ Features – decltype and std::declval

by Arne Mertz

From the article:

decltype and std::declval are two features that go hand in hand and are most useful in template metaprogramming and in conjunction with the use of type deduction via auto, e.g. in generic lambdas...

Writing a reflection engine from scratch - Manuel Sanchez - Meeting C++ 2016

By Meeting C++ | Jan 25, 2017 09:47 AM | Tags: reflection c++14 basics advanced

Next Video from Meeting C++ 2016

Writing a reflection engine from scratch

by Manuel Sanchez

 

The Future of Generic Programming -- How to design good concepts and use them well -- Stroustrup

By Blog Staff | Jan 23, 2017 04:08 PM | Tags: None

This new paper by Bjarne Stroustrup has been brewing over the holidays, and is now ready for release as a prepublication draft:

Concepts: The Future of Generic Programming
or, How to design good concepts and use them well

by Bjarne Stroustrup

From the draft paper:

Conclusions

Concepts complete C++ templates as originally envisioned. I don’t see them as an extension but as a completion.

Concepts are quite simple to use and define. They are surprisingly helpful in improving the quality of generic code, but their principles – and not just their language-technical details – need to be understood for effective use. In that, concepts are similar to other fundamental constructs, such as functions. Compared to unconstrained templates, there are no run-time overheads incurred by using concepts.

Concepts are carefully designed to fit into C++ and to follow C++’s design principles:

• Provide good interfaces
• Look for semantic coherence
• Don’t force the user to do what a machine does better
• Keep simple things simple
• Zero-overhead

Don’t confuse familiarity and simplicity. Don’t confuse verbosity with “easy to understand.” Try concepts! They will dramatically improve your generic programming and make the current workarounds (e.g., traits classes) and low-level techniques (e.g., enable_if – based overloading) feel like error-prone and tedious assembly programming.

Const, Move and RVO--Bartlomiej Filipek

By Adrien Hamelin | Jan 23, 2017 02:21 PM | Tags: performance intermediate

const does not prevent (N)RVO, youhou.

Const, Move and RVO

by Bartlomiej Filipek

From the article:

C++ is a surprising language. Sometimes simple things are not that simple in practice. Last time I argued that in function bodies const should be used most of the time. But two cases were missed: when moving and when returning a value.

Does const influence move and RVO?

Functional in C++11 and C++14: Dispatch Table and Generic Lambdas--Rainer Grimm

By Adrien Hamelin | Jan 23, 2017 02:13 PM | Tags: intermediate c++11

C++ is evolving.

Functional in C++11 and C++14: Dispatch Table and Generic Lambdas

by Rainer Grimm

From the article:

My favourite example the dispatch table shows how nice the features in modern C++ work together. A dispatch table is a table of pointers to functions. In my case, it is a table of handles to polymorphic function wrappers...

Pros and Cons of Alternative Function Syntax in C++--Petr Zemek

By Adrien Hamelin | Jan 18, 2017 03:01 PM | Tags: c++11 basics

Do you know the trailing return type?

Pros and Cons of Alternative Function Syntax in C++

by Petr Zemek

From the article:

C++11 introduced an alternative syntax for writing function declarations. Instead of putting the return type before the name of the function (e.g. int func()), the new syntax allows us to write it after the parameters (e.g. auto func() -> int). This leads to a couple of questions: Why was such an alternative syntax added? Is it meant to be a replacement for the original syntax? To help you with these questions, the present blog post tries to summarize the advantages and disadvantages of this newly added syntax...