• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.

Archived

This topic is now archived and is closed to further replies.

casper

[java] What does a template in C++ equivalent to in Java

13 posts in this topic

Hello all, I need to know what Java uses for templates because I definitely need that type of functionality. Thanks, Casper
0

Share this post


Link to post
Share on other sites
This isn''t exactly an answer to your question, but this may be useful. Everything in Java inherits from Object. This inheritance is implicit, and exists whether you tell it to explicitly or not.

Therefore, you can use some of the functionality for a template by using Object. All of the classes for storing information use this, ie Vector. You might want to look at java.util.Vector to see how you can effectively use Object.

This may not directly answer your question, but might get you on a useful track.

Thanks,
Shaun
0

Share this post


Link to post
Share on other sites
I wanted to add this caveat to what I just said. All of the basic types in java (ie float, double, int, boolean) do not inherit from Object. Rather there are wrappers that enclose them as objects (ie Float, Double, Int, etc).
0

Share this post


Link to post
Share on other sites
It would''ve been nice for you to explain what a template was, instead of assuming everyone knows c++. From what i gather reading posts about c++ templates are like interfaces. Tell me if that''s not true cuz i want to know what a c++ template is.
0

Share this post


Link to post
Share on other sites
No, Java doesn''t support template like behaviour yet. There was an article few months back in Dr.Dobb''s Journal about Generics (or something) that are going to be introduced to Java language specification at some point. But until that you will just have to either revert to the Object paradigm or do search & replace to make containers or algorithms for different types.

The "everything is inherited from Object" paradigm that sckime is talking doesn''t really cut it as a replacement for templates for several reasons:

1. There is no compile time type checking for the casts you need to perform when e.g. getting an element from java.util.Vector. This is a major consern if you are making a product and want to make the product as robust as possible before it even reaches testing as testing costs money and runtime type checking requires extensive testing.

2. You have to know what elements you are storing in the generic Object references. And as a consecuence from this it is really hard to efficiently store different types into same container that uses the Object paradigm. Sure you can use the instanceof operation, but that is slow, slow, slow. And it also adds more possible execution paths to the code which in turn adds more test cases to be tested.

3. Performing some operations with/to these Object objects is a pain as you will have to make a new interface or baseclass that introduces the operation to the class and then cast every stored object to the interface/baseclass.

4. Last, but not least (as we are talking about Java game development here) the extensive type casting needed in the Object paradigm approach is quite slow in Java. I once did a simple A* search tree implementation that tried to solve a simple 3x3 slide puzzle and got a HUGE (around 1.5 times) performance increase just by writing specialized containers (without using the java.util.Vector as a base class) for the few key objects that I needed to store.
0

Share this post


Link to post
Share on other sites
quote:
Original post by Jim_Ross

It would''ve been nice for you to explain what a template was, instead of assuming everyone knows c++. From what i gather reading posts about c++ templates are like interfaces. Tell me if that''s not true cuz i want to know what a c++ template is.


Nope, C++ template is not an interface. Template is, well it is a sort of a class template.

When you define a template class you can leave the handled datatype(s) open and then define it upon compiling. E.g. if I wanted to make a Vector template I would use a special tag (datatype) in the place of the datatype I wanted to handle and just define that a vector holds a datatype array and can add a datatype "objects" and get a datatype "object" from the array. Then when I want to have a vector for e.g. MyOwnClass objects I just construct the Vector template and tell the template that the datatype is going to be MyOwnClass. And when I compile the code the compiler creates a new Vector class definition from the template and replaces all references to datatype with MyOwnClass.

You can "emulate" this with Java by writing a file e.g. Vector.template and writing the code there using datatype as the "object" type you are going to handle. Then when you need a Vector in your app, you just copy the Vector.template to some other folder, rename it to e.g. VectorInt.java and search-replace every datatype word with int. And presto! You have a Vector capable of handling integers.

Actually you could write a small utility to do this for you, hmm... Smells like a small project idea...
0

Share this post


Link to post
Share on other sites
Templates are available on the Java platform. Just look at the Pizza compiler / the Kiev Language. I haven''t looked at the source code, hence I don''t know yet how it is implemented. Probably some kind of preprocessor.

===
David Teller
Editions Vigdor
http://www.vigdor.com
ddt@vigdor.com
David.Teller@ens-lyon.fr
http://www.ens-lyon.fr/~dtelle


Les Mots appartiennent a ceux qui savent s''en servir.
0

Share this post


Link to post
Share on other sites
Javanerd''s explanation of templates, although he states that they are not templates, sounds very much like they are similar to templates. Interfaces are agreements that all subclasses shall obey a certain standard, like a template for a class. It seems like making an Object interface, then subclassing it with the types that you need and typecasting should solve all your template problems.

On a side note, I don''t see why one would "need the ''functionality''" of dynamically typed data. I get that ''feature'' all the time in scripted languages like php. It is definately not needed, and in fact, it is a hinderance sometimes.
0

Share this post


Link to post
Share on other sites
Typecasting is quite as good as templates. Templating is a compile time effect, not a dynamic effect. Essentially to get the same kind of functionality out of java right now, you need to write a wrapper around a Object referencing data structure to handle the data passing properly. So you start maintaining at least two separate objeccts for one objects worth of functionality.

