Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #22526 > unrolled thread

simple StringBuilder proposal

Back to article view | Back to comp.lang.java.programmer

Contents

  simple StringBuilder proposal Roedy Green <see_website@mindprod.com.invalid> - 2013-02-26 03:53 -0800
    Re: simple StringBuilder proposal Andreas Leitgeb <avl@gamma.logic.tuwien.ac.at> - 2013-02-26 15:15 +0000
      Re: simple StringBuilder proposal Roedy Green <see_website@mindprod.com.invalid> - 2013-02-27 10:25 -0800
      Re: simple StringBuilder proposal Roedy Green <see_website@mindprod.com.invalid> - 2013-02-27 10:30 -0800
        Re: simple StringBuilder proposal Andreas Leitgeb <avl@gamma.logic.tuwien.ac.at> - 2013-02-28 08:30 +0000
          Re: simple StringBuilder proposal markspace <markspace@nospam.nospam> - 2013-02-28 07:54 -0800
    Re: simple StringBuilder proposal markspace <markspace@nospam.nospam> - 2013-02-26 08:31 -0800
      Re: simple StringBuilder proposal Lew <lewbloch@gmail.com> - 2013-02-26 10:33 -0800
        Re: simple StringBuilder proposal markspace <markspace@nospam.nospam> - 2013-02-26 10:47 -0800
          Re: simple StringBuilder proposal Leif Roar Moldskred <leifm@dimnakorr.com> - 2013-02-26 13:29 -0600
            Re: simple StringBuilder proposal Peter Duniho <NpOeStPeAdM@NnOwSlPiAnMk.com> - 2013-02-26 12:08 -0800
          Re: simple StringBuilder proposal Lew <lewbloch@gmail.com> - 2013-02-26 13:32 -0800
            Re: simple StringBuilder proposal Roedy Green <see_website@mindprod.com.invalid> - 2013-02-27 10:33 -0800
          Re: simple StringBuilder proposal Robert Klemme <shortcutter@googlemail.com> - 2013-02-26 22:53 +0100
            Re: simple StringBuilder proposal markspace <markspace@nospam.nospam> - 2013-02-26 15:54 -0800
              Re: simple StringBuilder proposal Robert Klemme <shortcutter@googlemail.com> - 2013-03-01 07:35 +0100
        Re: simple StringBuilder proposal Roedy Green <see_website@mindprod.com.invalid> - 2013-02-27 10:31 -0800
          Re: simple StringBuilder proposal Sven Köhler <remove-sven.koehler@gmail.com> - 2013-02-28 05:14 +0100
    Re: simple StringBuilder proposal Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2013-02-26 09:41 -0800
    Re: simple StringBuilder proposal Jan Burse <janburse@fastmail.fm> - 2013-02-26 20:21 +0100
      Re: simple StringBuilder proposal Joerg Meier <joergmmeier@arcor.de> - 2013-02-26 23:07 +0100
        Re: simple StringBuilder proposal Jan Burse <janburse@fastmail.fm> - 2013-02-27 00:09 +0100
          Re: simple StringBuilder proposal Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2013-02-26 15:19 -0800
            Re: simple StringBuilder proposal Jim Janney <jjanney@shell.xmission.com> - 2013-02-27 09:34 -0700
              Re: simple StringBuilder proposal Jan Burse <janburse@fastmail.fm> - 2013-02-27 19:18 +0100
                Re: simple StringBuilder proposal Arne Vajhøj <arne@vajhoej.dk> - 2013-02-27 19:56 -0500
                  Re: simple StringBuilder proposal Jan Burse <janburse@fastmail.fm> - 2013-02-28 10:19 +0100
                    Re: simple StringBuilder proposal Arne Vajhøj <arne@vajhoej.dk> - 2013-02-28 08:16 -0500
                      Re: simple StringBuilder proposal Jim Janney <jjanney@shell.xmission.com> - 2013-02-28 16:40 -0700
                        Re: simple StringBuilder proposal Arne Vajhøj <arne@vajhoej.dk> - 2013-02-28 18:51 -0500
              Re: simple StringBuilder proposal Arne Vajhøj <arne@vajhoej.dk> - 2013-02-27 20:01 -0500
    Re: simple StringBuilder proposal Silvio <silvio@internet.com> - 2013-02-26 22:03 +0100
      Re: simple StringBuilder proposal Silvio <silvio@internet.com> - 2013-02-26 22:04 +0100
    Re: simple StringBuilder proposal Sven Köhler <remove-sven.koehler@gmail.com> - 2013-02-27 03:47 +0100
      FastCat 'performance' (was: simple StringBuilder proposal) Joerg Meier <joergmmeier@arcor.de> - 2013-02-27 18:16 +0100
        Re: FastCat 'performance' markspace <markspace@nospam.nospam> - 2013-02-27 09:58 -0800
          Re: FastCat 'performance' Jan Burse <janburse@fastmail.fm> - 2013-02-27 19:31 +0100
            Re: FastCat 'performance' Joerg Meier <joergmmeier@arcor.de> - 2013-02-27 20:00 +0100
              Re: FastCat 'performance' Jan Burse <janburse@fastmail.fm> - 2013-02-27 20:41 +0100
                Re: FastCat 'performance' Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2013-02-27 12:38 -0800
                  Re: FastCat 'performance' Joerg Meier <joergmmeier@arcor.de> - 2013-02-27 21:58 +0100
                    Re: FastCat 'performance' Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2013-02-27 13:32 -0800
                  Re: FastCat 'performance' Lew <lewbloch@gmail.com> - 2013-02-27 13:42 -0800
                    Re: FastCat 'performance' Lew <lewbloch@gmail.com> - 2013-02-27 13:44 -0800
                    Re: FastCat 'performance' Joerg Meier <joergmmeier@arcor.de> - 2013-02-27 22:51 +0100
                      Re: FastCat 'performance' Sven Köhler <remove-sven.koehler@gmail.com> - 2013-02-28 05:19 +0100
                        Re: FastCat 'performance' Joerg Meier <joergmmeier@arcor.de> - 2013-02-28 13:09 +0100
                  Re: FastCat 'performance' markspace <markspace@nospam.nospam> - 2013-02-27 13:57 -0800
                    Re: FastCat 'performance' Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2013-02-27 15:23 -0800
                  Re: FastCat 'performance' Arne Vajhøj <arne@vajhoej.dk> - 2013-02-27 18:52 -0500
                  Re: FastCat 'performance' Sven Köhler <remove-sven.koehler@gmail.com> - 2013-03-01 17:26 +0100
        Re: FastCat 'performance' Sven Köhler <remove-sven.koehler@gmail.com> - 2013-02-27 21:00 +0100
        Re: FastCat 'performance' (was: simple StringBuilder proposal) Wanja Gayk <brixomatic@yahoo.com> - 2013-03-27 10:17 +0100

