/ Forside / Teknologi / Udvikling / C/C++ / Nyhedsindlæg
Login
Glemt dit kodeord?
Brugernavn

Kodeord


Reklame
Top 10 brugere
C/C++
#NavnPoint
BertelBra.. 2425
pmbruun 695
Master_of.. 501
jdjespers.. 500
kyllekylle 500
Bech_bb 500
scootergr.. 300
gibson 300
molokyle 287
10  strarup 270
Compile/Make på Solaris vs. Windows
Fra : Lasse Bigum


Dato : 16-05-03 16:48

Hej,

Jeg studerer på AUC hvor vi har lavet et program der vha. Genetisk
Algoritmer kan finde den optimale løsning til TSP problemer, vi har lavet en
test-udgave af programmet der kan køre en stor række af løkker igennem for
at teste hvordan de forskellige parametre påvirker vores løsning, alt det
her fungerer, efter nogen hovedbrud , ganske fint.

Der er dog et *enkelt* men. Det tager rigtigt lang tid at køre disse tests,
og det er grunden til at vi gerne vil have dem til at køre på AUC's
basis-server, dolomit. Men vi kan ikke compile vores kode på solaris, som vi
gør på Windows. Jeg har fået at vide at der skulle være nogle make-flags man
kan smide som gør at gcc bliver MEGET mindre streng med hvor variablerne er
deklareret og om vores header.h fil bliver inkludereret flere gange (og
derved prototyper vi vores funktioner flere gange).

Er der nogen der kan give nogle gode kommentarer? Har været inde på
http://gcc.gnu.org/onlinedocs/ og kigge, men der er så mange flag at jeg
ikke kan overskue dem.

På forhånd tak,
Lasse Bigum



 
 
Bertel Brander (16-05-2003)
Kommentar
Fra : Bertel Brander


Dato : 16-05-03 20:04

Lasse Bigum wrote:
> Hej,
>
> Jeg studerer på AUC hvor vi har lavet et program der vha. Genetisk
> Algoritmer kan finde den optimale løsning til TSP problemer, vi har lavet en
> test-udgave af programmet der kan køre en stor række af løkker igennem for
> at teste hvordan de forskellige parametre påvirker vores løsning, alt det
> her fungerer, efter nogen hovedbrud , ganske fint.
>
> Der er dog et *enkelt* men. Det tager rigtigt lang tid at køre disse tests,
> og det er grunden til at vi gerne vil have dem til at køre på AUC's
> basis-server, dolomit. Men vi kan ikke compile vores kode på solaris, som vi
> gør på Windows. Jeg har fået at vide at der skulle være nogle make-flags man
> kan smide som gør at gcc bliver MEGET mindre streng med hvor variablerne er
> deklareret og om vores header.h fil bliver inkludereret flere gange (og
> derved prototyper vi vores funktioner flere gange).
>
> Er der nogen der kan give nogle gode kommentarer? Har været inde på
> http://gcc.gnu.org/onlinedocs/ og kigge, men der er så mange flag at jeg
> ikke kan overskue dem.
>

Jeg har ikke prøvet at kompile på solaris men kender dog gcc fra cygwin
og linux. Det er ikke noget problem at have prototyper flere gange, det
er heller ikke noget problem hvor variablerne er erklæret, men der
findes IKKE flag til gcc der gør at den oversætter alt.
Måske kunne du fortælle hvordan I compiler nu (hvilken compiler etc.) og
hvilke fejl I får når I compiler på solaris.

/b

--
Bertel Brander, author of Wain, a free text editor for programmers:
http://home20.inet.tele.dk/midgaard/program.htm


Lasse Bigum (17-05-2003)
Kommentar
Fra : Lasse Bigum


Dato : 17-05-03 17:14

> > Er der nogen der kan give nogle gode kommentarer? Har været inde på
> > http://gcc.gnu.org/onlinedocs/ og kigge, men der er så mange flag at jeg
> > ikke kan overskue dem.
> >
>
> Jeg har ikke prøvet at kompile på solaris men kender dog gcc fra cygwin
> og linux. Det er ikke noget problem at have prototyper flere gange, det
> er heller ikke noget problem hvor variablerne er erklæret, men der
> findes IKKE flag til gcc der gør at den oversætter alt.
> Måske kunne du fortælle hvordan I compiler nu (hvilken compiler etc.) og
> hvilke fejl I får når I compiler på solaris.

Ja, længere snip kommer her:
(Vores make-file er vedhæftet denne post så I kan slå mig oven i hovedet
skulle den indeholde forkerte ting, men den er blot nakket fra Dev-C++
programmets makefile til Windows)

