serializeAttributes() const, whether const?

[etcaptor]

serializeAttributes are defined like const function in Irrlicht 1.4
In general the most function that gets parameters in Irr 1.4. are already "const".
Well, good style but it's very restrictive, because it's not possible any changes toward another member from our derivate class when some attribute reaches desired value.
And suggest that similar class member is not marked only for reading" like these attributes"
So, I think that this is disadvantage.

[hybrid]

I did not get the full sense of your post (try it with other words maybe), but the reason why serialize *must* be const is that we have to keep the state of the objects unchanged during serialization. You wouldn't get a properly serialized scene otherwise: If serialize could change the state, you would start with state A, change to A' during serialization and finish with state A''. The 'snapshot' you just got is a blend of A, A', and A'' (which does not exist at all at any point in time), and you would lose the chance to continue with your app at the same point where you started serialization. So you will have to work around this problem (use mutables if nothing else works).

[Ico]

Maybe a local member variable "bChangedSinceLastExport" that isn't serialized - would be the only logical reason to not make it const that I can think of right now.

[bitplane]

bChangedSinceLastExport would be a good excuse for a mutable though

[etcaptor]

Maybe a local member variable "bChangedSinceLastExport" that isn't serialized - would be the only logical reason to not make it const that I can think of right now.

Hehe OnEndSerilization() event

@Hybrid, thanks for reply and for explanation. Seems you have been understood my question. Or maybe I'm too lazy to redefine all related functions in my project like const
Yet I prefer this function without restrictions. By default my compiler generates only warning message when modifying of some class member is bypassed with assigned function. With another compilers it's a error message.

And any example from Niko's IrrKlangSceneNode

Code: Select all

	ISceneNode::serializeAttributes(out, options);
	const char** soundNames = 0;

	if ( SoundEngine && options && ( options->Flags & io::EARWF_FOR_EDITOR ) )
	{
		// show a list of all loaded sound files in editor

		int count = SoundEngine->getSoundSourceCount();
		soundNames = new const char*[count+3];

		for (int i=0; i<count; ++i)
			soundNames[i] = SoundEngine->getSoundSource(i)->getName();

		soundNames[count] = "";
		soundNames[count+1] = "<select>"; // editor file selector
		soundNames[count+2] = 0;

		out->addEnum("SoundFileName", SoundFileName.c_str(), soundNames);

		delete [] soundNames; 
	}

Well, when local variables are used within const function there are no problems. For more advanced similar tasks using of local variables instead class members is not good idea. More sometime these shared class members must be changed from another noconst functions. So, in this case I don't want to write many code lines in body of const function or to use global variables instead class members.

[Dorth]

const is probably the best viral infection you can give code. It both makes you say ahead of time what should or shouldn't modify things, what will or will not be modified, force you to stick to it (to an extend, at least ^^ ) and propagate by sheer necessity. I can only reccomand you inflict it to you own project too ^^

[etcaptor]

Yes, I already lost whole day with it. Now my project is "const married" .
Yet I hope that some day serializeAttributes() function will be noconst like Irr 1.31 implementation