[C] probleem

[DaFearLess]

ik ben begonne met een beetje C programeren

maar ik ben nu al twee dagen aan het zoeken hoe je iets mee kan geven aan het programma


dus als ik een prog test maakt

en ik start het op met

./test txt

dat hij dan het argument wat ik opgegeven heb als een gebruikt in het programma


mischien een beetje vaag uitgelegd maar kweet niet hoe ik het uit moet leggen laat staan dat ik goed kan zoeken


alvast bedankt

[Verwijderd]

code:

int main(int argc, char* argv[])
{ 
 int i;
 for (i=1; i<argc; i++) printf("%d %s\n",i,argv[i]);
 return 0;
}

[yodax]

je moet dan zoiets als:

code:

#include <iostream.h>
void main(int argc, char **argv)
{
  cout << "Received " << argc << " arguments...\n";
  for (int i=0; i<argc; i++)
    cout << "argument " << i << ": " << argv[i] << endl;
}

Alleen is cout c++ maar je snapt het wel.

[elnino]

Op Sunday 28 October 2001 20:49 schreef yodax het volgende:
je moet dan zoiets als:

code:

#include <iostream.h>
void main(int argc, char **argv)
{
  cout << "Received " << argc << " arguments...\n";
  for (int i=0; i<argc; i++)
    cout << "argument " << i << ": " << argv[i] << endl;
}

Alleen is cout c++ maar je snapt het wel.

In C moet je printf gebruiken met daarin %d, %s etc. Je kent het wel en stdio.h i.p.v. iostream.h. Een goede C tutorial is trouwens How Stuff Works (ook genoemd in de FAQ). Daar wordt dit ook in behandeld...

[DaFearLess]

ik heb nu dit

code:

#define SALT "ab"    
#define _XOPEN_SOURCE
#include <stdlib.h>
#include <stdio.h> 
#include <unistd.h>


int main(char* argv[])
{
  int i;
  char * string;
  i=1;
  string=crypt(argv[i],SALT);
  puts(string);
  return 0;
  
}

maar als ik nu het prg draai krijg ik een segmentation error
dat kan nooit goed wezen

de code zal wel erg triest zijn maar ziet iemand wat er fout aan is (of mischien makkelijker wat is er goed aan )

[Infinitive]

ja, je hebt:

int main(char **bla);

staan, i.p.v.:

int main(int argv, char **argv);

Bovendien controleer je niet hoeveel parameters er zijn (dat zit in die argv), dus als er geen paramters zijn meegegeven dan krijg je (hopelijk) een segmentfault.

BTW: hij hoort toch niet eens te compileren als je main functie niet goed gedefinieerd is?

[JeroenB]

Je krijgt wel allemaal voorbeelden maar geen goeie uitleg

Een standaard console applicatie krijgt twee parameters mee (eigenlijk zelfs drie geloof ik met de environment variabelen, maar die laten we even buiten beschouwing.) De main functie ziet er dan zo uit:

code:

int main(int argc, char *argv[])
{
  return 0;
}

argc is een int waarin het aantal commandline parameters staat, inclusief de naam van het programma zelf. argv is een array met daarin al die parameters. Als je dus een programma compiled naar hallo.exe en dat runt met de parameters parm1 en parm2, dan tik je dus dit in:

C:\hallo.exe parm1 parm2

argc is dan 3 en argv heeft ook 3 elementen:

argv[0] == "C:\hallo.exe"
argv[1] == "parm1"
argv[2] == "parm2"

Stel je wilt de gebruiker verplichten om 2 parameters mee te geven, dan doe je dat bijv. zo:

code:

#include <stdio.h>

int main(int argc, char *argv[])
{
  if(3 == argc)
  {
    printf("Nee lul, je moet twee parameters opgeven!\n");
    return -1;
  }

  // doe hier wat met de parameters

  return 0;
}

Denk eraan, voor 2 parameters check je dus op 3 omdat de commandline waar de executable zelf instaat ook meetelt

(En voor degenen die moeilijk doen over mijn notatie, ik doe (3 == argc) omdat als je per ongeluk = ipv == doet dan krijg je als je eerst het nummer doet een compiler error, anders compileert het wel maar heb je een rare bug )

[DaFearLess]

ok ik heb nu dit en dat werkt perfect

code:

#define SALT "ab"
#define _XOPEN_SOURCE 
#include <stdlib.h>  
#include <stdio.h>   
#include <unistd.h>

