[c(++)] dynamically allocated memory returnen

[cobratbq]

Ik ben bezig met een proggie die een aantal dingen uit een bestand moet halen en in z'n geheugen moet laden. Het nadeel is dat het bestand ontzettend variabel kan zijn. Daardoor moet ik gebruik maken van dynamically allocated memory. Maar hoe moet ik in een subfunctie waarbij ik malloc-pointer gebruik een return-code laten geven en tegelijkertijd de geheugen vrij maken.

voorbeeldje (heeeel simpel voorbeeldje):

code:

char *voorbeeldje( char *testje ) {
  char *dynamic_mem;

  dynamic_mem = malloc( (strlen(testje)+1)  * sizeof(char));
  //... heel hoop handelingen ... ... ... ... ...

  free( dynamic_mem ); //Hier wil ik dus zowel de pointer clearen als de data returnen
  return dynamic_mem;
}

Is er een manier om zowel de free functie te gebruiken en om gegevens uit de pointer te returnen?

Sorry als het al eens naar voren gekomen is, maar ik wist niet hoe ik dit op moest zoeken.

[ Voor 1% gewijzigd door cobratbq op 20-12-2002 22:25 . Reden: Kromme zin wegwerken ]

[.oisyn]

Ik snap je niet helemaal, als je je geheugen vrijgeeft dan heeft het toch al niet meer nut om het te returnen? Het geheugen is dan immers niet meer valide

Je zult dus gewoon de pointer moeten meegeven, en het free'en daarvan is een taak voor de caller.

[cobratbq]

Stel ik heb wa geheugen:
"Dit is een string in het geheugen".
ik filter daar "een string" uit, die wil ik returnen.
Maar omdat die string soms heeeeel lang is en soms heel kort, wil ik het dynamische geheugen gebruiken om zo de grootte aan te passen aan de inkomende tekst.
Maar dan kan ik hem niet returnen en dan moet ik alsnog een gewone var-array declareren met een hoop geheugen omdat ik niet weet hoe lang de string wordt.
En dan heeft dat hele verhaal van dynamisch geheugen weer weinig nut.

Ik filter bijvoorbeeld uit 500 bytes geheugen 10 bytes en die moet ik returnen.

Maar ik weet van tevoren niet dat het maar 10 bytes geheugen zijn, dus kan ik niet gewoon een variabele declareren.

[ Voor 27% gewijzigd door cobratbq op 20-12-2002 22:40 ]

[Lone Gunman]

kan je niet eerst bepalen hoeveel mem je moet alloceren en dan pas alloceren ?
ipv eerst alloceren voor de complete string ?

[ Voor 82% gewijzigd door Lone Gunman op 20-12-2002 22:41 ]

[.oisyn]

C:

char * copyString (const char * pStr)
{
    char * ret = (char *)malloc (strlen (pStr) + 1);
    strcpy (ret, pStr);
    return ret;
}

nu retourneer je toch gewoon nieuw geheugen? En dat is dynamisch. De caller moet echter wel het geheugen weer vrijgeven zodra ie ermee klaar is

[cobratbq]

.oisyn schreef op 20 december 2002 @ 22:39:

C:

char * copyString (const char * pStr)
{
    char * ret = (char *)malloc (strlen (pStr) + 1);
    strcpy (ret, pStr);
    return ret;
}

nu retourneer je toch gewoon nieuw geheugen? En dat is dynamisch. De caller moet echter wel het geheugen weer vrijgeven zodra ie ermee klaar is

Dus als ik je goed begrijp kan ik het geheugen wat ik aangemaakt heb ik de functie ook nog buiten de functie vrijgeven? Dat zou idd heel mooi zijn. Tnx.

[.oisyn]

natuurlijk kan dat, het staat immers op de heap, dat blijft bestaan tot je het vrijgeeft, of tot je programma afsluit

[cobratbq]

