• 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.
Sign in to follow this  
Followers 0
Liuqahs15

[JAVA] What if I don't define the toString() method?

8 posts in this topic

im not sure about java, but in C# it would be printed like this:

 

(assume your example class is in the namespace MyObjects.Classes)

"to String = MyObjects.Classes.ExampleObject"

I assume something similar will happen, either way, it will not cause your program to crash or cause something to catch fire :)

Edited by Andy474
0

Share this post


Link to post
Share on other sites

If you don't define toString() it will be inherited from Object, that defines it as

getClass().getName() + '@' + Integer.toHexString(hashCode())

 

 

That's more along the lines of what I was looking for, thanks. By the way, is that Integer.toHexString(hashCode()) supposed to be the object's location in the heap?

 

Andy747 mentioned that it saves your program from crashing, but shouldn't that be a compile-time error anyway? If I'm trying to convert an object to a string, and toString() isn't explicitly overridden, doesn't that imply that I made a typo, and I don't actually want to convert the object itself into a string?

 

I'm sure there's a good reason why it does this, so that's why I'm asking.

Edited by Shaquil
0

Share this post


Link to post
Share on other sites
Why might toString be a good idea?

* Getting a textual representation of an object is a super common task. When logging debug information, for example.

* As every class derives from Object, there is a sensible place to define the toString method

* There is a sensible default which can be applied when the programmer doesn't specify their own toString

* Guaranteeing that all objects have some kind of string representation allows us to do things like printing a list of all objects in a collection without worrying about the specific object types involved
1

Share this post


Link to post
Share on other sites

I'm sure there's a good reason why it does this, so that's why I'm asking.

Because Java has string concatenation in a very special place, his heart, its a magical place where overrideable operators live and thrive! So it can do very special things in there, like the one you described.

0

Share this post


Link to post
Share on other sites

By the way, is that Integer.toHexString(hashCode()) supposed to be the object's location in the heap?

No. Hash codes are normally meant to be used in hash tables and things like that. The hashCode() defined by Object might very well use the memory address but it's not guaranteed, and many classes overrides this method to return the same hash code for all objects that compares equal.

As much as is reasonably practical, the hashCode method defined by class Object does return distinct integers for distinct objects. (This is typically implemented by converting the internal address of the object into an integer, but this implementation technique is not required by the JavaTM programming language.)

0

Share this post


Link to post
Share on other sites
A hash code should be immutable and deterministic so is unlikely to be based on memory address?
0

Share this post


Link to post
Share on other sites

A hash code should be immutable and deterministic so is unlikely to be based on memory address?

 

In the Sun/Oracle implementation, it's not actually the memory address used by default, but rather a value based on the object's reference (the reference value is not necessarily the same as the memory address, but could be). This is all implementation dependent and there are no guarantees that's what will be used. So it's not something to be relied on. What can be relied on is that a default hashcode implementation exists for every object that will allow the object to be stored in hashmaps and such.

0

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0