Hi Jabier, I'm not 100% sure, but you may consider to always use floating point numbers for the type of calculation you are doing, unless you are sure you want integer calculation. So then it becomes:

(4./3.) * (sqrt(2.) - 1.)

regards, Johan

On 1-7-2014 9:41, Jabiertxo Arraiza Cenoz wrote:

Thanks Nathan. I just read it in a book but dont remeber when necessary :(. And thanks for the operator precedence tip.

Cheers, Jabier.

El mar, 01-07-2014 a las 07:59 +1000, Nathan Hurst escribió:

...

On Mon, Jun 30, 2014 at 11:56:15PM +0200, Jabiertxo Arraiza Cenoz wrote:

...

Hi to all.

I try this in my debian calculator: "4 / 3 * (sqrt(2) - 1)" and return 0,55228475 in C++ return 0.414214

I want 0,55228475. Where i lost? I have the cmath header

4/3 = 1 because the type of both arguments is int. 4.0/3 fixes your problem. I would put (4./3) * sqrt() because operator precedence for divide is not always clear.

njh

---

Open source business process management suite built on Java and Eclipse Turn processes into business applications with Bonita BPM Community Edition Quickly connect people, data, and systems into organized workflows Winner of BOSSIE, CODIE, OW2 and Gartner awards http://p.sf.net/sfu/Bonitasoft

---

Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel

Interesting problem. Concerning readability of floating point numbers, for me personally "4.0" is better than just "4.". Is this just personal preference or is there any benefit of just "4."?

A quick search for "float" on inkscape coding style page didn't show anything.

On 2-7-2014 18:01, Jon A. Cruz wrote:

On Wed, Jul 2, 2014, at 07:06 AM, Christoffer Holmstedt wrote:

...

Interesting problem. Concerning readability of floating point numbers, for me personally "4.0" is better than just "4.". Is this just personal preference or is there any benefit of just "4."? A quick search for "float" on inkscape coding style page didn't show anything.

I was thinking exactly the same thing. Sure, dropping the '0' leaves for fewer characters to type, but it makes the decimal much harder to spot. Legibility helps with maintenance and with spotting bugs, so it's generally a good idea to make things more legible. Among other things, think of decimal calculations in a parameter list "3 * 4., 5 *3". When next to a comma it will really hide on some systems. Much harder for the human eye to catch in casual scanning. That goes along with parenthesis. Technically they are often not required... however making them explicit helps the poor humans who have to read the code. It's such a good practice that when Java was being designed, that suggestion (add parenthesis even when not required by the language) was actually included in the Java language spec itself. And think... that was for a language that does not have all the ambiguity that C/C++ has.

Not too long ago, I started changing small bits of code to not rely on operator precedence. We could enable "-Wparentheses" for this. It also nicely catches some other issues like: if (x = 0) {

} forcing one to write if ((x = 0)) {

} if you really meant the assignment.

cheers, Johan

On 2-7-2014 22:50, Liam White wrote:

On Wed, Jul 2, 2014 at 4:45 PM, Johan Engelen <jbc.engelen@...2592... mailto:jbc.engelen@...2592...> wrote:

We could enable "-Wparentheses" for this. It also nicely catches some
other issues like:
if (x = 0) {

}
forcing one to write
if ((x = 0)) {

}
if you really meant the assignment.

So if I write

if (SPItem* item = dynamic_cast<SPItem*>(obj)) { // do something with item }

Would it flag that too?

I think so. You would need double parentheses. I am a little confused, because -Wparentheses is enabled with -Wall, which we already use... The assignment thing is clang-only it seems. But I thought -Wparentheses also complains about operator precedence, but perhaps only with combinations of || and &&...

- Johan

On Wed, Jul 2, 2014, at 01:50 PM, Liam White wrote:

So if I write

if (SPItem* item = dynamic_cast<SPItem*>(obj)) { // do something with item }

I was thinking that should be flagged as it is actually an abuse of the condition.

You have two things collapsed to a single line, and at the least it will interfere with debugging. On the other hand, when broken apart, consider the break-point possibilities:

1 SPItem *item = dynamic_cast<SPItem*>(obj);

2 if (item) {

3 ...

n }

You can now set a breakpoint on line one or on line two. It might seem less useful, but if one combines a condition on a breakpoint at line 2 you can stop only if it is null or only if it not null, etc. However you do lose a bit of safety by leaving that pointer around to possibly use after it is no longer valid. Fixing that gives

{

SPItem *item = dynamic_cast<SPItem*>(obj);

if (item) {

...

}

}

Extra parenthesis can be added at any time to limit scope of any variables. Quite handy, that. However a more logical restructuring could also be. There are other options too, including for loops

for (SPItem *item = dynamic_cast<SPItem*>(obj); item; item = NULL) {

}

That would address the assignment issue, and keep it to a single line. I'll have to ponder if that is better enough. It is definitely not to the level of abusing the 'for' statement that the for(EVER) idiom is. :-)

But the bigger question would be why use such code to begin with? It is a very C style approach. "Let's just store everything as void* and cast back as needed on the fly". A more C++ centric approach would not have a raw obj pointer, but something more specific. I'd suggest looking at the structure of the surrounding code to see if that can be fixed here and the dynamic_cast<> be avoided completely.

-- Jon A. Cruz jon@...18...