Page 1 of 3  [1] 2 3  Next page →

#22526 — simple StringBuilder proposal

With FastCat, I can write:

 sb.append( "<input name=\"cx\" type=\"hidden\" value=\"", cseAccount,
":", cseCode, "\">\n" );

It is just shorthand for

sb.append( "<input name=\"cx\" type=\"hidden\" value=\"",)
sb.append(cseAccount);
sb.append(":");
sb.append(cseCode);
sb.append( "\">\n" );

I propose StringBuilder learn the same trick.
-- 
Roedy Green Canadian Mind Products http://mindprod.com
One thing I love about having a website, is that when I complain about
something, I only have to do it once. It saves me endless hours of 
grumbling.

[toc] | [next] | [standalone]

#22532

Roedy Green <see_website@mindprod.com.invalid> wrote:
> With FastCat, I can write:
>  sb.append( "<input name=\"cx\" type=\"hidden\" value=\"", cseAccount,
> ":", cseCode, "\">\n" );
> It is just shorthand for
> sb.append( "<input name=\"cx\" type=\"hidden\" value=\"",)
> sb.append(cseAccount);
> sb.append(":");
> sb.append(cseCode);
> sb.append( "\">\n" );
> I propose StringBuilder learn the same trick.

I agree that explicitly calling append only once for
a couple of separate things is fine, as in: eventually
makes code clearer. (Even though your concrete example
doesn't look like supporting my claim, as the line grew
too long.)

Have you tried writing
 sb.append( "<input name=\"cx\" type=\"hidden\" value=\"" + cseAccount + ...)
?

I think, I once read here, that the JIT might even be smart enough
to not create a new StringBuilder for the "+"s, but inline it into
the existing StringBuilder.

Have you done timing tests that support your claim that creating
temporary arrays (for the varargs-call) is really faster than simple
"+"-style argument concatenation?  If so, how big was the difference?

[toc] | [prev] | [next] | [standalone]