labi0233@dolomit/dokumenter/p2/source/unixsource> make
gcc -c main.c -o main.o -ansi -g3 -pedantic -Wall
main.c: In function `main':
main.c:13: parse error before `argumenter'
main.c:14: `argumenter' undeclared (first use in this function)
main.c:14: (Each undeclared identifier is reported only once
main.c:14: for each function it appears in.)
main.c:17: parse error before `*'
main.c:18: `knudeArray' undeclared (first use in this function)
main.c:28: parse error before `int'
main.c:47: `test_mutationSandsynlighed' undeclared (first use in this
function)
main.c:52: parse error before `double'
main.c:54: `test_mutationProcent' undeclared (first use in this function)
main.c:54: `mpStart' undeclared (first use in this function)
main.c:54: `mpMaks' undeclared (first use in this function)
main.c:54: `forOeg' undeclared (first use in this function)
main.c:62: `test_elitismeUdvaelgProcent' undeclared (first use in this
function)
main.c:69: `test_mutationSkift' undeclared (first use in this function)
main.c:77: `s' undeclared (first use in this function)
main.c:89: `r' undeclared (first use in this function)
main.c:122: parse error before `int'
main.c:124: `q' undeclared (first use in this function)
main.c:124: `gGange' undeclared (first use in this function)
main.c:129: `t' undeclared (first use in this function)
main.c:143: parse error before `double'
main.c:144: `tempLAMTTAL' undeclared (first use in this function)
*** Error code 1
make: Fatal error: Command failed for target `main.o'
labi0233@dolomit/dokumenter/p2/source/unixsource>

Her dør den så, jeg har så lige pasted det vigtigste fra main.c herind,
linjenumrene skulle passe:

Nedenstående linje er nr. 1, og så fremdeles, ikke hele koden er pastet her
da det ville fylde for meget (?)
/*
Dette er hovedfilen til vores projekt program, og ud fra denne fil
bliver der compilet
en eksekverbar fil.
*/

#include "header.h"

int main(int argc, char *argv[])
{
srand(time(NULL));

/* Her initialiserer vi vores argumenter til resten af programmet */
arg argumenter;
argumenter = commandVar(&argc, argv);

/* Her skaber vi vores knuder, enten ud fra en fil, eller genererer
dem */
knude *knudeArray;
knudeArray = hentKnuder(&argumenter);

if (!(argumenter.knudeAntal < 3))
{
if(argumenter.testMode)
{
/* Filnavn til den store resultat-fil */
RydTempResultat(&argumenter);

/* T\206l hvilken test vi har gang i */
int t = 1;

/* Vi vil teste, s\205 lav nogle fake variabler */
int s, r, q;



Mogens Hansen (17-05-2003)
Kommentar
Fra : Mogens Hansen


Dato : 17-05-03 18:44


"Lasse Bigum" <Lasse[R:E:M:O:V:E]@hardwareonline.dk> wrote

[8<8<8<]
> int main(int argc, char *argv[])
> {
> srand(time(NULL));

Hvor er "srand" erklæret ?
Er programmet et C eller C++ program ?

>
> /* Her initialiserer vi vores argumenter til resten af programmet
*/
> arg argumenter;

Hvor er typen "arg" erklæret ?

> argumenter = commandVar(&argc, argv);
>
> /* Her skaber vi vores knuder, enten ud fra en fil, eller
genererer
> dem */
> knude *knudeArray;

Hvor er typen "knude" erklæret ?

Man er nok nød til at se lidt af "header.h"

Venlig hilsen

Mogens Hansen



Lasse Bigum (17-05-2003)
Kommentar
Fra : Lasse Bigum


Dato : 17-05-03 21:00

> > int main(int argc, char *argv[])
> > {
> > srand(time(NULL));
>
> Hvor er "srand" erklæret ?
> Er programmet et C eller C++ program ?

Srand er da en del af C's library funktioner eller noget i den retning, med
andre ord: funktionen ligger i C.

> > arg argumenter;
>
> Hvor er typen "arg" erklæret ?
>
> > argumenter = commandVar(&argc, argv);
> >
> > /* Her skaber vi vores knuder, enten ud fra en fil, eller
> genererer
> > dem */
> > knude *knudeArray;
>
> Hvor er typen "knude" erklæret ?
>
> Man er nok nød til at se lidt af "header.h"

Ok, du får den herunder

---------------------------------

#include <stdio.h>
#include <stdlib.h>
#include <time.h>
#include <limits.h>
#include <float.h>
#include <math.h>

#define STD_KNUDEANTAL 10
#define STD_INDIVIDANTAL 500
#define STD_MAKSGEN 1000
#define STD_MUTATION_SAND 1
#define STD_MUTATION_PROCENT 5
#define STD_SELEKTIONMETODE "roulette"
#define STD_MUTATIONMETODE "random"
#define STD_MUTATIONSKIFT 0
#define STD_DOBBELBARN 1
#define STD_BEDSTEFORAELDER 1
#define STD_ELITISMEPROCENT 5
#define MAX_TEMP_STRING 1000
#define MAX_TEMP_TAL 50
#define PI 3.14

typedef struct time_keeper
{
clock_t begin_clock, save_clock;
time_t begin_time, save_time;
} time_keeper;

typedef struct individ
{
double laengde;
int *knudeArray;
} individ;

typedef struct knude
{
double x, y;
} knude;

typedef struct cons_cell
{
int data;
struct cons_cell *next;
} cons_cell;

typedef struct foraeldre
{
int fA, fB;
} foraeldre;

typedef struct arg
{
int knudeAntal, individAntal, maksGen, bedsteForaeldre, cirkelKnuder,
mutationSkift, dobbelBarn;
int udskrivTekst, testMode, printGrafFil;
double mutationSandsynlighed, mutationProcent, elitismeUdvaelgProcent,
sidsteLaengde, gennemsnitLaengde;
char *selektionMetode, *mutationMetode;
char *filnavn, *resultatFil, *csvGenerationFil;
char *mutationStandard;
} arg;

/* Funktioner i generation.c */
void lavGenerationer(arg *argumenter, knude *knudeArray);

/* Funktioner i hentknuder.c */
knude *hentKnuder(arg *argumenter);
knude *lavKnuder(arg *argumenter);
knude *lavCirkelKnuder(arg *argumenter);
knude *indlaesKnuder(arg *argumenter);
int odd(int x);

/* Funktioner i lavPopulation.c */
individ *lavPopulation(knude knudeArray[], arg *argumenter);
individ lavIndivid(knude knudeArray[], int knudeAntal);
cons_cell *arrayTilListe(knude knudeArray[], int knudeAntal);
cons_cell *cons(int data, cons_cell *next);
int head(cons_cell *cell);
cons_cell *tail(cons_cell *cell);
void sletElement(cons_cell *p, int k);

/* Funktioner i sorter.c */
void popSort(individ *popArray, knude knudeArray[], arg *argumenter);
void byt(individ *, individ *);
double lavLaengde(int intKnudeArray[], knude knudeArray[], int knudeAntal);

/* Funktioner i elitisme.c */
int elitisme (individ *glPopArray, individ nyPopArray[], arg *argumenter);

/* Funktioner i selektion.c */
foraeldre *selektion(individ popListe[], int antalForaeldre, arg
*argumenter);

/* Funktioner i roulette.c */
foraeldre roulette(arg *argumenter, double fitness[]);
double *lavFitness(individ popArray[], arg *argumenter);

/* Funktioner i crossover.c */
void lavCrossover(foraeldre *foraeldreArray, individ popArray[], int
antalForaeldre,
arg *argumenter, individ nytPopArray[], int startIndex);

/* Funktioner i mutation.c */
char *strCopy (const char *s);
char *strToLower (const char *input);
int strSammenLign (const char *s1, const char *s2, size_t u);
void mutation(individ *popArray, arg *argumenter, int startIndex);
void mutering(individ *individ, arg *argumenter);
int random(int minimum, int maksimum);
int afrund(double x);
void bytKnuder(int *p, int *q);
void selectMutMetode (arg *argumenter, int generationer);

/* Funktioner i command.c */
arg commandVar(int *arg_antal, char *argumenter[]);
void print_help(void);

/* Funktioner i interaktion.c */
int inter_KnudeAntal(void);
char *inter_FilNavn(void);
int inter_IndividAntal(void);
int inter_MaksGen(void);
int inter_cirkelKnuder(void);
double inter_Elitisme(void);
double inter_MutationProcent(void);
double inter_MutationSandsynlighed(void);
char *inter_SelektionMetode(void);
char *inter_MutationMetode(void);
char *inter_ResultatFil(void);
int inter_MutationSkift(void);
int inter_getInt(void);
double inter_getDouble(void);
char *inter_getString(void);

/* SkrivIndivid */
void rydFil (arg *argumenter);
char *dkKommatal (double tal, int decimaler);
void skrivIndividLaengde (arg *argumenter, individ *individ, int
generation);
void RydTempResultat (arg *argumenter);
void skrivTestSnit(arg *argumenter, int test_nr);



Mogens Hansen (18-05-2003)
Kommentar
Fra : Mogens Hansen


Dato : 18-05-03 08:27


"Lasse Bigum" <Lasse[R:E:M:O:V:E]@hardwareonline.dk> wrote

> > > int main(int argc, char *argv[])
> > > {
> > > srand(time(NULL));
> >
> > Hvor er "srand" erklæret ?
> > Er programmet et C eller C++ program ?
>
> Srand er da en del af C's library funktioner eller noget i den retning,
med
> andre ord: funktionen ligger i C.

Den er jeg med på.
Men man kunne ikke se om den nødvendige headerfil (i C <stdlib.h>, i C++
<cstdlib>) var blevet inkluderet i den kode der blev postet.

Spørgsmålet om hvorvidt jeres program er C eller C++ er væsentligt for at
kunne hjælpe at afklare hvorfor det ikke oversætter.
Som Bertel Brander har sagt skal lokale variable placeres i starten af en
blok i C (C89), hvor det ikke er krævet i C++. Så vidt jeg husker har den
seneste C Standard (C99), heller ikke et sådant krav.

Jeres program er baseret på at variable ikke skal erklæres i starten af en
blok.

Derfor kan jeres problem bl.a. være at i prøver at oversætte med en C99
compiler på Windows og en C89 compiler på Solaris.
Hvilken version af gcc bruger i på de 2 systemer (skriv gcc --version) ?

[8<8<8<]
> Ok, du får den herunder

Det ligner et C program.

Lige et par gode råd om header-filer:

1. Lav include-guards:

#ifndef GUARD_HEADER_H
#define GUARD_HEADER_H
/*
* here goes the declarations
*/
#endif

Det sikrer imod at noget bliver erklæret mere end een gang pr. compilation
unit.


2. Undlad at inkludere mere i header-filer end højest nødvendigt.
Det giver unødvendigt mange afhængigheder, og dermed lange
compileringstider.
Så vidt jeg hurtigt kan se, har jeres headerfil slet ikke brug for nogen
includes - flyt dem alle over i C filen.

Venlig hilsen

Mogens Hansen



Lasse Bigum (18-05-2003)
Kommentar
Fra : Lasse Bigum


Dato : 18-05-03 12:17

> > Srand er da en del af C's library funktioner eller noget i den retning,
> med
> > andre ord: funktionen ligger i C.
>
> Den er jeg med på.
> Men man kunne ikke se om den nødvendige headerfil (i C <stdlib.h>, i C++
> <cstdlib>) var blevet inkluderet i den kode der blev postet.

Fair nok, men det er den i headeren

> Spørgsmålet om hvorvidt jeres program er C eller C++ er væsentligt for at
> kunne hjælpe at afklare hvorfor det ikke oversætter.
> Som Bertel Brander har sagt skal lokale variable placeres i starten af en
> blok i C (C89), hvor det ikke er krævet i C++. Så vidt jeg husker har den
> seneste C Standard (C99), heller ikke et sådant krav.
>
> Jeres program er baseret på at variable ikke skal erklæres i starten af en
> blok.
>
> Derfor kan jeres problem bl.a. være at i prøver at oversætte med en C99
> compiler på Windows og en C89 compiler på Solaris.
> Hvilken version af gcc bruger i på de 2 systemer (skriv gcc --version) ?

Den returnerer: egcs-2.91.66

Har ingen anelse om hvad version det er i henhold til hvad du skrev.

> Det ligner et C program.
>
> Lige et par gode råd om header-filer:
>
> 1. Lav include-guards:
>
> #ifndef GUARD_HEADER_H
> #define GUARD_HEADER_H
> /*
> * here goes the declarations
> */
> #endif
>
> Det sikrer imod at noget bliver erklæret mere end een gang pr. compilation
> unit.

Arh, tak. Som sagt er jeg rimeligt ny i C, så jeg takker for alle gode råd
jeg kan få

> 2. Undlad at inkludere mere i header-filer end højest nødvendigt.
> Det giver unødvendigt mange afhængigheder, og dermed lange
> compileringstider.
> Så vidt jeg hurtigt kan se, har jeres headerfil slet ikke brug for nogen
> includes - flyt dem alle over i C filen.

Det vil jeg gøre, tak

/Lasse



Mogens Hansen (18-05-2003)
Kommentar
Fra : Mogens Hansen


Dato : 18-05-03 12:53


"Lasse Bigum" <Lasse[R:E:M:O:V:E]@hardwareonline.dk> wrote

[8<8<8<]
> > Hvilken version af gcc bruger i på de 2 systemer (skriv gcc --version) ?
>
> Den returnerer: egcs-2.91.66

På begge systemer ?
Den er fra 15. marts 1999
(http://www.gnu.org/software/gcc/releases.html#timeline).
Derfor er det sikkert fornuftigt at antage at det er en C89 compiler, og
således kræver at lokale varibale erklæres i starten af en blok.


Venlig hilsen

Mogens Hansen



Lasse Bigum (18-05-2003)
Kommentar
Fra : Lasse Bigum


Dato : 18-05-03 16:31

> > > Hvilken version af gcc bruger i på de 2 systemer (skriv gcc --version)
?
> >
> > Den returnerer: egcs-2.91.66
>
> På begge systemer ?

Nej, jeg har kun kørt den der gcc --version på Solaris maskinen. Ved ikke
hvad version der følger med til Dev-C++

> Den er fra 15. marts 1999
> (http://www.gnu.org/software/gcc/releases.html#timeline).
> Derfor er det sikkert fornuftigt at antage at det er en C89 compiler, og
> således kræver at lokale varibale erklæres i starten af en blok.

Crap Men ok, tak, det er da en stor hjælp. Jeg vil lige lavet noget mere
påtrængende først og så gå over til EDB-værkstedet og høre om de ikke kan
opgradere gcc med en nyere version. Vil de ikke det må jeg jo på arbejde

Tak

/Lasse



Mogens Hansen (18-05-2003)
Kommentar
Fra : Mogens Hansen


Dato : 18-05-03 19:05


"Lasse Bigum" <Lasse[R:E:M:O:V:E]@hardwareonline.dk> wrote

[8<8<8<]
> Nej, jeg har kun kørt den der gcc --version på Solaris maskinen. Ved ikke
> hvad version der følger med til Dev-C++

Såvidt jeg husker var det V3.2 sidst jeg checkede.
Du kan bruge makroerne
__GNUC__
__GNUC_MINOR__
__GNUC_PATCHLEVEL__
til at finde ud af det inde fra source koden:
<C++ kode>
#include <iostream>

int main()
{
using namespace std;
cout << __GNUC__ << '.' << __GNUC_MINOR__ << '.' << __GNUC_PATCHLEVEL__
<< endl;
}
</C++ kode>

Venlig hilsen

Mogens Hansen



Martin Moller Peders~ (17-05-2003)
Kommentar
Fra : Martin Moller Peders~


Dato : 17-05-03 19:29

In <3ec65edd$0$29539$ba624c82@nntp04.dk.telia.net> "Lasse Bigum" <Lasse[R:E:M:O:V:E]@hardwareonline.dk> writes:

>> > Er der nogen der kan give nogle gode kommentarer? Har været inde på
>> > http://gcc.gnu.org/onlinedocs/ og kigge, men der er så mange flag at jeg
>> > ikke kan overskue dem.
>> >
>>
>> Jeg har ikke prøvet at kompile på solaris men kender dog gcc fra cygwin
>> og linux. Det er ikke noget problem at have prototyper flere gange, det
>> er heller ikke noget problem hvor variablerne er erklæret, men der
>> findes IKKE flag til gcc der gør at den oversætter alt.
>> Måske kunne du fortælle hvordan I compiler nu (hvilken compiler etc.) og
>> hvilke fejl I får når I compiler på solaris.

>Ja, længere snip kommer her:
>(Vores make-file er vedhæftet denne post så I kan slå mig oven i hovedet
>skulle den indeholde forkerte ting, men den er blot nakket fra Dev-C++
>programmets makefile til Windows)

Kan du laegge alt sourcen et eller andet sted og poste URL'en, saa
skal jeg nok hurtigt finde et par fejl.

Mvh
Martin

Lasse Bigum (17-05-2003)
Kommentar
Fra : Lasse Bigum


Dato : 17-05-03 20:53

> Kan du laegge alt sourcen et eller andet sted og poste URL'en, saa
> skal jeg nok hurtigt finde et par fejl.

Det måtte det jo ende med

Jeg har lagt alt sourcen i et rar-pakket format, er det et problem? Kan også
godt smide kilde-koden op i stedet hvis det er nemmere for jer
http://but.auc.dk/~labi0233/source.rar

Strukturen er:
source --> filerne til Windows compile
unixsource --> alle filer efter dos2unix, her ligger også vores
Makefile som vi bruger med "make", og som derefter giver fejl
resultater --> mappe der bruges til testresultaterne

/Lasse



Bertel Brander (18-05-2003)
Kommentar
Fra : Bertel Brander


Dato : 18-05-03 01:00

Lasse Bigum wrote:
>>Kan du laegge alt sourcen et eller andet sted og poste URL'en, saa
>>skal jeg nok hurtigt finde et par fejl.
>
>
> Det måtte det jo ende med
>
> Jeg har lagt alt sourcen i et rar-pakket format, er det et problem? Kan også
> godt smide kilde-koden op i stedet hvis det er nemmere for jer
> http://but.auc.dk/~labi0233/source.rar
>
I C (i modsætning af i C++) skal erklæring af lokal variable placeres i
starten af en blok:

int f(void)
{
int x;
p();
char dont;
for(x = 0; x < 10; x++)
{
int z = x*x;
g(z);
char nono = '9';
h(nono);
}
}

I dette eksempel er erklæringerne af x og z ok, hvorimod erklæringerne
af dont og nono ikke er det.
Når I har fixet disse vil I have fjernet en stor del af jeres fejl. Det
næste er så at inkludere de rette system header filer (f.ex ctype.h (for
en prototype på isspace) og string.h (for strcat)).

Godnat.

/b


Lasse Bigum (18-05-2003)
Kommentar
Fra : Lasse Bigum


Dato : 18-05-03 12:20

> I C (i modsætning af i C++) skal erklæring af lokal variable placeres i
> starten af en blok:

*snip*

> Når I har fixet disse vil I have fjernet en stor del af jeres fejl. Det
> næste er så at inkludere de rette system header filer (f.ex ctype.h (for
> en prototype på isspace) og string.h (for strcat)).

Hvis compileren understøtter det er det vel ikke et problem? Jeg har lige
svaret Mogens Hansen på hvad version vores compiler er: egcs-2.91.66, og jeg
aner ikke om den understøtter det med at der kommer variabler nede i koden,
men hvis den ikke gør forklarer det jo sikkert en del.

Hvad angår at inkludere system header filerne, det skule jeg mene vi har
gjort i header.h?

Tak

/Lasse



Bertel Brander (18-05-2003)
Kommentar
Fra : Bertel Brander


Dato : 18-05-03 13:33

Lasse Bigum wrote:
>>I C (i modsætning af i C++) skal erklæring af lokal variable placeres i
>>starten af en blok:
>
>
> *snip*
>
>
>>Når I har fixet disse vil I have fjernet en stor del af jeres fejl. Det
>>næste er så at inkludere de rette system header filer (f.ex ctype.h (for
>>en prototype på isspace) og string.h (for strcat)).
>
>
> Hvis compileren understøtter det er det vel ikke et problem? Jeg har lige
> svaret Mogens Hansen på hvad version vores compiler er: egcs-2.91.66, og jeg
> aner ikke om den understøtter det med at der kommer variabler nede i koden,
> men hvis den ikke gør forklarer det jo sikkert en del.
>
> Hvad angår at inkludere system header filerne, det skule jeg mene vi har
> gjort i header.h?
>
Hverken ctype.h eller string.h er inkluderet i header.h (eller andre
steder).

/b


Lasse Bigum (18-05-2003)
Kommentar
Fra : Lasse Bigum


Dato : 18-05-03 16:33

> > Hvad angår at inkludere system header filerne, det skule jeg mene vi har
> > gjort i header.h?
> >
> Hverken ctype.h eller string.h er inkluderet i header.h (eller andre
> steder).

Nej, du har ret. Men hvorfor virker det mon under Windows så? Spekulerer på
om Dev-C++ selv inkluderer disse uden vi skal skrive det?

Vi skal blot skrive:
#include <ctype.h>

for at gøre dette, ikke?

/Lasse



Bertel Brander (18-05-2003)
Kommentar
Fra : Bertel Brander


Dato : 18-05-03 19:37

Lasse Bigum wrote:
>>>Hvad angår at inkludere system header filerne, det skule jeg mene vi har
>>>gjort i header.h?
>>>
>>
>>Hverken ctype.h eller string.h er inkluderet i header.h (eller andre
>>steder).
>
>
> Nej, du har ret. Men hvorfor virker det mon under Windows så? Spekulerer på
> om Dev-C++ selv inkluderer disse uden vi skal skrive det?
>
Det der mangler fra de to headerfiler er nogle prototyper på nogle
funktioner (der mangler iøvrigt også prototyper for nogle af jeres egne
funktioner). Normalt får man en warning hvis der mangler en prototype.
I nogle tilfælde sker der ikke noget ved at kalde en funktion uden en
protype, i andre tilfælde kan det være fatalt.
Det er (næsten ) altid en god ide at have en prototype for de funktioner
man kalder, ligesom det er en god ide at studere alle warnings fra
kompileren grundigt.

> Vi skal blot skrive:
> #include <ctype.h>
>
> for at gøre dette, ikke?
>
Ja.


Peder Skyt, Z=nospam (17-05-2003)
Kommentar
Fra : Peder Skyt, Z=nospam


Dato : 17-05-03 19:42

On Sat, 17 May 2003 18:14:16 +0200, "Lasse Bigum"
<Lasse[R:E:M:O:V:E]@hardwareonline.dk> wrote:

>>> Er der nogen der kan give nogle gode kommentarer? Har været inde på
>>> http://gcc.gnu.org/onlinedocs/ og kigge, men der er så mange flag at jeg
>>> ikke kan overskue dem.

Pjat. Vær ærlig - du gider bare ikke sætte dig ind i dem

>> Jeg har ikke prøvet at kompile på solaris men kender dog gcc fra cygwin
>> og linux.

Ditto her.

>(Vores make-file er vedhæftet denne post
Nej, det er den ikke. Det er heller ikke tilladt i denne gruppe
Brug en webserver.

>gcc -c main.c -o main.o -ansi -g3 -pedantic -Wall
Husk "-I."

>main.c:13: parse error before `argumenter'
Den kender ikke "arg"

