ProgrammeringsBaren! Småprat, om det du elsker!

[GeirGrusom]

Har et lite problem med å kompilere BASIC til C som kanskje noen har noen idéer om:

 

Function Foo(ByRef bar As Integer) As Integer
 bar = bar + 100
 Return bar * 2
End Function

Det som er problemet her, er om noen skriver:

 

Dim foobar As Integer = Foo(100)

 

Hvordan skal jeg kunne oversette det til C, uten å lage flere definisjoner på Foo?

 

Foreløpig blir det slik:

int32_t Foo(int32_t* var)
{
 *var = *var + 100;
 return *var * 2;
}

 

Men tar jeg ikke helt feil, så er ikke C veldig glad i følgende:

 

int32_t foobar = Foo(&100);

 

Så hvordan kan jeg egentlig gjøre det? Det jeg tenkte var å bare gjøre det til en feil å gi noe annet enn variabler til ByRef argumenter.

[Gjest Slettet+9871234]

* slik du bruker den i programsnutten er indirection / peker operatoren, mens & er adresse / referanse operatoren. Der er forskjell på kall ved verdi (by value) og kall ved referanse (by reference). Lett å gjøre feil her.

 

Lær deg grundig hvordan disse virker eksakt i ulike situasjoner ved å laste ned PDF versjonen av

 

http://en.wikipedia.org/wiki/The_C_Programming_Language

 

second edition og lese relevante avsnitt. Du kan jo søke i PDF dokumenter.

 

Er borte fra C og C++ nå, så jeg har ikke tid til å være mer spesifikk og siden djevelen er i detaljene vil jeg også være varsom med eksakte råd.

 

PDF versjonen er tilgjengelig på nettet om du har .pdf i søke strengen.

 

Alle som skal begynne med programmering bør studere den boken grundig å løse oppgavene: http://users.powernet.co.uk/eton/kandr2/index.html

Endret 5. oktober 2011 av Slettet+9871234

[GeirGrusom]

Kanskje utforme det på en annen måte (jeg lager en kompilator for BASIC -> C for de som ikke vet det)

Sett at jeg har følgende kode:

 

Function Foo(ByRef bar As Integer) As Integer
 bar *= 2;
 return bar + 2;
End Function

Dim FooValue = 200
Foobar1 = Foo(200)
Foobar2 = Foo(FooValue)

 

Hvor Foo blir oversatt til følgende C kode

int32_t Foo(int32_t* bar)
{
 *bar *= 2;
 return *bar + 2;
}

 

Spørsmålet er Hvordan kan jeg utforme de to funksjonskallene for Foo slik at de vil kompilere i C, uten å lage mer enn den ene definisjonen for Foo?

[tomsi42]

Så hvordan kan jeg egentlig gjøre det? Det jeg tenkte var å bare gjøre det til en feil å gi noe annet enn variabler til ByRef argumenter.

Strengt tatt er det en feil å gi noen annet enn variabler til ByRef argumenter.

 

Du kan oversette Foobar1 = Foo(200) med følgene:

 

int32_t xx200 = 32;
int32_t Foobar1 = Foo(&xx200);

[GeirGrusom]

Så hvordan kan jeg egentlig gjøre det? Det jeg tenkte var å bare gjøre det til en feil å gi noe annet enn variabler til ByRef argumenter.

Strengt tatt er det en feil å gi noen annet enn variabler til ByRef argumenter.

 

Du kan oversette Foobar1 = Foo(200) med følgene:

 

int32_t xx200 = 32;
int32_t Foobar1 = Foo(&xx200);

Det er jo alltids en mulighet. Takker!

[Gjest Slettet+9871234]

Men tar jeg ikke helt feil, så er ikke C veldig glad i følgende:

 

int32_t foobar = Foo(&100);

Hvor er minne adressen til 100?

 

Igjen anbefaler jeg deg å lese de relevante delene av "C Biblen".

Endret 5. oktober 2011 av Slettet+9871234

