StringBuilder: come ottenere la stringa finale?

Question

Qualcuno mi ha detto che è più veloce concatenare le stringhe con StringBuilder. Ho modificato il mio codice ma non vedo alcuna proprietà o metodo per ottenere la stringa di build finale.

Come posso ottenere la stringa?

Answer 1

Puoi usare .ToString () per ottenere String da StringBuilder .

Answer 2

Quando dici " è più veloce concatenare String con un generatore di string " ;, questo è vero solo se stai ripetutamente (ripeto - ripetutamente ) concatenando al stesso oggetto.

Se stai solo concatenando 2 stringhe e stai facendo qualcosa con il risultato immediatamente come stringa , non ha senso usare StringBuilder .

Mi sono appena imbattuto nel bel scrivere di Jon Skeet su questo: http: // www. yoda.arachsys.com/csharp/stringbuilder.html

Se stai usando StringBuilder , per ottenere la stringa risultante, è solo una questione di chiamare ToString () (non sorprende).

Answer 3

Dopo aver completato l'elaborazione utilizzando StringBuilder, utilizzare il metodo ToString per restituire il risultato finale.

Da MSDN:

using System;
using System.Text;

public sealed class App 
{
    static void Main() 
    {
        // Create a StringBuilder that expects to hold 50 characters.
        // Initialize the StringBuilder with "ABC".
        StringBuilder sb = new StringBuilder("ABC", 50);

        // Append three characters (D, E, and F) to the end of the StringBuilder.
        sb.Append(new char[] { 'D', 'E', 'F' });

        // Append a format string to the end of the StringBuilder.
        sb.AppendFormat("GHI{0}{1}", 'J', 'k');

        // Display the number of characters in the StringBuilder and its string.
        Console.WriteLine("{0} chars: {1}", sb.Length, sb.ToString());

        // Insert a string at the beginning of the StringBuilder.
        sb.Insert(0, "Alphabet: ");

        // Replace all lowercase k's with uppercase K's.
        sb.Replace('k', 'K');

        // Display the number of characters in the StringBuilder and its string.
        Console.WriteLine("{0} chars: {1}", sb.Length, sb.ToString());
    }
}

// This code produces the following output.
//
// 11 chars: ABCDEFGHIJk
// 21 chars: Alphabet: ABCDEFGHIJK

Answer 4

Vorrei solo buttare fuori che potrebbe non essere necessariamente più veloce, avrà sicuramente un footprint di memoria migliore. Questo perché le stringhe sono immutabili in .NET e ogni volta che cambi una stringa ne hai creata una nuova.

Answer 5

A proposito di memoria più veloce / migliore:

Ho esaminato questo problema con Java, presumo che .NET sarebbe altrettanto intelligente al riguardo.

L'implementazione per String è piuttosto impressionante.

L'oggetto String traccia " length " e " condiviso " (indipendentemente dalla lunghezza dell'array che contiene la stringa)

Quindi qualcosa di simile

String a = "abc" + "def" + "ghi";

può essere implementato (dal compilatore / runtime) come:

 - Extend the array holding "abc" by 6 additional spaces.
 - Copy def in right after abc 
 - copy ghi in after def. 
 - give a pointer to the "abc" string to a 
 - leave abc's length at 3, set a's length to 9
 - set the shared flag in both.

Poiché la maggior parte delle stringhe ha vita breve, ciò rende in alcuni casi un codice MOLTO efficiente. Il caso in cui NON è assolutamente efficace è quando si aggiunge una stringa all'interno di un ciclo o quando il codice è così:

a = "abc";
a = a + "def";
a += "ghi";

In questo caso, stai molto meglio usando un costrutto StringBuilder.

Il mio punto è che dovresti stare attento ogni volta che ottimizzi, a meno che tu non sia ASSOLUTAMENTE sicuro di sapere cosa stai facendo, E sei assolutamente sicuro che sia necessario, E test per assicurarti che il codice ottimizzato faccia passare un caso d'uso, basta codificarlo nel modo più leggibile possibile e non tentare di pensare al compilatore.

Ho perso 3 giorni a scherzare con le stringhe, memorizzare nella cache / riutilizzare i costruttori di stringhe e testare la velocità prima di esaminare il codice sorgente della stringa e capire che il compilatore lo stava già facendo meglio di quanto potessi nel mio caso d'uso. Quindi ho dovuto spiegare come non sapevo VERAMENTE cosa stavo facendo, ho solo pensato di saperlo ...

Answer 6

Non è più veloce concatolare - Come sottolineato da smaclell, il problema è la stringa immutabile che impone un'allocazione aggiuntiva e la ricopiatura dei dati esistenti.

" un " + " b " + " c " non ha più a che fare con il generatore di stringhe, ma ripetuti concat con una stringa intermedia diventano sempre più veloci man mano che il numero di concat diventa più grande come:

x = " a " ;; x + = " b " ;; x + = " c " ;; ...