>main.c:17: parse error before `*'
Den kender ikke "knude"

>main.c:28: parse error before `int'
Den kender ikke RydTempResultat()

>#include "header.h"
Det er måske en forkert "header.h" den får fat i?

Nedenfor finder du en makefile-template du evt. kan bruge (den er
testet med nyeste cygwin). Husk at ændre MAKEFILE, at indentation skal
være tabulering, og at tomme linier skal være *helt* tomme. Og Solaris
hedder antageligvis noget andet end i686...


/Peder Skyt

----hello.mk == everything below---
MAKEFILE = hello.mk

# Select target
CC_ARCH = -march=i686 -m128bit-long-double

# Define some optimization choices
CC_OPTIM_0 = $(CC_ARCH) -O0 -g
CC_OPTIM_1 = $(CC_ARCH) -O1 -s
CC_OPTIM_2 = $(CC_ARCH) -O2 -s
CC_OPTIM_3 = $(CC_ARCH) -O3 -s
CC_OPTIM_X = $(CC_ARCH) -O3 -s -ffast-math -funroll-loops
-malign-double

# Select optimization
CC_OPTIM = ${CC_OPTIM_3}

# Memo-to-self: Options implied by -Wall
CC_OPTS_Wall = \
   -Wchar-subscripts \
   -Wcomment \
   -Wformat \
   -Wimplicit-int \
   -Wimplicit-function-declaration \
   -Wmain \
   -Wmissing-braces \
   -Wparentheses \
   -Wreorder \
   -Wreturn-type \
   -Wsequence-point \
   -Wswitch \
   -Wtrigraphs \
   -Wuninitialized \
   -Wunused-function \
   -Wunused-label \
   -Wunused-parameter \
   -Wunused-variable \
   -Wunused-value

