String value holders: useful or memory hogs?

From: Oliver Plohmann (oliver_at_plohmann.com)
Date: 10/30/04

  • Next message: Stefan Schulz: "Re: why URLConnection is declared abstract"
    Date: 30 Oct 2004 12:19:33 -0700
    
    

    I have a lot of collections in my application that hold strings which
    represent objects. These objects are often on remote machines, which
    is the reason why I plug in their id strings into some collections
    instead of the objects themselves. This makes it possible that coding
    errors may happen, which the compiler cannot find. Example:

    List<String> nodeIds = new Array<String>();
    List<String> agentIds = new Array<String>();

    String nodeId = "uniqueNodeId";
    agentIds.add(nodeId); // logical coding error and compiler would not
    complain

    The compiler would find these kind of errors if string value holders
    were used:

    public class NodeId {

        protected String id = null;
        // remaining code omitted for brevity
    }

    public class AgentId {

        protected String id = null;
        // remaining code omitted for brevity
    }

    List<NodeId> nodeIds = new Array<NodeId>();
    List<AgentId> agentIds = new Array<AgentId>();

    NodeId nodeId = new NodeId("uniqueNodeId");
    agentIds.add(nodeId); // ==> compiler error !!

    Now I'm expecting memory consumption to raise because of these value
    holder classes like NodeId and AgentId. I wonder whether it will make
    a difference. I guess so, but I wonder how much. Did any body out
    there already try something similar and has some recommendations?

    Thanx for any feed-back,
    Oliver


  • Next message: Stefan Schulz: "Re: why URLConnection is declared abstract"

    Relevant Pages

    • Re: Is C99 the final C? (some suggestions)
      ... > Microsoft compiler, or do you draw the line at C89? ... in the same sense that the implementors of the Lua language considered C to be ... Now why would they bother if portable mutex implementations ... C doesn't have strings. ...
      (comp.lang.c)
    • Re: Symbols, metacircular evaluation, external representation.
      ... You could only use strings, and you would have to use parsers all the time. ... same kind of symbolic expressions, it's very easy to write functions ... writting a metacircular interpreter (or a lisp compiler), ... lists. ...
      (comp.lang.scheme)
    • Re: Verbose functional languages?
      ... A lazy language might, in the end, not be what you need. ... if the compiler unboxes them for you by way of optimization. ... and strictness can be infered to a great extent. ... But strings were always a very slow and memory ...
      (comp.lang.functional)
    • Re: Internal Representation of Strings
      ... strings are likely to be very small, ... It just seems like low overhead strings always have a ... (No, I haven't built a compiler, yet). ... saving 1 or 2 bytes will not matter so much if the memory comes ...
      (comp.compilers)
    • Re: newbie question about string initialization
      ... This is almost certainly a variation in compiler "interpretation" of the ... standard, I'm not sure if it can be classified as a "bug" but certainly a ... functions that are "safe" versions that do a character by character check ... The design of F77 strings is extremely poor in a number of significant areas ...
      (comp.lang.fortran)