[C] comparison between pointer and integer

[Maarten Kroon]

Voor een kleine school opdracht moet ik een stukje C schrijven waarin alle "voorwerpen" uit een Array worden afgedrukt welke een lengte hebben kleiner dan 100 en beginnen met de letter "G". Ik dacht zelf aan het onderstaande:

C:

int j;
  for (j = 0; j < aantalVoorwerpen; j++) {
    if (magazijn[j].lengte <= 100 && magazijn[j].naam[0] == "G") {
      druk_af(magazijn[j]);    
    }
  }

Maar de compiler (DEV C++) komt met de volgende melding:
comparison between pointer and integer

Alle code compiled (en werkt) naar behoren, behalve het stuk dat ervoor moet zorgen dat alleen voorwerpen welke beginnen met "G" getoond worden. Hieronder de volledige code mocht iemand die willen inzien:

C:

#include <stdio.h>

int aantalVoorwerpen = 0;

typedef struct voorwerp{
  int nummer;
  char naam[20];
  float gewicht, lengte;
} Voorwerp;       

void druk_af(Voorwerp v) {
  printf("%-15s heeft nummer %d, weegt %.2f kg en is %.2f cm\n", v.naam, v.nummer, v.gewicht, v.lengte); 
}

int main(void) {
  while(aantalVoorwerpen > 40 || aantalVoorwerpen < 3) {
    printf("Hoeveel voorwerpen wilt u toevoegen?\n");
    scanf("%d", &aantalVoorwerpen);
    if (aantalVoorwerpen > 40 || aantalVoorwerpen < 3) {
      printf("Aantal voorwerpen moet groter of gelijk zijn aan 3 en kleiner of gelijk aan 40\n");
    }
    printf("\n");  
  }
  int i;
  Voorwerp magazijn[40];
  for (i = 0; i < aantalVoorwerpen; i++) {
    printf("Nummer van voorwerp %d\n", i+1);
    scanf("%d", &magazijn[i].nummer);
    printf("Naam van voorwerp %d\n", i+1);
    scanf("%s", &magazijn[i].naam);
    printf("Gewicht van voorwerp %d\n", i+1);
    scanf("%f", &magazijn[i].gewicht);
    printf("Lengte van voorwerp %d\n", i+1);
    scanf("%f", &magazijn[i].lengte);
    printf("\n");
  }

  int j;
  for (j = 0; j < aantalVoorwerpen; j++) {
    if (magazijn[j].lengte <= 100 && magazijn[j].naam[0] == "G") {
      druk_af(magazijn[j]);    
    }
  }

  system("pause");
  return 0;
}

[ Voor 4% gewijzigd door MueR op 26-06-2010 22:25 ]

[Exirion]

Maak van "G" eens 'G' en het werkt. Wat je nu doet is dat je de eerste letter van de string (een char dus) vergelijkt met de pointer naar de const string "G". Da's appels met peren vergelijken.

[Soultaker]

Gebruik voortaan alsjeblieft [code][/code]-tags in plaats van quotes om code te posten, zodat indentation behouden blijft. Dat leest een stuk makkelijker.

