string find_addr( const list<employee>& emps, const string& name ) {
    const auto i = find_if( begin(emps), end(emps),
                      [&](const auto& e) { return e == name; } );
    return i != end(emps) ? i->addr : "";
}

On the compiler that I checked, if name() returns a const string&, then e == name optimizes to the same code as e.name() == name. No penalty here. However, if name() returns a string, then the impact is significant (the complexity prevented inlining and temporaries were created).

And if you are into unit testing, you would also like that find_if version has only 2 branches (I’m not really into testing STL implementation), while the range-for version has 4 (depending on how you define branches), so you need more test cases for 100% code coverage.

The question becomes, do you want this to work?

void f (complex c);
f ({ 0.f, 1.f });

Simply making the two parameter constructor explicit just to guard against the one-argument case then is unsuitable because it guards against the multi arg case too. You will need to overload it (possibly using constructor delegation in the implementation).

I had a similar thought when I read the class, “what exactly does it mean to increment a complex number?”. I don’t think I’ve ever used increment on a floating point number.

1. Make it impossible or very hard to use incorrectly (fail to compile, crashes, etc when used incorrectly – see std::chrono as a simple example) – this is the most important guideline for type design because it both prevent errors by mistake and, more importantly, it drives the usage (it’s like walls for a blind: when you touch it you know you can’t go this way);
2. Make sure each operation have only one way to be done – this actually improve composition (note that if two functions does the same thing but in a different way that impact the semantic, it’s two operations);
3. Hide complexity. Unfortunately it is not always efficient to hide totally the implementation details of our types (maybe it will be with modules but don’t count on it until we got implementations), but if you can hide the details, the only thing visible is how to use it.
4. Give a unique responsability to the type, not more.
5. Make it as short as possible, that is, a minimum of functions (depends on the domain and responsability);
6. Use names as obvious as possible in the domain context;
7. Document the interface. I put this at last because I consider it of last resort but you always end up doing it for member functions doing not that obvious operations.

While equality may feel simpler than inequality, I generally prefer to check for success rather than failure when the two options are basically equivalent.

I confirmed that VC++ 2012 Nov CTP works fine with v{vv}.

Thank you for your answer.

The example class is presumably intended to be a numeric type, so it should follow the conventions established by int, double and other numeric types. It doesn’t. Note that its definition of operator+() isn’t [i]intrinsically[/i] wrong; it isn’t impossible to use correctly: but it is different to how operator+() works for double so very liable to be used incorrectly. It doesn’t matter if the documentation describes the idiosyncratic behaviour correctly and lucidly. Few programmers will think to read it.

Programmers have ample opportunities to be creative. Deciding the behaviour of operator+() is not one of them.

I just tried:

- GCC 4.8 and VC++ 2012 Nov CTP which both like it;

- GCC 4.7.2 which thinks F f{a}; is illegal; and

- Intel ICC 13.0.1 which thinks v{vv} is illegal.

I believe GCC 4.8 and VC++ 2012 Nov CTP have it right.

return i == end(emps) ? "" : i->addr;

Equality feels slightly simpler than inequality. I’d also prefer to avoid converting the c-string to a std::string:

return i == end(emps) ? string() : i->addr;

The conversion probably won’t allocate memory, but it’s still doing unnecessary work – possibly including a call to strlen(), for example.

@Sam: Good point, noted.

@Adrian: A program that does that has undefined behavior and could achieve the same effect by dereferencing a random int cast to a pointer. Within defined behavior, the range-for can iterate only one way, from the front in order visiting every element exactly once, and the only possibly variation in behavior is that it could stop early if there’s a break or return inside vs. visiting all elements.

@tivrfoa: I just compared using “no optimizations” vs. “max optimizations” compiler flags.

One more thing which comes to mind — given that it makes sense for “complex” to have value semantics (as opposed to reference semantics), we’d probably want to consider preventing inheritance (for the same reason it’s not a good idea to inherit from an STL container).

As in:
Guideline #4: A base class destructor should be either public and virtual, or protected and nonvirtual.
http://www.gotw.ca/publications/mill18.htm

I don’t see the case for public & virtual (since I don’t see the case for our “complex” class having reference semantics). Hence, I’d go with the other alternative.

This is where C++11 comes in, as it allows us to use “final” to prevent inheritance:
http://en.cppreference.com/w/cpp/language/final

The increment and decrement operators make intuitive sense for discrete types, like counters, chars, certain enumerations, even bools.

Perhaps because I’ve always thought of these operators as analogues of Pascal’s succ() and pred(), it’s always seemed odd to me that C and C++ provide them for floating point types. What does it mean to increment a type that approximates a continuous quantity? It’s not intuitive (to me), given a double d, what

++d

would mean. Does it increment by 1.0 or does it increment by some epsilon to get to the next higher, representable value? Both would be useful, and, given that I could always write

d += 1.0;

for the former, defining operator++ for the latter would make the most sense. But alas, that’s not the case. That might just be my own bias.