[Matsemann]

Har skrevet en del kode for å leke meg med forskjellige touch-typer på android. Det å dra på ting, holde fingeren nede, bevege den osv.

Noe som er litt pain, siden om man holder fingeren helt i ro, trigges ingen touch-events fra APIet. Samtidig er det umulig å sette ned en finger uten å trigge titalls move-events, som man da må filtrere ut osv.

 

Uansett, legger om all testkode til et mini-rammeverk, en slags touchprocessor, og etter litt klipp og lim endte jeg blant annet opp med denne snutten:

			if(inFling)
			return true;
		return false;

:!:

[ze5400]

Men tar jeg ikke helt feil, så er ikke C veldig glad i følgende:

 

int32_t foobar = Foo(&100);

Hvor er minne adressen til 100?

 

Igjen anbefaler jeg deg å lese de relevante delene av "C Biblen".

 

Det er ikke ofte jeg føler jeg har behov for å si noe, men dette er en av de gangene jeg virkelig må.

Etter å ha lest en del innlegg av deg oppfatter jeg deg som svært arrogant, rett og slett en bedreviter.

 

Nå som personangrepene er ute av veien ...

Henning kjenner utmerket godt til hvordan pekere fungerer, og også ByRef i VB, så hvordan det å slå opp i K&R (eller en annen C-bok) skal hjelpe ham er får du nesten utbrodere på. Det er da vitterlig ikke noe galt i å komme på forumet med en konkret problemstilling man man ønsker å løse på en elegant måte? Helst uten å få beskjed om å lese bok x, y eller z.

Om jeg ikke tar helt, ett hundre prosent feil, nå var "Men tar jeg ikke helt feil, så er ikke C veldig glad i følgende:" rett og slett en figure of speech, ikke et faktisk spørsmål.

 

ByRef i VB er ikke kresen, og den funksjonen han lister opp vil fungere helt fint i VB, så løsningen til Tomsi42 er vel det mest konstruktive som har kommet inn hittil.

 

Beklager at dette innlegget er helt unyttig, men jeg trengte rett og slett å si det.

</angryrant>

 

 

 

[Gjest Slettet+9871234]

Det er ikke ofte jeg føler jeg har behov for å si noe, men dette er en av de gangene jeg virkelig må.

Etter å ha lest en del innlegg av deg oppfatter jeg deg som svært arrogant, rett og slett en bedreviter.t.

Det var kun et spørsmål. Men du får jo mange poeng for ditt svar, så da er det vel godt nok for deg og andre.

 

Det kan også være svært tidseffektivt og lese hva originalkilden sier og repetere det fra tid til annen. Mange gode programmere (som jeg mener Henning er - sikkert mye bedre enn meg) har gått seg vill i (dinglende) pekere og referanser i C / C++.

 

Det var ikke ment som arroganse eller bedrevitende, men som et velment råd. Tolk det som du (dere) vil.

 

Hvis du er ute etter enighet og stryking med hårene er du kommet til feil person. Se deg om og hva det har ført til i den finanskrisen verden nå opplever.

 

Programmerer man i C, bør man etter min mening alltid ha K & R siste utgave for hånden, gjerne som PDF dokument.

 

Det er meget raskt å søke gjennom hele dokumentet på

 

pointer

 

pointer operator

 

address operator

 

indirection

 

pass by value

 

pass by reference

Endret 5. oktober 2011 av Slettet+9871234

[Gjest Slettet+9871234]

Det er ikke ofte jeg føler jeg har behov for å si noe, men dette er en av de gangene jeg virkelig må.

Da hadde det kanskje vært bedre at du tidde stilt i stedet for å prøve å skremme andre fra å si sin mening.

 

Det er for sent når atomanlegget gikk i luften eller et romskip styrtet i havet på grunn av en triviell programmeringsfeil. Jeg gjentar et av mine favoritt sitater:

 