int main(int argc, char* argv[])
{ 
  if(3 == argc)
  {
    printf("Nee lul, je moet een parameters opgeven!\n");
    return -1;
  }

  if(1 == argc)
  {
    printf("Nee lul, je moet een parameters opgeven!\n");
    return -1;
  }

  char * string;
  string=crypt(argv[1],SALT);
  puts(string);
  return 0; 
}

ok het werkt nu harstikke bedankt
en een goeie uitleg ook snap zelfs wat ik gedaan heb

[.oisyn]

Op Sunday 28 October 2001 21:35 schreef JeroenB het volgende:

[.. bladiebladiebla ..]

code:

#include <stdio.h>

int main(int argc, char *argv[])
{
  if(3 == argc)
  {
    printf("Nee lul, je moet twee parameters opgeven!\n");
    return -1;
  }

  // doe hier wat met de parameters

  return 0;
}

[.. bladiebladiebla ..]

uhm, maak daar maar van: if (argc != 3)
Nu geeft ie die foutmelding alleen als je 2 parameters meegeeft

en dafearless: bij jou moet het dus worden: if (argc != 2)

[stylee]

code:

if(3 == argc)

FF OiSyN' opmerking achterwege latend... ik heb nooit begrepen hoe mensen condities op deze manier kunnen schrijven

code:

if(argc == 3)

is toch veeeeeeeeeeel duidelijker en uhm mja makkelijker om te mappen naar werkelijkheid ofzo

Netals in DirectX in 24 uur waar ze code schrijven als

code:

if (TRUE == bla) { ... }

Zal wel iets met persoonlijke stijl en smaak te maken hebben maar ik kon het niet laten

[Verwijderd]

Stel je vergeet een =

code:

if (3= argc)

Geeft dit een compiler error, terwijl

code:

if(argc = 3)

Gewoon compileerd en een fantastishe bug frabriceerd.

Kortom bescherming tegen typo's/bugs erg praktish als je je die manier van programeren aanleerd.

[edit: layout een bietje bij geschaafd]

[drm]

Op maandag 29 oktober 2001 00:25 schreef Yarvieh het volgende:
Stel je vergeet een =

code:

if (3= argc)

Geeft dit een compiler error, terwijl

code:

if(argc = 3)

Gewoon compileerd en een fantastishe bug frabriceerd.

Kortom bescherming tegen typo's/bugs erg praktish als je je die manier van programeren aanleerd.

[edit: layout een bietje bij geschaafd]

Vind ik wel een goeie, maar of dat opweegt tegen de leesbaarheid
Zo'n fantastische bug is het trouwens niet eens, want dat zijn toch dingen die je (ik wel iig) het eerst ziet.

[JeroenB]

drm: Ik had het zelf notabene gemotiveerd in mijn oorspronkelijke post, onderaan (Waarom ik die omgekeerde notatie gebruik.)

OiSyN: Je hebt natuurlijk helemaal gelijk, typo... Zo zie je maar weer dat de oude stelregel voor code op usenet ook hier op het forum opgaat: Alleen code plaatsen als je het zelf hebt gecompiled en getest Een typo zit tenslotte in een klein hoekje...

[Verwijderd]

terwijl
------------
if(argc = 3)
------------
Gewoon compileerd en een fantastishe bug frabriceerd.

Alleen als je dom genoeg bent om geen warnings aan te zetten:

code:

int blah = 0;

int main(void)
{
    if (blah = 1) {
        blah++;
    }
    return 0;
}

code:

