2

I am sometimes (randomly) getting incorrect initialization of values, which makes me think I'm using memory uninitialized somewhere. My main data structure is:

template <class state>
class learnedStateData {
public:
    learnedStateData() :gCost(DBL_MAX), hCost(0), isDead(false) {}
    state theState;
    double gCost;
    double hCost;
    bool isDead;
};

This is being stored in a STL hash_map. Any thoughts on how I might get uninitialized data (besides the theState) from this data structure?

Let me clarify: I don't want my values to be uninitialized, but they appear to be randomly at times.

Nathan S.
  • 5,244
  • 3
  • 45
  • 55
  • 2
    Besides theState you have properly initialized every member of your class. Hence not initializing theState could be the source of the problem. – Prasoon Saurav Oct 01 '10 at 06:39
  • 1
    If `state` has a default constructor, it's automatically called, so no need to explicitly call it. However, if there's no default constructor, that's another story. – Jim Buck Oct 01 '10 at 07:05
  • 1
    *how I might get uninitialized data (besides the theState)*... By this which **data** you mean is uninitialized? Besides `theState`, other data shown in the `class` seems to be initialized properly... – liaK Oct 01 '10 at 07:11
  • Thanks for the pointers. It ends up I was accidentally passing a reference to an object in the hash_map. When the hash_map was automatically resized, my data got scrambled. – Nathan S. Oct 01 '10 at 18:46

3 Answers3

4

The implementation is perfectly sound... your issue must be elsewhere. You could use a tool like valgrind to check for invalid memory accesses, uninitialised reads etc.. You could add some assertions to try to narrow down the point where the state is corrupted. If you provide a hash algorithm, make sure it returns the same value consistently for the same key value. Check you don't somehow modify the key of an object while it's inside the container. You might swap in a std::map<> and see if the problem disappears.

Tony Delroy
  • 102,968
  • 15
  • 177
  • 252
  • It ends up the implementation is sound, as you say. The problem was that I had a reference to an instance in the hash_map that was being randomly reset when the hash_map changed sizes. – Nathan S. Oct 01 '10 at 18:44
  • 1
    Glad to hear you found the bug. Cheers. – Tony Delroy Oct 04 '10 at 01:31
3

You have not initialized theState inside the constructor

Use Value Initialization

template <class state>
class learnedStateData {
public:
    learnedStateData() :theState(),gCost(DBL_MAX), hCost(), isDead() {}
    state theState;        ^                         ^          ^
    double gCost;          |_________________________|__________|
    double hCost;                            |
    bool isDead;                        Value Initialized
};
Community
  • 1
  • 1
Prasoon Saurav
  • 91,295
  • 49
  • 239
  • 345
  • 4
    How is that relevant? The question goes out of its way to say theState isn't the problem, and value initialisation is no more reliable than the explicit values provided in the question. – Tony Delroy Oct 01 '10 at 07:03
  • @Tony : How isn't value initialization reliable? How can someone automagically decide what exactly the problem is just by looking at the provided code? Can you? The only problem I could see was that `theState` wasn't initialized. Furthermore how could he say so confidently that the uninitialized object/variable was not causing any problem? – Prasoon Saurav Oct 01 '10 at 07:05
  • 3
    @Prasoon: I'm not saying value initialisation isn't reliable, I'm asking why you think it would be _more_ reliable. My opinion is that the data members are being initialised correctly already, and providing an alternative way to do the same thing won't help. The issue is elsewhere in the object lifetime. He may be confident theState isn't relevant because one or more of the other fields are being corrupted, and theState isn't relevant to its/their processing. – Tony Delroy Oct 01 '10 at 07:15
  • 1
    Oh, and I'm not automagically saying where the problem is - I'm saying there's no point providing an alternative where the problem's clearly not. If we can't form a relevant answer - we need to say so and ask for more details, not go off on an aside. – Tony Delroy Oct 01 '10 at 07:17
  • 2
    @Tony : `My opinion is that the data members are being initialised correctly already`. You are overlooking the fact that `state` may be a primitive type (depending on the template argument) without any default constructor. Are you sure that `theState` would be properly initialized in that case?. Well I'm not. – Prasoon Saurav Oct 01 '10 at 08:20
  • 1
    @Prasoon: I'm not overlooking that, I'm accepting the information given in the question that the problems seen are in the other fields. Surely you understand my point by now? – Tony Delroy Oct 01 '10 at 08:38
3

Is it possible that you've got an invalid iterator or pointer to a learnedStateData<T> somewhere?

Doug
  • 8,780
  • 2
  • 27
  • 37