Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 07 Jun 2012
Offline Last Active May 16 2014 03:06 PM

Posts I've Made

In Topic: Opinion needed: returning values without null checks everywhere

13 May 2014 - 04:56 PM

If the only way that client code can call with invalid keys, sanitize that input in a central place before passing it on to the rest of the program. Sounds like after that input has been checked, it would be a program fault if an invalid key was supplied, so then you can handle that with exceptions and return references to your data.


Sticking to pointers and checking null everywhere because there may have been an invalid key supplied at the command line seems wrong to me.



So while you'll probably still need some way of checking that the colleciton contains the key->value mapping, you only need to do it once when the key is received from the user.


Speaking in terms of a generic collection object, a return value of NULL from your function value* getThing(const key&); ) could mean that the key is mapped onto NULL or that the key is not in the map. You've already mentioned that keys will not be mapped onto null values, so in this instance a return value of NULL can only mean that the key is not in the collection. However will that always be the case? Are you intending to re-use the collection? Also someone updating the code in the future may not immediatly appreciate that a return value of NULL can only be generated when the key isn't mapped. Therefore, while NULL checks would work, I think adding explicit 'exists' checks could make your code easier to read and make the collection class more re-usable.


Both of your suggestions look like fine choices.


Another option you might want to consider, (although I'd still go with the 'bool exists(const key&)' suggestion) is to have your collection return a default object when the key isn't stored. The object would be an instance of a default class, extending the class of the values stored in the collection, but stubbing out all procedures so that they do nothing and all functions so that they return neutral values. Then the rest of your code can process the default object as if a key-value map was found, removing the need for any 'exists' or 'is NULL' checks. (The NULL Object pattern, from Robert Martin's book 'Agile Softwaree Development: Principles, Patterns and Practices')

In Topic: How to access to methods in a private constructor class

01 March 2014 - 09:35 AM

Just to add to dr01d3k4's explanation, static members are class members and therefore accessed through the class, non-static members are object (instance) members and are accessed via an object / instance.

In Topic: Arrays of class objects in Java

01 March 2014 - 09:27 AM

Or an alternative would be to create the instances of Appointment when you create DayPlanner, e.g.

public class Planner {
    Appointment[] DayPlanner = new Appointment[] {new Appointment(), new Appointment(), new Appointment()};

DayPlanner is an array with 3 elements.

In Topic: List<MyParentClass>

05 December 2013 - 04:58 PM

Would this work?


class BasicComponent<T extends GroupIcon>


     List<T> icon;



class ItemGroup : BasicComponent<ItemIcon>


     icon.Add(new ItemIcon(seed));



class MonsterGroup : BasicComponent<MonsterIcon>


     icon.Add(new MonsterIcon(seed));


In Topic: [C++/SFML] ECS - How to deal with the entities?

02 October 2013 - 01:50 PM

As you separated the components already from the entities, I think it would get simpler if you dont put all components belonging to one entity into one array, but put all components of a single component-type into an array and if you try to not put all that lowlevel array handling inside that single manager class.


This is the approach I'm currently using and it's working fine at the moment, although I cannot comment on performance as the game I'm making is pretty simple. I've created a 'ComponentCollection' class which abstracts the syncing of the two vectors away from my higher level classes. Here are some of the method/function signatures included in the public interface:

	 * Associates the UID with the component.
	 * The component can only be added if:
	 * <ul>
	 * <li> The UID has not already been added </li>
	 * <li> If a UID with the same index is currently mapped to a component, then this
	 *      new UID will be mapped to the new component (overwriting the old mapping) only if
	 *      the salt in the new UID is greater than the salt in the currently mapped UID. </li> 
	 * </ul>
	 * @throws NullPointerException if gameObjectID or component are null.
	 * @param gameObjectID		UID of game object.
	 * @param component			component to be mapped to the UID. Cannot be null.
	 * @return True if successfully added, false otherwise
	public boolean add(UID gameObjectID, ComponentType component);

	 * Gets the component mapped to the game object UID passed in.
	 * @throws IllegalArgumentException if there is no component mapped to the UID (including if there is a
	 * 			component mapped, but the component's UID has a different salt.
	 * @throws NullPointerException if gameObjectID is null.
	 * @param gameObjectID		UID to lookup.
	 * @return component mapped to UID
	public ComponentType get(UID gameObjectID);

	 * Removes the mapping of UID to component for the UID gameObjectID
	 * @param gameObjectID		UID for which the mapping is to be removed
	 * @throws NullPointerException if gameObjectID is null.
	 * @return	True if component mapping was removed, False otherwise.
	public boolean remove(UID gameObjectID);

UID is a wrapper class containing your 'CID' and 'index'.