Home » Blog » Categories » Articles & Books

Articles & Books

What new capabilities do user-defined literals add to C++? -- StackOverflow

By Blog Staff | Mar 8, 2013 04:57 PM | Tags: None

Over the past year, UDLs have started to become available in some popular C++ compilers, including gcc 4.7 and Clang 3.1. As people are adopting those compilers in real code and starting to be ablel to use this feature, a natural question is how useful they are and how to use them:

What new capabilities do user-defined literals add to C++?

C++11 introduces user-defined literals which will allow the introduction of new literal syntax based on existing literals (int, hex, string, float) so that any type will be able to have a literal presentation.

Examples:

// imaginary numbers
std::complex<long double> operator "" _i(long double d) // cooked form
{
    return std::complex<long double>(0, d);
}
auto val = 3.14_i; // val = complex<long double>(0, 3.14)

// binary values
int operator "" _B(const char*); // raw form
int answer = 101010_B; // answer = 42

// std::string
std::string operator "" _s(const char* str, size_t /*length*/)
{
    return std::string(str);
}
auto hi = "hello"_s + " world"; // + works, "hello"_s is a string not a pointer

// units
assert(1_kg == 2.2_lb); // give or take 0.00462262 pounds

At first glance this looks very cool but I'm wondering how applicable it really is, [...] do you feel this feature will justify itself? What other literals would you like to define that will make your C++ code more readable?

Quick Q: Why isn't std::initializer_list a core-language built-in? -- StackOverflow

By Blog Staff | Mar 6, 2013 12:24 PM | Tags: basics

Quick A: Because it doesn't have to be. It's "the C++ way" to prefer library solutions, and initializer_list shows how far you can get with a pure library solution, then the rest of the way with minimal language support to create initializer_list objects.

Recently on SO:

Why isn't std::initializer_list a core-language built-in?

It seems to me that it's quite an important feature of C++11 and yet it doesn't have its own reserved keyword (or something alike).

 

Instead, initializer_list it's just a template class from the standard library that has a special, implicit mapping from the new braced-init-list {...} syntax that's handled by the compiler.

At first thought, this solution is quite hacky. ...

The Importance of std::function -- Malte Skarupke

By Blog Staff | Mar 5, 2013 01:03 PM | Tags: intermediate

See also "Generalizing Observer", written ten years ago when std::function was first adopted.

The Importance of std::function

by Malte Skarupke

... Classically an update loop would be implemented something like this: ...

And this is a good solution at first. But you’ve got that inheritance in there, and that doesn’t scale. You will probably want to add a render loop and maybe a separate update loop for the editor. Once you’ve got that many base classes it makes sense to combine them into one. And now you’ve just started on the way of having a big base class that gets used everywhere. Soon enough adding something different to the update loop involves a whole lot of unnecessary work.

Here is an alternate update loop using std::function: ...

 

Quick Q: How to initialize a const object (say vector) with complex initialization? -- StackOverflow

By Blog Staff | Mar 5, 2013 10:56 AM | Tags: basics

Quick A: With a lambda function. Try const mytype myobj{ []{ /* compute value */ return value; } }.

How would you initialize a const vector of function results using C++11?

Is it possible to use something like generate_n to create a const vector of, say, random numbers? I couldn't think of a way to do it without deriving vector and doing the assignment in the constructor.

C++ and Xcode 4.6 -- from Marshall Clow

By Eric Niebler | Mar 1, 2013 01:36 PM | Tags: basics

Marshall Clow gives some helpful tips for C++ programmers migrating to to XCode 4.6:

C++ and XCode 4.6

So, you’ve installed Xcode 4.6, and you are a C++ programmer.

You want to use the latest and greatest, so you create a new project, and add your sources to the project, and hit Build, and … guess what? Your code doesn’t build!

Continue reading...

 

No, really, moving a return value is easy -- StackOverflow

By Blog Staff | Feb 25, 2013 08:55 AM | Tags: basics

People new to C++11 often hear about move semantics, and expect that they have to do work to take advantage of it. That's often not true, and often the cleanest, simplest code that doesn't even mention move or && anywhere is just what you want -- that's C++11, clean, safe, and faster than ever.

Perhaps the most common case (and question) involves returning values from functions. The new rule for modern C++ style: Just return even big objects by value, and move Just Happens.

It just came up again on StackOverflow:

C++11 rvalues and move semantics confusion

The link skips straight to Howard Hinnant's clear and correct answer.

Sometimes we just try too hard, because we expect efficient programming not to be easy. Welcome to C++11.

Quick Q: When should I use std::function vs. make my function a template? -- StackOverflow

By Blog Staff | Feb 21, 2013 09:25 AM | Tags: intermediate

To accept a functor as a parameter, when should you:

  • accept a std::function, which adds an indirection, vs.
  • make your function a template<class Func> and accept a Func, which can bind directly to whatever is passed?

std::function vs template

Thanks to C++11 we received the std::function family of functor wrappers. Unfortunately, I keep hearing [...] that they are horribly slow. [... Is the right recommendation] that functions can be used as de facto standard of passing functors, and in places where high performance is expected templates should be used?

Quick Q: How do I move an expensive object into a map? -- StackOverflow

By Blog Staff | Feb 19, 2013 04:39 AM | Tags: basics

Quick A: Using the form of insert that takes an rvalue and passing a temporary or a std::move'd object, or calling emplace.

Moving an object into a map

The problem with this is that the huge objects will be copied into the maps

 

Huge huge1(some,args);
Huge huge2(some,args);

std::map<int,Huge> map1;
std::map<Huge,int> map2;

map1.insert({0,huge1});
map2.insert({huge2,0});

how can I guarantee a move? Will this work or is there more to it?

map1.insert({0,std::move(huge1)});
map2.insert({std::move(huge2),0});