(Wat is het trouwens met de C revival op GoT de laatste tijd? Niet dat ik klaag, want 't blijft mijn favoriete programmeertaal, maar het is wel opvallend.)

[H!GHGuY]

lengt zou je trouwens beter geen float maken maar een integer of beter nog, een size_t

[ Voor 18% gewijzigd door H!GHGuY op 26-06-2010 09:15 ]

[Comp_Lex]

Soultaker schreef op zaterdag 26 juni 2010 @ 02:10:
(Wat is het trouwens met de C revival op GoT de laatste tijd? Niet dat ik klaag, want 't blijft mijn favoriete programmeertaal, maar het is wel opvallend.)

offtopic:
Ach, dit soort topics vind ik beter dan al die PHP en SQL topics de hele tijd.

[Haan]

Comp_Lex schreef op zaterdag 26 juni 2010 @ 10:22:
[...]

offtopic:
Ach, dit soort topics vind ik beter dan al die PHP en SQL topics de hele tijd.

offtopic:
Toch kreeg ik koude rillingen toen ik hier in de startpost een method tegenkwam die "druk_af" heet, brrrr.

[ValHallASW]

Exirion schreef op zaterdag 26 juni 2010 @ 01:40:
Maak van "G" eens 'G' en het werkt. Wat je nu doet is dat je de eerste letter van de string (een char dus) vergelijkt met de pointer naar de const string "G". Da's appels met peren vergelijken.

Het irritante hierbij is alleen dat de compiler je letter een 'integer' noemt en je string een 'pointer'. (in plaats van, zeg, char en *char). Hoort dat in gcc 3.4 (de versie die standaard bij dev-c++ zit, vijf jaar oud enzo) of gebruikt TS gewoon een rare compiler?

[ Voor 13% gewijzigd door ValHallASW op 26-06-2010 10:47 ]

[H!GHGuY]

ValHallASW schreef op zaterdag 26 juni 2010 @ 10:45:
[...]

Het irritante hierbij is alleen dat de compiler je letter een 'integer' noemt en je string een 'pointer'. (in plaats van, zeg, char en *char). Hoort dat in gcc 3.4 (de versie die standaard bij dev-c++ zit, vijf jaar oud enzo) of gebruikt TS gewoon een rare compiler?

Het is ook gewoon een const char en een const char*?

[MLM]

een paar aanmerkingen nog:
1) hardcoded array sizes, zowel je magazijn als je naam, zelden een goed idee (stel je hebt als voorwerp een "vuvuzelaconcertdubbelcd", hoe ga je die naam dan opslaan?). als je C gebruikt, dan ga je je beter goed voelen als je pointers gebruikt, anders is NU het moment om naar C# te gaan.
2) je hebt een magazijn van voorwerpen, maar die word nooit geinitialiseerd of ingelezen ofzo, het enige wat je gaat zien is een partij garbage (als je geluk hebt, je string-printf gaat kunnen segfaulten als je naam niet null-terminated is)
3) je druk-af functie neemt een voorwerp-argument bij value, waardoor due voor elke aanroep het complete object gekopieerd moet worden. gebruik een pointer-naar-const (const Voorwerp *v)

[ValHallASW]

H!GHGuY schreef op zaterdag 26 juni 2010 @ 12:11:
Het is ook gewoon een const char en een const char*?

De foutmelding was:

comparison between pointer and integer

En hoewel een 'const char*' een pointer is en een 'const char' een integer kan zijn, is deze foutmelding niet echt... duidelijk

[Soultaker]

Alle geheeltallige datatypen kleiner dan int (char, short) worden naar int geconverteerd binnen een expressie, dus op het moment dat de vergelijking plaatsvindt is die inderdaad tussen een int en een pointer. Maar ik kan me ook voorstellen dat dat verwarrend is voor een beginner.

[Olaf van der Spek]

Soultaker schreef op zaterdag 26 juni 2010 @ 02:10:
(Wat is het trouwens met de C revival op GoT de laatste tijd? Niet dat ik klaag, want 't blijft mijn favoriete programmeertaal, maar het is wel opvallend.)

Als ik "naam[20]" zie weet ik gelijk weer waarom het absoluut niet mijn favoriete taal is.

MLM schreef op zaterdag 26 juni 2010 @ 12:59:
1) hardcoded array sizes, zowel je magazijn als je naam, zelden een goed idee (stel je hebt als voorwerp een "vuvuzelaconcertdubbelcd", hoe ga je die naam dan opslaan?). als je C gebruikt, dan ga je je beter goed voelen als je pointers gebruikt, anders is NU het moment om naar C# te gaan.

Wat is er met C++ gebeurd?

[ Voor 37% gewijzigd door Olaf van der Spek op 26-06-2010 19:23 ]

[Maarten Kroon]

Exirion schreef op zaterdag 26 juni 2010 @ 01:40:
Maak van "G" eens 'G' en het werkt. Wat je nu doet is dat je de eerste letter van de string (een char dus) vergelijkt met de pointer naar de const string "G". Da's appels met peren vergelijken.

Dit werkt, hartelijk dank.

Nog even over alle andere rare dingetjes in de code: het is maar een schoolopdachtje, een practicum, niet eens voor een cijfer. School wilt het graag zo hebben, ik ga er verder niet moeilijk over doen.

[farlane]

