assigning to static map<>s in classes

Today I've been trying to seperate a class so all the function definitions are in the cpp file, like they're supposed to be, with only the class definition in the header file. Don't complain that I should have started off that way: I admit I'm a retard.

I've run into a problem with the map I'm using and I think I've isolated it down to a scoping problem, maybe. I have a map defined in the public part of CLASS (ie in the header file):

Code:

static std::map<string,string> params;

Then I've declared it again in the CLASS.cpp file as:

Code:

std::map<string, string>	CLASS::params;

When I try to assign to it in one of the class functions it fails. I've made sure there is memory for it and such. Just to make it obvious what I'm doing:

Code:

void	CLASS::save_param( char *_nvpair )
{
	params["bob"] = "bill";								// assign to the map<>
	std::cout<< ((params.size())?"yea":"ney");
}

Simple, eh?
I know that the assign fails because params.size() returns 0.

The actual point the code fails at is apparently line 988 in xtree:

Code:

_Nodeptr _Lbound(const key_type& _Keyval) const
	{	// find leftmost node not less than _Keyval
	_Nodeptr _Pnode = _Root();  // <- this line
	...

I thought I sorted this problem before, but splitting up the code is giving me flashbacks. Any help would be welcomed with a crushing (but friendly) bear hug.

weird, try

Code:

   params.insert(make_pair("bob", "bill"));
   cout << params.size() << endl;

see what output that gives you.

You say you know it fails because the size stays at 0, so what happens at line 988 in xtree that makes you think it is "failing" there. Is it crashing, asserting, returning null, what?

The code posted looks just fine. The problem is probably in code you have not posted. Make sure you didn't accidentally define any other maps or variables named params, and make sure the code you think is executing is actually executing.

If you could provide a simple, compilable example that demonstrates the problem, it would help as well.

[Daved: xtree is much bigger than me. I don't understand it one bit...]
OK... I've made a 'test' example (it's good practice, something I don't have. Yay). It compiles, but doesn't work. I'm sure this isn't a particularly obscure problem - if it is, then I'm approaching it in the wrong way maybe?

minicgi.h

Code:

#include <iostream>
#include <map>
#include <string>

class CLASS
{
public:
	static std::map<std::string, std::string> params;
	void	save_param( char *_nvpair );
};

minicgi.cpp

Code:

#include "minicgi.h"

std::map<std::string, std::string> CLASS::params;


void	CLASS::save_param( char *_nvpair )
{
	char *n = _nvpair;
	char *v = strchr( _nvpair, '=' );	// this points just before 'value' begins

	if( v[0] != 0x00 ){		
		v[0] = 0x00;			// seperates n from v
		++v;				// now v points to 'value'
		params[n] = v;			// assign to the map<>
	}
}

test_main.cpp

Code:

#include "minicgi.h"

int main(void)
{
	CLASS c;

	c.save_param("bill=bob");
	std::cout<< c.params["bill"] << std::endl;
	return 0;
}

Incidentally I found that the line: v[0] = 0x00 causes an error here. That is confusing, since in the full class that I'm using, that exact same line works. Also, wierdly, the map seems to work on this example (at least if you set the n/v manually, which isn't any help), but not on the other.

Either way, that code worked perfectly - consistently - before I split the class into the two files. My utter noobishness in such matters is baffling.

>> xtree is much bigger than me. I don't understand it one bit...
You are the one who said it was "failing" at that line of code. I just want to know what made you say that. Did you just open the file and randomly pick a line? Of course not. You had a reason for mentioning that line of code in your post, so I was hoping that you could clarify that reason.

Why are you using strchr? Why not just use a C++ string and parse that? Once you learn the syntax, it would be much less error prone. Code that works "perfectly" one time and then strangely stops working is usually due to undefined behavior because the code wasn't correct originally.

By the way, if strchr fails, then v is null, so checking v[0] against 0x00 is bad, you should check if (v != 0 ).

You are the one who said it was "failing" at that line of code. I just want to know what made you say that.

It was the MS just-in-time debugger that told me: it pointed secretly to the line mentioned. Looking on google didn't help, since the odd result that was actually relevant was usually just brushed over, without being solved.

As for using std::strings, I could, but that wouldn't solve the problem. I think it would actually involve another line or two also, making it look messier. There's something up with what I have atm though. *shrugs*

Point taken about comparing v. I actually had it like that at one point, but changed it for some reason. Two things I'm not sure about though: first, since v is declared already, won't it being assigned NULL make v[0] = v = NULL? Second, is if(v!= 0) the same as if(v) - I only ask since v is a char*, so maybe it isn't converted to an int in the second comparison?

Thanks for the input.

if (v != 0) is the same as if (v) which is the same as if (v != NULL) which is the same as if (v != 0x00).

v[0] = v = NULL is bad because you are accessing v[0] when v is null. If v is null you should not check v[0]. That is not the same thing. It will often lead to a crash.

I think it is certainly possible that using std::strings might solve the problem. It is up to you to decide what to do, I just think they are harder to make simple errors (like the one above) with.

>> It was the MS just-in-time debugger that told me: it pointed secretly to the line mentioned
When did it point to that line? On an access violation? an ASSERT? an exception? So far all I know is that it "failed" on that line. The debugger information helps a little, it makes me think that some memory error has occurred that corrupted the map or its data, but more information on what you mean by "failed" would help.

Remember, you said you know it failed because the size was zero, so I was assuming that it didn't crash (otherwise how would it finish the size() call). If it did crash, what part of your code was being executed at that time in the call stack?