Eftersom beteendet inte är definierat när du låter indexen gå utanför storleken för a i cal_sum, så går det inte att dra någon slutsats om huruvida en 32-bitars kompilator skulle vara bättre från detta exempel.
Denna kod för nearest neighbour ger segmentatinon fault med g++ version 9.2.1 men fungerar bra med Raspberry Pi (32bit).
#include<iostream>
using namespace std;
int c = 0, cost = 1000;
int g[3][3 ] = { {1,2,3},{4,5,8},{6,7,10}};
void swap(int *x, int *y) {
int t;
t = *x;
*x = *y;
*y = t;
}
void cal_sum(int *a, int n) {
int i, s= 0;
for (i = 0; i <= n; i++) {
s+= g[a[i %3]][a[(i+ 1) %3]];
}
if (cost >s) {
cost = s;
}
}
void permute(int *a,int i,int n) {
int j, k;
if (i == n) {
cal_sum (a,n);
} else {
for (j = i; j <= n; j++) {
swap((a + i), (a + j));
cal_sum(a+1,n);
swap((a + i), (a + j));
}
}
}
int main() {
int i, j;
int a[] = {1,2,3};//take array elements
permute(a, 0,2);
cout << "minimum cost:" << cost << endl;
}
Några tips?
Mitt tips är - skyll inte på kompilatorn. Om det inte bygger, inte beter sig rätt, eller om det kraschar, så utgå från att du har gjort fel. Att det "funkar" på 32-bit är bara ren och skär tur. Eller egentligen otur, för det hade hjälpt dig mer om det hade kraschat där också.
Tack för svaren!
Ja det ser ut som om gcc för Raspberry Pi är ovanligt förlåtande.
En annan fråga:
Uppdateras gcc för 32 bitars x86 såsom 64 bitars x86_64 med alla nya c och c++ standarder?
Tack för svaren!
Ja det ser ut som om gcc för Raspberry Pi är ovanligt förlåtande.
En annan fråga:
Uppdateras gcc för 32 bitars x86 såsom 64 bitars x86_64 med alla nya c och c++ standarder?
gcc kan kompilera till både 32 och 64 bitars arkitektur oavsett platform gcc körs på. Finns en flagga du sätter vid kompileringen.
Kolla på raden:
cal_sum(a+1,n);
och försök förstå varför det inte fungerar att göra så.
Mitt tips är - skyll inte på kompilatorn. Om det inte bygger, inte beter sig rätt, eller om det kraschar, så utgå från att du har gjort fel. Att det "funkar" på 32-bit är bara ren och skär tur. Eller egentligen otur, för det hade hjälpt dig mer om det hade kraschat där också.
Nu har det hänt något med kompilatorn för Raspberry Pi.
Jag testar just RPi 4 med uppdaterad programvara:
pi@raspberrypi:~/New_dec2019 $ g++ permute3.cpp
pi@raspberrypi:~/New_dec2019 $ ./a.out
minimum cost:-1225247576
Här anar man felet!
pi@raspberrypi:~/New_dec2019 $ cp a.out permute3.out
pi@raspberrypi:~/New_dec2019 $ g++ permute33.cpp
pi@raspberrypi:~/New_dec2019 $ ./a.out
minimum cost:2
Med en större array
Svaret på topic är nej, på en 64-bit CPU är en 64-bits kompilator alltid bättre än en 32-bitars.
Motivera gärna varför!
Jag kan tänka mej att antalet användare avgör. Många användare gör att buggar upptäcks fortare.
Så är det för X86_64 men hur är det för ARM?
Tack för svaren! Ja det ser ut som om gcc för Raspberry Pi är ovanligt förlåtande.
En annan fråga:
Uppdateras gcc för 32 bitars x86 såsom 64 bitars x86_64 med alla nya c och c++ standarder?
Handlar inte om att kompilatorn är mer förlåtande utan hur minnet är ordnat. Segmentation fault innebär per definition att programmet försöker läsa eller skriva till en virtuell minnesadress som inte är mappad mot en fysisk adress. Använder du alls virtuellt minne på din raspberry pi? Vilken sidstorlek används? I vilken ordning länkas programmets datasegment ihop? Vad kommer efter det fält där du läser utanför gränsen?
Angående kompilatorer så utvecklas både gcc och clang efter principen "felaktig kod är odefinierad". I praktiken innebär det att kod som skulle läsa utanför gränsen markeras som "don't care" om kompilatorn upptäcker detta, med följd att kompilatorn kan generera precis vilken kod den vill. Orsaken är att man vill ge kompilatorn möjlighet att optimera bort exekveringsvägar som ändå inte är nåbara i ett korrekt program.
Det egentliga problemet här har ingenting med 32 eller 64 bitar att göra, utan snarare att du inte förstår hur c++, temporära objekt och pekare fungerar.
cal_sum(a + 1, n);
Här blir det fel, du hoppar utanför minnet på a.
Det egentliga problemet här har ingenting med 32 eller 64 bitar att göra, utan snarare att du inte förstår hur c++, temporära objekt och pekare fungerar.
cal_sum(a + 1, n);
Här blir det fel, du hoppar utanför minnet på a.
Vad är det din kod försöker göra?
Ja jag vet att det är utanför. Men varje kompilator beter sig något olika.
Ett svårare problem är troligen division med noll.
https://people.sc.fsu.edu/~jburkardt...lbrot_ppm.html
Här är två varianter av Mandelbrot. Den seriella dumpar filen på bildskärmen...inte så vackert. OpenMP varianten lagrar PPM-en. Om jag ökar från 500x500 till 800x800 så går det bra med den seriella men blir segmentation fault med Open MP varianten.
Division med noll eller något annat?
Flashback finansieras genom donationer från våra medlemmar och besökare. Det är med hjälp av dig vi kan fortsätta erbjuda en fri samhällsdebatt. Tack för ditt stöd!
