reduced size of `ValueFlow::Value`
Still need to clean up the macros. And I would like to get the TODOs addressed as well.
The constant for the padding also needs to be adjusted so takes the default alignment into account and we do not overpad. I was also thinking about a macro.
This is mostly clean now and reduces the size from 168 bytes to 136 bytes.
But the debugpath code is broken. And I still want to cleanup the redundancies in the config.h macros.
This is mostly clean now and reduces the size from 168 bytes to 136 bytes.
But the
debugpathcode is broken. And I still want to cleanup the redundancies in theconfig.hmacros.
I backed out the debugpath changes for now. The size is now only reduced from 168 bytes to 152 bytes.
I backed out the debugpath changes for now. The size is now only reduced from 168 bytes to 152 bytes.
Does it make sense to hide debugpath behind some build flag? If somebody needs it then he can build cppcheck with that. Or maybe leave it out in the release builds?
Does it make sense to hide
debugpathbehind some build flag? If somebody needs it then he can build cppcheck with that. Or maybe leave it out in the release builds?
That is included in the --debug output so changing that will potentially open a can of worms.
In the future, I would like to introduce dynamic attributes as some of these attributes are only used for some rare occasions, and it doesnt make sense to always have a static field for such attributes:
struct Attributes {
template<class A>
const auto& get() const
{
return read<A>().get();
}
template<class A, class T>
void set(T x) const
{
return read<A>().set(x);
}
template<class A>
const A& read() const
{
return static_cast<const A*>(attr.at(key<A>()).get());
}
template<class A>
A& write()
{
return static_cast<A*>(attr.at(key<A>()).get());
}
private:
std::unordered_map<std::type_index, ValuePtr<Attribute>> attrs;
template<class A>
static std::type_index key()
{
return std::type_index(typeid(A));
}
};
We could probably make this copy-on-write as well to make the copies cheaper.
In the future, I would like to introduce dynamic attributes as some of these attributes are only used for some rare occasions, and it doesnt make sense to always have a static field for such attributes:
That would be something to consider. If I find the time (haha) I will give it a look.