Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 25 Mar 2005
Offline Last Active Dec 08 2012 01:12 AM

Topics I've Started

Is C++ too complex?

30 November 2012 - 01:42 AM

I always want to improve my C++ knowledge and this time around this means finding out what parts of C++ aren't any good, so I thought I'd field a question to the experts: what parts of the c++ language are too complex to the point they interfere with writing good code and should be avoided as much as possible. Should I always use the stdio and not iostream for example, dynamically allocated memory in classes vs putting it in structs. What's the debate on what parts of c++ improve code, and the other parts that are over complicated and are damaging to code standards.

Template Partial Specialization of Templated Type With Pointers

11 October 2012 - 02:18 AM

Ok guys, this code works and I don't know why, some one enlighten me: (and yes in this case I need it to work this way and I find it strange that it does, I was expecting to craft a more complicated solution to this problem)

// This is all just test code

// ZE templates
template <typename T>
struct Info {
  static void Print();
template <typename T>
struct Info<MyTemplate<T>>  {
  static void Print();
template <typename T>
void Info<T>::Print() {
  std::cout << typeid( T ).name() << std::endl;
template <typename T>
void Info<MyTemplate<T>>::Print() {
  std::cout << typeid(T).name() << std::endl;
  std::cout << typeid( MyTemplate<T> ).name() << std::endl;

// ZE usage

// Output:
// int
// Output:
// int
// class MyTemplate<int>
// Output:  class MyTemplate<int*>*

I needed to get that pointer reference for MyTemplate<int>* and the non pointer reference for MyTemplate<int> as well to manage this stuff and amazingly enough:

template <typename T> void Info< MyTemplate<T> >

Gives me a MyTemplate<T>* when MyTemplate<T>* is asked for, when I use MyTemplate<T> in the template code. Sort of hard to understand that since it's a bit of a linguistic mess, but I'm pretty sure you guys get the point. It seems the T of the template argument is lost in the second case, and I don't know why that is either. Full disclosure; I am running on the belief that this is functioning by typeid working, as of yet I haven't tested whether or not the lack of the T in the second MyTemplate means that the MyTemplate<T>* is unusable.

Only just realised after posting that the MyTemplate<int>* case is not being handled by the partially specialized function. So it's not working, mod delete.

basically the end result is that there will have to be two partial specializations for pointer & non pointer type.

Allocation, Initialization & Deallocation of Objects

09 October 2012 - 03:00 AM

I'm building a reflection system, I've got the parser, I've got the reflection system to turn the parsed data into objects in game, I've got binary reading/writing for serialization ( that can even withstand a few code changes so it's not rigid and doesn't require rebuilding binaries every time the code is changed ) I've got a fair bit of stuff going in it. Now I come to what is probably the most important aspect to me as the programmer who's going to use it ( other important aspects such as the syntax for the language being simple enough for designers/artists)

(Note: For the time being let's think architecture design, leave any DO or DO NOT, allocate in constructor/initialization function as a secondary tip, not the main article because I don't really want to go into that argument here. I'm not even going to say where I side on that. And I don't want such considerations to be an interference in the design of my memory/initialization solution, I just want the best solution either or. So truce? )

What I want to explore is how to allocate the memory for objects, delete them effectively, as well as handle the initialization of the data for the object. There are a few ways of doing this and I'm more than happy to code a couple out to see if they're feasible before I stick with one. The techniques I know of are:

(A): Using specific reflection struct, as input to constructor for object

struct ReflectionData {
class ReflectionUser {
ReflectionUser( ReflectionData&amp; );

Created with:

template <typename Type, typename Reflect>
void Constructor( void* object, void* reflect ) {
   if( reflect ) {
	  // inline constructor - reflection
	  new (object) Type( *(Reflect*)reflect );
   } else {
	  // inline constructor - no reflection
	  new (object) Type;

This would pretty much be using new/delete with the factory handling the delete.

(B): By initializing the data members directly from reflection, no parsing of reflection struct. This has the advantage that the reflection system can be used for live edit without any live-edit specific support for standard types. Types that have custom behaviours, such as entities that have components will need a general purpose function for live edit to be created, but it would be just 1 function for all components.

class MyClass {
   int x, y, z;

  // Call Init from the factory once the object has had it's members loaded to load in textures etc
   void Init();

template <typename T>
void Construct( void* object, DataObject&amp; data ) {
   new (object) T;
   for( data ) {
	   // Get the field name
	   // find the field in T
	   // Get the Type of the field
	   // Use the type to construct the object
	   // Paraphased code:
	   Construct< field_type >( object + field_offset, data[field_index] );

void MyClass::Init() {
   // Load texture or something.  

One thing I can do with this techique to load texture resources is that any object that has resources, owns a texture object, and when the texture object is created via the reflection system, it's constructor adds it to a list of textures that need to be loaded to a resource manager. Simple enough.

That's the two ways I know of doing this, if you have any others I would like to hear them because I don't feel comfortable continuing when I only have 2 options to select from; I find myself ignorant of other possible techniques.

As to Deletion:

Using new/delete means I can use the new keyword in any construction of objects and the deletion of objects is handled by whatever class owns them. This is simple enough. It is possible to delete the objects through the reflection manager, with something such as:

// Definition for a field
struct Field {
   size_t offset;
   bool is_pointer;

struct Type {
   Field *fields;

template <typename T>
void Destroy( void * object ) {
  // Get the object Type
  Type* t  = get type from database
  for all fields
	 if field is pointer
	   Destroy< field type >( object + field offset )

  free( object )

Any one who of any other / or best use strategies to achieve this?


I am a bit slow but I figured out I can use a template as well as template specialization to handle any objects that require a resolve step, such as asset loading, as most objects created are not going to need to load assets and any assets that are loaded will be from a pretty specific set of items, such as:
- Textures
- Audio
So all I need to do is create a templated Resource type

template <typename T>
class Resource {
  Resource( T&amp; data );
  shared_ptr<T> resource;

And then partially specialize the reflection system's constructor function:

template <typename T>
void TypeHandler<Resource<T>> (void *object, Data&amp; data ) {
   // Construct type T from Data
   T tobj;
   for ( data as field ) {
        tobj[field] = data[field];

   // Now create the resource from that T obj value
   new (object) Resource<T>( data );  

And in the constructor for resource:

template <typename T> Resource<T>::Resource( T&amp; data ) {
   resource = manager.Find( data );

As well as setting up some templates for the different resource managers etc, this should pretty much achieve what I'm after as far as designing the 'resolve' step in my project. Will still keep checking to see if anyone has any examples or different methods they've used in the past.

Multi-Core Technology

29 September 2012 - 08:05 PM

There doesn't appear to be a hardware board and this is pretty much a hardware question related to the business sides of the hardware but it relates to me via lockless programming.

I've been really interested in lockless programming for a long time now, haven't actually tried it because I haven't had a reason to use it yet, but today I learnt about the parallella project and I reckon it's a pretty cool idea to try and create an open source hardware framework for parallel processing but I worry that the technological solutions that allow programmers to get the most out of multi-core processors may be licensed. Such as the PowerPC's perticular read/write ordering that allow a thread to read the value that was written while the write op is on it's way to the cache (if I remember the talk correctly). As to proprietary barriers take 3d printing for example which is something that has opened up thanks partly to some patents expiring.

So what I'm interested to know is does anyone know about the business side to parallel computing, are we in a situation where proprietary technology is the only technology that is going to give programmers the best capabilities for squeezing the most out of the platforms or what is the future of this technology. Is buying myself one of these parallela boards going to be something where I can play around with some ARM&RISC's locklessly just so I can feel awesome. Are we going to have the next 20+ years of intel/amd ruling the parallel processor market because they got on the ground early and solved a bunch of early technological problems.

EDIT: Just realised this could fit in the business thread but I don't know if anyone other than programmers would know this.

Component-Entity or Entity Module

05 August 2012 - 11:33 PM

I'm working on building utilities (explicitly not an engine) for a game project I'm working on. One of those utilities is getting C++ and scripting working together so that the scripting language can be used to set properties of C++ classes, and also to react to changes in those properties that come from the game and other general scripting things.

But there are constraints to the design. The scripting component is for logic, not functionality and for custom behaviour modification by cleverly dropping some reactions to events in and not building the base functionality. And I know exactly how the scripting will fit into an entity and entity-manager module; but I'm still grasping at straws with how the scripting will work with components. My thoughts on this are so far:

Entity & Script Module:
Entity has properties & functions
These properties & functions are exported to the script.
This allows me to do everything I need to do in terms of controlling game logic, scripting levels, tweaking properties & iterating on custom mechanics in real time.

I think this is a safe model, because I know that the script will be able to do it's job with minimal programming support. I know that sounds like a pipe dream but it's all to do with what the scope of the script is, which isn't much, it can handle it.

However I can only guarantee that this script can do it's job for this particular project, which is simple in scope, but I can't guarantee that this entire module will fit the requirements of future projects and thus become an inflexible trashware that was short sighted in it's purpose and usage.

Entity, Component & Script Module:
Entity has components.
Entity has script.
The components are set for an entity by the script. So the components an entity uses are data defined. These would be components like weapons, movement, health, AI, physics.
The components communicate amongst themselves but they essentially replace the properties and functions that were exported to the script as before. The components now reporting to and receiving their tips from the script.

I can see the benefit in this, It does make the design constraints of code a little tighter, so better code. I can see that it allows me to do basically exactly the same thing as number 1. How ever by my estimation supporting the mechanics that can be customised will be more c++ code in the game. On the flip side of code conservation, I'm very sure that a reflection parser and builder for an ecs module, that's what I'm calling it now, will be much easier to write and support because of the constraints of components operating with the scripting.

The thing that I grasp, is that a lot of experienced programmers despise the entity model because they've wished for something in the past. I'm asking for the advice, which of these two options represents the least risk to the project, measured against long term benefit.

PS: I'm still on the fence with this, but I am leaning towards #2 because of the future benefit, and because I can call it an E.C.S. module, Full Metal Panic! fan? Anyone?

UPDATE: I'm researching as much of the component object model as possible so that I can learn enough about it to make a decision between it and the entity model. If anybody has some source code detailing the use of a component model, and I mean some component classes, entity classes, and data representation that links them together. I'd really love to see it.