Even if I make peace with increment and decrement on a double, what should they mean on a complex? That’s even less intuitive. A complex is a two-dimensional quantity. Should increment affect the real part or the imaginary part or both? It’s simply not obvious–at least not to everyone.

In the interest of making it easy to use correctly and difficult to use incorrectly, I’d leave out the increment and decrement operators for this class at least until a client of the class made a strong case for them. (A strong case might be that having these operators enables a class or function template that otherwise can’t use them.) In the mean time, a client can write

c += 1.0;

, which is not only correct, it’s _obviously_ correct. To everyone.

To me, that’s the difference between a well-implemented class interface and a well-_designed_ one.

for (const auto & e : emps) {
  if (e.name == "Herb") {
    emps.push_front(employee("Bjarne"));
  }
}

Obviously, this isn’t an advisable thing to do in the loop, but the compiler isn’t likely to notice. Thus a range-based for loop might give you more confidence that it visits each element in order, but, unless emps is const, you cannot be absolutely certain without looking inside the body and without knowing the type of container and that container type’s iterator invalidation rules. Right?

The first answer coming to my mind is “Documentation”.
The standard classes are quite well documented – imagine how difficult it would be to use them correctly without this documentation, and how easy it would be to use them incorrectly.

It makes me a little sad that no one mentioned this so far.

Among the very effective programmers that I got to know, the share of those who actually write good documentation is surprisingly low. There are even some who explicitly argue against documentation. I often wonder why this is so.

Reasons might be:

* Documentation is (usually) not being paid for. What usually matters is functionality.

* Not every one is a born writer. Some very effective programmers that I got to know write surprisingly bad natural language. My guess is that most of these actually know this (but some don’t :-). Many people dislike doing things that they are not good at. Thus I assume that some simply hate writing documentation because it makes them feel bad, or even inadequate.

* Writing good documentation is a skill that by most people must be learned. This takes at least effort and time, and thereby usually money.

* Tools that check for language errors in documentation are not widespread. This is in contrast to the code, where the compiler and tools like lint can help to work out the kinks.

Granted, in contexts where the code is not likely to ever be read, writing documentation has only one benefit that I can think of: The writer can hone his writing skills.

However, in contexts where the code is likely to be read, maintained or reused, documentation is crucial. In my professional experience (15y), this is the case in by far the majority of projects. In some circumstances, especially when key people leave a project, missing or bad documentation can become extremely expensive.

class complex 
{
	// allow access to private members
	friend ostream& operator<<( ostream& os, const complex& c );

public:
	// doubles as default ctor
	complex( double r = 0, double i = 0 ) : real(r), imag(i) { }

	// to efficiently implement operator+ 
	complex& operator+=(const complex& c) 
	{
		real += c.real;
		imag += c.imag;

		return *this;
	}

	// return reference to result
	complex& operator++()
	{        
		++real;        
		return *this;    
	}    

	// return unchanged object by value
	complex operator++( int ) 
	{        
		auto temp = *this;        
		++real;        
		return temp;    
	}   

	// ... more functions that complement the above ...
private:    
	double real, imag;
};

// IO operator cannot be a class member. 
// Class member ops require the left operand to be a class object
ostream& operator<<( ostream& os, const complex& c ) 
{        
	os << "(" << c.real << "," << c.imag << ")";
	return os;
}

// allows implicit conversion of operands
complex operator+ ( const complex &c1, const complex& c2 ) 
{   
	complex c(c1);
	c += c2; 
	return c;
}  

return i != end(emps) ? i->addr : "";

Find just returns an iterator that you still have to check. The range-for version just returns.

std::get<0>()

(blog ate my pointy braces) isn’t a member function of std::tuple, still isn’t returning by value..
@Herb: Wait a minute. Are you saying that

auto& x = function_that_creates_widget_and_returns_by_value().get_name();

is ‘good’, but

auto& x = get_widget_name(function_that_creates_widget_and_returns_by_value());

isn’t? I so far failed to create any example where a get(xx) construct can have a dangling reference what is fixed just by replacing that call to a xx.get() construct, that’s why I think the two are equivalent, thus should use the same guidelines for return type.

ps Unfortunately saw similar when someone was writing a linked list class. It was a good lunch!

class complex{
   complex() = default;
   complex( const complex& other) = default;
   complex& operator = (const complex& other) = default;
   // other method and ctors   ..............................
}

using namespace std;

// IO operator cannot be a class member. 
// Class member ops require the left operand to be a class object
ostream& operator<<( ostream& os, const complex& c ) 
{        
	os << "(" << c.real << "," << c.imag << ")";

	return os;
}

complex operator+ ( const& complex c1, const& complex c2 ) 
{   
	complex c = c1;
	c.real += c2.real; // '+=' assumed
	c.imag += c2.imag;

	return c;
}  

class complex 
{
	// allow access to private members
	friend ostream& operator<<( ostream& os, const complex& c );
	friend complex operator+ ( const& complex c1, const& complex c2 );

public:
	complex( double r = 0, double i = 0 ) : real(r), imag(i) { } // doubles as default ctor

