Create String from char - so difficult??

[column.column]

Hello,

How to create new String having one char. Is it really only way to
create new char array that has length one and using it create string?

char a = 'a';
String ss = new String ( new char[] {a});


By the way, in first line characters '' represents only char or it
might be something else? As i understood "" always represents String.

Thank You

 

[RedGrittyBrick]

Hello,

How to create new String having one char. Is it really only way to
create new char array that has length one and using it create string?

char a = 'a';
String ss = new String ( new char[] {a});


By the way, in first line characters '' represents only char or it
might be something else? As i understood "" always represents String.

Any of the following will work.

String s = "a";

String s = "" + 'a';

char c = 'a';
String s = "" + c;

 

[Lothar Kimmeringer]

How to create new String having one char. Is it really only way to
create new char array that has length one and using it create string?

char a = 'a';
String ss = new String ( new char[] {a});

String ss = Character.toString('a');
alternatively
String ss = String.valueOf('a');
This way is to be preferred over the usual answer
String ss = "" + 'a';
Reason for this is the way Strings are working in Java and what
the Java-compiler creates out of that line:
String ss = new StringBuffer().append("").append(String.valueOf('a')).toString();


Regards, Lothar
--
Lothar Kimmeringer E-Mail: (e-mail address removed)
PGP-encrypted mails preferred (Key-ID: 0x8BC3CD81)

Always remember: The answer is forty-two, there can only be wrong
questions!

 

[Arne Vajhøj]

String s = "" + 'a';

char c = 'a';
String s = "" + c;

"" +

i not good code style.

Arne

 

[Roedy Green]

char a = 'a';
String ss = new String ( new char[] {a});

see http://mindprod.com/applet/converter.html

 

[RedGrittyBrick]

String s = "" + 'a';

char c = 'a';
String s = "" + c;

"" +

i not good code style.

True. Lothar explained why and suggested
char c = 'a';
...
s = Character.toString(c);

Perhaps
Character c = 'a';
...
String s = c.toString();
would often be marginally preferable?

 

[Owen Jacobson]

"" +

i not good code style.

True. Lothar explained why and suggested
     char c = 'a';
     ...
     s = Character.toString(c);

Perhaps
     Character c = 'a';
     ...
     String s = c.toString();
would often be marginally preferable?

For almost entirely superstitious reasons I would prefer the former
over the latter, even though the latter is more uniform with respect
to other, non-primitive types. I dislike intentionally obscuring the
line between primitives and non-primitives in Java almost as much as I
dislike the existence of primitive, non-reference types in Java in the
first place.

 

[Roedy Green]

How to create new String having one char. Is it really only way to
create new char array that has length one and using it create string?

Surely somebody has had it up to here with the irregularity of Java
conversion functions and written a wrapper class to convert any
primitive to any other (plus strings).

like this

double Cvt.todouble( String s );
float Cvt.tofloat ( int i );
Float Cvt.toFloat ( long l );

.....

See http://mindprod.com/applet/converter.html
for the code to implement each function.

 

[Lew]

Surely somebody has had it up to here with the irregularity of Java
conversion functions and written a wrapper class to convert any
primitive to any other (plus strings).

like this

double Cvt.todouble( String s );
float Cvt.tofloat ( int i );
Float Cvt.toFloat ( long l );

I understand why you did it, but the lack of camel case is jarring (no pun
intended). Besides, with autoboxing you don't need two versions:

float f = Cvt.toFloat( int i );
Float fc = Cvt.toFloat( int i );

Then again,

float f = i;

works just fine.

As for String conversions, I don't understand what you mean by the
"irregularity" at all. The String class has valueOf() overloads for all the
primitive types. The primitive type wrapper classes except Character have
valueOf( String ) overloads. It's hard to be more regular than that, unless
you insist on "remedying" the sole exception of Character, and I suspect that
one is due to the special relationship between Strings and chars and the
existence of String.charAt().

It's not worth running around Jericho's barn to wind up where I'm already
standing.

 

[Mark Space]

