> > 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