"But after a while, most programmers realize that this means that a program is equipped with a safety net: many errors that programmers make when they construct programs are caught by this net before they lead to unpleasant effects. An example: A very expensive American space rocket crashed on its way to Venus a few years ago, because of an extremely trivial error in a FORTRAN program. A comma had been written as a point, and, as a consequence of that, the start of a special kind of repeat imperative was mistakenly read as an assignment imperative assigning a value to an undeclared variable. Had it been required to declare every variable in FORTRAN programs, the compiler would have discovered that the variable was undeclared and the error would have been caught much earlier than in the Atlantic Ocean."

Professor Bjørn Kirkerud (1989): "Object Oriented Programming With Simula". Addison Wesley Publishing Company ISBN 0 201 17574 6. Page 31-32.

Du kan lese en hel tråd her:

 

The camelot, the straw man and the faceless community.

 

Visste du forresten at du kan risikere å bli stilt for riksrett dersom du som medlem av den norske kongens råd unnlater å si din mening.

 

Nå er ikke dette forumet kongens råd og kravet til sikre programmer sikkert ikke all verden .

Endret 5. oktober 2011 av Slettet+9871234

[ze5400]

Dette er nettopp hva jeg snakker om. Relevansen i dine innlegg er ofte tvilsom.

Jeg ser ihvertfall ingen relevans mellom Hennings Basic->C oversetter og bugs relatert til verken kommafeil eller pekere.

 

Forøvrig er det nettopp slikt unit testing og inkrementell utvikling er ment for motvirke.

En annen ting er at sikkerhetskritiske systemer gjerne har trippelmodulær redundans, hvilket nærmest garanterer at feilen ligger i spesifikasjonene ved mishaps.

 

Ikke at det har mye å si mtp. Hennings søken etter løsning for sitt ByRef-problem ...

 

 

Forøvrig prøver jeg ikke å skremme noen fra å si sin mening, noe jeg håper fremgår klart fra mitt opprinnelige innlegg.

Alt jeg gjør er å uttrykke min mening, på lik linje som du uttrykker din.

[x871kx6167ss7]

Så hvordan kan jeg egentlig gjøre det? Det jeg tenkte var å bare gjøre det til en feil å gi noe annet enn variabler til ByRef argumenter.

Strengt tatt er det en feil å gi noen annet enn variabler til ByRef argumenter.

 

Du kan oversette Foobar1 = Foo(200) med følgene:

 

int32_t xx200 = 32;
int32_t Foobar1 = Foo(&xx200);

 

Regner med det er en skrivefeil, og at du mener:

int32_t xx200 = 200;
int32_t Foobar1 = Foo(&xx200);

 

Jeg hadde tenkt til å si det samme.

 

Jeg hadde også tenkt til å si at man kunne spare plass ved å lagre samme konstant bare ett sted i minne. Men det blir jo helt feil. Det er jo avgjørende at hver instans av konstanten får sin egen lokasjon. Men selv da føler jeg at man må være forsiktig mtp rekursjon og løkker.

[Gjest Slettet+9871234]

Dette er nettopp hva jeg snakker om. Relevansen i dine innlegg er ofte tvilsom.

Jeg ser ihvertfall ingen relevans mellom Hennings Basic->C oversetter og bugs relatert til verken kommafeil eller pekere.

 

Forøvrig er det nettopp slikt unit testing og inkrementell utvikling er ment for motvirke.

En annen ting er at sikkerhetskritiske systemer gjerne har trippelmodulær redundans, hvilket nærmest garanterer at feilen ligger i spesifikasjonene ved mishaps.

 

Ikke at det har mye å si mtp. Hennings søken etter løsning for sitt ByRef-problem ...

 

 

Forøvrig prøver jeg ikke å skremme noen fra å si sin mening, noe jeg håper fremgår klart fra mitt opprinnelige innlegg.

Alt jeg gjør er å uttrykke min mening, på lik linje som du uttrykker din.