float f = Cvt.toFloat( int i );
Float fc = Cvt.toFloat( int i );

I don't find either of these to be all that readable. In Roedy's
example, just the change in case is easy for my old eyes to miss. In
your case, overloading functions always runs the risk of calling the
wrong function on accident. (Say if the compiler is the one choosing
which function to call, how certain are you it calls the one you thought
it would?)

I think I'd make the function name more explicit, and skip the overloading.

float f = Cvt.toPrimitiveFloat( int i );
Float f2 = Cvt.toFloat( int i );

Or something like that. The idea of readability is key here.

 

[Owen Jacobson]

I don't find either of these to be all that readable.  In Roedy's
example, just the change in case is easy for my old eyes to miss. In
your case, overloading functions always runs the risk of calling the
wrong function on accident. (Say if the compiler is the one choosing
which function to call, how certain are you it calls the one you thought
it would?)

The whole point of Lew's post is that there is no overloading, as the
language already provides a feature that obviates the need for it. In
this case, there is a single method

public static float toFloat (int i)

In the second case, the returned float is being automatically boxed to
a Float by the compiler, freeing the programmer from having to write a
second method.

(Futhermore, Java forbids programmers from overloading by return type
only...)

-o

 

[Roedy Green]

Then again,

float f = i;

works just fine.

that's the problem. the lack of predictability and regularity. You
need something a newbie can use mindlessly. A decent optimiser
should inline them all so the final code would be just that.

 

[Roedy Green]

As for String conversions, I don't understand what you mean by the
"irregularity" at all. The String class has valueOf() overloads for all the
primitive types. The primitive type wrapper classes except Character have
valueOf( String ) overloads. It's hard to be more regular than that, unless
you insist on "remedying" the sole exception of Character, and I suspect that
one is due to the special relationship between Strings and chars and the
existence of String.charAt().

have a look at all the various conversions at
http://mindprod.com/applet/converter.html

There are pockets of regularity, but overall it drives newbies to
distraction.

 

[Eric Sosman]

that's the problem. the lack of predictability and regularity. You
need something a newbie can use mindlessly. A decent optimiser
should inline them all so the final code would be just that.

Neither newbies nor roedies[*] should be encouraged
to write code mindlessly.

[*] Needed a word connoting uncommon breadth and depth
of experience, the opposite of "newbie." For the sake of
sentence punch, wanted a two-syllable word ending in "-ies"
to highlight the contrast; this was the best I could find.

 

[Roedy Green]

I understand why you did it, but the lack of camel case is jarring (no pun
intended). Besides, with autoboxing you don't need two versions:

float f = Cvt.toFloat( int i );
Float fc = Cvt.toFloat( int i );

you can't quite to do that e.g.

boolean isBig = ctv.toFloat( i ).isInfinite();

I don't think autoboxing would be smart enough to handle that.

 

[Mark Space]

(Futhermore, Java forbids programmers from overloading by return type
only...)

Oh, good point. I didn't realize that.

 

[John W. Kennedy]

that's the problem. the lack of predictability and regularity. You
need something a newbie can use mindlessly. A decent optimiser
should inline them all so the final code would be just that.

You're on the road to reinventing PL/I.

 

[Lew]

Float Cvt.toFloat ( long l );

Lew wrote,

you can't quite to do that e.g.

boolean isBig = ctv.toFloat( i ).isInfinite();

I don't think autoboxing would be smart enough to handle that.

Works fine here:

package testit;
public class Boxer
{
public static Float toFloat( int in )
{
return (float) in;
}

public static Float toFloat( long in )
{
return (float) in;
}

public static void main(String[] args)
{
int in = 17;
boolean isBig = toFloat( in ).isInfinite();
System.out.println( "Is "+ in +" big? "+ isBig );

long ln = 4000000000L;
isBig = toFloat( ln ).isInfinite();
System.out.println( "Is "+ ln +" big? "+ isBig );

}
}

 

[Roedy Green]

isBig = toFloat( ln ).isInfinite();

Good. that gets rid of the need to distinguish between toFloat and
tofloat.