[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: [cdt-dev] Of Char[] and String

It will neither be a problem to represent the constants as Strings nor is it a problem to have them as char[]. There are
just a limited number of them.
However, the AST needs to represent a lot of names. For that we cannot afford the additional memory needed by the
string-objects. The char[] constants are more or less a consequence of having to work with char[] here or there.
 
Markus.


From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Alex Blewitt
Sent: Monday, July 20, 2009 8:44 PM
To: CDT General developers list.
Subject: [cdt-dev] Of Char[] and String
Importance: Low

As a general observation, I'm confused with the amount of char[] that happens in the CDT codebase. Is this a general consequence of C programmers working in Java, or are there underlying reasons? I happen to come across this today:

    private static final char[] EMPTY_CHAR_ARRAY = new char[0];
    private static final char[] ONE = "1".toCharArray(); //$NON-NLS-1$

The problem with char[] is that it's generally a less efficient one for storage than the underlying String model is, and in any case, you end up with the String being backed by a similar array in the first place (which is then interned). 

Consider the following class:

public class Test {
  public static final char[] foo = "1".toCharArray();
  // public static final char[] foo = {'1'};
  // public static final String foo = "1";
}

If I compile this (Mac OS X with Java 6) I get the following sizes of class file generated:

char with toCharArray = 329b
char with in-line array = 272b
String = 248b

What I can't understand is why we have the string "1" (which will take up space in the Class' intern pool) and then taking up more space than if we'd just used the string on its own. 

There's probably a reason, but one that isn't immediately obvious to me. Perhaps someone could enlighten me? It's probably all related to the fact that Token has a char[] getCharImage(), but that in itself just lends the question to 'why doesn't that return a String ...'

Alex