457,967 Members | 1,182 Online
Need help? Post your question and get tips & solutions from a community of 457,967 IT Pros & Developers. It's quick & easy.

# function to match parenthesis '(' and ')'

 P: n/a I need a simple function that can match the number of beginning and ending parenthesis in an expression. Here's a sample expression: ( ( "john" ) and ( "jane" ) and ( "joe" ) ) Does .NET have something built-in that can accomplish this, or do I have to write my own parser? I don't want to reinvent the wheel if possible. Nov 17 '05 #1
38 Replies

 P: n/a "Steve Kirsch" wrote: I need a simple function that can match the number of beginning and ending parenthesis in an expression. Here's a sample expression: ( ( "john" ) and ( "jane" ) and ( "joe" ) ) There's nothing in the Framework to count the number of occurrences of a character in a string, but you can find any one occurrence with String.IndexOf, and do this in a loop to count them all. (Each time you find one, increment the start position and loop back.) P. Nov 17 '05 #2

 P: n/a Salam The simple solution to this problem is to implement a stack, when u encounter '(' push it on the stack, and when u encounter ')', pop it from the stack. In the End, check if the stach is empty, if it is empty then the parenthesis are match else they are not. -- ALI RAZA SHAIKH MCAD.net www.programmersparadise.cjb.net alirazashaikh.blogspot.com "Steve Kirsch" wrote in message news:%2****************@TK2MSFTNGP15.phx.gbl...I need a simple function that can match the number of beginning and endingparenthesis in an expression. Here's a sample expression: ( ( "john" ) and ( "jane" ) and ( "joe" ) ) Does .NET have something built-in that can accomplish this, or do I have to write my own parser? I don't want to reinvent the wheel if possible. Nov 17 '05 #3

 P: n/a Salam The simple solution to this problem is to implement a stack, when u encounter '(' push it on the stack, and when u encounter ')', pop it from the stack. In the End, check if the stach is empty, if it is empty then the parenthesis are match else they are not. -- ALI RAZA SHAIKH MCAD.net www.programmersparadise.cjb.net alirazashaikh.blogspot.com "Steve Kirsch" wrote in message news:%2****************@TK2MSFTNGP15.phx.gbl...I need a simple function that can match the number of beginning and endingparenthesis in an expression. Here's a sample expression: ( ( "john" ) and ( "jane" ) and ( "joe" ) ) Does .NET have something built-in that can accomplish this, or do I have to write my own parser? I don't want to reinvent the wheel if possible. Nov 17 '05 #4

 P: n/a On Sat, 22 Oct 2005 15:52:27 -0500, "Steve Kirsch" wrote: I need a simple function that can match the number of beginning and endingparenthesis in an expression. Here's a sample expression:( ( "john" ) and ( "jane" ) and ( "joe" ) )Does .NET have something built-in that can accomplish this, or do I have towrite my own parser? I don't want to reinvent the wheel if possible. private bool IsValidString(string expression) { int balance = 0; foreach(char c in expression) switch(c) { case '(': balance++; break; case ')': if(--balance < 0) return false; break; } return balance == 0; } -- Marcus Andrén Nov 17 '05 #5

 P: n/a How about a Regular Expression? The following Regular Expression will capture all opening and closing parentheses. It puts opening parentheses into Group 1 ("opening"), and closing parenthese into Group 2 ("closing"): (?[$$])|(?[$$]) Using the Regex Class, you can count the number of each group separately. -- HTH, Kevin Spencer Microsoft MVP ..Net Developer Ambiguity has a certain quality to it. .. "Steve Kirsch" wrote in message news:%2****************@TK2MSFTNGP15.phx.gbl...I need a simple function that can match the number of beginning and endingparenthesis in an expression. Here's a sample expression: ( ( "john" ) and ( "jane" ) and ( "joe" ) ) Does .NET have something built-in that can accomplish this, or do I have to write my own parser? I don't want to reinvent the wheel if possible. Nov 17 '05 #6

 P: n/a "ALI RAZA" wrote in message news:%2****************@TK2MSFTNGP15.phx.gbl... Salam The simple solution to this problem is to implement a stack, when u encounter '(' push it on the stack, and when u encounter ')', pop it from the stack. In the End, check if the stach is empty, if it is empty then the parenthesis are match else they are not. -- All of this assumes that ALL parens should be pushed on the stack. For instance: Console.WriteLine("("); would not work. In a situation like this you might need to make sure the paren is not part of a string. All of this depends on the use to which the function is being applied. Bill Nov 17 '05 #7

 P: n/a Kevin Spencer wrote: How about a Regular Expression? The following Regular Expression will capture all opening and closing parentheses. It puts opening parentheses into Group 1 ("opening"), and closing parenthese into Group 2 ("closing"): (?[$$])|(?[$$]) Using the Regex Class, you can count the number of each group separately. That will count them, but not make sure that they match - it would say that: )( is valid, for instance. -- Jon Skeet - http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet If replying to the group, please do not mail me too Nov 17 '05 #8

 P: n/a True, Jon, but that was not the question asked. A regular expression could also be developed that would ensure they match. If it were requested, I would be glad to take the time to do so. -- HTH, Kevin Spencer Microsoft MVP ..Net Developer Ambiguity has a certain quality to it. "Jon Skeet [C# MVP]" wrote in message news:MP************************@msnews.microsoft.c om... Kevin Spencer wrote: How about a Regular Expression? The following Regular Expression will capture all opening and closing parentheses. It puts opening parentheses into Group 1 ("opening"), and closing parenthese into Group 2 ("closing"): (?[$$])|(?[$$]) Using the Regex Class, you can count the number of each group separately. That will count them, but not make sure that they match - it would say that: )( is valid, for instance. -- Jon Skeet - http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet If replying to the group, please do not mail me too Nov 17 '05 #9

 P: n/a Kevin Spencer wrote: True, Jon, but that was not the question asked. Well, it asked about "matching" parentheses. I think it's reasonable to assume that the OP doesn't actually want ")(" to match - especially given the sample. A regular expression could also be developed that would ensure they match. If it were requested, I would be glad to take the time to do so. Hmm... I seem to remember something in CS classes saying that this is something that regular expressions actually can't do. You can develop them that will match down to a certain level of nesting (i.e. for any given number of levels of nesting, you can build a regular expression which will match it), but nothing to match *any* level of nesting. I could easily be wrong though... -- Jon Skeet - http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet If replying to the group, please do not mail me too Nov 17 '05 #10

 P: n/a He did say "match," although what he meant by it was somewhat ambiguous. If I have the time, I'll give it a shot. -- HTH, Kevin Spencer Microsoft MVP ..Net Developer Ambiguity has a certain quality to it. "Jon Skeet [C# MVP]" wrote in message news:MP************************@msnews.microsoft.c om... Kevin Spencer wrote: True, Jon, but that was not the question asked. Well, it asked about "matching" parentheses. I think it's reasonable to assume that the OP doesn't actually want ")(" to match - especially given the sample. A regular expression could also be developed that would ensure they match. If it were requested, I would be glad to take the time to do so. Hmm... I seem to remember something in CS classes saying that this is something that regular expressions actually can't do. You can develop them that will match down to a certain level of nesting (i.e. for any given number of levels of nesting, you can build a regular expression which will match it), but nothing to match *any* level of nesting. I could easily be wrong though... -- Jon Skeet - http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet If replying to the group, please do not mail me too Nov 17 '05 #11

 P: n/a Steve Kirsch wrote: Marcus Andren's code was simple and easy enough to do the job, so I'm using that for now. I'm not knowledgable about regular expressions at the moment, and don't have the time to learn them right now (this project is due tomorrow!). So, I'll stick with the simple validation accomplished by Marcus's code (above), and hopefully I'll learn some regular expressions in the future to come enhance this in a future version. If one of you would like to suggest an alternative to Marcus' code using regular expressions, please post the code. Thanks again, and best regards to all. It's worth learning regular expressions just because they're very useful in certain situations. However, any regular expression solution to this problem is likely to be significantly more complicated than the code Marcus provided, and probably slower too. It's very easy to see by inspection that Marcus's code works. (Admittedly I'd decrement balance in one statement and check it in another, but that's a minor nit-pick.) Checking that a matching regular expression - especially one that copes with arbitrary levels of nesting - is correct would be very, very hard. It's always worth thinking about the right tool for the job - in this case, regular expressions aren't the right tool, IMO. -- Jon Skeet - http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet If replying to the group, please do not mail me too Nov 17 '05 #13

 P: n/a Steve, you can use the following regex : ^[^()]*(?:$$([^()]*(?:(?:(\()[^()]*)+(?:(?<-2>$$)[^()]*)+)*(?(2)(?!)))\)[^() ]*)*$Here a simple example to know if parenthesis match : Regex regex=new Regex(@"^[^()]*(?:$$([^()]*(?:(?:(\()[^()]*)+(?:(?<-2>$$)[^()]*)+)*(?(2)(?!) ))\)[^()]*)*$"); if (!regex.IsMatch(theStringIWantToCheck)) MessageBox.Show("Parenthesis do not match !"); Another example to know all the subexpressions (not the inner subexpression but you can find them with recursivity) : Regex regex=new Regex(@"^[^()]*(?:$$([^()]*(?:(?:(\()[^()]*)+(?:(?<-2>$$)[^()]*)+)*(?(2)(?!) ))\)[^()]*)*$"); Match match=regex.Match(theStringIWantToCheck); if (match.Success) { foreach(Capture c in match.Groups[1].Captures) MessageBox.Show("SubExpression="+c.Value); //You can have the number of subexpressions with match.Groups[1].Captures.Count } else { MessageBox.Show("Parenthesis do not match !"); } If you want to understand how it works, there is a good article from Ryan Byington that helped me to make this regexe : http://blogs.msdn.com/bclteam/archiv...15/396452.aspx You can also use RegexOptions.Compiled in Regex, and also use Static Regex class if you want a faster Regex. Marcus Code is obviously quicker than this one with Regex (on my computer, it's 4 times quicker), but I would prefer Regex. It's more "object" like. You can do what you want without modifying your source code. Everything is stored in Capures field in one shot, so you can navigate very easily. If you wanted to do the same with Marcus Code, I guess it would not be 4 times quicker but maybe not more than 2 times quicker.) Hope it helps, Ludovic Soeur. Nov 17 '05 #14  P: n/a "Jon Skeet [C# MVP]" wrote in message news:MP************************@msnews.microsoft.c om... Checking that a matching regular expression - especially one that copes with arbitrary levels of nesting - is correct would be very, very hard. "Ludovic SOEUR" wrote in message news:ev**************@TK2MSFTNGP15.phx.gbl... Steve, you can use the following regex : ^[^()]*(?:$$([^()]*(?:(?:(\()[^()]*)+(?:(?<-2>$$)[^()]*)+)*(?(2)(?!)))\)[^() ]*)*$ Hehe. Guess Ludovic just proved Jon's point. =) I think if you are evil enough to write such a regexp, you must never ever supply a comment telling what the regexp does. Heck, the maintainance guys need to think for themselves! =) Happy Coding - Michael S Nov 17 '05 #15

 P: n/a Ludovic SOEUR wrote: Steve, you can use the following regex : ^[^()]*(?:$$([^()]*(?:(?:(\()[^()]*)+(?:(?<-2>$$)[^()]*)+)*(?(2)(?!)))\)[^() ]*)*$Here a simple example to know if parenthesis match : Regex regex=new Regex(@"^[^()]*(?:$$([^()]*(?:(?:(\()[^()]*)+(?:(?<-2>$$)[^()]*)+)*(?(2)(?!) ))\)[^()]*)*$"); That's simple, is it? Out of interest, how long do you think it would take to understand that, if presented with it with no prior knowledge? How long do you think you'd take to verify that it's correct? Marcus Code is obviously quicker than this one with Regex (on my computer, it's 4 times quicker), but I would prefer Regex. It's more "object" like. Well, the code which does it explicitly is faster, and *much* easier to understand. I don't see where the real benefit comes in, just from it being more "object" like. You could always encapsulate Marcus's code in a "ParenthesisMatcher" class or something similar. With the explicit code, it's easy to modify, easy to verify by inspection, easy to understand, and fast. The regular expression is none of these. It's just the wrong tool for the job, IMO. Jon Nov 17 '05 #16

 P: n/a I did not think that my post would start a debate. So as it has started, I have to reply. I put this sample to prove that it's possible with regex and I would like to do a time comparison too. I still stay on my point of view when I say I prefer RegEx version if you do not need to do this check 100 000 times. First of all, I would like to answer to Michael's reply. No, I'm not evil enough to write such a RegEx. I used the Regex from the Ryan Byington's one http://blogs.msdn.com/bclteam/archiv...15/396452.aspx that is very well explained. The only improvment was to remove all 'names' and to capture ONLY valid strings (the ones Steve is looking for). I ALWAYS explain my regular expressions and this one is a very usefull one that is known by most of who works with regex. Maintenance for this case is useless. It's like providing a function for the System namespace. You dont have to do maintenance for "substring" method of string class. When a regular expression is known to be correct and used by many developpers, you don't have to change anything. Only put a link to the original explanation and add comment in your code if you want to be more precise. On the other hand, Marcus code must be commented, and i would say, more than the regex one...it should be surprising for most people who are not used to balancing in regex. Second, to answer to Jon, it took me 2 minutes to understand the original regex from Ryan Byington. Firstly because it's well commented and also because I am used to writting balanced regex. To verify it was correct was very quick. Encapsulate Marcus' code in a "ParenthesisMatcher" is logical and I agree with you. Doing that and then store all subparts to have a direct access takes time. I said it was 4 times quicker (in fact it's 3.5) and I guess with en encapulated version, Marcus's one can reach 2 times. So why taking time to write an entire class doing the check, giving a direct access to the subelements, comment all this methods of course, write many lines of code ? It is alredy done with this regex which is known. It does all the works. Why allways rewriting what is done and working ? I totally disagree when you say that regular expression is not the job for this work. With one line that you do not mind if it's understable, you can do everything you need with parenthesis balancing. It's the right tool if you not need to do a loop over thousands of checks, you don't have to write your own classes or method, everything is already done. It's like using a dll, libray, in four words, reusing what was done. Ludovic SOEUR. "Jon Skeet [C# MVP]" a écrit dans le message de news:11*********************@g49g2000cwa.googlegro ups.com... Ludovic SOEUR wrote: Steve, you can use the following regex : ^[^()]*(?:$$([^()]*(?:(?:(\()[^()]*)+(?:(?<-2>$$)[^()]*)+)*(?(2)(?!)))\)[^() ]*)*$Here a simple example to know if parenthesis match : Regex regex=new Regex(@"^[^()]*(?:$$([^()]*(?:(?:(\()[^()]*)+(?:(?<-2>$$)[^()]*)+)*(?(2)(?!) ))\)[^()]*)*$"); That's simple, is it? Out of interest, how long do you think it would take to understand that, if presented with it with no prior knowledge? How long do you think you'd take to verify that it's correct? Marcus Code is obviously quicker than this one with Regex (on my computer, it's 4 times quicker), but I would prefer Regex. It's more "object" like. Well, the code which does it explicitly is faster, and *much* easier to understand. I don't see where the real benefit comes in, just from it being more "object" like. You could always encapsulate Marcus's code in a "ParenthesisMatcher" class or something similar. With the explicit code, it's easy to modify, easy to verify by inspection, easy to understand, and fast. The regular expression is none of these. It's just the wrong tool for the job, IMO. Jon Nov 17 '05 #17

 P: n/a Hi Jon, That's not too long for a Regular Expression. They are quite cryptic, though, if you're not used to the syntax. Unlike C, there is no ability to separate sections of instruction, even across lines. Like C, though, the more you practice, the better you get at it. It also helps to have a good IDE (or 2) for developing and testing Regular Expressions in. Regular Expressions are quite powerful in terms of how they do their parsing. It is essentially procedural, and character-based. Still, in this case, I can see how Marcus' code would be a more elegant solution. Just wanted to pique your interest in the power of Regular Expressions, which are invaluable in certain situations, such as parsing complex patterns in large strings and/or documents, replacing patterns rather than identical blocks of text, etc. -- HTH, Kevin Spencer Microsoft MVP ..Net Developer Ambiguity has a certain quality to it. "Jon Skeet [C# MVP]" wrote in message news:11*********************@g49g2000cwa.googlegro ups.com... Ludovic SOEUR wrote: Steve, you can use the following regex : ^[^()]*(?:$$([^()]*(?:(?:(\()[^()]*)+(?:(?<-2>$$)[^()]*)+)*(?(2)(?!)))\)[^() ]*)*$Here a simple example to know if parenthesis match : Regex regex=new Regex(@"^[^()]*(?:$$([^()]*(?:(?:(\()[^()]*)+(?:(?<-2>$$)[^()]*)+)*(?(2)(?!) ))\)[^()]*)*$"); That's simple, is it? Out of interest, how long do you think it would take to understand that, if presented with it with no prior knowledge? How long do you think you'd take to verify that it's correct? Marcus Code is obviously quicker than this one with Regex (on my computer, it's 4 times quicker), but I would prefer Regex. It's more "object" like. Well, the code which does it explicitly is faster, and *much* easier to understand. I don't see where the real benefit comes in, just from it being more "object" like. You could always encapsulate Marcus's code in a "ParenthesisMatcher" class or something similar. With the explicit code, it's easy to modify, easy to verify by inspection, easy to understand, and fast. The regular expression is none of these. It's just the wrong tool for the job, IMO. Jon Nov 17 '05 #18

 P: n/a Kevin Spencer wrote: That's not too long for a Regular Expression. Maybe not for a regular expression, but compared with the simple C# code, it's much too long and cryptic. They are quite cryptic, though, if you're not used to the syntax. I would argue that they're *relatively* cryptic even if you are used to the syntax. I'm not exactly a total newbie to regular expressions, but it would have taken me a fair amount of time to work out what that one was doing and verify it. Unlike C, there is no ability to separate sections of instruction, even across lines. Like C, though, the more you practice, the better you get at it. It also helps to have a good IDE (or 2) for developing and testing Regular Expressions in. Does that mean you agree that it's pretty difficult to understand them by just inspection? Regular Expressions are quite powerful in terms of how they do their parsing. It is essentially procedural, and character-based. Oh, they're incredibly powerful and very useful - *in the right situations*. Still, in this case, I can see how Marcus' code would be a more elegant solution. Just wanted to pique your interest in the power of Regular Expressions, which are invaluable in certain situations, such as parsing complex patterns in large strings and/or documents, replacing patterns rather than identical blocks of text, etc. I certainly appreciate that regexes are useful. I just don't think this is a place where they're suitable. I would guess that at least half of the requests for regular expressions I see on the newsgroups are inappropriate places to apply regular expressions. A lot of people seem to approach any textual problem with the immediate idea of "use a regular expression!" without considering whether or not it's the best/simplest way of solving it. Jon Nov 17 '05 #19

 P: n/a Ludovic SOEUR wrote: Maintenance for this case is useless. It's like providing a function for the System namespace. You dont have to do maintenance for "substring" method of string class. When a regular expression is known to be correct and used by many developpers, you don't have to change anything. So you're assuming that it will never, ever have to change it's function. It won't have to, say, change to balance < and > as well as or instead of ( and ). I don't like making that kind of assumption. I don't like having code which is hard to read - in particular, harder to read that an alternative, which is the case here. In many cases, regular expressions prevent you from having to write very complicated parsers. In those cases, the REs are the simpler code. Here, they're just not. Second, to answer to Jon, it took me 2 minutes to understand the original regex from Ryan Byington. Firstly because it's well commented and also because I am used to writting balanced regex. To verify it was correct was very quick. Do you think every maintenance engineer would only take two minutes? How long did it take you to understand the code Marcus produced? It certainly took me less than two minutes... Encapsulate Marcus' code in a "ParenthesisMatcher" is logical and I agree with you. Doing that and then store all subparts to have a direct access takes time. I said it was 4 times quicker (in fact it's 3.5) and I guess with en encapulated version, Marcus's one can reach 2 times. So why taking time to write an entire class doing the check, giving a direct access to the subelements, comment all this methods of course, write many lines of code ? It is alredy done with this regex which is known. It does all the works. Why allways rewriting what is done and working ? Either you encapsulate this in another method (or specific type) or you don't. If you don't, you have to have the bare regular expression itself available, which is pretty unpleasant IMO. If you do, it doesn't matter (from a usage point of view) whether you use a regular expression or the code from Marcus. I totally disagree when you say that regular expression is not the job for this work. With one line that you do not mind if it's understable, you can do everything you need with parenthesis balancing. You may not mind whether or not all your code is as readable as it can be. I certainly do. You might be interested to know that I ran the alternatives of "use a regular expression" or "use some simple logic" past a couple of colleagues - they were pretty much dumbfounded that anyone would use a regular expression in this situation, where the logic is so straightforward. Jon Nov 17 '05 #20

 P: n/a > I certainly appreciate that regexes are useful. I just don't think this is a place where they're suitable. I would guess that at least half of the requests for regular expressions I see on the newsgroups are inappropriate places to apply regular expressions. A lot of people seem to approach any textual problem with the immediate idea of "use a regular expression!" without considering whether or not it's the best/simplest way of solving it. Yes, I agree with you. that is a good summary of Regex usage today. I will however add, for this topic (validating and parsing expressions with parenthesis), that a known regex does all the job requested. Of course you can write code, write your own libraries that should be more elegant (it depends on what you think is elegant). I prefer reuse what is already done and only optimise it if necessary. Nov 17 '05 #21

 P: n/a Ludovic SOEUR wrote: First of all, I would like to answer to Michael's reply. No, I'm not evil enough to write such a RegEx. I used the Regex from the Ryan Byington's one http://blogs.msdn.com/bclteam/archiv...15/396452.aspx that is very well explained. Sorry to reply twice to the same post, but I just looked at the blog above. There are two points which are interesting to note: 1) This is .NET-specific - as I stated (with some trepidation!) before, there is no way to do this in "general" regular expressions. Therefore anyone reading it and trying to understand it not only needs to know regular expressions, but the .NET variety of them. 2) One of the comments is "My brain just exploded." That comment was added by someone who is very familiar with regular expressions, given the blog he links to. I would be willing to bet that if you gave both versions to 1000 "average" C# coders, far, far more would be able to understand the code from Marcus than the regular expression. Why include effectively "black box" code when you can so easily avoid it? Jon Nov 17 '05 #22

 P: n/a In article , Jon Skeet [C# MVP] wrote: : Hmm... I seem to remember something in CS classes saying that this is : something that regular expressions actually can't do. You can develop : them that will match down to a certain level of nesting (i.e. for any : given number of levels of nesting, you can build a regular expression : which will match it), but nothing to match *any* level of nesting. I : could easily be wrong though... Yes and no. If you mean regular expressions in the same sense as theoretical computer scientists use it, you're correct. Keep in mind, however, that the toolbox is pretty bare: literals, concatenation, grouping, alternation, and Kleene star. The .NET framework's "regular expressions" are more powerful in that they don't limit reconizers to regular languages (i.e., languages that finite-state automata can recognize). For example, by application of the pumping lemma, we can show that the language of strings where each character is either an 'a' or a 'b' and where each string consists of two copies of a substring appended together is not regular. (Notation makes this clearer: L = { ww : w \in {a, b}* }.) Backreferences make the construction trivial: Regex r = new Regex(@"^([ab]*)\1$"); In *Mastering Regular Expressions*, Friedl gives an VB.NET example for matching balanced parentheses, which I've paraphrased and translated to C# below: string pattern = @"^ $$(?> \( (?) |$$ (?<-DEPTH>) )* (?(DEPTH)(?!)) \)$"; Regex balanced = new Regex(pattern, RegexOptions.IgnorePatternWhitespace); See page 430 of http://www.oreilly.com/catalog/regex2/chapter/ch09.pdf Hope this helps, Greg -- - That scruffy beard... Those suspenders... That smug expression... You're one of those condescending Unix computer users! - Here's a nickel, kid. Get yourself a better computer. -- Dilbert Nov 17 '05 #24

 P: n/a In article <11*********************@g49g2000cwa.googlegroups. com>, Jon Skeet [C# MVP] wrote: : [...] : With the explicit code, it's easy to modify, easy to verify by : inspection, easy to understand, and fast. The regular expression is : none of these. It's just the wrong tool for the job, IMO. I mean, really. What's wrong with MOV and SCASB? Greg -- Today is already the tomorrow which the bad economist yesterday urged us to ignore. -- Henry Hazlitt, Economics in One Lesson Nov 17 '05 #25

 P: n/a "Ludovic SOEUR" wrote in message news:ec**************@tk2msftngp13.phx.gbl... So you will say that my code is not maintenable ? I disagree. Firstly, there is no need to modify it (it's like modifying indexOf of string class). A black box ? It's the same when you use a DLL or use any of the function in C#. It is true that THIS Regex will never need to be changed because this regex solves THIS problem. But, What if the problem changes??? Jon already brought up <,>. What about {,}and [,]? Or...Let's go crazy, what about /*,*/ These are all common Balanced pairs. What if the problem domain demands that we handle them too? (or some arbitrary subset) Granted, you may find another Off-the-shelf Regex to handle the problem, and you may not. More importantly, The guy who inherited your code will need to find it. So the original Regex may not need maintenance, but it may diverge form the problem set requiring a new solution. So, how likely is it that the Problem domain will change over time? That depend on the problem. If the problem will not likely change over time Perhaps the Regex will be fine. If obvious changes to the problem can be handled easily by Regex as well then Perhaps the Regex will be fine. If it is likely that the problem will morph beyond a "simple" regex then perhaps it is NOT the way to go. I brought up the question of embedded parens in quotes as follows: Console.WriteLine("("); Should this match or not:? Depends on the problem domain What about this: (("Hello")("")(":^)")) That smiley in the third set of parens COULD ruin your day. So the question is: Can your solution easily handle small (obvious) changes to the problem set? If so, go for it. If not, then you are doing no favors to the guy who needs to fix the code. I am not passing judgment of the use of the Regex. I find it difficult to understand, but, if it works...what the heck. When I solve a problem I always play devil's advocate with my solution. Have I built a solution that is robust enough to handle obvious (and not so obvious) changes? Bill Nov 17 '05 #26

 P: n/a Agreed on all points. Jon! -- Kevin Spencer Microsoft MVP ..Net Developer A watched clock never boils. "Jon Skeet [C# MVP]" wrote in message news:11**********************@g14g2000cwa.googlegr oups.com... Kevin Spencer wrote: That's not too long for a Regular Expression. Maybe not for a regular expression, but compared with the simple C# code, it's much too long and cryptic. They are quite cryptic, though, if you're not used to the syntax. I would argue that they're *relatively* cryptic even if you are used to the syntax. I'm not exactly a total newbie to regular expressions, but it would have taken me a fair amount of time to work out what that one was doing and verify it. Unlike C, there is no ability to separate sections of instruction, even across lines. Like C, though, the more you practice, the better you get at it. It also helps to have a good IDE (or 2) for developing and testing Regular Expressions in. Does that mean you agree that it's pretty difficult to understand them by just inspection? Regular Expressions are quite powerful in terms of how they do their parsing. It is essentially procedural, and character-based. Oh, they're incredibly powerful and very useful - *in the right situations*. Still, in this case, I can see how Marcus' code would be a more elegant solution. Just wanted to pique your interest in the power of Regular Expressions, which are invaluable in certain situations, such as parsing complex patterns in large strings and/or documents, replacing patterns rather than identical blocks of text, etc. I certainly appreciate that regexes are useful. I just don't think this is a place where they're suitable. I would guess that at least half of the requests for regular expressions I see on the newsgroups are inappropriate places to apply regular expressions. A lot of people seem to approach any textual problem with the immediate idea of "use a regular expression!" without considering whether or not it's the best/simplest way of solving it. Jon Nov 17 '05 #27

 P: n/a Thanks Bill for living on the same planet as I. Good post! Happy Maintaince - Michael S Nov 17 '05 #29

 P: n/a Ludovic SOEUR wrote: I certainly appreciate that regexes are useful. I just don't think this is a place where they're suitable. I would guess that at least half of the requests for regular expressions I see on the newsgroups are inappropriate places to apply regular expressions. A lot of people seem to approach any textual problem with the immediate idea of "use a regular expression!" without considering whether or not it's the best/simplest way of solving it. Yes, I agree with you. that is a good summary of Regex usage today. I will however add, for this topic (validating and parsing expressions with parenthesis), that a known regex does all the job requested. Of course you can write code, write your own libraries that should be more elegant (it depends on what you think is elegant). I prefer reuse what is already done and only optimise it if necessary. You had to go to a web page to find that code. I'm sure you *could* have found something like Marcus's code on a web page. Alternatively, the code that Marcus wrote was easy to write in the first place - no need to hunt it down. Given the option of "look for something that someone else has done, which I (and anyone reading the code) will need to put significant effort into understanding" and "write something from scratch in about 10 lines of easily understandable code" I'll pick the second one every time. -- Jon Skeet - http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet If replying to the group, please do not mail me too Nov 17 '05 #30

 P: n/a "Michael S" wrote in message news:Ou**************@TK2MSFTNGP12.phx.gbl... Thanks Bill for living on the same planet as I. Good post! That's funny. I just read your post with the same thought. {of course Bill was replaced with Michael in my thought :^) } Bill Nov 17 '05 #31

 P: n/a Hehe. We should set up a virtual company and hire Ludovic with a nice salary and have him maintain code for a while. With that experience he'll come running back late, in like a week, crawling with bugs Then we can fire him without even pay him for doing nothing. =) Happy Maintaining - Michael S ps. Ludovic: I hope you get that I'm just being funny on your behalf. I hope you'll forgive me. "Bill Butler" wrote in message news:CA87f.6596\$%A1.5723@trndny01... "Michael S" wrote in message news:Ou**************@TK2MSFTNGP12.phx.gbl... Thanks Bill for living on the same planet as I. Good post! That's funny. I just read your post with the same thought. {of course Bill was replaced with Michael in my thought :^) } Bill Nov 17 '05 #33

 P: n/a "Ludovic SOEUR" wrote in message news:uG**************@TK2MSFTNGP15.phx.gbl... P.S. Michael : I could not stop laughting seeing your reply about me. Why not try to work in the same company ? It should be very interesting.... ;-) Nice that I made you laugh. Me and you at the same work-place? I think I would need an army of ninja-wizards.. and bears too... http://unix.rulez.org/~calver/pictures/mordor.gif Ludovic. Regards - Michael S Nov 17 '05 #35

 P: n/a Couldn't you use the split function. string a = "a( ( 'john' ) and ( 'jane' ) and ( 'joe' ) )"; string[] b; b = a.Split( '(' ); MessageBox.Show((b.Length-1).ToString()); b = a.Split( ')' ); MessageBox.Show((b.Length-1).ToString()); Nov 17 '05 #37

 P: n/a Kevin wrote: Couldn't you use the split function. string a = "a( ( 'john' ) and ( 'jane' ) and ( 'joe' ) )"; string[] b; b = a.Split( '(' ); MessageBox.Show((b.Length-1).ToString()); b = a.Split( ')' ); MessageBox.Show((b.Length-1).ToString()); Aside from the needless performance hit (which may not be a problem in many situations) that doesn't check that the parentheses actually balance - it just counts them. So "))))((((" would "succeed", even though it's clearly wrong. Jon Nov 17 '05 #38

 P: n/a using System; using System.Collections; class ParenthesisParser { public static bool CorrectParenthesis(char[] elements) { Stack stack = new Stack(); char ch; for (int i = 0; i < elements.Length; i++) { ch = elements[i]; switch ( ch ) { case '(': stack.Push( ch ); break; case ')': if (stack.Count == 0) return false; stack.Pop( ); break; } } return stack.Count == 0; } } "Steve Kirsch" wrote: I need a simple function that can match the number of beginning and ending parenthesis in an expression. Here's a sample expression: ( ( "john" ) and ( "jane" ) and ( "joe" ) ) Does .NET have something built-in that can accomplish this, or do I have to write my own parser? I don't want to reinvent the wheel if possible. Nov 17 '05 #39

### This discussion thread is closed

Replies have been disabled for this discussion.

### Similar topics

Browse more C# / C Sharp Questions on Bytes