Path: csiph.com!x330-a1.tempe.blueboxinc.net!aioe.org!news.glorb.com!news-out.readnews.com!transit3.readnews.com!nx01.iad01.newshosting.com!newshosting.com!69.16.185.11.MISMATCH!npeer01.iad.highwinds-media.com!news.highwinds-media.com!feed-me.highwinds-media.com!spln!extra.newsguy.com!newsp.newsguy.com!news2 From: Michael Wojcik Newsgroups: comp.lang.java.programmer Subject: Re: boolean to int : was char to decimal Date: Mon, 09 May 2011 12:51:47 -0400 Organization: Micro Focus Lines: 42 Message-ID: References: <92ea64F3avU1@mid.individual.net> NNTP-Posting-Host: peccc0e814ad4517842746ad71de910401fd1f6f963e48b6d.newsdawg.com Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.8.1.23) Gecko/20090812 Thunderbird/2.0.0.23 Mnenhy/0.7.5.0 In-Reply-To: Xref: x330-a1.tempe.blueboxinc.net comp.lang.java.programmer:3867 Jeff Higgins wrote: > Yes, the nested if/else seems more clear in the above short example. And that shows why context is often important in a question of coding style. Your short example contained nothing that could justify the odd use of the switch statement. (And your Java version made even less sense, since it lost the C++ boolean-int conversions and symmetry.) > Now I wonder about the original author's motivation for > the use of switch statement. Code clarity, optimization, idiomatics? It looks to me like the C++ code may have been based on a C implementation of the algorithm, which would have been a bit simpler, since the int casts would have been unnecessary: switch (((d2 > curve_collinearity_epsilon) << 1) + (d3 > curve_collinearity_epsilon)) { I would have preferred binary-or there rather than addition, for clarity, but either works. And that, in turn, may have come from a description of the algorithm that treated the two tests for inner-point collinearity as a pair of bits (which is what this code is doing). Or it may have originally been implemented on a processor where {test, test, shift, add, computed-goto} was a faster sequence than {test, branch, test, branch}. Bezier-curve rendering is a plausible target for optimization. Or it may just be idiosyncrasy, particularly since this is a directly recursive implementation, which seems likely to dwarf any savings from fooling with the collinearity tests. It's unlikely a Java implementation will benefit detectably from anything other than the straightforward cascading-if-else design. Certainly that would be the one to start with, and only investigate alternatives if performance is a problem and profiling indicates this is a useful target for optimization. -- Michael Wojcik Micro Focus Rhetoric & Writing, Michigan State University