New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Canvas class: hide std::list methods and do some cleanup #2364
Conversation
OK. Autotools in my machine build. |
Checking now. |
That's just a luck )
it faults on different files, so you need to restart it several times to reproduce. You can test it using this command:
I noticed that it loops in
and this is result:
It hangs because layer inside |
Quite interesting. Here a I could build Synfig Studio, open it and even load some files... :) |
36609d7
to
f359753
Compare
std classes are not supposed to be derived: their methods are not virtual. Methods created here are required for building.
Although not used in current code, we may need it.
Only and the special null layer if it still does not exist (Like in constructor call)
and fix its documentation
f359753
to
103d04d
Compare
Sorry - I was rebasing to master and accidentally included an additional commit. I'll force push it again to fix it. |
103d04d
to
8b2453d
Compare
done |
Merged. Thank you! |
Although
Canvas
itself is (argh) astd::list
of layers, it must always have a forced last list element: a null layer.As a consequence, it must
override
somestd::list
methods to assure a programmer doesn't access or remove this special layer: likesize()
andend()
.However, std containers are not supposed to be derived as they don't have virtual methods. A misplaced cast (like passing a Canvas as argument to a function that accepts
std::list
as parameter) may broken the list.As original code was written way before C++11, some methods were added to
std::list
(and more may will be added). A distracted programmer could use those new methods and break the special behavior of this derivedstd::list
. Example:push_back()
with different signatures of the original - and they do exist now on C++11: current implementation only overrides one.Therefore, it is best to just hide this ancestral class by making this inheritance
private
and make it available to programmer only via wrapped or customized methods.