[C/C++] lengte van een element in de argumentvector

[Dooievriend]

Momenteel zit ik met het volgende probleem:

In de standaard argumentvector (char** argv) zit een tweede element, namelijk een bestandsnaam (bvb "../workspace/iets.txt"). Graag had ik nu een char* nieuwbestand gemaakt die argv[1] concateneert met ".abc", zodanig dat nieuwbestand=="../workspace/iets.txt.abc". Hoe doe ik dit?

Het probleem waarmee ik zit is dat ik niet snap hoe je kan weten hoelang de reeks karakters waar argv[1] naar verwijst is. Indien ik dit wist, zet ik er een for loop over en kopieer ik de karakters naar een array, waarna ik een pointer naar het eerste element van de array maak en klaar is kees. Hoe kom ik deze lengte te weten?

Een korte zoektocht via google naar meer info omtrent de argumentvector of een pointer verwijzend naar het eerste element van een array leverde niets op, en ik vermoed dat ik iets simpels over het hoofd zie. Iemand enig idee?

[Woy]

Je bent bekend met de str(n)len en anderen str(n)* functies?

[ Voor 13% gewijzigd door Woy op 31-10-2011 15:42 ]

[MSalters]

Simpeler, aangezien je bijkbaar C++ mag gebruiken:

C++:

std::string nieuwbestand =  argv[1];
nieuwbestand += ".abc";

[Dooievriend]

Ah, met dank aan Woy. strncat en strlen zien er veelbelovend uit. Zoeken op die termen leidde me naar http://www.cplusplus.com/reference/clibrary/cstring/ , wat voldoende mogelijkheden biedt voor wat ik wil, zonder dat de compiler klaagt.

@MSalters: ik had gehoopt dat zoiets werkte, maar blijkbaar moet ik daarvoor eerst nog een library importeren denk ik. Ik krijg in ieder geval volgende error: ‘string’ is not a member of ‘std’. Op zich denk ik dat ik wel C++ mag gebruiken, maar hoe minder libraries ik moet importeren, hoe beter. strcat en strlen zijn C blijkbaar? En die geven gelukkig geen problemen...

Allright, dit was de uiteindelijke oplossing, nogmaals dank!

C:

char nieuwbestand[strlen(argv[1])+4];
strcpy(nieuwbestand,argv[1]);
strcat(nieuwbestand,".txt");

[ Voor 12% gewijzigd door Dooievriend op 31-10-2011 16:12 . Reden: oplossing toegevoegd ]

[Verwijderd]

Dooievriend schreef op maandag 31 oktober 2011 @ 15:55:
Ah, met dank aan Woy. strncat en strlen zien er veelbelovend uit. Zoeken op die termen leidden me naar http://www.cplusplus.com/reference/clibrary/cstring/ , wat voldoende mogelijkheden biedt voor wat ik wil, zonder dat de compiler klaagt.

@MSalters: ik had gehoopt dat zoiets werkte, maar blijkbaar moet ik daarvoor eerst nog een library importeren denk ik. Ik krijg in ieder geval volgende error: ‘string’ is not a member of ‘std’. Op zich denk ik dat ik wel C++ mag gebruiken, maar hoe minder libraries ik moet importeren, hoe beter. strncat en strlen zijn C blijkbaar? En die geven gelukkig geen problemen...

Bij je includes

C++:

#include <string>

gebruiken.

[Dooievriend]

Verwijderd schreef op maandag 31 oktober 2011 @ 16:11:
[...]

Bij je includes

C++:

#include <string>

gebruiken.

Dit werkt idd ook. Niettemin beperk ik het aantal libraries liever, moderne code is ondergeschikt aan snelheid in dit geval.

Niettemin, dank voor de hulp, ik leer bij aan een razend tempo op tweakers.net

[EddoH]

Wat heeft het includen van een library met snelheid te maken?

[Dooievriend]

EddoH schreef op maandag 31 oktober 2011 @ 16:16:
Wat heeft het includen van een library met snelheid te maken?

Zorgen extra libraries niet voor een tikkeltje overhead? Extra geheugenruimte voor de extra routines, meer tijd om te linken etc. Of sla ik de bal hier mis?

In ieder geval heeft de originele programmeur om wat voor reden dan ook de library niet toegevoegd, en bijgevolg wil ik hem ook niet toevoegen tenzij het niet anders kan. Maar in dit geval kon het dus anders.

[EddoH]

Dooievriend schreef op maandag 31 oktober 2011 @ 16:21:
[...]

Zorgen extra libraries niet voor een tikkeltje overhead? Extra geheugenruimte voor de extra routines, meer tijd om te linken etc. Of sla ik de bal hier mis?

In ieder geval heeft de originele programmeur om wat voor reden dan ook de library niet toegevoegd, en bijgevolg wil ik hem ook niet toevoegen tenzij het niet anders kan. Maar in dit geval kon het dus anders.

Extra geheugen is iets anders dan snelheid. Overhead ligt aan de compiler en omgeving waarop gedraait wordt.
Bovendien is de libc die je nu gebruikt misschien ook een externe lib, of wordt geinlined door de compiler.