You still seem unclear on the concept of templates, so I will attempt to further clarify. (Forgive the syntax.)

Let's say I want a Stack class that I will only pit Sprite objects into. With C++ templates I would do something like:


template <class T> class Stack {
Push(T * element);
T * Pop();
T * Peek();
};

And declare like:
Stack<Sprite> sprite_stack;
Which would create an object that has Push(Sprite *) method, Sprite * Pop() method, etc.

In Java I'd do something like:

class Stack_impl {
Push(Object element);
Object Pop();
Object Push();
}

class SpriteStack {
Push(Sprite element);
Sprite Pop();
sprite Peek();
}

And then I'd have to either inherit or encapsulate SpriteStack from Sprite in order to use the Object bound Stack_impl class. This isn't too bad for just one pair, but you can see the extra annoyance it would be to maintain a SpriteStack and a PolygonStack and a SpriteStackStack vs. simply instantiating a Stack<Sprite>, Stack<Polygon>, Stack<Stack<Sprite>>.

This post editted due to severe html butchering.

Edited by - SiCrane on 3/13/00 12:24:05 PM
0

Share this post


Link to post
Share on other sites
quote:
Original post by SiCrane

Typecasting is quite as good as templates. Templating is a compile time effect, not a dynamic effect. Essentially to get the same kind of functionality out of java right now, you need to write a wrapper around a Object referencing data structure to handle the data passing properly. So you start maintaining at least two separate objeccts for one objects worth of functionality.

(some text snipped)

And then I'd have to either inherit or encapsulate SpriteStack from Sprite in order to use the Object bound Stack_impl class. This isn't too bad for just one pair, but you can see the extra annoyance it would be to maintain a SpriteStack and a PolygonStack and a SpriteStackStack vs. simply instantiating a Stack, Stack, Stack>.



I'll have to disagree with you on this. Runtime typecasting is not as good option as compile time type checking.

When you store something in e.g. java.util.Vector it will be stored and retreived as an Object reference. When you need to cast that to your own class (e.g. the Sprite object you used). You have to do

Sprite mySprite = (Sprite) mySpriteVector.firstElement();


And this is error prone. Of course you can catch the invalid cast exception, but in order to even get the exception you will have to have a test case for that particular situation. This takes us back to the "what you can test with compiler is less work when testing the system later on".

No, in your example case you can't inherit from the stack that uses objects. If you try:

class SpriteStack extends Stack_impl {
Push(Sprite element);
Sprite Pop();
sprite Peek();
}


The compiler will give you error that you can't override a method by changing the return type. Even if you could override it would still leave the Push( Object object ) method visible in the SpriteStack class and that would allow you to add objects of any type in to the stack.

You can encapsulate the Stack_impl inside SpriteStack but that (as you point out) requires writing a new class by hand for every type you want to handle. It also adds one more invokation for each call you make to the methods and as we are talking game programming here, that is bad news for the performance.

As you said "Templating is a compile time effect, not a dynamic effect" and that is its strength. The resulting code is typechecked on compile time and the resulting code is faster (as you don't need to do any type checking/casting on runtime). I'm quite eager to get the templates into Java standard. It really just requires a syntax to specify the template usage and a compiler specification on how it interpretes that syntax and generates code. No changes to the Java bytecode itself are needed.

But until that time, we just have to write those copy-paste containers for every object type by hand or use the inferior "everything is inherited from Object" paradigm.

Edited by - javanerd on 3/14/00 6:46:41 AM
0

Share this post


Link to post
Share on other sites
quote:
Original post by Jim_Ross
Javanerd''s explanation of templates, although he states that they are not templates, sounds very much like they are similar to templates. Interfaces are agreements that all subclasses shall obey a certain standard, like a template for a class. It seems like making an Object interface, then subclassing it with the types that you need and typecasting should solve all your template problems.

On a side note, I don''t see why one would "need the ''functionality''" of dynamically typed data.


Hmm? Templates are not templates eventhough they are templates? Well, I got your point though.

Templates are not like interfaces. Templates contain the IMPLEMENTATION of the class, but just leave the handled datatype to be specified at compile time.

Dynamically typed data? Templates are compile time, statically typed things. That would be handy in Java.
0

Share this post


Link to post
Share on other sites
Oops. The reason why my post may not have seemed very coherent was because I forgot to put the not in:
"Typecasting is quite as good as templates."
I meant to say:
"Typecasting is not quite as good as templates."
That''ll teach me to not proofread my posts.
0

Share this post


Link to post
Share on other sites
hmm, Templates are compile time?

I thought that an specialized instance of the template for each type you use it with, will be created in memory at run-time. Why would you want a version of the template for a type that youu never use it with?
0

Share this post


Link to post
Share on other sites
Object code is emitted for each different template type that is referenced in code. If you declare Stack<int> then a it''ll create Stack<int> object code. If you declare a Stack<char>, the compiler will create Stack<char> object code. It has to be compile time, C++ doesn''t support creation of functions as first class values. It''s possible, for example, to create run-time templated object in object extended Scheme only because it maintains lambda expressions as first class values.
0

Share this post


Link to post
Share on other sites