#22581

On Tue, 26 Feb 2013 15:15:19 +0000 (UTC), Andreas Leitgeb
<avl@gamma.logic.tuwien.ac.at> wrote, quoted or indirectly quoted
someone who said :

>
>Have you tried writing
> sb.append( "<input name=\"cx\" type=\"hidden\" value=\"" + cseAccount + ...)
>?
>
>I think, I once read here, that the JIT might even be smart enough
>to not create a new StringBuilder for the "+"s, but inline it into
>the existing StringBuilder.

If the strings are literals, they will be concatenated at compile
time.

However in my case they are a string of boiler plate with variable
fields t this will be done very clumsily at run time.

The FastCat technique just saves up the constituent strings, then at
toString time, allocates char[] exactly the right size and builds the
String very quickly. This is quite a bit more efficient than what
default + StringBuilder does, growing/copying its buffer over and
over.

-- 
Roedy Green Canadian Mind Products http://mindprod.com
One thing I love about having a website, is that when I complain about
something, I only have to do it once. It saves me endless hours of 
grumbling.

[toc] | [prev] | [next] | [standalone]

#22582

On Tue, 26 Feb 2013 15:15:19 +0000 (UTC), Andreas Leitgeb
<avl@gamma.logic.tuwien.ac.at> wrote, quoted or indirectly quoted
someone who said :

>
>Have you done timing tests that support your claim that creating
>temporary arrays (for the varargs-call) is really faster than simple
>"+"-style argument concatenation?  If so, how big was the difference?

My application, expanding macros for my website ran about 10% faster
when I optimised StringBuilders to use the proper size.  I do more
than just concatenate,  so the concatenate was actually faster than
that.  I forget now the additional speed for the FastCat wrinkle. The
main thing is it does garbage collection less often.  It is much
easier to get an accurate fastcat estimate, and the penalty is less
for being off.

-- 
Roedy Green Canadian Mind Products http://mindprod.com
One thing I love about having a website, is that when I complain about
something, I only have to do it once. It saves me endless hours of 
grumbling.

[toc] | [prev] | [next] | [standalone]

#22609

Roedy Green <see_website@mindprod.com.invalid> wrote:
><avl@gamma.logic.tuwien.ac.at> wrote, quoted or indirectly quoted
>> Have you done timing tests that support your claim that creating
>> temporary arrays (for the varargs-call) is really faster than simple
>> "+"-style argument concatenation?  If so, how big was the difference?
>
> My application, expanding macros for my website ran about 10% faster
> when I optimised StringBuilders to use the proper size.  I do more
> than just concatenate,  so the concatenate was actually faster than
> that.  I forget now the additional speed for the FastCat wrinkle. The
> main thing is it does garbage collection less often.  It is much
> easier to get an accurate fastcat estimate, and the penalty is less
> for being off.

I think I missed your point, then.  I thought your proposal was merely
to adopt FastCat's varargs-append into standard StringBuilder, but now
it seems you're mainly comparing FastCat's different internal strategy,
instead of just the particular varargs-append().

[toc] | [prev] | [next] | [standalone]

#22624

On 2/28/2013 12:30 AM, Andreas Leitgeb wrote:

> I think I missed your point, then.  I thought your proposal was merely
> to adopt FastCat's varargs-append into standard StringBuilder, but now
> it seems you're mainly comparing FastCat's different internal strategy,
> instead of just the particular varargs-append().


I think the point of FastCat is its internal strategy.  I think the 
point of the OP was to point out that StringBuilder might want to adopt 
a varargs method.

[toc] | [prev] | [next] | [standalone]

#22537

On 2/26/2013 3:53 AM, Roedy Green wrote:
>   sb.append( "<input name=\"cx\" type=\"hidden\" value=\"", cseAccount,
> ":", cseCode, "\">\n" );
>
> It is just shorthand for
>
> sb.append( "<input name=\"cx\" type=\"hidden\" value=\"",)
> sb.append(cseAccount);
> sb.append(":");
> sb.append(cseCode);
> sb.append( "\">\n" );
>
> I propose StringBuilder learn the same trick.
>

I think I see what you are saying.  Java 8 is "in the chute" *right 
now*, so it might be timely to send in an enhancement request.  I don't 
think they're feature complete yet.

Send some sample code that does what you ask, I think it helps move the 
process along and promotes understanding also:

public class StringBuilderUtils {
   private StringBuilderUtils() {}

