C++ excessive bracketts removal

[Dennis Yurichev]

Hello.
I'm looking for any algorithm which can take C++ experssion at input
and offer at output the same expression with excessive bracketts
removed.
Where should I look for it?

 

[Jack Klein]

Hello.
I'm looking for any algorithm which can take C++ experssion at input
and offer at output the same expression with excessive bracketts
removed.
Where should I look for it?

Google?

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://c-faq.com/
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.club.cc.cmu.edu/~ajo/docs/FAQ-acllc.html

 

[pauldepstein]

Google?

--
Jack Klein
Home:http://JK-Technology.Com
FAQs for
comp.lang.chttp://c-faq.com/
comp.lang.c++http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++http://www.club.cc.cmu.edu/~ajo/docs/FAQ-acllc.html

Jack,

Actually, I think the OP has a legitimate question (although it's not
strictly a c++ language question.)
The problem is that the OP is probably unfamiliar with the word
"parse". It's hard to find what he's looking for if you don't include
the word "parse" in the google search. "Parsing" is the technical
term for what the OP wants to do.

Hopefully, the OP now has enough info to find what he needs.

Paul Epstein

 

[tony_in_da_uk]

Hello.
I'm looking for any algorithm which can take C++ experssion at input
and offer at output the same expression with excessive bracketts
removed.
Where should I look for it?

FWIW, I doubt very much you'll find anyone else has had enough motive
to create and maintain such a program or library. Parsing C++
expressions is a significant pain, and can't be done without parsing
the entire program to know the types of all the arguments, including
return types of functions. To do it to remove brackets doesn't
clearly offer a good return on effort ;-). Also, simplification
relies on operator precedence, and as the rules for that are pretty
complex, programmers often want certain brackets left in for
"documentation" purposes. We all know * comes before +, but fewer
remember && before ||, and fewer still for weirder rules like whether
& comes in higher or lower than &&....

Tony

 

[Guest]

Hello.
I'm looking for any algorithm which can take C++ experssion at input
and offer at output the same expression with excessive bracketts
removed.
Where should I look for it?

What you want is probably a code prettyfier. The goal of a prettyfier is
to take some code an convert it so that it conforms to some coding
standard, so you want a prettyfier with a standard that do not use
excessive brackets (some standards will include excessive brackets).

 

[James Kanze]

FWIW, I doubt very much you'll find anyone else has had enough motive
to create and maintain such a program or library. Parsing C++
expressions is a significant pain, and can't be done without parsing
the entire program to know the types of all the arguments, including
return types of functions.

That's not true. All you really need to know is which
identifiers resolve to type names, and even then, only in a very
few specific cases (and I'm not even sure that there are such
cases). Parsing C++ in general is very difficult, but if you
know you're dealing with an expression, the expressions
themselves aren't too much of a problem.

To do it to remove brackets doesn't
clearly offer a good return on effort ;-). Also, simplification
relies on operator precedence, and as the rules for that are pretty
complex, programmers often want certain brackets left in for
"documentation" purposes. We all know * comes before +, but fewer
remember && before ||, and fewer still for weirder rules like whether
& comes in higher or lower than &&....

That's the real reason, I suspect. Rather than remove brackets,
it would probably be more useful to insert them everywhere, so
the user could see how the compiler understands what he wrote.

 

[tony_in_da_uk]

Me:

James Kanze:
That's not true. All you really need to know is which
identifiers resolve to type names, and even then, only in a very
few specific cases (and I'm not even sure that there are such
cases). Parsing C++ in general is very difficult, but if you
know you're dealing with an expression, the expressions
themselves aren't too much of a problem.

Yeah. As usual, you're right James. As long as you've at least done
pre-processing, any embedded "identifier()" appearing in legal C++ -
where identifier isn't a reserved word (or, and etc) - can be treated
as a discrete value, and types don't affect operator precedence. Of
course, you can't validate expressions without knowing the types. For
example: *f might be a dereferenced pointer, or an attempted
multiplication with the left-hand-side missing. Anyway, that wasn't
what I was thinking about at the time - my mind was running away with
thoughts of evaluating the expressions, confusing the issues....

Thanks,

Tony

 

[Stuart Redmann]

I was a bit confused about the wish to remove superfluous brackets from C++
code, as brackets are actually operator calls and should never be superfluous.
Then I realized that brackets can be used to refer to all kinds of punctuation
marks like parenthesis, (square) brackets, or braces, so your request started to
make sense. I think you should follow the practise of computer scientist, and
use the word bracket only if you mean square bracket (see wikipedia: "With
respect to computer science, the term is sometimes said to only strictly apply
to the square or box type.")

FWIW, I doubt very much you'll find anyone else has had enough motive
to create and maintain such a program or library. Parsing C++
expressions is a significant pain, and can't be done without parsing
the entire program to know the types of all the arguments, including
return types of functions. To do it to remove brackets doesn't
clearly offer a good return on effort ;-). Also, simplification
relies on operator precedence, and as the rules for that are pretty
complex, programmers often want certain brackets left in for
"documentation" purposes.

Just wanted to add, that braces (see above) are also used to insert a code block
which can be used to force the compiler to dispose of local variables to this
block. There are actually examples where this behaviour cannot be taken away, or
else the code will crash.

Regards,
Stuart

 

[Ole Nielsby]

That's not true. All you really need to know is which
identifiers resolve to type names, and even then, only in a very
few specific cases (and I'm not even sure that there are such
cases).

Here is one:

typedef int a;
return (a) - 1; //c-style cast, prefix operator, brackets required

const int a = 10;
return (a) - 1; //infix operator, brackets are redundant

 

[Pete Becker]

That's the real reason, I suspect. Rather than remove brackets,
it would probably be more useful to insert them everywhere, so
the user could see how the compiler understands what he wrote.

Maybe. I've had to debug Java code compiled to C, with Lots of Infernal
Stupid Parentheses. It's not fun. (Both the compiler and the Java code
were under development at the time; otherwise I wouldn't have been
looking at the generated C code). The parentheses are mostly
distractions. Of course, that's whole programs, not isolated
expressions.

 

[James Kanze]

On 2007-10-11 22:46:29 -1000, James Kanze <[email protected]> said:

Maybe. I've had to debug Java code compiled to C, with Lots of Infernal
Stupid Parentheses. It's not fun. (Both the compiler and the Java code
were under development at the time; otherwise I wouldn't have been
looking at the generated C code). The parentheses are mostly
distractions. Of course, that's whole programs, not isolated
expressions.

It depends on context, and too many parentheses can also cause
problems. I think that a program to fully parenthesize isolated
expressions could be useful: any time you're not sure,
copy/paste the expression into it, and find out. That doesn't
mean that I think every expression in the source code should be
completely parenthesized