C# - Kontrollera om parenteser är balanserade

Som sidkuriosa: Här är en lösning i Scala som använder sig av rekursion och pattern matching. Troligtvis tillräckligt mycket "pseudo" för att inte ge bort lösningen gratis

  def isBalanced(input: String, depth: Int = 0): Boolean =
    input.splitAt(1) match {
      case ("", _)     => depth == 0
      case ("(", rest) =>              isBalanced(rest, depth + 1)
      case (")", rest) => depth > 0 && isBalanced(rest, depth - 1)
      case (_, rest)   =>              isBalanced(rest, depth)
    }

  isBalanced("(apa)")                             //> res0: Boolean = true
  isBalanced("(())")                              //> res1: Boolean = true
  isBalanced("(kalle)olle(pelle)")                //> res2: Boolean = true
  isBalanced("")                                  //> res3: Boolean = true
  
  isBalanced(")(((((((((((((((((")                //> res4: Boolean = false
  isBalanced("())")                               //> res5: Boolean = false
  isBalanced("())(")                              //> res6: Boolean = false

Jag tänker att detta kan vara intressant för de som främst sitter med Java/PHP/C# eller liknande. Pattern matching och rekursion lämpar sig väldigt bra för att dekonstruera simpla rekursiva strukturer.

Dina if:ar går ju mot Parentes och inte A så det där kan omöjligen bli rätt...

Stack<char> Källkod = new Stack<char>();

string Parentes = tbxParentes.Text;

foreach (char A in Parentes)
{
    if (Parentes == "(")
    {
        Källkod.Push(A);
    }
    if (Parentes == ")" && Källkod.Count() > 0)
    {
        Källkod.Pop();
    }
}

if (Källkod.Count() > 0)
{
    lblUtskrift.Text = "Fel";
}
else
{
    lblUtskrift.Text = "Rätt";
}

Du är nära...

Stack<char> Källkod = new Stack<char>();

string Parentes = ")()()(";

foreach (char A in Parentes)
{
    if (A == '(') // char i c# skrivs med ' medans string skrivs med "
    {
        Källkod.Push(A);
    }
    else if (A == ')') // char i c# skrivs med ' medans string skrivs med "
    {
        if (Källkod.Count > 0)
        {
            Källkod.Pop();
        }
        else // Vi försöker stänga en parentes, men ingen är öppen, dvs koden "kompilerar" inte.
        {
            Källkod.Push('x'); // Ett dummy-värde för att Källkod.Count inte ska vara 0.
            break; // Vi avbryter loopen.
        }
    }
}

if (Källkod.Count == 0)
{
    Console.Write("Rätt");
}
else
{
    Console.Write("Fel");
}

Min tanke var mest att TS lösning innehöll slarvfel, men du kanske har rätt. TS kanske inte har någon som helst aning vad det är för skillnad på en char eller string. TS kanske borde göra betydligt mer basic uppgifter ur sin bok... Om inte annat kan TS släppa det här nu och träna på datatyper och foreach-loopar :). (Editade in lite kommentarer)

Du kanske skulle börja med lite enklare utskrifter så du får en förståelse för t ex din foreach-loop:
https://dotnetfiddle.net/Widget/myB7P5

Jag skulle inte kalla det nära när killen knappt förstår skillnaden mellan "Parentes" och "A" i sin loop.

@Teknocide: gillar helt klart (svans)rekursiva lösning, problemet är bara att de kan ha otrevliga överraskning i språk/plattformar som inte garanterar att optimera bort svansrekursion (som t.ex. JVM (Java,Scala) och CLR (C#)).

Som du skrivit koden nu så kommer moderna versioner av den "vanliga" scala-kompilatorn utföra "tail-call optimization" och alla typer av strängar är "safe". Men lite lagom ologisk så kommer det smälla med java.lang.StackOverFlowError på en del input (väldigt högt djup, ~1000 på 32-bit och ~10000 på 64-bit) om man i stället råkar ha samma kod i en metod på ett objekt.

Nu kan det i.o.f.s. smälla även med en imperativ lösning baserade på en explicit stack, men det händer först när man helt enkelt inte har nog med RAM att hantera alla '('. Det rekursiva lösningen smäller långt innan, framförallt på 32-bitsystem.

Finns i.o.f.s språk som garanterar optimering svansrekursion (t.ex. Haskell och Clojure om man explicit använder recur) och språk där stacken växer dynamiskt vid behov (t.ex. Go och Erlang), där är det "safe" men en sådan lösning även i produktionskod.