   /** Example only, should be an instance method on StringBuilder
     * rather than a static method.
     */
   public static void append( StringBuilder sb, Object... toAppend ) {
     for( Object o : toAppend )
       sb.append( o );
   }
}

Not tested or even compiled....

[toc] | [prev] | [next] | [standalone]

#22547

markspace wrote:
>  Roedy Green wrote:
>> With FastCat, I can write: 
>> 
>>   sb.append( "<input name=\"cx\" type=\"hidden\" value=\"", cseAccount,
>> ":", cseCode, "\">\n" );
> 
>> It is just shorthand for
> 
>> sb.append( "<input name=\"cx\" type=\"hidden\" value=\"",)
>> sb.append(cseAccount);
>> sb.append(":");
>> sb.append(cseCode);
>> sb.append( "\">\n" );
> 
>> I propose StringBuilder learn the same trick.

Java already has a shorthand for that:

  String s = "<input name=\"cx\" type=\"hidden\" value=\""
              + cseAccount + ":" + cseCode +  "\">\n";

> I think I see what you are saying.  Java 8 is "in the chute" *right 
> now*, so it might be timely to send in an enhancement request.  I don't 

Adding a feature that already exists is not an enhancement.

> think they're feature complete yet.

It is not the job of the API to provide every conceivable cover method for 
every conceivable combination of use cases. Good thing, too, or we programmers 
would have no jobs.

-- 
Lew

[toc] | [prev] | [next] | [standalone]

#22548

On 2/26/2013 10:33 AM, Lew wrote:
>
> Java already has a shorthand for that:
>
>    String s = "<input name=\"cx\" type=\"hidden\" value=\""
>                + cseAccount + ":" + cseCode +  "\">\n";

This requires that the compiler actually create a second StringBuilder. 
  This is not efficient.  What Roedy is saying is that given an existing 
StringBuilder object, he wants to be able to invoke multiple #append() 
calls with out having to spell out each one.

>
> It is not the job of the API to provide every conceivable cover method for
> every conceivable combination of use cases.

This is a point.  I think that the varagrs method might be notably 
inefficient in many cases, as primitives would be autoboxed.  However, 
it would not hurt to actually investigate this and determine how much 
and how often the autoboxing becomes an issue.  That investigation I'll 
leave to the concerned parties, however.

[toc] | [prev] | [next] | [standalone]

#22550

markspace <markspace@nospam.nospam> wrote:
> 
> This requires that the compiler actually create a second StringBuilder. 
>  This is not efficient.

Generally speaking, you build up text with StringBuilders because you
want to output that text somewhere and not just to fiddle around with
it in local memory. If you're going to do I/O anyway, the overhead of
such temporary StringBuilder objects is the least of your worries when
it comes to performance.

Or, to put it another way: if the overhead of creating such
StringBuilder objects has an actual, non-academic impact on the
performance of your program you are almost certainly doing things very
wrong at a higher level.

-- 
Leif Roar Moldskred

[toc] | [prev] | [next] | [standalone]

#22551

On Tue, 26 Feb 2013 13:29:31 -0600, Leif Roar Moldskred wrote:

> markspace <markspace@nospam.nospam> wrote:
>> 
>> This requires that the compiler actually create a second StringBuilder. 
>>  This is not efficient.
> 
> Generally speaking, you build up text with StringBuilders because you
> want to output that text somewhere and not just to fiddle around with
> it in local memory. If you're going to do I/O anyway, the overhead of
> such temporary StringBuilder objects is the least of your worries when
> it comes to performance.
> 
> Or, to put it another way: if the overhead of creating such
> StringBuilder objects has an actual, non-academic impact on the
> performance of your program you are almost certainly doing things very
> wrong at a higher level.

I think that's not quite right, though it's going in the correct direction.

There are in fact examples of programs that do a heavy amount of text
processing which is not directly related to output. And StringBuilders are
a key element in some of that processing.

Just because _some_ of the time, i/o is involved and will swamp the
performance effects, that's not to say it's true all of the time.
Performance of string handling can still matter.

That said, to your point: extra unreachable instances of StringBuilders
(i.e. those that live just long enough to do this sort of work) should not
impose much additional GC overhead as compared to having fewer such
instances.

Convenience is often (if not nearly always) in tension with performance. In
most scenarios, the syntax that Java already offers provides exactly the
convenience being requested here, with negligible performance impact.

