[C++] Pointer probleem

[Verwijderd]

Ik heb een funtie die een 3 letterige code meekrijgt. De ascii waardes van de afzonderlijke letters worden opgeteld en het totaal wordt verhoogd met 200. Het cijfer dat hier uit komt vormt samen met de 3 letters de nieuwe code. Ik doe dit met de onderstaande code.

C++:

AnsiString CreateNewCode(AnsiString Code)
{
  char word[3];
  int decimal[4], tmp=200;

  StrCopy(word, Code.c_str());

  for(int i=0; i<3; i++)
  {
    decimal[i] = int(word[i]);
    tmp=tmp+decimal[i];
  }

  AnsiString ff = IntToStr(tmp);

  return StrCat(Code.c_str(),ff.c_str());
}

De code compileerd foutloos maar als ik hem uitvoer krijg ik een invallid pointer operation, wanneer ik de foutmelding wegklik zie ik wel de juiste NewCode.
Ik heb dit weekend gegoogled maar niet echt iets nuttigs gevonden.

Mijn vermoeden is dat zodra de fuctie out of scope raakt er nog pointers in de functie staan die ik niet verwijderd heb. Ik weet dit echer niet zeker.

Wie weet het wel?

[LordLarry]

Let wel dat C strings altijd een /0 aan het eind bevatten. Een 3 letterige string benodigt dan ook 4 plaatsen.

[whoami]

Als je debugged, op welke lijn geeft ie dan die fout?

[LordLarry]

En het is veiliger om StrLCpy te gebruiken aangezien je daar een maximale lengte aan mee kan geven. Wat zeker niet onverstandig is in jouw geval waar de strings erg klein zijn.

Verder is 1 teken niet groter dan een byte, dus de int is eigenlijk te groot. Maar om efficiente redenen is de int wel sneler als een byte.

Waarom, vul je decimal? je doet er niets mee toch?

En waarom gebruik je StrCat (c string) terwijl je volgensmij gewoon 2 AnsiStrings kan samenvoegen met +?

[Verwijderd]

Als je debugged, op welke lijn geeft ie dan die fout?

Op de line waar ik de functie aanroep.

[LordLarry]

Erm...wordt ik hier genegeerd?

[Verwijderd]

Erm...wordt ik hier genegeerd?

Nee nee, ik ben jouw tips nu aan het proberen. Nee ik negeer je niet!!!

[Verwijderd]

En het is veiliger om StrLCpy te gebruiken aangezien je daar een maximale lengte aan mee kan geven. Wat zeker niet onverstandig is in jouw geval waar de strings erg klein zijn.

Ok heb ik gedaan, loste het probleem nog niet op maar wel een verbetering van de code.

Verder is 1 teken niet groter dan een byte, dus de int is eigenlijk te groot. Maar om efficiente redenen is de int wel sneler als een byte.

Weer iets geleerd!

Waarom, vul je decimal? je doet er niets mee toch?

Helemaal waar, dit was een vonst van google en daar heb ik zelf dus niet goed op gelet. Ik heb het weggehaald maar het probleem was er nog.

En waarom gebruik je StrCat (c string) terwijl je volgensmij gewoon 2 AnsiStrings kan samenvoegen met +?

En deze tip loste mijn probleem op. Bedankt dus voor de tuning en tips.

[LordLarry]

Geen probleem. Heb je er ook char word[4]; ipv char word[3]; van gemaakt? Want dit is zeker ook een bug.

[Verwijderd]

kweenie welke c++ jij gebruikt. . maar bij mij (ms vc++) levert strcat geen ansistring op . . .maar een 'gewone' string

[Verwijderd]

kweenie welke c++ jij gebruikt. . maar bij mij (ms vc++) levert strcat geen ansistring op . . .maar een 'gewone' string

Klopt. Maar door de toevoeging .c_str() achter een AnsiString wordt deze geconverteerd naar een ''gewone' string.

C++:

return StrCat(Code.c_str(),ff.c_str());

[farlane]

Verwijderd schreef op 07 oktober 2002 @ 10:38:
kweenie welke c++ jij gebruikt. . maar bij mij (ms vc++) levert strcat geen ansistring op . . .maar een 'gewone' string

Bovendien heet die functie strcat en niet StrCat. Ik heb het idee dat dit een Borland iets is ?

[Boy]

LordLarry schreef op 07 oktober 2002 @ 10:07:
Let wel dat C strings altijd een /0 aan het eind bevatten. Een 3 letterige string benodigt dan ook 4 plaatsen.

\0

[Verwijderd]

Heb je er ook char word[4]; ipv char word[3]; van gemaakt? Want dit is zeker ook een bug.

Ik neem aan dat de laatse plaats voor de '\0'. Dit is natuurlijk de nette manier van programmeren. Maar ff voor mijn begrip, als ik maar 3 geheugen plaatsen heb

char word[3];

en ik heb een string van 'ABC\0'. Dat zou de '\0' buiten de string vallen maar heb ik toch nog altijd mijn 'ABC'? Of nie?

[ Voor 0% gewijzigd door Verwijderd op 07-10-2002 10:51 . Reden: \ ipv / ]

[kvdveer]

Verwijderd schreef op 07 oktober 2002 @ 10:50:
[...]

en ik heb een string van 'ABC\0'. Dat zou de '\0' buiten de string vallen maar heb ik toch nog altijd mijn 'ABC'? Of nie?

Ja, maar vervolgens kun je het niet meer als string behandelen.
strcpy kopieert de \0 mee, dus als je kopieert naar een buffer van 3 chars, dan overschrijf je een byte ander geheugen. Zoiets heet een "off-by-one bufferoverrun", bugtraq staat er vol mee.

[LordLarry]

wat kvdveer zegt, plus dat je een 'oneindige' string hebt en de c string functies dus netzolang doorgaan tot ze een \0 tegenkomen. Daarbij krijg je dus mogelijk een erg lange string met rotzooi karakters erin.

[Zoijar]

Hmm zo uit mn hoofd (niet getest!)

code:

#include <string>
#include <sstream>

template <class T>
std::String toString(const T& src) {
    std::ostringstream sstr;
    sstr << src;
    return sstr.str();
}


std::string createNewCode(const std::string& str) {
    static const int len = 3;
    int sum = 0;
    std::string result;

    if (str.size() != len) {
        // possibly throw exception or return empty string or whatever
    }

    for (int i=0; i<len; ++i) {
        sum += static_cast<unsigned int>(str[i]);
        result += str[i];
    }

    return (result + toString(sum));
}

Moet je een eind op weg helpen denk ik...

[ Voor 0% gewijzigd door Zoijar op 07-10-2002 11:06 . Reden: std::ostringstream ]

[MSalters]

LordLarry schreef op 07 oktober 2002 @ 10:07:
Let wel dat C strings altijd een /0 aan het eind bevatten. Een 3 letterige string benodigt dan ook 4 plaatsen.

Kan zijn, maar hij gebruikt geen string. Hij gebruikt een array van 3 karakters. Weliswaar vult hij deze niet op de goede manier, maar die buffer hoeft echt geen 4 chars te zijn.
Sowieso moet die buffer eruit. Die maakt de code onleesbaar.
Wat is er mis met

code:

tmp = 200;
for(i=0; i!=3 && i!= Code.size(); ++i )
  tmp+= Code[i];

[LordLarry]

Je hebt gelijk, maar in zijn geval was het toch echt een bug en een string van 3 chars vult toch echt een ruimte van 4.