MLM schreef op zaterdag 26 juni 2010 @ 12:59:
een paar aanmerkingen nog:
1) hardcoded array sizes, zowel je magazijn als je naam, zelden een goed idee (stel je hebt als voorwerp een "vuvuzelaconcertdubbelcd", hoe ga je die naam dan opslaan?). als je C gebruikt, dan ga je je beter goed voelen als je pointers gebruikt, anders is NU het moment om naar C# te gaan.

Je stelt iha een zinnig maximum en zorgt dat die niet overschreden wordt; dat hoeft helemaal geen probleem te zijn. Pointers moet je beheersen, maar dat staat los van hoe je je geheugenallocaties doet.

[Olaf van der Spek]

farlane schreef op zaterdag 26 juni 2010 @ 22:01:
Je stelt iha een zinnig maximum en zorgt dat die niet overschreden wordt; dat hoeft helemaal geen probleem te zijn.

Bij fixed array sizes is over het algemeen of de limiet te laag of er wordt geheugen verspild.

[farlane]

Olaf van der Spek schreef op zaterdag 26 juni 2010 @ 22:14:
Bij fixed array sizes is over het algemeen of de limiet te laag

Dan is je maximum niet zinnig gekozen

of er wordt geheugen verspild.

Dat is inderdaad een afweging

[prototype]

Olaf van der Spek schreef op zaterdag 26 juni 2010 @ 22:14:
[...]

Bij fixed array sizes is over het algemeen of de limiet te laag of er wordt geheugen verspild.

Dat is de afweging idd, ook op basis van space/time complexity, maar dat is niet anders dan in C#/Java. Als je daar een ArrayList foo instantiateert b.v. dan alloceert hij vaak ook net iets meer dan je nodig hebt om insertions die voorbij foo.size efficienter te maken, i.e. een realloc zo min mogelijk nodig te maken; de free-list afgaan om een groot genoege chunk aan geheugen te vinden is 't vaak gewoon niet waard vergeleken met "het geheugen dat je verspilt". Wanneer je een insertion doet die voorbij foo.size komt, wordt er vaak een realloc (of iets vergelijkbaars) gedaan zodanig dat hij een factor c groter is dan voorheen, waarbij c vaak 1.7 is. Ook daar wordt iig een initiele capacity gebruikt waarbij capacity >= size. In C++ geeft een std::string om vergelijkbare redenen ook een string terug waarbij de str.size <= str.capacity. Long story short, denk niet echt dat je een taal dit kan verwijten, die accomodeert gewoon hoe je machine werkt, een laag hoger dan assembly he? Kwestie van zinnige limieten kiezen.

[Olaf van der Spek]

farlane schreef op zondag 27 juni 2010 @ 13:56:
Dan is je maximum niet zinnig gekozen

Als gebruiker heb ik daar natuurlijk niks aan.

prototype schreef op zondag 27 juni 2010 @ 14:17:
Long story short, denk niet echt dat je een taal dit kan verwijten, die accomodeert gewoon hoe je machine werkt, een laag hoger dan assembly he? Kwestie van zinnige limieten kiezen.

In andere talen is het gevolg slechts een performance issue, in C is het een functioneel issue. Ik begrijp niet hoe je dat over een kam kunt scheren.

[ Voor 18% gewijzigd door Olaf van der Spek op 27-06-2010 19:19 ]

[prototype]

Olaf van der Spek schreef op zondag 27 juni 2010 @ 19:14:
[...]

Als gebruiker heb ik daar natuurlijk niks aan.


[...]

In andere talen is het gevolg slechts een performance issue, in C is het een functioneel issue. Ik begrijp niet hoe je dat over een kam kunt scheren.

Snap niet helemaal wat je met die zin bedoelt: arrays zijn in talen als C#/Java even fixed als in C. Probeer daar maar eens char[10] foo; en dan foo[11] te accessen, krijg je even hard een ArrayOutOfBoundsException als dat je bij C naar alle waarschijnlijkheid een segfault om de oren krijgt. De array representeert over het algemeen een continue regio aan geheugen. Dat in een taal als PHP b.v. de lijst zich als een lijst/hashmap gedraagt, wil niks zeggen over z'n implementatie, waarbij de fixed size array met een "redelijke maximum" als initial capacity al gauw een optie is die je wil overwegen als je O(1) access wil bewerkstelligen.