# Memo-to-self: Options not used
CC_OPTS_DontUse = \
   -Waggregate-return \
   -Wformat=2 -Wformat-nonliteral -Wformat-security \
   -Wpadded \
   -Wunreachable-code

# Options common to both C and C++
CC_OPTS_Common = \
   -pipe \
   -pedantic \
   -pedantic-errors \
   -W -Wall -Werror \
   -Wconversion \
   -Wdisabled-optimization \
   -Wfloat-equal \
   -Winline \
   -Wmissing-format-attribute \
   -Wmissing-noreturn \
   -Wno-long-long \
   -Wpacked \
   -Wredundant-decls \
   -Wshadow \
   -Wundef \
   -Wwrite-strings \
   $(CC_OPTIM)

# Options for compiling C programs
CC_OPTS_for_C = \
   $(CC_OPTS_Common) -I. -I/usr/local/include -L/usr/local/lib
-lc \
   -Wmissing-declarations \
   -Wmissing-prototypes \
   -Wnested-externs \
   -Wredundant-decls \
   -Wstrict-prototypes

# Options for compiling C++ programs
CC_OPTS_for_Cpp = \
   $(CC_OPTS_Common) -I. -I/usr/local/include -L/usr/local/lib
-lstdc++\
   -ffor-scope \
   -Wold-style-cast \
   -Wredundant-decls \
   -Wsign-promo