Ja je heb gelijk, goeie vergelijking trouwens met die file-pointer, stom van me. Tnx

[Glimi]

Mjah, als je C++ in je titel hebt, waarom werk je dan nog met char* ipv std::string

[MSalters]

Voor de duidelijkheid: zo wordt het in C++:

code:

std::string voorbeeldje(  std::string  testje ) {
  //... heel hoop handelingen met testje (kopie van orgineel)... ... ... ...
  return testje;
}

Eén regel code, dus.

[.oisyn]

Glimi schreef op 20 december 2002 @ 23:13:
Mjah, als je C++ in je titel hebt, waarom werk je dan nog met char* ipv std::string

volgens mij staat de ++ toch echt tussen haakjes

[Glimi]

.oisyn schreef op 21 december 2002 @ 16:45:
volgens mij staat de ++ toch echt tussen haakjes

Wat dus betekend?

[MisterData]

Glimi schreef op 22 December 2002 @ 21:03:

[...]

Wat dus betekend?

Als je het als regex ziet is het alleen maar een subexpressie hoor Ik zou als het kan ook met std::string werken... veel makkelijker dan al dat gerotzooi met char* enzo

[.oisyn]

Glimi schreef op 22 december 2002 @ 21:03:
[nohtml]
[...]
[/nohtml]
Wat dus betekendt?

imho dat ie een oplossing zoekt die zowel in C als in C++ werkt

[curry684]

Glimi schreef op 20 december 2002 @ 23:13:
Mjah, als je C++ in je titel hebt, waarom werk je dan nog met char* ipv std::string

Sinds wanneer werkt char* niet meer in C++? De laatste keer dat ik checkte wel...

[Glimi]

curry684 schreef op 23 December 2002 @ 13:55:
Sinds wanneer werkt char* niet meer in C++? De laatste keer dat ik checkte wel...

1) Ik impliceer nergens dat het niet meer werkt, ik vraag me af waarom men kiest voor char* ipv std::string
2) Naar ik dacht is de STL standaard binnen ANSI C++, dus waarom die niet verkiezen als je C++ programmeert?
3) Waarneer is de laatste keer dat jij checkte

[curry684]

Glimi schreef op 23 December 2002 @ 14:14:
1) Ik impliceer nergens dat het niet meer werkt, ik vraag me af waarom men kiest voor char* ipv std::string

Omdat een toegespitste oplossing op basis van atomaire types per definitie sneller is dan een encapsulatie. En de char is wel een atomair type (no includes required), en std::string niet.

2) Naar ik dacht is de STL standaard binnen ANSI C++, dus waarom die niet verkiezen als je C++ programmeert?

Standaard is 1 ding, verplicht is een 2e.

3) Waarneer is de laatste keer dat jij checkte

Zo'n 10 minuten geleden

[Glimi]

curry684 schreef op 23 December 2002 @ 14:18:
Omdat een toegespitste oplossing op basis van atomaire types per definitie sneller is dan een encapsulatie. En de char is wel een atomair type (no includes required), en std::string niet.

Die need naar 'raw-speed ipv safety' verwacht ik niet van iemand die geheugen wil vrijgeven en dan een pointer ernaartoe wil returnen

Standaard is 1 ding, verplicht is een 2e.

mjah, ik vind het juist een van de grote voordelen van C++, maar je bent inderdaad niet verplicht het te gebruiken. Maar zo'n instelling verwacht ik meer van een verstokte C programmeur

Zo'n 10 minuten geleden

Aan het werk joh? Geen vakantie

[curry684]

Glimi schreef op 23 december 2002 @ 14:24:
Die need naar 'raw-speed ipv safety' verwacht ik niet van iemand die geheugen wil vrijgeven en dan een pointer ernaartoe wil returnen

Okeeeeeeeeeeeeee.... maar als je de bak opblaast doe het dan in stijl

Aan het werk joh? Geen vakantie