Muligens kommer vi fra ulik bakgrunn, men mener du det ikke er viktig å ha referanse / bruker manualer for det språket du programmerer i for hånden eller på internet som for Java? Jeg har ikke funnet like god online ressurser for C og C++ som for java. Jeg er vant med meter tykke (og det er ingen overdrivelse) manualer i språk utviklet ved MIT. Noe av det viktigste vi lærte nybegynnere (jeg sier ikke at Henning er nybegynner) var å slå opp i manualer. Da er det vel et mildt råd og anbefale han å gå til C kilden, boken av K & R på et par hundre sider som det er uhyre lett å slå opp i med dagens verktøy. Rediger + søketekst + gjentatte klikk på neste med musepekeren i PDF dokumentet. Det er langt lettere enn å slå opp i metertykke papirmanualer eller google problemet der man ikke kan vite kvaliteten på svaret.

 

Søker du på

 

c reference manual

 

er dette http://www.acm.uiuc.edu/webmonkeys/book/c_guide/ første treff. Andre treff, en gammel C reference PDF manual av Dennis M Ritchie har jeg heller ikke brukt. Men jeg kjenner den kompakte og gode boken til K & R hvor jeg fikk de svarene jeg trengte den gangen jeg drev med C. Der er kanskje en mer oppdatert

 

http://home.datacomm.ch/t_wolf/tw/c/c9x_changes.html

 

C referanse manual på nettet som noen av dere kjenner. Et raskt overblikk av de første treffene for søkestrengen:

 

C9X reference OR user manual

 

gir ingen menigsfylte treff.

 

For øvrig er min raske løsning noen ganger en henvisning. Dersom du mener mine henvisninger er irrelevante må du gjerne mene det. Henning er nok i stand til å plukke ut det han trenger og forsvare seg selv.

Endret 6. oktober 2011 av Slettet+9871234

[GeirGrusom]

Jeg hadde også tenkt til å si at man kunne spare plass ved å lagre samme konstant bare ett sted i minne. Men det blir jo helt feil. Det er jo avgjørende at hver instans av konstanten får sin egen lokasjon. Men selv da føler jeg at man må være forsiktig mtp rekursjon og løkker.

Hvis en setter det i et eget scope så går det fint

[torbjørn marø]

"But after a while, most programmers realize that this means that a program is equipped with a safety net: many errors that programmers make when they construct programs are caught by this net before they lead to unpleasant effects. An example: A very expensive American space rocket crashed on its way to Venus a few years ago, because of an extremely trivial error in a FORTRAN program. A comma had been written as a point, and, as a consequence of that, the start of a special kind of repeat imperative was mistakenly read as an assignment imperative assigning a value to an undeclared variable. Had it been required to declare every variable in FORTRAN programs, the compiler would have discovered that the variable was undeclared and the error would have been caught much earlier than in the Atlantic Ocean."

Professor Bjørn Kirkerud (1989): "Object Oriented Programming With Simula". Addison Wesley Publishing Company ISBN 0 201 17574 6. Page 31-32.

Hver gang jeg har sett deg dra frem dette får jeg lyst til å fortelle om fordelene dynamiske språk som LISP har gitt hos NASA. Her er et sitat fra Peter Seibel:

 

An even more impressive instance of remote debugging occurred on NASA's 1998 Deep Space 1 mission. A half year after the space craft launched, a bit of Lisp code was going to control the spacecraft for two days while conducting a sequence of experiments. Unfortunately, a subtle race condition in the code had escaped detection during ground testing and was already in space. When the bug manifested in the wild--100 million miles away from Earth--the team was able to diagnose and fix the running code, allowing the experiments to complete. One of the programmers described it as follows:

 

"Debugging a program running on a $100M piece of hardware that is 100 million miles away is an interesting experience. Having a read-eval-print loop running on the spacecraft proved invaluable in finding and fixing the problem."

 