all: hello1 hello2

hello1:      $(MAKEFILE) hello1.c hello1.h
   $(CC) 2>&1 hello1.c -o $@ $(CC_OPTS_for_C)

hello2:      $(MAKEFILE) hello2.cpp hello2.hpp
   $(CC) 2>&1 hello2.cpp -o $@ $(CC_OPTS_for_Cpp)


Lasse Bigum (17-05-2003)
Kommentar
Fra : Lasse Bigum


Dato : 17-05-03 20:56

> Pjat. Vær ærlig - du gider bare ikke sætte dig ind i dem

Har du set listen? Der er mange.....men ja, det kan du godt tolke som et
"jeg gider ikke at sætte mig ind i dem"

> >(Vores make-file er vedhæftet denne post
> Nej, det er den ikke. Det er heller ikke tilladt i denne gruppe
> Brug en webserver.

Ok, vedhæftede filer er bandlyst? Rart nok at vide

> >gcc -c main.c -o main.o -ansi -g3 -pedantic -Wall
> Husk "-I."

Hvad gør -I flagget?

> >main.c:13: parse error before `argumenter'
> Den kender ikke "arg"
>
> >main.c:17: parse error before `*'
> Den kender ikke "knude"
>
> >main.c:28: parse error before `int'
> Den kender ikke RydTempResultat()
>
> >#include "header.h"
> Det er måske en forkert "header.h" den får fat i?

Nej, for det virker som sagt fint på Windows. Jeg har smidt et link til den
rar-pakkede source i en af mine andre svar, men du kan også lige få linket
hvis det har interesse: http://but.auc.dk/~labi0233/source.rar

> Nedenfor finder du en makefile-template du evt. kan bruge (den er
> testet med nyeste cygwin). Husk at ændre MAKEFILE, at indentation skal
> være tabulering, og at tomme linier skal være *helt* tomme. Og Solaris
> hedder antageligvis noget andet end i686...

Jeg vil lige give den en chance, jeg prøver....takk

/Lasse



Igor V. Rafienko (16-05-2003)
Kommentar
Fra : Igor V. Rafienko


Dato : 16-05-03 20:11

[ Lasse Bigum ]

[ ... ]

> Jeg studerer på AUC hvor vi har lavet et program der vha. Genetisk
> Algoritmer kan finde den optimale løsning til TSP problemer,


*himmel*

Og dette gjør dere i C? Kondolerer.

[ ... ]


> Der er dog et *enkelt* men. Det tager rigtigt lang tid at køre disse
> tests, og det er grunden til at vi gerne vil have dem til at køre på
> AUC's basis-server, dolomit. Men vi kan ikke compile vores kode på
> solaris, som vi gør på Windows. Jeg har fået at vide at der skulle
> være nogle make-flags man kan smide som gør at gcc bliver MEGET
> mindre streng med hvor variablerne er deklareret og om vores
> header.h fil bliver inkludereret flere gange (og derved prototyper
> vi vores funktioner flere gange).


Det slår meg at innstillingen _deres_ er veldig interessant -- dere
vil ikke fikse høyst sannsynligvis defekt kode, men vil heller tvinge
kompilatoren til å akseptere noe som kanskje ikke er lovlig C?

Men, tilbake til problemstillingen. Det å #include'e _deklarasjoner_
av variable og funksjoner flere ganger er lovlig i C og gcc aksepterer
dette. Derimot skal det finnes en og bare en _definisjon_ av
variable/funksjoner. Sikker på at du ikke forveksler disse to?

Kan du poste det _minste_ eksempelet som illustrerer problemet med gcc?

[ ... ]





ivr
--
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

Lasse Bigum (17-05-2003)
Kommentar
Fra : Lasse Bigum


Dato : 17-05-03 17:22

> > Jeg studerer på AUC hvor vi har lavet et program der vha. Genetisk
> > Algoritmer kan finde den optimale løsning til TSP problemer,
>
> *himmel*
>
> Og dette gjør dere i C? Kondolerer.

Heh, ja....siger heller ikke det var nemt, men nu virker det. Dog har vi
nogle overflows eller sådan noget hø nogle enkelte steder, hvilket betyder
at vi bliver nødt til at udføre den samme operation 2 gange for at sikre os
at resultatet bliver rigtigt, gør vi det kun én gang kan der risikere at
komme en skrald-værdi i variablen.

> > Der er dog et *enkelt* men. Det tager rigtigt lang tid at køre disse
> > tests, og det er grunden til at vi gerne vil have dem til at køre på
> > AUC's basis-server, dolomit. Men vi kan ikke compile vores kode på
> > solaris, som vi gør på Windows. Jeg har fået at vide at der skulle
> > være nogle make-flags man kan smide som gør at gcc bliver MEGET
> > mindre streng med hvor variablerne er deklareret og om vores
> > header.h fil bliver inkludereret flere gange (og derved prototyper
> > vi vores funktioner flere gange).
>
>
> Det slår meg at innstillingen _deres_ er veldig interessant -- dere
> vil ikke fikse høyst sannsynligvis defekt kode, men vil heller tvinge
> kompilatoren til å akseptere noe som kanskje ikke er lovlig C?

Ikke helt forstået? Jeg vil give dig ret i at det virker som om at Dev-C++'s
compiler er RET ligeglad med mange ting, for jeg tror at et compile på en
Unix/Linux dåse vil give betydeligt flere warnings og fejl, men nu kodede vi
altså allesammen på Windows.

> Men, tilbake til problemstillingen. Det å #include'e _deklarasjoner_
> av variable og funksjoner flere ganger er lovlig i C og gcc aksepterer
> dette. Derimot skal det finnes en og bare en _definisjon_ av
> variable/funksjoner. Sikker på at du ikke forveksler disse to?

Jeg forveksler dem ikke, for en af vores nabogrupper havde netop et problem
med dette, og de blev nødt til at lave en header-fil til hver .c fil, for
deri at lave deres prototyper på funktionerne. Hvis de lavede altsammen i én
samlet header-fil, så gav den warnings (eller fejl? er ikke lige sikker)

> Kan du poste det _minste_ eksempelet som illustrerer problemet med gcc?
Mit svar på Bertel Branders post skulle gerne indeholde et eksempel, men det
kan ikke compileres, hvis du er interesseret i at få koden tilsendt og se
problemet for dig selv, så gør jeg gladeligt dette

/Lasse



Mogens Hansen (17-05-2003)
Kommentar
Fra : Mogens Hansen


Dato : 17-05-03 18:45


"Lasse Bigum" <Lasse[R:E:M:O:V:E]@hardwareonline.dk> wrote

[8<8<8<]
> Dog har vi
> nogle overflows eller sådan noget hø nogle enkelte steder, hvilket betyder
> at vi bliver nødt til at udføre den samme operation 2 gange for at sikre
os
> at resultatet bliver rigtigt, gør vi det kun én gang kan der risikere at
> komme en skrald-værdi i variablen.

Kan du forklare det lidt nærmere ?
Hvorfor skal du udføre den samme operation 2 gange, og hvordan _sikrer_ det
jer at resultatet så er _rigtigt_ ?

Lyder det ikke som om at løsningen på det problem er at få operationen til
at virke første gang ?

[8<8<8<]
> > Det slår meg at innstillingen _deres_ er veldig interessant -- dere
> > vil ikke fikse høyst sannsynligvis defekt kode, men vil heller tvinge
> > kompilatoren til å akseptere noe som kanskje ikke er lovlig C?
>
> Ikke helt forstået? Jeg vil give dig ret i at det virker som om at
Dev-C++'s
> compiler er RET ligeglad med mange ting, for jeg tror at et compile på en
> Unix/Linux dåse vil give betydeligt flere warnings og fejl, men nu kodede
vi
> altså allesammen på Windows.

Det lyder ikke som en egenskab ved operativsystemerne, men nærmere som
egenskaber ved de compilere der anvendes.
Giver gcc væsentligt forskellige warnings på Linux og MS-Windows ?

Prøv at læs Igor V. Rafienko's kommentar een gang til.
Der er højest sandsynligt noget galt med jeres kode. Den rigtige løsning er
at sikre at koden forekommer at være korrekt, inden man forsøger at
oversætte med en anden compiler.

[8<8<8<]
> Jeg forveksler dem ikke, for en af vores nabogrupper havde netop et
problem
> med dette, og de blev nødt til at lave en header-fil til hver .c fil, for
> deri at lave deres prototyper på funktionerne. Hvis de lavede altsammen i
én
> samlet header-fil, så gav den warnings (eller fejl? er ikke lige sikker)

Hmm...
Det lyder underligt.
Faktisk lyder det ikke rigtigt - der må være noget andet på spil.


Venlig hilsen

Mogens Hansen



Lasse Bigum (17-05-2003)
Kommentar
Fra : Lasse Bigum


Dato : 17-05-03 21:10

> > Dog har vi
> > nogle overflows eller sådan noget hø nogle enkelte steder, hvilket
betyder
> > at vi bliver nødt til at udføre den samme operation 2 gange for at sikre
> os
> > at resultatet bliver rigtigt, gør vi det kun én gang kan der risikere at
> > komme en skrald-værdi i variablen.
>
> Kan du forklare det lidt nærmere ?
> Hvorfor skal du udføre den samme operation 2 gange, og hvordan _sikrer_
det
> jer at resultatet så er _rigtigt_ ?
>
> Lyder det ikke som om at løsningen på det problem er at få operationen til
> at virke første gang ?

Jeg giver dig ret i at det lyder meget underligt, dumt, forkert, og som
noget der bør rettes. MEN, nu er vi jo studerende i den situation at vores
program + rapport skal afleveres om noget der ligner 8 dage, så vores
primære fokus er at skidtet virker, hvilket det gør. Nu er det bare sådan at
vi gerne vil have banket nogle flere, og længere tests igennem, inden vi
skal op til eksamen, og det virker en universitets-server som det helt
rigtige at lade gøre. Men vi kan ikke compile det :-/

Hvordan det sikrer os at resultatet er rigtigt? Det kan vi gøre ved at
printe indholdet af variablen ud lige efter den bliver assignet. Vi kan blot
konstatere at hvis vi _ikke_ gør det 2 gange, så får vi skraldværdier, gør
vi det fungerer det "som det skal" (og så alligevel ikke helt, i og med at
vi jo netop skal gøre det 2 gange )


> > > Det slår meg at innstillingen _deres_ er veldig interessant -- dere
> > > vil ikke fikse høyst sannsynligvis defekt kode, men vil heller tvinge
> > > kompilatoren til å akseptere noe som kanskje ikke er lovlig C?
> >
> > Ikke helt forstået? Jeg vil give dig ret i at det virker som om at
> Dev-C++'s
> > compiler er RET ligeglad med mange ting, for jeg tror at et compile på
en
> > Unix/Linux dåse vil give betydeligt flere warnings og fejl, men nu
kodede
> vi
> > altså allesammen på Windows.
>
> Det lyder ikke som en egenskab ved operativsystemerne, men nærmere som
> egenskaber ved de compilere der anvendes.
> Giver gcc væsentligt forskellige warnings på Linux og MS-Windows ?
>
> Prøv at læs Igor V. Rafienko's kommentar een gang til.
> Der er højest sandsynligt noget galt med jeres kode. Den rigtige løsning
er
> at sikre at koden forekommer at være korrekt, inden man forsøger at
> oversætte med en anden compiler.

Vi kan ret hurtigt blive enige om at der *et* eller andet sted i koden er
noget der går galt, men det kan altså compiles og køres under Windows uden
at det skaber sig. Dette vil vi også gerne opnå på Solaris serveren. Vi
bruger GCC.exe under Windows og gcc under Solaris, skulle mene forskellen er
den samme, men de flags der sendes til compileren er sikkert ikke. Det var
det jeg håbede I kunne give mig nogle tip om.

GCC giver os ikke direkte warnings, men vores IDE (Dev-C++) gør, det er
udelukkende disse vi reagerer på når vi koder under Windows. De warnings som
gcc kaster af sig når vi prøver at compile under Solaris virker uforståelige
på os. Vi *har* defineret de ting den brokker sig over.

> > Jeg forveksler dem ikke, for en af vores nabogrupper havde netop et
> problem
> > med dette, og de blev nødt til at lave en header-fil til hver .c fil,
for
> > deri at lave deres prototyper på funktionerne. Hvis de lavede altsammen
i
> én
> > samlet header-fil, så gav den warnings (eller fejl? er ikke lige sikker)
>
> Hmm...
> Det lyder underligt.
> Faktisk lyder det ikke rigtigt - der må være noget andet på spil.

Ja, men næppe nisser, højst dårlig/ukorrekt kodning fra vores side. Jeg ved
godt det lyder meget dovent og ladt bare at skrive "det virker på Windows,
så det gider vi altså ikke at pille mere i", men det er første gang vi koder
i C, vi har haft 10 forelæsninger om det, og "that's it". Alt i alt synes
jeg vi har lavet noget helt OK kode, minus det med at der et eller andet
sted er en fejl der bevirker vi skal lave de operationer 2 gange før de
virker.

Med mit indlæg her håbede jeg lidt på at de warnings gcc giver under Solaris
var nogen man kunne se bort fra, og det blot var et spørgsmål om at give gcc
de rigtige flag for at det virkede.

/Lasse



Mogens Hansen (18-05-2003)
Kommentar
Fra : Mogens Hansen


Dato : 18-05-03 08:27


"Lasse Bigum" <Lasse[R:E:M:O:V:E]@hardwareonline.dk> wrote

[8<8<8<]
> Jeg giver dig ret i at det lyder meget underligt, dumt, forkert, og som
> noget der bør rettes. MEN, nu er vi jo studerende i den situation at vores
> program + rapport skal afleveres om noget der ligner 8 dage, så vores
> primære fokus er at skidtet virker, hvilket det gør.

Det er klart at der ligger et tidspres.

Problemet er blot, at hvis programmet har lidt problemer på een platform er
det ikke usandsynligt at det får nogle lidt andre problemer, når man flytter
det til en anden platform.

[8<8<8<]
> Vi
> bruger GCC.exe under Windows og gcc under Solaris, skulle mene forskellen
er
> den samme, men de flags der sendes til compileren er sikkert ikke. Det var
> det jeg håbede I kunne give mig nogle tip om.

Er det samme version af gcc (skriv gcc --version) ?

Venlig hilsen

Mogens Hansen



Lasse Bigum (18-05-2003)
Kommentar
Fra : Lasse Bigum


Dato : 18-05-03 12:21

> Det er klart at der ligger et tidspres.
>
> Problemet er blot, at hvis programmet har lidt problemer på een platform
er
> det ikke usandsynligt at det får nogle lidt andre problemer, når man
flytter
> det til en anden platform.

Ja, det er vist ret tydeligt at det er tilfældet her, hehe...men så er det
jo bare at starte omvendt en anden gang, dvs. kode til den mere strikse
compiler først og så flytte det nemt (og uden fejl) over til Windows
bagefter.

> > Vi
> > bruger GCC.exe under Windows og gcc under Solaris, skulle mene
forskellen
> er
> > den samme, men de flags der sendes til compileren er sikkert ikke. Det
var
> > det jeg håbede I kunne give mig nogle tip om.
>
> Er det samme version af gcc (skriv gcc --version) ?

egcs-2.91.66

/Lasse



Per Abrahamsen (20-05-2003)
Kommentar
Fra : Per Abrahamsen


Dato : 20-05-03 16:44

"Lasse Bigum" <Lasse[R:E:M:O:V:E]@hardwareonline.dk> writes:

> Ja, det er vist ret tydeligt at det er tilfældet her, hehe...men så er det
> jo bare at starte omvendt en anden gang, dvs. kode til den mere strikse
> compiler først og så flytte det nemt (og uden fejl) over til Windows
> bagefter.

Så simpelt er det altså ikke. Jeres GCC på MS Windows er nyere end
den i har på Solaris, det betyder at den tillader flere ting fra nye
standarder (C99), men *også* at den har fjernet ting fra gamle
standarder, tvivlsomme udvidelser, og er blevet bedre til at finde
regulære fejl i koden.

Det smarteste ville nok være at bruge den nye GCC, men med -ansi
-pedantic" flag så den ville brokke sig hvis i brugte features der lå
udenfor C89 standarden.

Søg
Reklame
Statistik
Spørgsmål : 177558
Tips : 31968
Nyheder : 719565
Indlæg : 6408924
Brugere : 218888

Månedens bedste
Årets bedste
Sidste års bedste