$ gcc -W -Wall test.c
test.c: In function `main':
test.c:5: warning: suggest parentheses around assignment used as truth value

[Verwijderd]

Maar dat is weer een beetje compiler afhankelijk, visual C genereerd er bv standaard (Warnig level 3) geen warning voor. (level 4 wel overigens)

[igmar]

code:

#define SALT "ab"    
#define _XOPEN_SOURCE
#include <stdlib.h>
#include <stdio.h> 
#include <unistd.h>


int main(int argc, char ** argv)
{
  char * string;

  if (argc < 2) {
    printf("Usage: %s value\n", argv[0]);
    exit(1);
  }
  
  string=crypt(argv[1],SALT);
  printf("%s", string);
  return 0;
  
}

Dit zal het beter doen. Ongetest, niet gecompileerd, maar het zal er niet veel naast zitten.

[JeroenB]

Jan_Klaassen: Persoonlijk vind ik het dommer (als we toch in die termen gaan praten) om uit te gaan bij het vinden van bugs van de reactie van een compiler op een syntactisch correct statement.

[.oisyn]

Op maandag 29 oktober 2001 21:13 schreef JeroenB het volgende:
Jan_Klaassen: Persoonlijk vind ik het dommer (als we toch in die termen gaan praten) om uit te gaan bij het vinden van bugs van de reactie van een compiler op een syntactisch correct statement.

Hoewel ik jouw notatie niet gebruik ben ik het wel met je eens. Bij veel compilers kun je die warning aanzetten, maar het komt ook wel eens voor dat ik het echt WIL met = ipv ==, dus een assignment en gelijk een if om de waarde te checken.
Ben het overigens wel met je eens als je zegt dat dat de leesbaarheid niet echt ten goede komt, maar mits goed gecomment kan iedereen zien dat wat daar staat ook goed is

[Verwijderd]

Op maandag 29 oktober 2001 21:58 schreef OiSyN het volgende:
Hoewel ik jouw notatie niet gebruik ben ik het wel met je eens. Bij veel compilers kun je die warning aanzetten, maar het komt ook wel eens voor dat ik het echt WIL met = ipv ==, dus een assignment en gelijk een if om de waarde te checken.

Klopt, en daarom is er dus een afspraak dat er niet gewarned wordt al een assignment binnen een conditionele expressie tussen haakjes staat. (Iig. de hele unix-famillie van compilers doet dat.)

code:

int main() {
  int blah;

  if(blah = 1) {}
  /* warning: suggest parentheses around */
  /* assignment used as truth value */

  /* dus: */
  if( (blah = 1) ) {}
  /* geen warning */

  return 0;
}

[Verwijderd]

Jan_Klaassen: Persoonlijk vind ik het dommer (als we toch in die termen gaan praten) om uit te gaan bij het vinden van bugs van de reactie van een compiler op een syntactisch correct statement.

Nou, dat vind ik dan een domme instelling

Eén van de redenen dat warnings bestaan is om de programmeurs er op te wijzen dat ze iets op een ambigue, en/of potentieel foute manier hebben gedaan, syntactisch correct of niet. Vind ik persoonlijk erg handig. Bovendien wordt duidelijk aangegeven hoe je die warning kunt vermijden, zie de post van Mietje hierboven.

[Verwijderd]

Thou shalt run lint frequently and study its pronouncements with care, for verily its perception and judgement oft exceed thine.

</oude_wijsheden>

[Korben]

Jan_Klaassen:

[..]

... Bovendien wordt duidelijk aangegeven hoe je die warning kunt vermijden, zie de post van Mietje hierboven.

Hmm dat is lang niet altijd... consider this:

code:

void *bert;

// ...

delete bert;

Krijg ik als warning:

code:

warning: void * is not a pointer-to-object.

Duidelijk... hmmm Ik bedoel ik weet wel hoe ik het moet oplossen:

code:

delete (een_struct_naam *)bert;

Maar ik kan me voorstellen dat de gemiddelde n00b dat niet weet.

[igmar]

Hmm dat is lang niet altijd... consider this:

code:

void *bert;

// ...

delete bert;

Krijg ik als warning:

code:

warning: void * is not a pointer-to-object.

Duidelijk... hmmm Ik bedoel ik weet wel hoe ik het moet oplossen:

code:

delete (een_struct_naam *)bert;

Maar ik kan me voorstellen dat de gemiddelde n00b dat niet weet.

delete is geen C operator, maar C++. Totaal OT in dit geval dus, aangezien de C++ regels anders zijn als de C regels.

[Verwijderd]

void *bert;

Oh, the horror!

code:

$ gcc -W -Wall test.cpp
test.cpp: In function `int main()':
test.cpp:5: warning: `void *' is not a pointer-to-object type

Zo duidelijker?

[curry684]

Op maandag 29 oktober 2001 00:25 schreef Yarvieh het volgende:
Geeft dit een compiler error, terwijl

code:

if(argc = 3)

Gewoon compileerd en een fantastishe bug frabriceerd.

Even Borland citeren:

[C++ Warning] main.cpp(15): W8060 Possibly incorrect assignment

En regel 1 van netjes C++ programmeren luidt nog steeds als volgt: EEN WARNING IS EEN ERROR

Dus ik prefereer hier ook leesbaarheid boven de 'bonus' van een error ipv warning. Het klopt ook gewoon voor je gevoel niet, als je op de markt loopt ga je ook niet drie vergelijken met het aantal appels in je mandje, maar ga je kijken of het aantal appels gelijk is aan drie.

[JeroenB]

Eén van de redenen dat warnings bestaan is om de programmeurs er op te wijzen dat ze iets op een ambigue, en/of potentieel foute manier hebben gedaan, syntactisch correct of niet. Vind ik persoonlijk erg handig. Bovendien wordt duidelijk aangegeven hoe je die warning kunt vermijden, zie de post van Mietje hierboven.

Warnings bestaan helemaal nergens in C. Sommige compilers implementeren ze om de programmeur te helpen. Laat me raden, je hebt ook zo'n kartonnetje tegen de achterruit van je auto geplakt zodat je als je achteruit aan het parkeren bent weet wanneer je je stuur moet terugdraaien?

Ik ben niet echt onder de indruk van de warnings die allerlei leuke compilers genereren (ook niet van die van curry684.) Als je professioneel software maakt dan kom je dagelijks in omgevingen waar je niet op het gebruik van bepaalde tools kunt bouwen. Je hebt dan alleen je kennis van de taal waar je het mee moet doen.

Die taal heeft allerlei mogelijkheden om het basisniveau van de software die je schrijft te verhogen zonder de interventie van ander gereedschap. Het omdraaien van de values in zo'n statement is er daar eentje van.

Conclusie: Warnings zijn features van handige compilers. Handige ontwikkelaars kunnen echter ook met stomme compilers werken.

[Nappa]

Op dinsdag 30 oktober 2001 16:00 schreef JeroenB het volgende:
(bla)
Conclusie: Warnings zijn features van handige compilers. Handige ontwikkelaars kunnen echter ook met stomme compilers werken.

Maar de warnings zijn wel degelijk nuttig, ze verhogen het gemak van het programmeren/debuggen wel enigszins. Je kunt wel met stomme compilers werken, maar waarom zou je als je ook een slimme compiler tot je beschikking hebt?

[Verwijderd]

Conclusie: Warnings zijn features van handige compilers. Handige ontwikkelaars kunnen echter ook met stomme compilers werken.

Maar de écht handige ontwikkelaars maken gebruik van de handige features van handige compilers.

Ik heb één basgitaar met 4 snaren, en één met 5. Volgens jouw logica zou ike de lage B van de 5 snarige bas niet mogen gebruiken

[curry684]

Op dinsdag 30 oktober 2001 16:00 schreef JeroenB het volgende:
(bla)
Conclusie: Warnings zijn features van handige compilers. Handige ontwikkelaars kunnen echter ook met stomme compilers werken.

Erg kortzichtig.

Zoals ik al zei: als je slim bent is beschouw je iedere warning als een error die verwijderd dient te worden, desnoods door een pragma. Het is een error, of het nu voortkomt uit ambigue grammaticagebruik of een downcast die 'toch wel goed gaat' of zo. Hij is alleen toevallig niet direct fataal voor het compileproces. Ik zou er persoonlijk niets op tegen hebben als warnings in de volgende versie van VS en BCB gewoon non-fatal error heten en/of alleen in debugbuilds toegestaan worden.

Ennuh ik weet niet met wat voor compilers jij werkt, maar zelfs omgevingen voor embedded sub-2Kb programmatuur geven deze warnings. Of werk jij nog op de C-64?

[.oisyn]

Op dinsdag 30 oktober 2001 11:38 schreef curry684 het volgende:

[..]

Even Borland citeren:

[C++ Warning] main.cpp(15): W8060 Possibly incorrect assignment

En regel 1 van netjes C++ programmeren luidt nog steeds als volgt: EEN WARNING IS EEN ERROR

Dus ik prefereer hier ook leesbaarheid boven de 'bonus' van een error ipv warning. Het klopt ook gewoon voor je gevoel niet, als je op de markt loopt ga je ook niet drie vergelijken met het aantal appels in je mandje, maar ga je kijken of het aantal appels gelijk is aan drie.

en als je nou geen appels lust?

Overigens heb je wel gelijk. Ikzelf compile bijna altijd op het hoogste warning level, en ik treat ze ook als errors. Op die manier zijn er ook geen warnings die echt serieus fout zijn door een typefout ofzo die niet opvallen tussen de andere warnings waar je verder niet naar kijkt.

Het moet gewoon compilen met 0 errors en 0 warnings, zo niet: code aanpassen!

[JeroenB]

Jan_Klaassen: Maar stel nu dat je moet optreden en je 5-snarige bas is kapot? Dan klinkt de muziek die je maakt dus gewoon verkeerd, omdat je ervanuit gaat dat je 5 snaren hebt?

curry684: Warnings bestaan niet in C/C++, warnings zijn verzonnen door compiler-makers. Derhalve zijn het dus ook geen fouten.

En begrijp me nou niet verkeerd, ik zet zelf de warninglevels zo hoog als ze maar kunnen, vooral als ik een final build maak voor een release. Waar het me alleen om gaat is dat argumenten als "intuitief" en "je moet gebruik maken van de features" allemaal niet kunnen opwegen tegen een methode die alle problemen op een bepaald punt simpelweg kan voorkomen.

Zie het als ESP op je auto: als je dan in de slip gaat stuurt de auto bij. Het hebben van zo'n veiligheidsfunctie op je auto zorgt er toch niet voor dat je als een idioot door de bocht gaat "omdat de auto het toch wel oplost"? Zelf doe ik liever een slipcursus en *natuurlijk* ben ik vervolgens wel blij als de feature op mijn auto zit. Maar als verantwoordelijke bestuurder mag je daar simpelweg niet vanuit gaan. En hetzelfde is waar voor programmeurs.

[curry684]

Op woensdag 31 oktober 2001 12:32 schreef JeroenB het volgende:
Jan_Klaassen: Maar stel nu dat je moet optreden en je 5-snarige bas is kapot? Dan klinkt de muziek die je maakt dus gewoon verkeerd, omdat je ervanuit gaat dat je 5 snaren hebt?

Exact. Je mist namelijk de onderste 5 noten die het ding kan spelen, dus kun je het (waarschijnlijk) niet. (duh )

curry684: Warnings bestaan niet in C/C++, warnings zijn verzonnen door compiler-makers. Derhalve zijn het dus ook geen fouten.

Ja heel leuk, maar Stroustrup & Co. bedachten ook niet dat jij zonodig assignments ging tikken waar je comparisons wil hebben. Dat de taal het per ongeluk slikt wil nog niet zeggen dat het correct is.

En sowieso vind ik een natuurlijke afkeer van dingen die niet officieel zijn nogal een walgelijk excuus om ze expres nog fouter te doen...

[Verwijderd]

Jan_Klaassen: Maar stel nu dat je moet optreden en je 5-snarige bas is kapot? Dan klinkt de muziek die je maakt dus gewoon verkeerd, omdat je ervanuit gaat dat je 5 snaren hebt?

Maar ik kan prima overweg met een 4-snarige bas, dus dat is geen enkel probleem. Het zijn verschillende instrumenten, dus je past je gewoon aan aan het instrument dat je speelt.

Waarom zou je zo star zijn?

En begrijp me nou niet verkeerd, ik zet zelf de warninglevels zo hoog als ze maar kunnen, vooral als ik een final build maak voor een release. Waar het me alleen om gaat is dat argumenten als "intuitief" en "je moet gebruik maken van de features" allemaal niet kunnen opwegen tegen een methode die alle problemen op een bepaald punt simpelweg kan voorkomen.

Maar dat is nou net het probleem -- dat is niet zo. Met jouw methode kun je net zo goed fouten maken, en het werkt alleen met constants, niet met variabelen. Een extra paar haakjes werkt altijd.

[.oisyn]

het is overigens wel ERRUG offtopic nu

[drm]

Op woensdag 31 oktober 2001 23:38 schreef Jan_Klaassen het volgende:
Maar ik kan prima overweg met een 4-snarige bas, dus dat is geen enkel probleem. Het zijn verschillende instrumenten, dus je past je gewoon aan aan het instrument dat je speelt.

Waarom zou je zo star zijn?

Een 5de snaar (lage op een bass is helemaal niet interessant voor de "bas(s)ics" _{flauw he}

Dus je vergelijking gaat helemaal niet op. Ik zou er een vergelijking tegenin willen werpen:
Stel, je bas is niet goed gestemd.

De gitarist uit de band zegt: "Warning: je moet je bas stemmen".

Dan zeg jij "Nee, want ik moet het straks ook kunnen spelen op een verpauperde basgitaar die niet meer te stemmen valt, want zo'n situatie komen we vast nog wel eens tegen".

Gitarist: "Ja, maar je kunt deze bas stemmen, waarom doe je het dan niet?"

Jij: "De basgitaar heeft die stemvleugeltjes alleen maar voor de luxe. Een echte basgitarist kan zonder!"

spannend verhaal.

Je hebt die warnings nou eenmaal. It's a feature, not a bug
Gebruik ze dan ook. Voorkom dubbelzinnige code. Doe desnoods twee regels over een actie die ook in 1 kan.

Maar dat is nou net het probleem -- dat is niet zo. Met jouw methode kun je net zo goed fouten maken, en het werkt alleen met constants, niet met variabelen. Een extra paar haakjes werkt altijd.

Maar je sluit meer fouten uit.