inheriting referencer/data class as template, should I optimize getData()?

[Fadey]

Sometimes coming up with a good title for topic seems harder than the problem
itself in the topic.

I have:

template<class T, class dataType>
class someContainer;

template<class T, class dataType>
class type_referencer {
	someContainer<T, dataType> *data;
	size_t pos;
public:
	T *getData() { return data->getData() + pos; }
};

template<class T>
class type_data {
	T *data;
public:
	T *getData() { return data; }
};

template<class T, class dataType>
class someContainer : public dataType { public:
	void someFunction() {
		T *data = this->getData();
		// do stuff with data...
	}
};

Lets assume I would wanna create a new string class where this string class
can be of two types. Actual string and a referencer string containing the position of string where its referencing.

	void someFunction() {
		T *data = this->getData();

*if class dataType is type_data then
instead of creating another variable and copying its value
from type_data::T *data to T *data, i want it to reference to type_data::T *data instead.

*if class dataType is type_referencer then I want
it to do what well, what it should do if no optimiziations are applied.
It would be pain to loop through (data+pos)[i] but efficient
when pointer*ptr=data+pos would loop through ptr[i] instead.

The question here is, do optimizer do it for me or do I have to implement
something special to my code to make this happen?

[dhayden]

if class dataType is type_data then instead of creating another variable and copying its value
from type_data::T *data to T *data, i want it to reference to type_data::T *data instead.

The problem with this approach is that you can't control when the referenced object will be destroyed. If the program destroys it while your string is still referring to it, then you have a dangling reference (or pointer).

You could create a separate substring class that works like you say and include a big warning in the documentation that says the underlying string must remain present for the substring to be valid.

[mbozzi]

std::string_view?

[Fadey]

The problem with this approach is that you can't control when the referenced object will be destroyed. If the program destroys it while your string is still referring to it, then you have a dangling reference (or pointer).

I mean same applies to any other pointer what can be pointing at destroyed object.
It's up to one, who uses them, to keep track on it.

[dhayden]

I mean same applies to any other pointer what can be pointing at destroyed object.
It's up to one, who uses them, to keep track on it.

That's true, but you're talking about a generic string object that might or might not point to another string. It seems like a big extra burden on the programmer to me.

[jonnin]

is this even remotely useful...

class 1 creates the thing via a pointer & new. (it did not already exist). It has a reference to that pointer for consistency.

classes 2 and 3 create a reference to that pointer via some convoluted communications / inheritance /whatever scheme.

if anyone deletes it, your good discipline sets the pointer to null immediately.
everyone always checks null before using. if threading, lock before delete and set null.

but now what. if class 1 deleted it, all 3 objects are 'dead'. You have to clean up somehow. They may safely do nothing now, but its memory and do nothing code and bloat every which way.