Mijn voorbeeld van die ArrayList was simpelweg om aan te tonen dat ook al wordt je er niet direct mee geconfronteerd doordat de interface er geen "noodzakelijke" melding van maakt, de implementatie van dergelijke dingen die dynamisch lijken op te schalen qua grootte ook vaak gebruik maken van "redelijke limieten". Vooral indien ze O(1) access moeten vertonen, waarbij de ArrayList onderwater ook geimplementeerd is met fixed sized arrays.

Het afdoen als "slechts" een performance issue vind ik vrij kort door de bocht; ik kan je makkelijk algoritmes geven die weinig geheugen verbruiken maar x jaar duren om een simpele oplossing te bedenken omdat ze "slechts" in tijd complexiteit nadelig zijn. Een algoritme gebruiken die iets meer geheugen verbruikt (i.e. iets meer alloceert dan hij daadwerkelijk nodig heeft) kan 't dan b.v. in een paar uur daartegenover oplossen.

Daarbij, de free-list nagaan doordat er een realloc moet plaatsvinden kan al gauw een lineaire search opleveren. Een betere maatstaaf is dan ook om te meten in termen van tijd EN ruimte. Een goede afweging tussen beiden kan een veel betere oplossing bieden.

[Olaf van der Spek]

prototype schreef op maandag 28 juni 2010 @ 00:24:
Snap niet helemaal wat je met die zin bedoelt: arrays zijn in talen als C#/Java even fixed als in C. Probeer daar maar eens char\[10] foo; en dan foo\[11] te accessen,

foo[10] is de eerste invalid index, maar dat wist je wel. Toch?
In andere talen gebruik je strings om een string op te slaan, geen fixed size array.

Het afdoen als "slechts" een performance issue vind ik vrij kort door de bocht;

Dit gaat niet over algoritmes of dat soort performance.

[prototype]

Olaf van der Spek schreef op maandag 28 juni 2010 @ 01:51:
[...]

foo\[10] is de eerste invalid index, maar dat wist je wel. Toch?

NO WAI ;-)

In andere talen gebruik je strings om een string op te slaan, geen fixed size array.

[...]

En hoe denk je dat die string is geimplementeerd over het algemeen in andere talen? Die gebruikt ook een fixed size array hoor omdat Strings immutable zijn en een array aan karakters zijn. Zie hier bijvoorbeeld de code van String in Java: http://www.docjar.com/html/api/java/lang/String.java.html

In het bijzonder op lijn 137:

Java:

private final char[] value;

Check daarbij de constructors ook even, en dan snap je m'n punt.

Maar even iets om het makkelijker voor je te maken:

C:

#include <stdio.h>

typedef const char* String;

int main(int argc, String* argv) {
    String hello = "Hello World\n";
    printf("%s", hello);
    return 0;
}

Meer familiar to C#/Java/PHP nu voor je? ;-) All kidding aside, je HOEFT niet expliciet de lengte van de array op te geven he als de compiler 't al kan bepalen voor je.

Dit gaat niet over algoritmes of dat soort performance.

Over wat voor soort performance dan wel?

[ Voor 12% gewijzigd door prototype op 28-06-2010 02:21 ]

[Olaf van der Spek]

prototype schreef op maandag 28 juni 2010 @ 02:11:
En hoe denk je dat die string is geimplementeerd over het algemeen in andere talen?

Ik weet hoe strings geimplementeerd zijn...

Over wat voor soort performance dan wel?

Een significant verschil.

Maar eh, ik heb het idee dat je mijn punt niet begrijpt.

[ Voor 8% gewijzigd door Olaf van der Spek op 28-06-2010 12:56 ]

[kluyze]

H!GHGuY schreef op zaterdag 26 juni 2010 @ 09:15:
lengt zou je trouwens beter geen float maken maar een integer of beter nog, een size_t

Waarom? Het is toch gewoon een maat voor de lengte van het product. Die kan toch 1,35m lang zijn. Je zou alles kunnen converteren naar mm maar dat zou je ook over het gewicht kunnen zeggen.

[Creepy]

Ik heb even wat geschoond hier, dus als er posts missen: dat klopt

[prototype]

Olaf van der Spek schreef op maandag 28 juni 2010 @ 12:18:

[...]

Een significant verschil.

Ik heb het idee dat je mijn punt niet begrijpt.

