Forum Stats

  • 3,871,973 Users
  • 2,266,360 Discussions
  • 7,911,017 Comments

Discussions

readability

2»

Comments

  • 843793
    843793 Member Posts: 41,732 Green Ribbon
    The closest thing to Java's import in C++ is
    using, not typedef. You can use the
    using directive to import types or entire
    namespaces into the current namespace. It operates
    nearly identically to Java's import statement.

    Typedef is different in that it creates a new
    name for an existing type. Java doesn't have any
    feature of any similarity.
    But the closest thing to C++'s typedef in java is import.

    typedef gives a new local name to an existing entity.

    import locally shortens the name of an external entity.

    Logically, import for generics would not allow you to specify a new name but instead would establish defaults for the type parameters.

    If you want a full new name it can be done with a class that inherits from the generic class, but this has implications at runtime. If the class is final, JIT should reduce these to nearly nothing.

    A real typedef would ensure that the runtime cost would be zero -- and because of its local scope would be less prone to C++'s abuses.

    Darron
  • 843793
    843793 Member Posts: 41,732 Green Ribbon
    You make it sound as if you're arguing to change the semantics of import as opposed to introducing a new typedef construct. I don't think that makes any sense, because they're really two different beasts which serve different purposes - as I described above.

    As another example, another good way to use typedefs in C++ is as type parameters to templates.
    class my_traits {
      public:
      typedef char parameter_type;
      typedef int return_type;
    };
    template <typename Traits> 
      Traits::return_type foo( Traits::parameter_type param );
    Even though the use is different, there's nothing special about the typedef mechanism in this context - it's still the same. It's just being used to do more powerful things. I could easily see a typedef construct being used in Java to do similar things if the generics framework is improved.

    God bless,
    -Toby Reyelts
  • 843793
    843793 Member Posts: 41,732 Green Ribbon
    As I mentioned before, subclassing the generic type has polymorphism issues that I think are more serious than runtime performance.

    While sitting here trying to work out some kind of syntax, though, I may have figured out why the spec has such a seemingly obvious omission. One of the stated goals of all of the 1.5 enhancements is to be non-invasive to the JVM. The idea was to implement generics entirely in the compiler, if possible. It's easy to see how ArrayList<ArrayList<Float>> could be used to generate bytecode, but I can't see how an alias for that could also be generated. What I mean is, compilation wouldn't be a problem as long as you always compiled the source file that contained the typedef. But what if you were using a typedef from a third-party library, or even one declared in another class that was already compiled? The class file could not contain that kind of information without a revision to the VM spec. Does this seem correct?
  • 843793
    843793 Member Posts: 41,732 Green Ribbon
    Yes, typedefs would only be local to the class.

    God bless,
    -Toby Reyelts
  • 843793
    843793 Member Posts: 41,732 Green Ribbon
    Which would hardly be more useful than no typedef at all.
  • 843793
    843793 Member Posts: 41,732 Green Ribbon
    That's not strictly true. There exists gobs of C++ source code that uses typedefs only for renaming ease of use local to a function or class. In the case of C++ containers which have no common parent, typedefing a container is akin to declaring your ArrayList as a Collection.

    In any case, I agree that having non-local typedefs would be very useful, especially with a more powerful Generics mechanism.

    God bless,
    -Toby Reyelts

  • 843793
    843793 Member Posts: 41,732 Green Ribbon
    Ah, well, maybe in JDK 1.6....
This discussion has been closed.