David Gallardo [mailto:[EMAIL PROTECTED]] wrote:

> I'm looking at the 1.4.0 API spec for StringBuffer which gives the
> following example using three strings:
>
> "String buffers are used by the compiler to implement the binary string
> concatenation operator +. For example, the code:
>
>       x = "a" + 4 + "c"
>
>
> "is compiled to the equivalent of:
>
>       x = new StringBuffer().append("a").append(4).append("c")
>                             .toString()
>
>
> "which creates a new string buffer (initially empty), appends the string
> representation of each operand to the string buffer in turn, and then
> converts the contents of the string buffer to a string. Overall, this
> avoids creating many temporary strings."

Ah, those crazy cats in the library group.  In this case it would be great
if they passed this example by the those swingin' hipsters in the compiler
group.  After all, you would expect the compiler group to be acquainted with
passages in the 1.4.0 language spec like this one:

      ****************************************************************
        15.28 Constant Expression
        ConstantExpression:
                Expression

        A compile-time constant expression is an expression denoting a
        value of primitive type or a String that is composed using only
        the following:

        o  Literals of primitive type and literals of type String
... snip ...
        o  The additive operators + and -
... snip ...

        Examples of constant expressions:
... snip ...

        "The integer " + Long.MAX_VALUE + " is mighty big."
      ****************************************************************
        --
http://java.sun.com/docs/books/jls/second_edition/html/expressions.doc.html#
5313

The clear expectation being, of course, that "compile-time constant
expressions"
should be evaluated at, you guessed it, compile time (yes, call me Mr.
MOTO).  That said, the whole "compiled to be the equivalent of..." business
in the documentation of StringBuffer must be almost wholly untrue *FOR THE
EXAMPLE GIVEN*.  However, if the example had been something like this:

        public String concatIt( String s1, int i, String s2)
        {
                return s1 + s2 + s3;
        }

Then the whole write up about String + and StringBuffer.append() is accurate
and very important!  Basically you don't gain anything (except maybe a small
preallocation optimization) by converting *static* chains of String
concatenation into StringBuffer.append() chains.  Furthermore, if the static
chain of concatenation is a constant expression, you *LOSE* as significant
compile-time optimization by converting it to a chain of appends.

HOWEVER, if you have a *dynamic* chain of String concatenations: a loop with
+= concatenation, recursive concatenation, complex conditional construction
involving concatenation, etc., THEN it can be immensely faster to use
StringBuffer and append through out the concatenation process, converting to
String only at the end.

> I haven't actually tested if this is true however, so I don't doubt you
> that actual compilers really don't do this.

Good.  Greg is right about the compile-time behavior.  However, as far as I
can tell you can't prove that by the StringBuffer javadoc...


> At 04:29 PM 1/20/2003 -0800, Greg Nudelman wrote:
> >[...]
> >Actually, if you read the StringBuffer API carefully, you'll
> note that the
> >compiler "has the option" to optimize String object
> >concatenation.  Actually, as the author of the original post (and my own
> >studies) indicated, what most compilers (most unfortunately) do is
> >concatenate only 2 strings at a time. Thus the overwhelming time/system
> >resources needed to append lots of String objects in a loop.

Personally I could not find anything in the StringBuffer API writeup that
says anything like "the compiler 'has the option' to optimize String object
concatenation".  The compiler does optimize these expressions *according to
the language spec*, but the StringBuffer documentation seems totally unaware
of that optimization.

-- Roger Glover



____________________________________________________
To change your JDJList options, please visit:
http://www.sys-con.com/java/list.cfm

Be respectful! Clean up your posts before replying
____________________________________________________

Reply via email to