Hi,
just to make clear, if it wasn't yet obvious:
Joerg Barfurth wrote:
So one could argue, fixing the warning does not necessarily fix the
problem, so we can remove the warning anyway.
Right. The warning (with warnings=errors) forces us to use a workaround,
which may even have a negative impact on the design (and thus
maintainability). And this workaround avoids one potentially risky
practice by using an equally risky one which happens to be not warned
about.
Agreed.
The one thing that the warning does, it that it makes you think about
this risk when you encounter it. But once you have become accustomed to
simply use the workaround design from the outset, that wears off
although the problem still lingers.
Agreed as well.
If yes, do so.
If no, disable the warning locally.
I find this ugly. And if we go this we we should look for a way to use a
platform independent, readable way to disable it inline with the code
(e.g. a SAFE_USE_OF_THIS_IN_CTOR_BEGIN macro) instead of sprinkling
platform-specific stuff all over the code (or makefiles).
If it is really (like Yarsten wrote) about 99% of occurrences, this
indeed is no solution.
So I agree, it may be more useful to disable the warning.
I'd however like to establish a rule that classes/functions taking a
pointer to (possibly) not fully constructed classes have a comment that
explicitely allows that - assuming that everywhere else it is a bug.
Nikolai
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