For those scenarios where some performance impact may exist then, once the
programmer has properly analyzed that scenario (i.e. stated a performance
goal, identified a performance problem where the code fails to meet that
goal, and has determined that it's the extra StringBuilder instances that
are causing the problem), all they need to do is sacrifice some of that
convenience to get their performance back.

There's no reason to litter the language with extra optional syntaxes to
support uninteresting user scenarios such as the one proposed here.

Pete

[toc] | [prev] | [next] | [standalone]

#22554

markspace wrote:
> Lew wrote:
>> Java already has a shorthand for that:
>>    String s = "<input name=\"cx\" type=\"hidden\" value=\""
>>                + cseAccount + ":" + cseCode +  "\">\n";
> 
> This requires that the compiler actually create a second StringBuilder. 

That's what HotSpot is for, right?

>   This is not efficient.  What Roedy is saying is that given an existing 
> StringBuilder object, he wants to be able to invoke multiple #append() 
> calls with out having to spell out each one.

Okay, if that is enough of a hassle, and the "inefficiency" of a second StringBuilder 
is really a concern, then you write the method yourself.

The only inefficiency I thought was operating was programmer mindspace efficiency.

Worrying about a second StringBuilder argument is bullshit if you don't have to see it.

It's not like 'StringBuilder#append()' is super-"efficient", now is it? It's gotta convert things 
using 'toString()' (oh, hey, there are a few extra objects there anyway, huh?), grow arrays, 
and do all kinds of stuff where having a second instance might not even be noticeable.

>> It is not the job of the API to provide every conceivable cover method for
>> every conceivable combination of use cases.
> 
> This is a point.  I think that the varagrs method might be notably 
> inefficient in many cases, as primitives would be autoboxed.  However, 

There's that strange notion of efficiency again. Primitives are parsed into a String 
rep for 'append()' anyway, are they not?

> it would not hurt to actually investigate this and determine how much 
> and how often the autoboxing becomes an issue.  That investigation I'll 
> leave to the concerned parties, however.

And how much additional 'StringBuilder' objects become an issue, and with what 
frequency in the programmer community to be worth handling.

I aver that in the end the String '+' operator is fine. Forget micro-optimizing the 
StringBuilder. A difference that makes no difference is no difference.

-- 
Lew

[toc] | [prev] | [next] | [standalone]

#22585

On Tue, 26 Feb 2013 13:32:07 -0800 (PST), Lew <lewbloch@gmail.com>
wrote, quoted or indirectly quoted someone who said :

>Okay, if that is enough of a hassle, and the "inefficiency" of a second StringBuilder 
>is really a concern, then you write the method yourself.

I did. It is called FastCat. It would be nice if FastCat,
StringBuilder, StringBuffer etc. implemented some interface so they
could be more easily substituted, e.g. in places like regex.

I am suggesting it might be a useful tool for others.
-- 
Roedy Green Canadian Mind Products http://mindprod.com
One thing I love about having a website, is that when I complain about
something, I only have to do it once. It saves me endless hours of 
grumbling.

[toc] | [prev] | [next] | [standalone]

#22555

On 26.02.2013 19:47, markspace wrote:

> This is a point.  I think that the varagrs method might be notably
> inefficient in many cases, as primitives would be autoboxed.  However,
> it would not hurt to actually investigate this and determine how much
> and how often the autoboxing becomes an issue.  That investigation I'll
> leave to the concerned parties, however.

Please don't forget the Object[] creation which is imposed for every 
such call.

I cannot really recall what class it was but there is a class which has 
an overloaded method with single arguments for the case 1 to 3 and then 
has a catch all with vararg.  Like this

void f()
void f(Object arg)
void f(Object arg1, Object arg2)
void f(Object arg1, Object arg2, Object arg3)
void f(Object arg1, Object arg2, Object arg3, Object... remainder)

Effective Java seems to have this pattern on page ~200 also.

So someone clearly must have assumed that this can be significant.  I'd 
say the effect is worst for short argument lists, i.e, if you have only 
the vararg method and pass just one argument then the overhead per 
instance is highest.

Kind regards

	robert

-- 
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/

[toc] | [prev] | [next] | [standalone]

#22559

On 2/26/2013 1:53 PM, Robert Klemme wrote:

> I cannot really recall what class it was but there is a class which has
> an overloaded method with single arguments for the case 1 to 3 and then
> has a catch all with vararg.  Like this

