1

Possible Duplicate:
Why is it an error to use an empty set of brackets to call a constructor with no arguments?

The small piece code code can not be successfully compiled on
Microsoft Visual Studio 2005

#include <iterator>
#include <algorithm>
#include <vector>
#include <iostream>

int main()
{
    std::vector<int> a;
    std::istream_iterator<int> be(std::cin);
    std::istream_iterator<int> en();
    std::copy(be, en, std::back_inserter(a));       
}

But this one is ok

#include <iterator>
#include <algorithm>
#include <vector>
#include <iostream>

int main()
{
    std::vector<int> a;
    std::istream_iterator<int> be(std::cin);
    std::istream_iterator<int> en; //Same to upon, only here less '()'
    std::copy(be, en, std::back_inserter(a));       
}
Community
  • 1
  • 1

1 Answers1

4

In the first case en is being declared as a function, not a variable. This is one of the many traps present in C++ syntax that makes hard to parse a C++ program.

The rule applied is more or less "if it can be parsed both as a declaration or as a definition then it's considered a declaration" and has been named "most vexing parse" by Scott Meyers. In your case the second line can be seen similar to

inf foo();

And is therefore considered a function declaration. Note that this very same trap can be even more subtle:

double x = 3.141592654;
int y(int(x));

here the second line is also a declaration for a function because language rules says here that the parenthesis around x can be ignored and therefore the meaning is int y(int x);.

6502
  • 112,025
  • 15
  • 165
  • 265
  • 2
    It's called the ["most vexing parse"](http://en.wikipedia.org/wiki/Most_vexing_parse). There are *many* references to it around the 'net. – Jan Hudec Dec 02 '11 at 07:37
  • I would like to add that while probably not available on VS2005, the version given in the question, this trap can be avoided by using the new C++11 initializer list: `std::istream_iterator be{std::cin}` and `std::istream_iterator en{}`. – Some programmer dude Dec 02 '11 at 07:39
  • 1
    @JoachimPileborg: the main problem of C++ is IMO complexity and adding more complexity doesn't seem to me a reasonable solution. If you need to know a lot strange rules to write correct C++ code moving to a language with even more even stranger rules is not a step forward. – 6502 Dec 02 '11 at 07:51
  • But the c++ standard allow declare a function in another function? – Wenbo Huang Dec 02 '11 at 07:51
  • @WenboHuang: Yes it does... it's not a feature used frequently (normally declarations are only inside include files). Note that anyway if the code was at toplevel instead than inside a function there would be no difference. – 6502 Dec 02 '11 at 07:53
  • @6502: That term is in the standard literature of C++. You really shouldn't do serious coding without having read the standard literature. – Sebastian Mach Dec 02 '11 at 12:10
  • @phresnel: I'm not sure I understand your point. I've read Effective STL in 2001 and I actually love Meyers style. I think for example that Effective C++ books should be mandatory for any professional programmer using C++. – 6502 Dec 02 '11 at 13:39
  • @6502: My post was based on the wrong assumption that you were talking about "most vexing parse" in your comment about C++'s complexity. Beg your pardon. – Sebastian Mach Dec 02 '11 at 14:30