Mag ik geen compiler aanraken tijdens m'n vakantie?

* curry684 doet in principe alleen wat Photoshoppen tijdens z'n vakantie maar moest ff wat uitproberen...

[.oisyn]

mensen schijnen me te negeren , vandaar nog een keertje:

.oisyn schreef op 23 December 2002 @ 12:11:

imho dat ie een oplossing zoekt die zowel in C als in C++ werkt

[Glimi]

.oisyn schreef op 23 December 2002 @ 17:39:
mensen schijnen me te negeren , vandaar nog een keertje:

Goh begint het je _nu_ pas op te vallen .oisyn

Maare waarom zou iemand dat willen? Ik wil mijn Javacode toch ook niet door GCC kunnen halen

[.oisyn]

Glimi schreef op 23 december 2002 @ 18:44:
Maare waarom zou iemand dat willen? Ik wil mijn Javacode toch ook niet door GCC kunnen halen

sinds wanneer is javacode compatible met c++

[curry684]

Glimi schreef op 23 December 2002 @ 18:44:
Goh begint het je _nu_ pas op te vallen .oisyn

Wie is .oisyn?

Maare waarom zou iemand dat willen? Ik wil mijn Javacode toch ook niet door GCC kunnen halen

Stel, ik schrijf een API die toegang verschaft tot een stuk van een OS. Stel, die noem ik Win32 API. Stel, die schrijf ik in C++, dan hebben alle C en VB programmeurs ter wereld pech. Stel, die schrijf ik in C, dan hebben alle C++ en VB programmeurs ter wereld geluk.

Just a thought

[Glimi]

curry684 schreef op 23 december 2002 @ 19:03:
Wie is .oisyn?

Die man die zondags altijd het vleesch komt snijden

Stel, ik schrijf een API die toegang verschaft tot een stuk van een OS. Stel, die noem ik Win32 API. Stel, die schrijf ik in C++, dan hebben alle C en VB programmeurs ter wereld pech. Stel, die schrijf ik in C, dan hebben alle C++ en VB programmeurs ter wereld geluk.

Just a thought

Mjah, dan moeten alsnog de talen C++/VB ook over een gelijkend soort basistypen bevatten als de taal waar de API in zit, anders zal er alsnog een vertaalslag moeten plaatsvinden (CORBA bijv)

[Verwijderd]

hmm... zooitje redenen om in C en niet in C++ te coden :

1) Je snapt geen C++
2) Je bent C++ hater
3) Je baas wil dat je het in C maakt
4) Je collega's (die het moeten gaan onderhouden) kunnen geen C++
5) Raw speed is belangrijker voor je project dan safety

Redenen genoeg dus...
Als het KAN zal ik altijd voor C++ kiezen (ivm reusability/ code safety) maar het KAN nou eenmaal niet altijd (wrede wereld )

[cobratbq]

Nou nou...
Ik had allang niet meer naar die topic gekeken, omdat ik naar mijn idee al een goed antwoord gekregen had.
Om even een aantal antwoorden te geven:
1. Ik snap wel C++, maar nog niet zo goed, en is in dit geval niet bruikbaar.
2. Ik ben geen C++ hater
3. Nope, geen baas, just me and my stupid project
4. Mijn collegas kunnen geen C, C++, VB, JAVA, DELPHI, Basic ... (wel heel oppervlakkig VBA )
5. Neuh, het moet geen uur duren, maar raw speed is niet van hoogste belang.