EnumSet, and there's five of them, not three.  It's a rather extreme 
case of "let's make this as fast as possible, even to compile directly 
to one machine instruction" rather than a general heuristic.

<http://docs.oracle.com/javase/7/docs/api/java/util/EnumSet.html>

[toc] | [prev] | [next] | [standalone]

#22643

On 27.02.2013 00:54, markspace wrote:
> On 2/26/2013 1:53 PM, Robert Klemme wrote:
>
>> I cannot really recall what class it was but there is a class which has
>> an overloaded method with single arguments for the case 1 to 3 and then
>> has a catch all with vararg.  Like this
>
> EnumSet, and there's five of them, not three.

Ah, yes!  Thank you for helping my feeble memory, Mark!

>  It's a rather extreme
> case of "let's make this as fast as possible, even to compile directly
> to one machine instruction" rather than a general heuristic.
>
> <http://docs.oracle.com/javase/7/docs/api/java/util/EnumSet.html>

Actually I had similar thoughts: EnumSet seemed quite aggressive 
optimized.  There's also the two bit set implementations underneath 
(long and BitSet) which seem to indicate Oracle's engineers expect heavy 
use of Enums.

Kind regards

	robert

-- 
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/

[toc] | [prev] | [next] | [standalone]

#22583

On Tue, 26 Feb 2013 10:33:25 -0800 (PST), Lew <lewbloch@gmail.com>
wrote, quoted or indirectly quoted someone who said :

>Java already has a shorthand for that:
>
>  String s = "<input name=\"cx\" type=\"hidden\" value=\""
>              + cseAccount + ":" + cseCode +  "\">\n";

The difference is you cannot give a size estimate when you use +.
-- 
Roedy Green Canadian Mind Products http://mindprod.com
One thing I love about having a website, is that when I complain about
something, I only have to do it once. It saves me endless hours of 
grumbling.

[toc] | [prev] | [next] | [standalone]

#22607

Am 27.02.2013 19:31, schrieb Roedy Green:
> On Tue, 26 Feb 2013 10:33:25 -0800 (PST), Lew <lewbloch@gmail.com>
> wrote, quoted or indirectly quoted someone who said :
> 
>> Java already has a shorthand for that:
>>
>>  String s = "<input name=\"cx\" type=\"hidden\" value=\""
>>              + cseAccount + ":" + cseCode +  "\">\n";
> 
> The difference is you cannot give a size estimate when you use +.

And you dont have to, because the stringbuilder implements exponential
groth. In result, the amount of characters copied during array expansion
is linear in the final length of the stringbuilder.

Regards,
  Sven

[toc] | [prev] | [next] | [standalone]

#22545

On 2/26/13 3:53 AM, Roedy Green wrote:
>
> With FastCat, I can write:
>
>   sb.append( "<input name=\"cx\" type=\"hidden\" value=\"", cseAccount,
> ":", cseCode, "\">\n" );
>
> It is just shorthand for
>
> sb.append( "<input name=\"cx\" type=\"hidden\" value=\"",)
> sb.append(cseAccount);
> sb.append(":");
> sb.append(cseCode);
> sb.append( "\">\n" );
>
> I propose StringBuilder learn the same trick.
>
I doubt it is the same.  Its probably more likely shorthand for this:

--- snip ---
final String[] hiddenArray = new String[] {
    "<input name=\"cx\" type=\"hidden\" value=\"",
    cseAccount,
    ":",
    cseCode,
    "\">\n"
}

for (String s: hiddenArray) { sb.append(s); }
--- /snip --

Which produces the same end result, but does have some mild overhead of 
the array creation. Unless you use that array directly, which I could see.

[toc] | [prev] | [next] | [standalone]

#22549

Roedy Green schrieb:
> It is just shorthand for
>
> sb.append("<input name=\"cx\" type=\"hidden\" value=\"");
> sb.append(cseAccount);
> sb.append(":");
> sb.append(cseCode);
> sb.append("\">\n");

Since append() returns the StringBuilder itself, you can also write:

sb.append("<input name=\"cx\" type=\"hidden\" value=\"")
   .append(cseAccount)
   .append(":")
   .append(cseCode)
   .append("\">\n");

There are a couple of methods in the JDK that are designed this way.

Bye

[toc] | [prev] | [next] | [standalone]

Page 1 of 3  [1] 2 3  Next page →

Back to top | Article view | comp.lang.java.programmer

csiph-web