Re: Ambiguities of c++

Thomas Ascher <thomas.ascher@gmx.at> wrote:


> I'm looking for information on ambiguities of the c++ grammar. Can
> someone give me a little help with this? I allready have Jim
> Roskind's Yacc grammar. So, does anyone know good www pages
> concerning this topic or can someone give me code/grammar
> examples...


Here's an example that tends to bite people using the STL:


        vector<char> vec (istream_iterator<char>(cin),
                                              istream_iterator<char>());


Is this


        1) the declaration of a variable named vec of type vector<char>,
        using the two-parameter ctor, taking two iterators built from standard
        input and the end-of-stream iterator respectively,


or


        2) the declaration of a function called vec, returning a vector<char>,
        taking two arguments, both of type istream_iterator<char>, the first
        of which is named 'cin' in the declaration (shadowing std::cin and
        ignored in declaration anyway), and the second of which is unnamed


?


I'll bet you a large ${container} of ${beverage} that the programmer
wanted the first interpretation, which would fill 'vec' with
characters read from stdin until an EOF arrived, and is truly a useful
idiom for manipulating that standard containers.


At least, it would be useful if the standard didn't require the second
interpretation. One must jump through one's choice of syntactically
ugly hoops to get the first version unambiguous, including adding a
pair of parens around the first parameter expression, or declaring vec
using the 'assignment' style rather than the 'function call' style.


I don't envy the beginning programmer who reads a well-written text, tries
this example, and has nobody around to explain the bizzare error messages
from the compiler.




Luck++;
Phil
--
pedwards at disaster dot jaj dot com | pme at sources dot redhat dot com
devphil at several other less interesting addresses in various dot domains

Return to the comp.compilers page.
Search the comp.compilers archives again.