It is
complaining about 'r' being declared twice below. This looks more like a
reassignment than a redeclaration to me. How do we properly fix it?. If all we
care about here is 'r' having function scope, can't I
just get rid of
the 'Range* ' typecast following the else { ? Or do I have
to change 'r' to 'not_r' following the else?
Getting rid of the second 'Range* ' was the trick. Verify and then push patch :)
I'm aware that these patches have been labeled as C++ "semantics" changes.
Yet we are not providing any usability test plans. Verifying a patch allows building is
only half the recovery.
Although I am learning, much of these C++ patching discussions remain over my head. No
different than speaking in a foreign language. :)
Somebody should propose a usability test plan to ensure the functional intent of the
patched code still works.
If indeed a patch is purely semantics, then I would like to see a list of project members
who have been deemed qualified to render those decisions. Then I can push patches with
ease-of-mind.
If not purely semantic, a usability test might be nothing more than verifying a specific
window appears, a mouse-click still functions, etc.
My point is a regularly raised topic in Trinity discussions is increased bugginess. A
basic quality control plan is needed with our patching efforts. That does not mean every
patch needs a 10-page test plan. Many don't.
Yes, I need to be pointed to articles that a C++ noob like me can read that explains these
semantic differences. I suspect most of these semantic differences are learned by
experience and seldom introduced upon in formal teaching.
Darrell
