Jump to content

Check out our Community Blogs

Register and join over 40,000 other developers!

Recent Status Updates

View All Updates

- - - - -

Working in a maximal munch

  • Please log in to reply
1 reply to this topic

#1 Chinmoy


    CC Addict

  • Just Joined
  • PipPipPipPipPip
  • 365 posts

Posted 11 June 2008 - 04:24 AM

Maximal munch

In computer programming, the "maximal munch" principle is the rule that as much of the input as possible should be processed when creating some construct.
[Quoting wikipedia]

But the real problem is where we have to solve such expression.

Welcome to the world of maximal munch.

In one of the early stages of C++ translation, the portion of the compiler that performs “lexical analysis” has the task of breaking up the input stream into individual “words,” or tokens. So when the lexical analyzer encounters a character like (->*), it might reasonably identify three tokens (-, >, and *), two tokens (-> and *), or a single token (->*)!

However to avoid this ambiguous state of affairs, the lexical analyzer has been taught to identify the lingest sequence, thus consuming as many characters as it legally can. The situation :: a maximal munch!

The expression a+++++b is illegal, because it’s tokenized as a ++ ++ + b, and it’s illegal to post-increment an rvalue like a++.

If you had wanted to post-increment a and add the result to a pre-incremented b, you’d have to introduce at least one space as in: a+++ ++b. If you are writing a code which should be reusable, even though it’s not strictly necessary you should consider including one more space as: a++ + ++b, and the last and best is the addition of a few parentheses: (a++) + (++B).

Maximal munch solves many more problems than it causes, but in two common situations, it’s an annoyance. The first is in the instantiation of templates with arguments that are themselves instantiated templates. For example, using the standard library, one might want to declare a list of vectors of strings:
list> lovos; // error!

Unfortunately, the two adjacent closing angle brackets in the instantiation are interpreted as a shift operator, and we’ll get a syntax error. Addition of whitespaces fixes the problem ::
list< vector > lovos;

Another situation - default argument initializers for pointer formal arguments ::
void process( const char *= 0 ); // error!

This declaration is attempting to use the *= assignment operator in a formal argument declaration.That is a syntax error. This problem comes under the “wages of sin” category. It wouldn’t have happened if the author of the code had given the formal argument a name. Not only is such a name some of the best documentation one can provide, its presence would have made the maximal munch problem impossible:
void process( const char *processId = 0 );

Read more on this topic :: The maximal munch | TECHARRAZ
  • 1

God is real... unless declared an integer

my blog :: http://techarraz.com/

#2 Guest_Jordan_*

  • Guest

Posted 11 June 2008 - 04:35 AM

Another excellent read! +rep
  • 0

Recommended from our users: Dynamic Network Monitoring from WhatsUp Gold from IPSwitch. Free Download