problem med if sæting

if ((point.x)==(400)&&(point.y)==(400)&&))
{
// todo
}

if ((point.x==400)&&(point.y==400))
{
// todo
}

if(point.x == 400 && point.y == 400)
{
  //TODO
}

har løst det    if (((point.x==400)&(point.y==400)))

hehe 3 forskellige løsninger  hvilken mon er bedst en af jeres eller min ?

jelzin har skrevet lige lovligt hurtigt, så der er et par typo'er.

min og kemos løsning er ens, bortset fra at jeg har puttet
ekstra parenteser omkring d e2 expressions der AND'es - det
syne sjeg er pænt.

Du har brugt binær AND i.s.f. logisk AND, hvilket jeg nok ikke
ville have brugt (og et sæt ekstra parenteser omkring det hele).
Men det virker.

arne_v  du har fortjent point,  det var en god forklaring og din løsning virker også

synes klart min er pænest :)

Spøg til side.... det er detaljer, men jeg synes det er skidt at bruge unødvendige parenteser. Dels fordi det bestemt ikke bliver mere overskueligt af det og dels fordi det indebærer et performance problem. Well.... i hvertfald i meget store programmer ;)

Glemte lige en detalje,

hvordan kan man gøre så det er point.x 400 +- 5 & point.y 400 +-5

kemo>

1)  ekstra parenteser i kilde-teksten betyder intet for runtime performance

2)  der er mnage som mener det er pænt altid at sætte parenteser, så
    udtrykkets evaluering er entyding for læseren uden at han/hun kender
    operator precedens

kaptajnkemo,  det var sgu egenlig også en god forklaring,  du må have en slat point til gode. performance er jo en vigtig detalje

Jeg tror du mener:

if ((point.x >= 395)&&(point.x <= 405)&&(point.y >= 395)&&(point.y <= 405))
{
// todo
}

ja det er lige præcis det, men den er ikke så variabel. jeg ville gerne
kunne erstatte 400 med en variable senere hen.
alla    m_pointx = 400
if point.x<=m_pointx osv.

Well, som arne siger så er der ikke tale om runtime performance problemer, men snarere compile tiden som sættes  i vejret. Men som sagt det er detaljer :)

Ang. pkt. 2: Jeg har svært ved at forholde mig til hvad mange gerne vil have. Jeg kan ikke forstå man har problemer med operator præcedens hvis man kan over skue sætninger som denne:
if((((x==1))&&((y==43)))||((z==34)))

men det må være folks eget valg.
Min holdning er at

if((x == 1 && y == 43)||(z==34))

til en hver tid er lettere at forstå, uanset hvad man kender til matematik.

if ((point.x >= (m_pointx-5))&&(point.x <= (m_pointx+5))&&(point.y >= (m_pointy-5))&&(point.y <= (m_pointy+5)))
{
// todo
}

if((x == 1 && y == 43)||(z==34))

forudsætter at folk ved at i C/C++ har == højere precedens end && !

[og det er ikke tilfældet i alle programmerings-sprog]

Hvis man derimod skriver:

if(((x == 1) && (y == 43))||(z==34))

kan man klare sig med en almen forståelse for parenteser.

if((((x==1))&&((y==43)))||((z==34)))

indeholder en del overflødige parenteser.

tja....
1. Med mindre jeg tager meget fejl er c/c++ & java de mest udbredte programmeringssprog, og ofte dem man starter med når man lærer programmering. Omvendt kan man vel antage at de sprog som ikke giver == højere præcedens (må indrømme jeg ikke ved hvilke) ikke er for nybegynderen, og de derfor udøves af de mere øvede programmører, som derfor godt kan overskue udtryk som i min løsning.

Min pointe er at nybegynderen har nemmere ved at forstå følgende udtryk (blå er en farve og rød er en farve) end de har ved det 2. udtryk ((blå er en farve) og (rød er en farve)). Men nok om det, det bliver vi nok ikke enige om, og det er vel i sidste ende en smagssag ;)

2. Mit eksempel med alle de overflødige parenteser var mere for at demonstrere at man ikke skal bruge overflødige tegn bare fordi man synes det ser godt ud (er pænt). Overdrivelse fremmer (nogle gange) forståelsen.

Det mest udbredte første sprog i et par årtier (Pascal) har faktisk
"AND" med højere precendes end "=".

Og når nu du nævner Java, så vil jeg dat lige citere fra SUN's
"Java Code Conventions":

#10.5 Miscellaneous Practices
#10.5.1 Parentheses
#It is generally a good idea to use parentheses liberally in expressions involving mixed operators
#to avoid operator precedence problems. Even if the operator precedence seems clear to you, it
#might not be to others—you shouldn’t assume that other programmers know precedence as
#well as you do.
#if (a == b && c == d) // AVOID!
#if ((a == b) && (c == d)) // USE