Wat is je punt precies? Gaarne als het kan meer dan 1 zin aan besteden. "Een significant verschil. :P" kan je niet zoveel mee ;-)

TS: ik zie trouwens volgens mij een fout in je code tov je probleemstelling:

Maarten Kroon schreef op zaterdag 26 juni 2010 @ 01:33:
Voor een kleine school opdracht moet ik een stukje C schrijven waarin alle "voorwerpen" uit een Array worden afgedrukt welke een lengte hebben kleiner dan 100 en beginnen met de letter "G". Ik dacht zelf aan het onderstaande:

C:

    if (magazijn[j].lengte <= 100 && magazijn[j].naam[0] == "G") { 

In je probleemstelling zeg je expliciet kleiner dan 100, in je code check je echter op kleiner of gelijk aan. Waar in je probleemstelling een artikel met lengte 100 dus niet afgedrukt zou worden, wordt dat in je code wel. Indien je probleemstelling klopt zal je code denk ik eerder het volgende moeten zijn:

C:

    if (magazijn[j].lengte < 100 && magazijn[j].naam[0] == 'G') { 

[ Voor 57% gewijzigd door prototype op 28-06-2010 13:57 . Reden: Mogelijke fout in code/probleemstelling van TS gezien ]

[ValHallASW]

kluyze schreef op maandag 28 juni 2010 @ 12:32:
Waarom? Het is toch gewoon een maat voor de lengte van het product. Die kan toch 1,35m lang zijn. Je zou alles kunnen converteren naar mm maar dat zou je ook over het gewicht kunnen zeggen.

Highguy ging er denk ik vanuit dat 'lengte' op de lengte van de string sloeg, en niet op de lengte van het product

[Olaf van der Spek]

prototype schreef op maandag 28 juni 2010 @ 13:00:
[...]

Wat is je punt precies? Gaarne als het kan meer dan 1 zin aan besteden. "Een significant verschil. :P" kan je niet zoveel mee ;-)

Dat het gebruiken van de string implementatie van een taal een goede keuze is om een string op te slaan en dat je dan geen functionele beperking (qua lengte) krijgt.

TS: ik zie trouwens volgens mij een fout in je code tov je probleemstelling:

Het is een float en daarbij zijn exacte vergelijkingen niet zo zinvol.

[.oisyn]

Die stelling is pertinent onwaar. Het feit dat je met floats te maken kunt krijgen met afrondingsfouten en de vergelijking in zo'n geval niet helemaal precies is wil niet zeggen dat het dan ook maar meteen betekent dat een exacte vergelijking op een float nooit zinvol is. Bij m'n software z-buffer renderer maakt een >= en een > bijvoorbeeld het verschil tussen een pixel wel tekenen en een pixel niet tekenen.

Daarnaast, zelfs al maakt het niet uit dan blijft het natuurlijk wel zo netjes om de vergelijking volgens de specs op te schrijven, en niet verkeerd omdat je denkt dat het verder toch niet uitmaakt.

[ Voor 41% gewijzigd door .oisyn op 28-06-2010 18:50 ]

[H!GHGuY]

ValHallASW schreef op maandag 28 juni 2010 @ 13:45:
[...]

Highguy ging er denk ik vanuit dat 'lengte' op de lengte van de string sloeg, en niet op de lengte van het product

Ik had willen antwoorden, maar toen ging tweakers.net down, of was ze op z'n minst onbereikbaar.
Punt is dat je gelijk hebt, ik dacht even dat die lengte op de string sloeg.

[prototype]

Olaf van der Spek schreef op maandag 28 juni 2010 @ 18:29:
[...]

Dat het gebruiken van de string implementatie van een taal een goede keuze is om een string op te slaan en dat je dan geen functionele beperking (qua lengte) krijgt.

[...]

Jammer, ik tel maar weer een zin Een string geimplementeerd in een taal, ja, misschien string literals en wat overloaded operaties erop die onderdeel uitmaken van de grammatica, maar verder dan dat zijn strings volgens mij niet echt geimplementeerd in de taal zelf anders dan standard libraries (die onderwater gebruik maken van fixed size arrays). Alleen omdat je niet geconfronteerd er mee wordt met dit feit betekent nog niet dat je daar geen rekening mee moet houden.

Wanneer je een string als immutable beschouwd (wat het geval is in Java vziw) betekent dat je voor zo'n string object exact kan bepalen wat de lengte ervan is bij initialisatie. Wat ik je nu al in een paar posts duidelijk probeer te maken is dat iets meer alloceren vaak handiger is voor performance redenen en dat je die afweging OOK moet maken en niet alleen kijken naar dat je een paar bytes "verspilt"; die verspilling in ruimte kan je vaak ruimschoots goedmaken met snelheid... en daarbij gaat het 9/10 keer om een paar bytes. Als je over "efficientie" wil praten van geheugen moet je eens kijken naar de footprint van een Java string object of C# string object Ik noem het overigens geen verspilling hoor, maar in dergelijke talen heb je ook met andere soorten overhead te maken die vaak groter zijn dan die paar bytes die je misschien extra allocate voor je string... Je werkt dan ook heel dicht op machine niveau in C.

Ik kan verder in C net zo goed strings alloceren die precies het aantal karakters gebruiken als dat ik nodig heb hoor, waarbij ik bij het initialiseren van een string literal dat niet eens expliciet hoef op te geven. Mijn flauwe voorbeeld van typedef const char* String; illustreert dit. Alleen maar omdat je String als type ziet wil dat niks zeggen over z'n implementatie en de implicaties erop.

Je opmerking over geen functionele beperkingen qua lengte raakt dan ook kant noch wal omdat in talen als Java en C# die string objecten ook uitgaan van fixed length arrays. Ik kan hierbij ook in constante tijd de karakters accessen op index via charAt, en verrek, bij:

Java:

String s1 = "foo";
s1.charAt(s1.length()); // Komt u maar met die exceptie.

Zowaar een limitatie op lengte

Verder, een concatenatie van:

Java:

String s1 = "foo";
String s2 = "bar";
String result = s1 + s2;

Resulteert over 't algemeen ook weer tot een nieuw string object "result" met lengte (s1.length + s2.length). Maar juist dat alloceren van een nieuw object kan onwenselijk zijn omdat het duur kan zijn in tijd/ruimte complexiteit om zoiets te doen als je dit b.v. in een lus doet voor een grote result string. Daarom wil je ook de optie overwegen om iets meer bytes te alloceren voor een string om die operaties op diezelfde string direct uit te kunnen voeren...

Note: in het specifieke geval van de JVM zouden hier eventueel optimalisaties op uitgevoerd kunnen worden als je veel String appends doet, maar ik weet niet zeker of de JVM dit ook daadwerkelijk doet. Toen ik nog veel Java deed niet iig.

Door een iets grotere char array alloceren kan je ervoor zorgen dat de concatenatie "efficienter" verloopt, en het eerste wat in me opkomt is dan ook de StringBuffer die ze in Java ook voor dit soort doeleinden naar voren schuiven. Ook deze alloceert een char array met een redelijke limiet als initiele lengte. Die doet in concept iets vergelijkbaars met wat jij zou doen als je strcat zou gebruiken op een "groot genoege destination buffer met wederom een redelijk limiet". Duik maar eens een keer in de broncode van StringBuffer om het zelf te zien. Al met al, redelijke limiete kiezen is gewoon een kwestie van afwegingen maken. Mag je nog een keer proberen te bevechten, maar dan verwijs ik je dit keer door naar een goed algoritmen, datastructuren en complexiteit boek. Heb volgens mij nu toch bijna echt alles al gezegd over dit onderwerp mbt strings.

Het is een float en daarbij zijn exacte vergelijkingen niet zo zinvol.

Zie .oisyn. Dit is ook m'n laatste reply op jouw posts, nothing personal, maar het lijkt alsof je je "punt" per post probeert te veranderen.

[farlane]

Olaf van der Spek schreef op zondag 27 juni 2010 @ 19:14:
Als gebruiker heb ik daar natuurlijk niks aan.

Als het echt zo is dat "in het algemeen" die fixed lengte te krap is (wat denk ik niet vaak het geval is), wordt het tijd om een bug in te dienen bij de maker van de software.

Btw, ergens zal er een maximum moeten zijn toch? Als dat niet erg hoog ligt kan het kiezen voor een fixed size array een stuk complexiteit wegnemen, en voor een stuk determinisme zorgen.

[MSalters]

Ik denk dat er hier teveel mensen de jaren 70 niet hebben meegemaakt. Fixed length strings zijn normaliter geen slim idee, om statistische redenen. User input heeft een statistische lengteverdeling, met typisch een long tail. Het is bepaald niet ongebruikelijk dat 5% van de strings 4 keer langer is dan gemiddeld. Dat betekent dat als je de fixed-length strings groot genoeg maakt voor 95% van de strings, je 300% meer ruimte gebruikt dan noodzakelijk. Dat percentage loopt nog verder uit de klauwen als je je strings groot genoeg maakt voor 99% van je input, dan kun je zomaar 1000% verspilling of meer hebben.

Er zijn natuurlijk specifieke gevallen waarin dat niet opgaat. Nederlandse postcodes bijvoorbeeld; daar valt de gemiddelde lengte samen met de maximum lengte. Daar is een char[6] op z'n plek. Je hebt niet eens een \0 nodig.

[Exirion]

MSalters schreef op dinsdag 29 juni 2010 @ 10:15:
Ik denk dat er hier teveel mensen de jaren 70 niet hebben meegemaakt.

Het issue is nogsteeds helemaal actueel als je bijvoorbeeld met een Cortex-M0 of Cortex-M3 werkt waar je met kilobytes ipv gigabytes geheugen te maken hebt Wat dat betreft is er een steeds grotere diversiteit van platformen ontstaan waaronder de lichtste qua resources doen denken aan de jaren 80.

[RayNbow]

MSalters schreef op dinsdag 29 juni 2010 @ 10:15:
Ik denk dat er hier teveel mensen de jaren 70 niet hebben meegemaakt. Fixed length strings zijn normaliter geen slim idee,

Het probleem van de gehele discussie is dat de scope niet vastgesteld is. Zo beargumenteert prototype dat je er niet onderuit komt. *Ergens* in je systeem zal je te maken hebben met een fixed-length string.
(Al is het alleen al om het feit dat je OS zaken moet bufferen.)

Beperk je echter de scope tot applicatiecode geschreven in een moderne programmeertaal met fatsoenlijke datatypes en I/O library, dan hoef je je niet druk te maken over fixed-length character arrays die eventueel te klein of veel te groot zijn. Nee, dan hoef je alleen de user input aan de I/O lib te vragen en die geeft vervolgens netjes de input in een geschikte vorm.

[Olaf van der Spek]

.oisyn schreef op maandag 28 juni 2010 @ 18:44:
Die stelling is pertinent onwaar. Het feit dat je met floats te maken kunt krijgen met afrondingsfouten en de vergelijking in zo'n geval niet helemaal precies is wil niet zeggen dat het dan ook maar meteen betekent dat een exacte vergelijking op een float nooit zinvol is. Bij m'n software z-buffer renderer maakt een >= en een > bijvoorbeeld het verschil tussen een pixel wel tekenen en een pixel niet tekenen.

Daarnaast, zelfs al maakt het niet uit dan blijft het natuurlijk wel zo netjes om de vergelijking volgens de specs op te schrijven, en niet verkeerd omdat je denkt dat het verder toch niet uitmaakt.

Dat is waar, maar geldt dat ook voor vergelijkingen met een constante?

[Olaf van der Spek]

farlane schreef op maandag 28 juni 2010 @ 22:15:
Als het echt zo is dat "in het algemeen" die fixed lengte te krap is (wat denk ik niet vaak het geval is), wordt het tijd om een bug in te dienen bij de maker van de software.

Dat soort 'bugs' wil je juist voorkomen.

Btw, ergens zal er een maximum moeten zijn toch?

Waarom? Input validatie, afhankelijk van het type app.
De hoeveelheid geheugen misschien ja, maar verder? Nee, niet echt.
Het aantal voorwerpen heeft ook al zo'n maximum dat er eigenlijk niet hoort te zijn.

[ Voor 36% gewijzigd door Olaf van der Spek op 29-06-2010 13:43 ]

[.oisyn]

Olaf van der Spek schreef op dinsdag 29 juni 2010 @ 13:30:
[...]

Dat is waar, maar geldt dat ook voor vergelijkingen met een constante?

Uiteraard. In mijn geval vergelijk ik met de constante 0