Hi all,

I've noticed/ had a bug when I used a std::string to store a variable in a struct, which was gone when I used a char array [255].

Below the 2 pieces of code, 1st being ok/preditable, 2nd not working.

struct DX11_VS_INPUT_ELEMENTDESC
{
	
	DX11_VS_INPUT_ELEMENTDESC(D3D11_INPUT_ELEMENT_DESC pInputDesc)
	{
		memset(SemanticName, 0, 255); 
		strcpy_s(SemanticName, pInputDesc.SemanticName);

		ElementDesc = pInputDesc;
		ElementDesc.SemanticName = nullptr;
	}

	D3D11_INPUT_ELEMENT_DESC	ElementDesc;
	char		 				SemanticName[255];
};

With the std::string:

struct DX11_VS_INPUT_ELEMENTDESC
{
	
	DX11_VS_INPUT_ELEMENTDESC(D3D11_INPUT_ELEMENT_DESC pInputDesc)
	{
		SemanticName = pInputDesc.SemanticName;

		ElementDesc = pInputDesc;
		ElementDesc.SemanticName = nullptr;
	}

	D3D11_INPUT_ELEMENT_DESC	ElementDesc;
	std::string					SemanticName;
};

At some point I create a checksum based on a std::vector of those struct's objects.

Results are unpredictable.

I think it has something to do with the fact that pInputDesc.SemanticName is a LPCSTR (no string by value).

Do you know how this can be explained and/or how this will work OK with a std::string?

Any input is appreciated.

Thanks. I understand now, basically .c_str() returns the array of characters (instead of the pointer to it).

I'll have to figure out if/ how I'll do that, because the variable is part of a struct, and the struct is hashed as a whole (void*). In that case it might be a good idea too just store the char array instead of a std::string.

Sorry, I'm actually hashing the DX11_VS_INPUT_ELEMENTDESC struct object.

Which contains the D3D11 inputElementDesc + a char array (or string :)) for the semanticName. In the D3D11 elementDesc I assign nullptr to the semanticname (LPCSTR) because of the exact reason above.

There's an interesting new design technique in which data and operations on that data are grouped together to minimize coupling between concepts. This makes reasoning about interactions between components much much simpler and enabled a finer-grained verification strategy, and in turns reduces the overall cost of development and especially maintenance by often an order of magnitude.

In you case, instead of designing a system so every component knew about the internals of every other component at the lowest possible level, you would design it so a component would expose only a small interface and hid its internals. That would mean your DX11_VS_INPUT_ELEMENTDESC struct would have an associated function that returns its own hashsum, and no generic function would have to have and in-depth low-level knowledge of how data is stored in the aggregate.

A modern language like C++ actually provides built-in support for this technique. By using the class synonym for the struct keyword you're indicating to readers your intention to encapsulate functionality and data, and by making the hashsum calculation a member function, you can indeed encapsulate such low-level details as memory allocation strategies and not have them leak out and affect the internal design of completely unrelated modules in your software.

This technique was the result of decades of practical development in the field and academic research, and it had a great impact on productivity in industry in general. Of course, if you're fixated on avoiding such techniques, there are alternatives (such as separate hashsum functions for different structs) that still let you minimize development and maintenance costs, or alternatively you might be keep to maximize your costs going forward, in which case feel free to make things increase in complexity combinatorially as you continue development.

But I would suggest that trying to had-craft data structures at a low level, and having to rely on the knowledge of the internals of standard library class implementations in general, is going to bite you in the bum swiftly, frequently, and hard.