nested generic HashMap problem

Discussion in 'Java' started by Chris Riesbeck, Apr 26, 2010.

  1. I've looked at the Java generics tutorial, Langer's FAQ, and similar
    online pages, but I'm still don't see what, if anything, I can do to
    make the last line (marked with the comment) compile, other than do a
    typecast and suppress the unchecked warning. Am I asking the impossible
    or missing the obvious?

    import java.util.HashMap;

    public class Demo<T> {
    private Class<T> base;
    private Cache cache;

    Demo(Class<T> b, Cache c) { base = b; cache = c; }

    Class<T> getBaseClass() { return base; }
    T get(long id) { return cache.get(this, id); }
    }

    class Cache {
    private HashMap<Class<?>, HashMap<Long, ?>> maps
    = new HashMap<Class<?>, HashMap<Long, ?>>();

    public <T> T get(Demo<T> demo, long id) {
    return getMap(demo).get(id);
    }

    public <T> void add(Demo<T> demo) {
    maps.put(demo.getBaseClass(), new HashMap<Long, T>());
    }

    private <T> HashMap<Long, T> getMap(Demo<T> demo) {
    return maps.get(demo.getBaseClass()); // incompatible types
    }
    }
     
    Chris Riesbeck, Apr 26, 2010
    #1
    1. Advertising

  2. Chris Riesbeck

    Lew Guest

    Chris Riesbeck wrote:
    > I've looked at the Java generics tutorial, Langer's FAQ, and similar
    > online pages, but I'm still don't see what, if anything, I can do to
    > make the last line (marked with the comment) compile, other than do a
    > typecast and suppress the unchecked warning. Am I asking the impossible
    > or missing the obvious?
    >
    > import java.util.HashMap;
    >
    > public class Demo<T> {
    > private Class<T> base;
    > private Cache cache;
    >
    > Demo(Class<T> b, Cache c) { base = b; cache = c; }
    >
    > Class<T> getBaseClass() { return base; }
    > T get(long id) { return cache.get(this, id); }
    > }
    >
    > class Cache {
    > private HashMap<Class<?>, HashMap<Long, ?>> maps
    > = new HashMap<Class<?>, HashMap<Long, ?>>();
    >
    > public <T> T get(Demo<T> demo, long id) {
    > return getMap(demo).get(id);
    > }
    >
    > public <T> void add(Demo<T> demo) {
    > maps.put(demo.getBaseClass(), new HashMap<Long, T>());
    > }
    >
    > private <T> HashMap<Long, T> getMap(Demo<T> demo) {
    > return maps.get(demo.getBaseClass()); // incompatible types
    > }
    > }


    No way while you have the wildcards there. Suppressing unchecked warnings
    will only expose you to ClassCastException.

    Did you also read the free chapter on generics from Josh Bloch's /Effective
    Java/ available at java.sun.com?

    You only suppress unchecked warnings when you have documentable proof that you
    cannot get a ClassCastException, and that documentation needs to be in the
    program comments.

    As defined, your 'Cache#maps' variable cannot even guarantee that the base
    type of the 'Class' key matches the type of the value map's value.

    Furthermore, you define all that in terms of concrete classes instead of
    interfaces. Oops.

    You might have better luck putting an upper bound (e.g., 'Foo') on the type of
    'T' and have

    public class Cache <Foo>
    {
    private Map <Class <? extends Foo>, Map <Long, Foo>> maps;
    }

    or perhaps

    public class Cache <Foo>
    {
    private Map <Class <? extends Foo>, Map <Long, ? extends Foo>> maps;
    }

    but as long as you're holding disparate types in your so-called "cache" I
    don't think you can avoid the risk of ClassCastException.

    I could be wrong. Type analysis is tricky.

    Whenever I find tricky generics questions like these, I find it pays to really
    think very hard about what to assert about the types. Once I figure that out
    the generics are a simple reflection of that analysis.

    --
    Lew
     
    Lew, Apr 26, 2010
    #2
    1. Advertising

  3. Lew wrote:
    > Chris Riesbeck wrote:
    >> I've looked at the Java generics tutorial, Langer's FAQ, and similar
    >> online pages, but I'm still don't see what, if anything, I can do to
    >> make the last line (marked with the comment) compile, other than do a
    >> typecast and suppress the unchecked warning. Am I asking the
    >> impossible or missing the obvious?
    >> ...
    >> public class Demo<T> {
    >> ...
    >> Class<T> getBaseClass() { return base; }
    >> T get(long id) { return cache.get(this, id); }
    >> }
    >>
    >> class Cache {
    >> private HashMap<Class<?>, HashMap<Long, ?>> maps
    >> = new HashMap<Class<?>, HashMap<Long, ?>>();
    >>...
    >> private <T> HashMap<Long, T> getMap(Demo<T> demo) {
    >> return maps.get(demo.getBaseClass()); // incompatible types
    >> }
    >> }

    >
    > No way while you have the wildcards there. Suppressing unchecked
    > warnings will only expose you to ClassCastException.
    >
    > Did you also read the free chapter on generics from Josh Bloch's
    > /Effective Java/ available at java.sun.com?


    Part of the above was meant to follow as best I could his pattern for
    type-safe heterogeneous containers.

    > As defined, your 'Cache#maps' variable cannot even guarantee that the
    > base type of the 'Class' key matches the type of the value map's value.
    >
    > Furthermore, you define all that in terms of concrete classes instead of
    > interfaces. Oops.


    I agree. This was the shortest compilable example I could come up with
    that still had the interactions I needed to support.

    > You might have better luck putting an upper bound (e.g., 'Foo') on the
    > type of 'T'
    >
    > [...snip...]
    >
    > Whenever I find tricky generics questions like these, I find it pays to
    > really think very hard about what to assert about the types. Once I
    > figure that out the generics are a simple reflection of that analysis.


    T can be anything. What I can assert is that if the key is Demo<T> then
    the nested map value is Map<T, Long>, where T = the return type of
    Demo<T> getBaseClass(). I can't figure out if there's a way to write
    that relationship in the type declaration.

    I really appreciate the quick response, Lew. Thanks
     
    Chris Riesbeck, Apr 26, 2010
    #3
  4. Chris Riesbeck

    markspace Guest

    Chris Riesbeck wrote:
    > I've looked at the Java generics tutorial, Langer's FAQ, and similar
    > online pages, but I'm still don't see what, if anything, I can do to
    > make the last line (marked with the comment) compile, other than do a
    > typecast and suppress the unchecked warning. Am I asking the impossible
    > or missing the obvious?



    Possibly. I've run into this before, that you basically can't use ? at
    all for retrieving values of a type other than object, so you're going
    to get a warning there no matter what you do.

    If I follow your logic correctly, I think you can add a type parameter
    to Cache, and that will allow you to use T instead of ? as a type
    parameter for the hash map. Take a gander at the following and see if
    it matches what you want to do:

    package test;

    import java.util.HashMap;

    public class Demo<T> {
    private Class<T> base;
    private Cache<T> cache;

    Demo(Class<T> b, Cache c) { base = b; cache = c; }

    Class<T> getBaseClass() { return base; }
    T get(long id) { return cache.get(this, id); }
    }

    class Cache<T> {
    private HashMap<Class<T>, HashMap<Long, T>> maps
    = new HashMap<Class<T>, HashMap<Long, T>>();

    public T get(Demo<T> demo, long id) {
    return getMap(demo).get(id);
    }

    public void add(Demo<T> demo) {
    maps.put(demo.getBaseClass(), new HashMap<Long, T>());
    }

    private HashMap<Long, T> getMap(Demo<T> demo) {
    return maps.get(demo.getBaseClass());
    }
    }
     
    markspace, Apr 26, 2010
    #4
  5. Chris Riesbeck

    Daniel Pitts Guest

    On 4/26/2010 2:54 PM, Chris Riesbeck wrote:
    > I've looked at the Java generics tutorial, Langer's FAQ, and similar
    > online pages, but I'm still don't see what, if anything, I can do to
    > make the last line (marked with the comment) compile, other than do a
    > typecast and suppress the unchecked warning. Am I asking the impossible
    > or missing the obvious?
    >
    > import java.util.HashMap;
    >
    > public class Demo<T> {
    > private Class<T> base;
    > private Cache cache;
    >
    > Demo(Class<T> b, Cache c) { base = b; cache = c; }
    >
    > Class<T> getBaseClass() { return base; }
    > T get(long id) { return cache.get(this, id); }
    > }
    >
    > class Cache {
    > private HashMap<Class<?>, HashMap<Long, ?>> maps
    > = new HashMap<Class<?>, HashMap<Long, ?>>();
    >
    > public <T> T get(Demo<T> demo, long id) {
    > return getMap(demo).get(id);
    > }
    >
    > public <T> void add(Demo<T> demo) {
    > maps.put(demo.getBaseClass(), new HashMap<Long, T>());
    > }
    >
    > private <T> HashMap<Long, T> getMap(Demo<T> demo) {
    > return maps.get(demo.getBaseClass()); // incompatible types
    > }
    > }


    Perhaps you should move the Map<Long, T> from Cache directly into Demo?

    public class Demo<T> {
    private Class<T> base;
    private Map<Long, T> cache;

    Demo(Class<T> b, Map<Long, T> c) { base = b; cache = c; }

    Class<T> getBaseClass() { return base; }
    T get(long id) { return cache.get(id); }
    }

    As a side note, I would make base and cache final.
    --
    Daniel Pitts' Tech Blog: <http://virtualinfinity.net/wordpress/>
     
    Daniel Pitts, Apr 27, 2010
    #5
  6. Daniel Pitts wrote:
    > On 4/26/2010 2:54 PM, Chris Riesbeck wrote:
    >> I've looked at the Java generics tutorial, Langer's FAQ, and similar
    >> online pages, but I'm still don't see what, if anything, I can do to
    >> make the last line (marked with the comment) compile, other than do a
    >> typecast and suppress the unchecked warning. Am I asking the impossible
    >> or missing the obvious?
    >>
    >> import java.util.HashMap;
    >>
    >> public class Demo<T> {
    >> private Class<T> base;
    >> private Cache cache;
    >>
    >> Demo(Class<T> b, Cache c) { base = b; cache = c; }
    >>
    >>
    >> class Cache {
    >> private HashMap<Class<?>, HashMap<Long, ?>> maps
    >> = new HashMap<Class<?>, HashMap<Long, ?>>();
    >>
    >>...
    >>
    >> private <T> HashMap<Long, T> getMap(Demo<T> demo) {
    >> return maps.get(demo.getBaseClass()); // incompatible types
    >> }
    >> }

    >
    > Perhaps you should move the Map<Long, T> from Cache directly into Demo?


    Which is actually where it started long ago, in the full set of classes,
    before Factory came along. And probably the best way to go after all.
    >
    > public class Demo<T> {
    > private Class<T> base;
    > private Map<Long, T> cache;
    >
    > Demo(Class<T> b, Map<Long, T> c) { base = b; cache = c; }
    >
    > Class<T> getBaseClass() { return base; }
    > T get(long id) { return cache.get(id); }
    > }
    >
    > As a side note, I would make base and cache final.


    I agree. It's a habit I still haven't gotten into, even though I const
    like crazy in C++.

    Thanks
     
    Chris Riesbeck, Apr 27, 2010
    #6
  7. markspace wrote:
    > Chris Riesbeck wrote:
    >> I've looked at the Java generics tutorial, Langer's FAQ, and similar
    >> online pages, but I'm still don't see what, if anything, I can do to
    >> make the last line (marked with the comment) compile, other than do a
    >> typecast and suppress the unchecked warning. Am I asking the
    >> impossible or missing the obvious?

    >
    >
    > Possibly. I've run into this before, that you basically can't use ? at
    > all for retrieving values of a type other than object, so you're going
    > to get a warning there no matter what you do.
    >
    > If I follow your logic correctly, I think you can add a type parameter
    > to Cache, and that will allow you to use T instead of ? as a type
    > parameter for the hash map. Take a gander at the following and see if
    > it matches what you want to do:
    >
    > package test;
    >
    > import java.util.HashMap;
    >
    > public class Demo<T> {
    > private Class<T> base;
    > private Cache<T> cache;


    Yes, if the Cache is in Demo, then I can do it. That was the original
    design. Time to chalk this up as a blind alley.

    Thanks, everyone, for the comments and problem solving.
     
    Chris Riesbeck, Apr 27, 2010
    #7
  8. Chris Riesbeck

    markspace Guest

    Chris Riesbeck wrote:
    >
    > Yes, if the Cache is in Demo, then I can do it.



    Just a note, in case you missed it: I didn't put the Cache inside of
    Demo, all I did was add a type parameter to Cache.


    > That was the original
    > design. Time to chalk this up as a blind alley.



    I think, given what you've shown us, you either have to remove the T
    type information from the return types in Cache (if you don't have a
    type, how can you guarantee that two different method calls actually
    correlate in their type? That's why the ? is messing you up), or you
    have to parameterize Cache, as I did, so the compiler can check your work.

    Also, I didn't modify any other code. Your program appears to me to be
    correct, so you could add a SupperssWarnings to the return type. But it
    might be better not to: There's always maintenance to consider, and
    keeping that SupperssWarnings valid through many code revisions,
    possibly not done by you, might not be easy or even possible.
     
    markspace, Apr 27, 2010
    #8
  9. Chris Riesbeck

    Lew Guest

    Daniel Pitts wrote:
    >> As a side note, I would make base and cache final.


    Chris Riesbeck wrote:
    > I agree. It's a habit I still haven't gotten into, even though I const
    > like crazy in C++.


    The semantics of Java's 'final' differ from C++'s 'const' somewhat, as with so
    many things that are similar between the languages but not quite the same.

    --
    Lew
     
    Lew, Apr 27, 2010
    #9
  10. markspace wrote:
    > Chris Riesbeck wrote:
    >>
    >> Yes, if the Cache is in Demo, then I can do it.

    >
    >
    > Just a note, in case you missed it: I didn't put the Cache inside of
    > Demo, all I did was add a type parameter to Cache.


    I did mis-read that.

    > I think, given what you've shown us, you either have to remove the T
    > type information from the return types in Cache (if you don't have a
    > type, how can you guarantee that two different method calls actually
    > correlate in their type?


    I don't follow the "don't have a type" part here. The correlation I was
    trying to capture was

    T get(Demo<T>, long)

    using an underlying Map(Demo<T>, Map<long, T>). That seems to me to be
    well-defined, just not definable in Java.

    > Also, I didn't modify any other code. Your program appears to me to be
    > correct, so you could add a SupperssWarnings to the return type. But it
    > might be better not to: There's always maintenance to consider, and
    > keeping that SupperssWarnings valid through many code revisions,
    > possibly not done by you, might not be easy or even possible.


    Yes. I try to keep all SuppressWarnings limited to those cases forced by
    old libraries or corner cases in Java that have no alternative. In this
    case, in the larger design, there's another approach that doesn't need
    to suppress unchecked warnings, so I'll stick with that.

    Thanks
     
    Chris Riesbeck, Apr 27, 2010
    #10
  11. Chris Riesbeck

    Lew Guest

    Chris Riesbeck wrote:
    > I don't follow the "don't have a type" part here. The correlation I was
    > trying to capture was
    >
    >     T get(Demo<T>, long)
    >
    > using an underlying Map(Demo<T>, Map<long, T>). That seems to me to be
    > well-defined, just not definable in Java.
    >


    What do you mean, not definable? That's exactly how you define it,
    what you wrote just there, modulo the typos.

    class Registry <T>
    {
    private final Map <Demo <T>, Map <Long, T>> demoMaps =
    new HashMap <Demo <T>, Map <Long, T>> ();

    ...
    }

    --
    Lew
     
    Lew, Apr 27, 2010
    #11
  12. Chris Riesbeck

    markspace Guest

    Chris Riesbeck wrote:

    > I don't follow the "don't have a type" part here. The correlation I was
    > trying to capture was
    >
    > T get(Demo<T>, long)
    >
    > using an underlying Map(Demo<T>, Map<long, T>). That seems to me to be
    > well-defined, just not definable in Java.



    What I was referring to was the actual type used in the program. Cache
    doesn't have a type (parameter) and so the hash map doesn't either.
    Thus, Java says "I don't have a type to check here" when you try to
    return a value.

    private HashMap<Class<?>, HashMap<Long, ?>> maps
    = new HashMap<Class<?>, HashMap<Long, ?>>();

    The ? says to me "I have no type." YMMV.

    In your design, you have a type, yes, but you need to tell the compiler.
     
    markspace, Apr 27, 2010
    #12
  13. Lew wrote:
    > Chris Riesbeck wrote:
    >> I don't follow the "don't have a type" part here. The correlation I was
    >> trying to capture was
    >>
    >> T get(Demo<T>, long)
    >>
    >> using an underlying Map(Demo<T>, Map<long, T>). That seems to me to be
    >> well-defined, just not definable in Java.
    >>

    >
    > What do you mean, not definable? That's exactly how you define it,
    > what you wrote just there, modulo the typos.
    >
    > class Registry <T>
    > {
    > private final Map <Demo <T>, Map <Long, T>> demoMaps =
    > new HashMap <Demo <T>, Map <Long, T>> ();
    >
    > ...
    > }
    >
    > --
    > Lew


    That defines a Map of Maps of one type T. I.e., you can make one
    Registry where an instance of Demo<Book> retrieves a Map of type <Long,
    Book>, and another Registry where a key of type Demo<Author> retrieves a
    Map of type <Long, Author>.

    But you can't define a single Registry where a Demo<Book> retrieves a
    Map<Long, Book> and Demo<Author> retrieves a Map<Long, Author>.
     
    Chris Riesbeck, Apr 27, 2010
    #13
  14. Chris Riesbeck

    Lew Guest

    Chris Riesbeck wrote:
    >>> I don't follow the "don't have a type" part here. The correlation I was
    >>> trying to capture was
    >>>
    >>>     T get(Demo<T>, long)
    >>>
    >>> using an underlying Map(Demo<T>, Map<long, T>). That seems to me to be
    >>> well-defined, just not definable in Java.

    >


    Lew wrote:
    >> What do you mean, not definable?  That's exactly how you define it,
    >> what you wrote just there, modulo the typos.
    >>
    >> class Registry <T>
    >> {
    >>  private final Map <Demo <T>, Map <Long, T>> demoMaps =
    >>    new HashMap <Demo <T>, Map <Long, T>> ();
    >>
    >>  ...
    >> }

    >


    >> --
    >> Lew

    >


    Don't quote sigs.

    Chris Riesbeck wrote:
    > That defines a Map of Maps of one type T. I.e., you can make one
    > Registry where an instance of Demo<Book> retrieves a Map of type <Long,
    > Book>, and another Registry where a key of type Demo<Author> retrieves a
    > Map of type <Long, Author>.
    >
    > But you can't define a single Registry where a Demo<Book> retrieves a
    > Map<Long, Book> and Demo<Author> retrieves a Map<Long, Author>.
    >


    That isn't what you asked for in the post to which I replied.

    --
    Lew
    don't quote sigs
     
    Lew, Apr 27, 2010
    #14
  15. Chris Riesbeck

    Daniel Pitts Guest

    On 4/27/2010 3:33 AM, Lew wrote:
    > Daniel Pitts wrote:
    >>> As a side note, I would make base and cache final.

    >
    > Chris Riesbeck wrote:
    >> I agree. It's a habit I still haven't gotten into, even though I const
    >> like crazy in C++.

    >
    > The semantics of Java's 'final' differ from C++'s 'const' somewhat, as
    > with so many things that are similar between the languages but not quite
    > the same.
    >

    Yes, I miss C++ "const", actually. I hated it when I was first learning
    C++, because it stopped me from doing things I thought I should be able
    to do (but were actually bad to do).

    --
    Daniel Pitts' Tech Blog: <http://virtualinfinity.net/wordpress/>
     
    Daniel Pitts, Apr 27, 2010
    #15
  16. Chris Riesbeck

    Daniel Pitts Guest

    On 4/27/2010 7:39 AM, Lew wrote:
    > Chris Riesbeck wrote:
    >> I don't follow the "don't have a type" part here. The correlation I was
    >> trying to capture was
    >>
    >> T get(Demo<T>, long)
    >>
    >> using an underlying Map(Demo<T>, Map<long, T>). That seems to me to be
    >> well-defined, just not definable in Java.
    >>

    >
    > What do you mean, not definable? That's exactly how you define it,
    > what you wrote just there, modulo the typos.
    >
    > class Registry<T>
    > {
    > private final Map<Demo<T>, Map<Long, T>> demoMaps =
    > new HashMap<Demo<T>, Map<Long, T>> ();
    >
    > ...
    > }

    Lew, the problem is "T" is different for every key of the map.

    map.put(String.class, new Map<Long, String>());
    map.put(Foo.class, new Map<Long, Foo>());

    There is no definition for Map<Class<...>, ...> which will fit the above
    usecases.

    One will need to carefully ensure the key matches the value, and cast
    appropriately, or not use a java.util.Map.

    --
    Daniel Pitts' Tech Blog: <http://virtualinfinity.net/wordpress/>
     
    Daniel Pitts, Apr 27, 2010
    #16
  17. Chris Riesbeck

    Daniel Pitts Guest

    On 4/27/2010 12:02 PM, Lew wrote:
    > Chris Riesbeck wrote:
    >>>> I don't follow the "don't have a type" part here. The correlation I was
    >>>> trying to capture was
    >>>>
    >>>> T get(Demo<T>, long)
    >>>>
    >>>> using an underlying Map(Demo<T>, Map<long, T>). That seems to me to be
    >>>> well-defined, just not definable in Java.

    >>

    >
    > Lew wrote:
    >>> What do you mean, not definable? That's exactly how you define it,
    >>> what you wrote just there, modulo the typos.
    >>>
    >>> class Registry<T>
    >>> {
    >>> private final Map<Demo<T>, Map<Long, T>> demoMaps =
    >>> new HashMap<Demo<T>, Map<Long, T>> ();
    >>>
    >>> ...
    >>> }

    >>

    >
    >>> --
    >>> Lew

    >>

    >
    > Don't quote sigs.
    >
    > Chris Riesbeck wrote:
    >> That defines a Map of Maps of one type T. I.e., you can make one
    >> Registry where an instance of Demo<Book> retrieves a Map of type<Long,
    >> Book>, and another Registry where a key of type Demo<Author> retrieves a
    >> Map of type<Long, Author>.
    >>
    >> But you can't define a single Registry where a Demo<Book> retrieves a
    >> Map<Long, Book> and Demo<Author> retrieves a Map<Long, Author>.
    >>

    >
    > That isn't what you asked for in the post to which I replied.

    It has been the problem that the OP has been trying to solve this entire
    thread.
    --
    Daniel Pitts' Tech Blog: <http://virtualinfinity.net/wordpress/>
     
    Daniel Pitts, Apr 27, 2010
    #17
  18. Chris Riesbeck

    Lew Guest

    Chris Riesbeck wrote:
    >>> That defines a Map of Maps of one type T. I.e., you can make one
    >>> Registry where an instance of Demo<Book> retrieves a Map of type<Long,
    >>> Book>, and another Registry where a key of type Demo<Author>
    >>> retrieves a
    >>> Map of type<Long, Author>.
    >>>
    >>> But you can't define a single Registry where a Demo<Book> retrieves a
    >>> Map<Long, Book> and Demo<Author> retrieves a Map<Long, Author>.


    Lew wrote:
    >> That isn't what you asked for in the post to which I replied.


    Daniel Pitts wrote:
    > It has been the problem that the OP has been trying to solve this entire
    > thread.


    In which he referred to wildcarded generics. In the post to which I
    responded, he seemed to have changed tack and remarked on what on the surface
    was a very specific point. While true, Daniel, your point is irrelevant.

    I believe that what the OP is doing is best served by finding some upper-bound
    type for the keys, at least, of the primary and secondary map layers, and
    using it for T, perhaps making the secondary value simply 'Object'. What
    they're trying to do is never going to be painless.

    Their desire to have the structures be typeless dooms them to conflict with
    the heart of generics. They will have to cast somewhere. Fortunately, they
    have a class token buried in all that goop, so they can at least hide the
    'catch (ClassCastException ex)' blocks down in the depths and throw only
    runtime exceptions. They'll need to Javadoc the hell out of the structures so
    that everyone knows that everything has to match the class token.

    As I finished typing this I see your other post, Daniel, where you made many
    of these points as well.

    --
    Lew
     
    Lew, Apr 28, 2010
    #18
  19. On 27-04-2010 15:17, Daniel Pitts wrote:
    > On 4/27/2010 3:33 AM, Lew wrote:
    >> Daniel Pitts wrote:
    >>>> As a side note, I would make base and cache final.

    >>
    >> Chris Riesbeck wrote:
    >>> I agree. It's a habit I still haven't gotten into, even though I const
    >>> like crazy in C++.

    >>
    >> The semantics of Java's 'final' differ from C++'s 'const' somewhat, as
    >> with so many things that are similar between the languages but not quite
    >> the same.

    >
    > Yes, I miss C++ "const", actually.


    +1

    Arne
     
    Arne Vajhøj, Apr 28, 2010
    #19
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Vince Darley
    Replies:
    4
    Views:
    4,470
    emilchacko
    Mar 2, 2010
  2. Replies:
    9
    Views:
    9,079
    John C. Bollinger
    May 2, 2005
  3. Murat Tasan
    Replies:
    1
    Views:
    8,076
    Chaitanya
    Feb 3, 2009
  4. Replies:
    2
    Views:
    448
  5. Rakesh
    Replies:
    10
    Views:
    12,216
    Mike Schilling
    Apr 8, 2008
Loading...

Share This Page