Ik zal ff kort uitleggen waar ik mee bezig ben.
Ik ben een programma aan het schrijven wat zowel in 16bit dos modus moet werken als in Win32. Daarom gebruik ik C en geen C++.
Ik ben een programmatje aan het schrijven waarmee ik aan de hand van een INF bestandje alle nodige bestanden van een driver kan backuppen.
Ja ik weet dat die programmaatjes bestaan, maar dat programmatjes is in VB geschreven, wat ik echt niet uit kan staan, en het werkt niet ideaal. Ik heb al een paar keer meegemaakt dattie toch niet alles gebackupped had.
Daarom ben ik zelf op onderzoek uitgegaan. Kheb MSDN doorgelezen en ben gaan schrijven. Toen kwam ik er dus achter dat het ene INFje 2 regels Strings code heeft en bijvoorbeeld NVIDIA heeft ongeveer 40 regels. Ik moest dus dynamic memory allocation gaan gebruiken. En aangezien ik eigenlijk nooit met pointers icm dynamic memory werk, ging dat niet ideaal.
Ik ben intussen al een flink eind op weg. Het commandline programmatje is al bijna klaar. Dat moet ik alleen nog uitvoerig testen. En dan ga ik een GUI schrijven waarvanuit het makkelijk te besturen is.

Waarom ik doe? Nou omdat ik eigenlijk altijd iets zoek om te programmeren. En omdat dat programmaatje WinDriversBackup niet helemaal goed werkte. Dat moet ik toch beter kunnen

Ik werk in een winkel die computers verkoopt ÉN repareert. Aangezien we altijd van die bakkies zonder drivers krijgen, en dan vaak nog van PackardBell en Compaq ook. Heb ik besloten maar een nieuw projectje te starten en zelf een programmatje te schrijven. Ik heb daarom gekozen voor DOS zodat als die lui de boel zover over de zeik hebben dat windows niet eens meer opstart, ik toch nog alle inf files af kan gaan. Da's alles beter dan 2,5 uur op internet gaan zoeken naar een driver voor een modem van Connexant (aren't they all?).

Als jullie het blijkbaar toch een interessant iets vinden.
Kunnen jullie een aantal INF files pasten in deze topic?
Gelieve niet te emailen omdat ik dan dalijk ladingen binne krijg en dat hoeft nu ook weer niet

Ik zit intussen op 1475 regels code en als alles goed gaat hoeft er aan de commandline tool nog maar weinig te veranderen.

Tnx 4 alle response

edit:
Oh ja, nog een goede reden waarom ik dit programmatje maak is: Toen ik met WinDriversBackup aan het experimenteren was en ik er achter kwam dat het weer niet werkte, zei ik hardop: "Dit schiet echt niet op, ik kan beter zelf een programmatje schrijven". Waarop een van onze vaste klanten zei: "Hehe, hoor daar, dat wil ik zien ...". En daarop zei m'n collega: "Hou op, anders doetie het nog ook hoor!!!".
Ofwel: Ik wil die klant een poepie laten ruiken

[ Voor 9% gewijzigd door cobratbq op 25-12-2002 20:38 ]

[Verwijderd]

Verwijderd schreef op 25 december 2002 @ 16:48:
5) Raw speed is belangrijker voor je project dan safety

C++ is (effectief) een superset van C, en omdat je in C++ geen performance inlevert voor features die je niet gebruikt is het onzin om te zeggen (of te impliceren) dat C sneller is dan C++. Met sommige C++ faciliteiten (templates+inlining) schijnt soms zelfs meer performance behaald te kunnen worden dan een C oplossing kan bieden.

[curry684]

Verwijderd schreef op 25 december 2002 @ 16:48:
hmm... zooitje redenen om in C en niet in C++ te coden :

1) Je snapt geen C++
2) Je bent C++ hater
3) Je baas wil dat je het in C maakt
4) Je collega's (die het moeten gaan onderhouden) kunnen geen C++
5) Raw speed is belangrijker voor je project dan safety

6) Executable/DLL size moet echt zo klein mogelijk zijn, tot aan gemiereneuk op de byte aan toe.

Ik heb ooit een Remote Desktop omgeving geschreven 'from scratch', en op basis van 5 en 6 de hook-DLL geschreven in C. Server en client-software wel allemaal in C++ natuurlijk.