Ref http://www.gigamonkeys.com/book/lather-rinse-repeat-a-tour-of-the-repl.html og http://www.flownet.com/gat/jpl-lisp.html

Endret 6. oktober 2011 av torbjørn marø

[tomsi42]

Regner med det er en skrivefeil, og at du mener:

int32_t xx200 = 200;
int32_t Foobar1 = Foo(&xx200);

Det stemmer. Nok et eksempel på at det lønner seg med code review

[GeirGrusom]

"But after a while, most programmers realize that this means that a program is equipped with a safety net: many errors that programmers make when they construct programs are caught by this net before they lead to unpleasant effects. An example: A very expensive American space rocket crashed on its way to Venus a few years ago, because of an extremely trivial error in a FORTRAN program. A comma had been written as a point, and, as a consequence of that, the start of a special kind of repeat imperative was mistakenly read as an assignment imperative assigning a value to an undeclared variable. Had it been required to declare every variable in FORTRAN programs, the compiler would have discovered that the variable was undeclared and the error would have been caught much earlier than in the Atlantic Ocean."

Professor Bjørn Kirkerud (1989): "Object Oriented Programming With Simula". Addison Wesley Publishing Company ISBN 0 201 17574 6. Page 31-32.

Hver gang jeg har sett deg dra frem dette får jeg lyst til å fortelle om fordelene dynamiske språk som LISP har gitt hos NASA. Her er et sitat fra Peter Seibel:

 

An even more impressive instance of remote debugging occurred on NASA's 1998 Deep Space 1 mission. A half year after the space craft launched, a bit of Lisp code was going to control the spacecraft for two days while conducting a sequence of experiments. Unfortunately, a subtle race condition in the code had escaped detection during ground testing and was already in space. When the bug manifested in the wild--100 million miles away from Earth--the team was able to diagnose and fix the running code, allowing the experiments to complete. One of the programmers described it as follows:

 

"Debugging a program running on a $100M piece of hardware that is 100 million miles away is an interesting experience. Having a read-eval-print loop running on the spacecraft proved invaluable in finding and fixing the problem."

 

Ref http://www.gigamonkeys.com/book/lather-rinse-repeat-a-tour-of-the-repl.html og http://www.flownet.com/gat/jpl-lisp.html

Fortran er ikke et dynamisk språk, og dessuten er implisitt variabel deklerasjon et tåpelig påfunn uansett hva slags språk det er i.

[Gjest Slettet+9871234]

Hver gang jeg har sett deg dra frem dette får jeg lyst til å fortelle om fordelene dynamiske språk som LISP har gitt hos NASA. Her er et sitat fra Peter Seibel:

Mitt eksempel illustrerer her i denne konteksten hvor viktig det er å kjenne det språket man jobber med. Jeg kjenner hverken LISP eller VB, men C som det her var snakk om. Jobber man med C er man nødt til å vite hvordan perkere og referanser fungerer. Pekere er en av styrkene til C. I stedet for å sende et stort objekt via funksjonskallet sendes en referanse (eller er peker mer presist? Der ser du hvor fort man glemmer om man ikke daglig jobber med et språk) til objektets minneaddresse.

 

"Debugging a program running on a $100M piece of hardware that is 100 million miles away is an interesting experience. Having a read-eval-print loop running on the spacecraft proved invaluable in finding and fixing the problem."

Er der en forskjell om programmet er 1 meter borte, så lenge det er mulig å kommunisere med programmet?

Endret 6. oktober 2011 av Slettet+9871234

[tomsi42]

Er der en forskjell om programmet er 1 meter borte, så lenge det er mulig å kommunisere med programmet?

Er programmet en meter borte, så vil du ha en svartid som er rask nok. På mars, vil det ta en god stund fra du sender en kommando til du får svar. Å steppe igjennom et program via debugger vil nok bli en interessant affære.

[GeirGrusom]

Å steppe igjennom et program via debugger vil nok bli en interessant affære.

Spesielt hvis det er LISP du skal debugge ^^