Klammerparenteser i programmering....

används till arrays i JavaScript, kan inte c/c++

Precis som TheMrjonte skriver kan de användas för arrayer. Om arrayOfNames är en array med namn kan du tex. använda arrayOfNames[2] för att komma åt tredje elementet i arrayen.

I C/C++ används de som offset för pekare. Jag är dåligt insatt i de språken så kan tyvärr inte ge mer information.

Minns inte riktigt just nu, och har ingen möjlighet att testa det på några timmar, men jag har för mig att du ska kunna göra saker som:

int value = 100;
char lastChar = (char)value[3];

Som sagt är jag inte helt hundra på det, jag kan lika gärna ha drömt det hela.

Det jag menar isåfall är att du använder [] för offsets i minnet

Skickades från m.sweclockers.com

Detta kommer inte att fungera. Att använda [] som offset fungerar bara ifall variabeln är en array eller pekare. Vad är det egentligen du försökte åstadkomma med den där kodsnutten?

Okej.. Nä, tänkte bara på att en int är 4 bytes, så att man kunde plocka ut värdet på en av dom bytesen.

Sen förväntar jag mig inte att det jag skrev skulle fungera till punkt och prickar. Det var bara nått jag kastade ihop på mobilen.

Skickades från m.sweclockers.com

Så långt som jag lärt mig så är det bara arrayer man använder dem i, finns säkert något mer sammanhang.

Det enda problemet är väl egentligen ett parantesfel. Det hade funkat att skriva så om du hade skrivit ((char)value)[3].

asd[3] är samma sak som *(asd+3) där asd är av typen int* / int[], vilket helt riktigt påpekat av Teknocide är en pekaroffset.
observera att 3[asd] fungerar också tack vare kommutativitet.
Edit:
Tänk också på att det är vanligt att overloada operatorn för datastrukturer och då gäller andra saker.

Rekommenderad läsning som tar upp en del av ämnet:
http://www.cplusplus.com/doc/tutorial/pointers/ (under rubriken "Pointers and arrays")

Det går inte eftersom value inte är en array eller pekare. Det kommer att generera ett kompilatorfel, i alla fall på gcc. Men ifall den hade lyckats tolka value som en pekare, så hade den ju gjort om intens värde till en char (och möjligen tappat information), och sedan försökt komma åt minnet på adressen: värdet av den trunkerade int:en plus en offset på 3 * storleken av en char. 100 + 3 * sizeof(char) = 103 (om en char är 1 byte).

Om man vill komma åt "sista" (LSB) byten i en int, får man maska bort det ointressanta, eller möjligen använda sig av en union (dock inte lika pålitligt eftersom man kan få olika värden beroende på vilken endianness maskinen man använder har).

hehe jo det har du rätt i. Hade inte riktigt alla hästar hemma när jag skrev det. Korrekt isf borde väl vara ((char*)&value)[3]. Testade det också och det funkade fint. Bra att du påpekade det iaf

Jo det där borde fungera på en big endian maskin, men jag hade nog avrättat den personen som skrev sådan kod ;-)

Här står det som arrayer på Svenska.

http://www.blinkenlights.se/articles...rguide/part13/

Sen har du ju

http://www.youtube.com/watch?v=DYZxs...f=list_related
http://www.youtube.com/watch?v=7Fn8e...feature=relmfu

Finns säkert mer advancerade saker dom andvänds till, jag har inte en aning iaf. Är nybörjare som dig. ^^

Fast nu är det ju enligt C-standarden strict aliasing violation att referera till samma minnesadress från olika perkartyper på det där sättet så korrekt C-kod är det inte. Sen att det kan råka fungera ändå ibland är en annan femma.

Char är ett undantag, en char-pekare får alltid vara ett alias till vilken typ some helst (dock bara åt ena hållet).

Betyder detta att man aldrig får typecasta en pekare till annat än char*? Gäller det samma för att man inte får typecasta en struct{ float a,b,c; }* till en float*? Det beror inte på endianess tex och ger ett definerat resultat så långt jag ser. Vad jag har fått ut från min snabba googling på ämnet är att det är anledningen till att det är otillåtet.