Misschien is de routine in stdlib wel zoveel sneller dat de eventuele overhwead teniet wordt gedaan.

Oftewel: je kunt er geen uitspraken doen, en vooral niet rechtlijnig zeggen dat includen van een lib inboet op snelheid

[Dricus]

Ook vind ik je argument om geen lib te willen toevoegen omdat de originele programmeur dat ook niet heeft gedaan nogal slecht. Besef je wel dat je met de oplossing die je post een risico op bugs introduceert waar je bij gebruik van een std::string niet eens over hoeft na te denken?

Je alloceert een char array met de lengte van argv[1] plus "4". Die "4" móet minstens even groot zijn als de lengte van de string die je er met strcat aan toe wilt voegen. Mocht het om de één of andere reden nodig zijn om er een extensie van 4 karakters aan toe te voegen (".abcd") dan heb je meteen een bug te pakken als je vergeet die "4" in een "5" te veranderen.

En denk nou niet: "dat overkomt mij niet". Dit soort dingen overkomt namelijk de beste programmeurs. En ik weet uit ervaring dat het zoeken naar de oorzaak van de resulterende heap corruptie enorm veel tijd in beslag kan nemen .

[Woy]

Bovendien lijkt een dergelijke bewerking die eenmalig gedaan word bij het opstarten me niet cruciaal voor de performance. Dus hou ook hier het volgende gezegde in gedachte: "premature optimization is the root of all evil"

[Dooievriend]

Lol, jullie hebben natuurlijk gelijk, maar in mijn specifiek geval zal dit de simpelste oplossing zijn die me het meeste vertrouwen inboezemt. Niettemin onthou ik jullie raad voor latere (en grotere) projecten

[MSalters]

Het probleem met strlen en strcat is dat ze de stringlengte niet weten maar meten, itt std::string waar het een member is. Daarom zijn ze vaak langzamer.

Overigens is het "extra library" verhaal wat dubieus: strlen komt ook uit een library.

[Zoijar]

Dit is vragen om bugs. Over een jaar denkt iemand, het moet niet .txt zijn maar .text! Ik verander het even in strcat(nieuwbestand,".text"); Buffer overflow. Wordt aanvankelijk niet opgemerkt... jaar later hebben we er weer een 0day bij

Gewoon std::string gebruiken.

[Dricus]

Okee, even samenvatten: Je gaat dus voor een overduidelijk "suboptimale" oplossing, ondanks dat het gegeven alternatief simpeler en veiliger is... De enige argumenten die je ervoor geeft zijn:

• Dit is een "specifiek" geval.
  
  Jouw geval moet dan wel héél specifiek zijn, wil het een dergelijke lelijke en risicovolle oplossing rechtvaardigen ten opzichte van een enorm simpele en veilige oplossing.
• Deze oplossing boezemt je het meeste vertrouwen in.
  
  Hoe je het voor elkaar krijgt meer vertrouwen te hebben in een lelijke en risicovolle oplossing dan in een simpele en veilige oplossing is me een raadsel.
• Je wil geen extra lib toevoegen vanwege performance en omdat de "originele programmeur" dat ook niet gedaan heeft.
  
  Je bent al gewezen op het feit dat premature optimization over het algemeen als bad practice wordt beschouwd. Ook je argument dat de originele programmeur genoemde lib ook niet heeft toegevoegd slaat kant nog wal. Dat zegt namelijk nog niet dat hij dit in dit geval niet alsnog gedaan had en het zegt al helemaal niets over zijn beweegredenen.

Als je van zins bent om van programmeren je vak te maken (of als je dat al gedaan hebt), dan zou ik als ik jou was mezelf niet tekort doen door in dit soort gevallen om dit soort redenen voor een lelijke en risicovolle oplossing te kiezen. Als het probleem wat Zoijar en ik schetsen optreedt en jij (of een collega) je vervolgens een breuk zoekt naar waar de fout zit, ga je het niet leuk vinden als je aan je baas moet gaan uitleggen dat je zoveel tijd hebt moeten steken in het oplossen van een bug die kinderlijk eenvoudig te voorkomen was geweest.

Het lijkt er misschien op dat er van een mug een olifant wordt gemaakt, maar dit soort gedrag wijst vaak op een, naar mijn mening, verkeerde mentaliteit van een programmeur. Het wijst op een gebrek aan een gezond(!) portie perfectionisme wat, vind ik, vereist is om dit vak goed uit te kunnen oefenen.

En nu houd ik erover op .

[.oisyn]

MSalters schreef op dinsdag 01 november 2011 @ 08:02:
Overigens is het "extra library" verhaal wat dubieus: strlen komt ook uit een library.

Exact. Eigenlijk wil je dus ook geen strlen(), strcpy() en strcat() gebruiken, die komen immers uit een library.

Sterker nog, beter gebruik je gewoon helemaal geen C of C++ maar schrijf je je executable direct in assembly.