	complex& operator++() // return reference to result
	{        
		++real;        
		return *this;    
	}    

	complex operator++( int ) 
	{        
		auto temp = *this;        
		++real;        
		return temp;    
	}   

	// ... more functions that complement the above ...
private:    
	double real, imag;
};


#include

return 0;
}


Having noted that efficiency is a valid consideration, one should also note that it's easy to walk into the premature optimization trap. And the class presented in this question looks like an example of that. Apparently it's meant to provide a convenient increment operator, a operator++, but that would be better provided for a class derived from std::complex&lt>T (derived class in order to minimize the problem of multiple definitions of such an operator).

The above addresses some main concerns of the "JG" question, question 1. Others have already discussed the trivia of the "Guru" question, question 2, what the compiler can tell you if you give it the code. I think the "Guru" designation for that is a bit misplaced: nowadays it's not hard to feed some code to a compiler.

So far the existing answers have failed to mention what a compiler can't tell you, such as the pros and cons of choosing `void` as result type for `operator++`. Much in the same vein as choosing an as yet somewhat unconventional signed size type. This has to do with the more challenging "hard to use incorrectly" aspect – challenging in part because some established conventions in C++ are at odds with that goal.

Ah I didn’t catch that, thanks.

What this class needs is 'getters' for real and imag. Then + and << can be implemented as non-friend functions. Although setters for simple data in a class is sometimes a mistake, it's warranted here. The sanity that the operators provide is simply to keep two values locked together in a sensible way. There are a great many reasons why we'd want getters for real and imag and the class is rather useless without them.

Adding the getters (not necessarily setters) also obeys the principle that you should be able to tell if two objects are equal based on their public interface alone. In other words, we want to be able to write == as a non-friend function as well. I forget where I got this principle but it's a good one.

That said, operator + should defer to +=, which should be added.

complex operator + (complex left, complex const& right)
{
  return left += right;
}

The compiler will get rid of the unnecessary temporaries either by using move construction or RVO.

So if you’re returning a const&, I know that both of these are safe:
A) string s = find_addr(emps, “Rick”);
B) if(find_addr( emps, “Rick” ).find( “Toronto” ) != string::npos) {}

But if you’re returning a value, one of those is less efficient.

I agree that hanging references/iterators is a very common problem, but every time I’ve encountered it, the caller made a conscious decision to store a reference rather than a value, including in the example you provided.

My bad. It is generally better to write operator+ as a friend for classes with implicit constructors:

//... inside the class
friend complex operator+(const complex& lhv, const complex& rhv) {
    return { lhv.real+rhv.real, lhv.imag+rhv.imag };
}
//...

This way both cmplx + 2.2 and 2.2 + cmplx will work.

It is when all but one of the parameters is defaulted.

for ( auto & e : emps ) {...}

given that emps is const.

The output of this is
2
garbage

if I change the F constructor to

     F(const vector<int>& vv) :v(vv) { cout << v[0] << endl; }

The output is correct as expected :
2
2

Why does the first one with {} not work as expected? Thanks!

That brings us to the second issue, which is that I can’t in good conscience say that

string find_addr( const list<employee>& emps, const string& name ) {
    const auto i = find_if( begin(emps), end(emps),
                      [&](const auto& e) { return e.name() == name; } );
    return i != end(emps) ? i->addr : "";
}

is more readable than

string find_addr( const list<employee>& emps, const string& name ) {
    for (const auto& e : emps) {
        if (e.name() == name) {
            return e.addr;
        }
    }
    return string(); 
}

Granted it’s fewer lines, but I can reason very intuitively about the bottom. The difference is small, so if the find_if case were faster then I’d use it. But an extra branch /and/ not as readable?

    // in class
    friend std::ostream& operator<<( std::ostream& os, complex const& c); 

    // in cpp
    #include <ostream>

    std::ostream& operator<<( std::ostream& os, complex const& c) {
        return os << '(' << c.real << ',' << c.imag << ')';
    }

5. operator+() actually implements more of `operator+=` and could take a const& to allow for rvalues (implicit conversions)

fixing it as operator+ (note const):

    complex operator+ ( complex const &other ) const {
        return { real + other.real, imag + other.imag };
    }

6. operator++() (prefix version) should return by reference

7. Consider using friend operator+ instead of member operator+ to allow for implicit conversion of the first operand as well:

    friend complex operator+ ( complex const& a, complex const &other )  {
        return { a.real + other.real, a.imag + other.imag };
    }

Note this becomes less useful if the constructor was made explicit

Complex a(1, 0), b(0, 1);
a + b;

Actually changes the value of a.

I would probably implement operator + like this:

complex operator +(complex other) const {
return complex(real+other.real, imag+other.imag);
}

Or perhaps in terms of an implemented += operator.

I wouldn’t necessarily take arguments by const& since this is a relatively small class and it may not be necessary.