[curry684]

Verwijderd schreef op 25 december 2002 @ 21:11:
[...]
C++ is (effectief) een superset van C, en omdat je in C++ geen performance inlevert voor features die je niet gebruikt is het onzin om te zeggen (of te impliceren) dat C sneller is dan C++. Met sommige C++ faciliteiten (templates+inlining) schijnt soms zelfs meer performance behaald te kunnen worden dan een C oplossing kan bieden.

Uhm ja maar....... als je geen van de features van C++ gebruikt dan ZIT je gewoon in C te coden

Zodra je feitelijk classes gaat maken komen er virtual function tables langs, RTTI type checking (!) etc. langs die allemaal performance eten. Templates zullen een perfect geoptimaliseerd C-progsel niet kunnen verslaan en inlining bestaat in C onder de naam 'parameterized macros'

[Verwijderd]

curry684 schreef op 26 December 2002 @ 12:22:
[...]

Uhm ja maar....... als je geen van de features van C++ gebruikt dan ZIT je gewoon in C te coden

Zodra je feitelijk classes gaat maken komen er virtual function tables langs, RTTI type checking (!) etc. langs die allemaal performance eten. Templates zullen een perfect geoptimaliseerd C-progsel niet kunnen verslaan en inlining bestaat in C onder de naam 'parameterized macros'

Akhorahil's derde argument suggereerde dat je alle toegevoegde features van C++ af kon wijzen op basis van de overhead die bepaalde features (die je helemaal niet hoeft te gebruiken!) met zich meebrengen. Dat is echter ronduit dom, omdat er genoeg C++ features zijn (namespaces, templates, references, standard library algoritmes, classes, etc.) waar je van kan profiteren zonder meteen snelheid te hoeven verliezen ten opzichte van C-only oplossingen.

[Verwijderd]

Het loopt wel een beetje offtopic hier, maar de reden waarom ik voor C en niet voor C++ kies is heel simpel, je kan hetzelfde resultaat verkrijgen met een derde van de code.

[Zoijar]

Wat een onzin...sorry hoor. Ik zie geen enkele rede om C te gebruiken ipv C++. De enige die ik kan bedenken is als er voor jouw target platform alleen een C compiler beschikbaar is en geen C++. En dan nog, je kan altijd bv comeau gebruiken op een ander platform om je C++ source naar ansi-c te compilen... Als je enigszins weet hoe de C++ features worden geimplemeteerd dan weet je dat ze geen "performance eten".
En dat je in C maar een derde van de code nodig hebt is natuurlijk niet waar.

Maarja...zal altijd wel zo blijven

[Verwijderd]

Zoijar schreef op 26 December 2002 @ 14:39:
Wat een onzin...sorry hoor. Ik zie geen enkele rede om C te gebruiken ipv C++. De enige die ik kan bedenken is als er voor jouw target platform alleen een C compiler beschikbaar is en geen C++. En dan nog, je kan altijd bv comeau gebruiken op een ander platform om je C++ source naar ansi-c te compilen... Als je enigszins weet hoe de C++ features worden geimplemeteerd dan weet je dat ze geen "performance eten".
En dat je in C maar een derde van de code nodig hebt is natuurlijk niet waar.

Maarja...zal altijd wel zo blijven

Wat heb je een fantastische beargumentatie. Het heeft niets te maken met beter/slechter maar met persoonlijke voorkeur. Wat vind ik prettiger werken en wat vind jij prettiger werken.

En toen IK mijn eigen C++ source ging herschrijven naar C werd het er een stuk kleiner door, met dezelfde functionaliteit en een stuk minder overhead...

Daarom vind ik het prettiger werken.

[Zoijar]

Lees dit maar is als voorbeeld, kan het zelf niet beter zeggen. Vandaar dat ik ook geen argumenten gaf, het is allemaal al zo vaak gezegd.

Link 1

Link 2