Home » Blog » Tags » basics

basics

Parameter or Argument?--Malte Langkabel

By Adrien Hamelin | Jul 21, 2016 02:04 PM | Tags: basics

Did you know the difference?

Parameter or Argument?

by Malte Langkabel

From the article:

I often hear people getting confused when talking about parameters and arguments. That confusion grows even stronger when one of them knows the difference but the other one doesn’t. So let’s shed some light on this issue and spread the knowledge! Programming involves talking to each other but that doesn’t have to be more painful than it already is wink

Quick Q: How to express constness of a forwarding reference?

By Adrien Hamelin | Jul 18, 2016 01:31 PM | Tags: c++11 basics

Quick A: To express constness, a const reference is what is needed.

Recently on SO:

How to express constness of a forwarding reference?

How can I express that f does not modify its parameter?

If the function doesn't modify its parameter then there is no benefit to using a forwarding reference. You use a forwarding reference when you want to forward the parameter on to some other function which cares whether the argument is an lvalue or an rvalue (because maybe there are separate overloads for lvalues and rvalues, and the rvalue one can be more efficient).

If your function doesn't modify the argument then it shouldn't need to care whether it has an lvalue or rvalue, so it can just take const T& unconditionally. That can bind to both lvalues and rvalues, and promises not to modify the parameter.

template<typename T>
void f(const T& t) { ... }

Quick Q: Are `==` and `!=` mutually dependent?

By Adrien Hamelin | Jun 29, 2016 01:42 PM | Tags: basics

Quick A: They are not, because it is not always true.

Recently on SO:

Are `==` and `!=` mutually dependent?

You would not want the language to automatically rewrite a != b as !(a == b) when a == b returns something other than a bool. And there are a few reasons why you might make it do that.

You may have expression builder objects, where a == b doesn't and isn't intended to perform any comparison, but simply builds some expression node representing a == b.

You may have lazy evaluation, where a == b doesn't and isn't intended to perform any comparison directly, but instead returns some kind of lazy<bool> that can be converted to bool implicitly or explicitly at some later time to actually perform the comparison. Possibly combined with the expression builder objects to allow complete expression optimisation before evaluation.

You may have some custom optional<T> template class, where given optional variables t and u, you want to allow t == u, but make it return optional<bool>.

There's probably more that I didn't think of. And even though in these examples the operation a == b and a != b do both make sense, still a != b isn't the same thing as !(a == b), so separate definitions are needed.