C++ malloc(): memory corruption problem

Fråga GOSH, han är C++ expert. Och han säger att minnesproblem och sånt, är inga problem. De är enkla att fixa. Säger han.

Du har förmodligen skrivit över någon buffer, alltså om du endast deklarerat en variabel med en buffer på 10 tecken men skriver dit 11 tecken så har du skrivit över buffern och in på annat område.
Om inte kompilatorn ser detta eller du inte får varning i debug så är det en klart svår bugg och hitta eftersom den kan ge upphov till fel på ett helt annat ställe.

Det är en av de svåraste buggarna om man inte har bra debughantering och inte tänkt på detta när man programmerar

läste lite mer noga:
char * test[10] och char [10] men inte string [10].
du vet att det är ganska stor skillnad på dessa. om du även lägger in dem i en lista så undrar jag om du har riktig koll på vad du tänkt göra?

kan du skicka upp lite kod?

Har du CPP koden med (där det görs alltså)

vet att du inte frågade detta men jag kan inte låta bli och nämna variabelbenämningen, den är inte konsekvent vilket gör koden mer svårläst. inga problem med så här lite kod men öka bara lite så har man huvudvärk

kolla här
http://www.sweclockers.com/forum/showthread.php?s=&postid=728...

Se det här som tips, alla väljer och koda som de vill givetvis men jag beskriver här vad som är inkonsekvent samt även ologiskt.

const char * goalFilename
goalFilename är en pekare men har inget "p", goal är med små bokstäver, vad är logiken i det?

Hade jag skrivit variabeln så hade jag skrivit så här
const char * pszFilenameGoal
Det är en pekare till en sträng av char som anger ett filnamn för något med "goal". En programmerare är i första hand intresserad av typen så den vet hur den skall jobba med variabel rent programmeringstekniskt. "goal" är mest för användaren som skall använda programmet.

TiXmlDocument * XmlConfig
Inget p och dessutom förstår man inte vad är för typ av objekt om man inte letar upp var det är deklarerat. Det skall alltid och gå och se direkt på variabeln så mycket som möjligt vad det är för typ av objekt. Detta för att få självdokumenterad kod.
Så här hade jag skrivit
TiXmlDocument* pTiXmlDocument
eller
TiXmlDocument* ptixmldocumentConfig

void setVariable(string variableName, string value)
Ena namnet har variable innan och det andra bara value, olika sätt och benämna

så här hade jag skrivit
void setVariable(string stringName, string stringValue)
Då ser du direkt vad det är för typ av variabel och även namnet

string mVariableStore[10];
detta är en vektor men det går inte och se, skall programmeraren använda variabeln så måste han leta upp deklarationen för att fatta hur den skall användas.
Bättre då att använda någon form av prefix för vektorer eller möjligen pekare
exempelvis
string m_astringVariableStore[10];
"a" står för array och string för det är en variabel av typen string
Personligen så föredrar jag och skriva m_ för medlemsvariabler eftersom m'et annars kan förväxlas med variabeltyp.

Tittat lite och hittade detta
"delete [] mVariableStore;"

varför kör du delete?

Det där är ett övergångsproblem och jag tycker du skall ändra direkt (om du tänkt jobba lite mer med programmering).

Problemet är att man som icke programmerare tänker mer som vi gör i vardagen. Ser du en bil så tänker du bil, ser du en färg så tänker du på färgens namn kanske.
I vår verkliga värld så är det just typen, alltså en bil är en bil som man kan köra. en färg är en färg som beskriver utseende. Vet du typen på objektet så vet du även hur du kan använda det. Du vet direkt att man kan köra en bil.

Men om du benämner en variabel med bilVolvo så vet programmeraren ingenting. Hade den sett bilen på parkeringsplatsen så givetvis men nu är det ett objekt i koden vilket är en helt annan sak. Vad syftet för dig som programmerare är med namnet, det är just och förklara hur variabeln kan användas.

Står det psz (en standard för charbuffer) så vet programmeraren direkt hur den kan jobba med variabeln. Du behöver inte förklara för andra hur du tänkt och vad som är vad.

angående delete på det dära så skall man inte köra delete på något som man inte gjort "new" på. Variabeln kommer skapas upp med automatik och även raderas med automatik så du behöver inte köra delete.

såg detta med:
--------------------------
/**
* A nonsense function that can be used to try different things.
*/
void KnowledgeBase::debugFunc() {
TiXmlDocument returnDocument;
TiXmlElement * root = new TiXmlElement("root");
returnDocument.LinkEndChild(root);

TiXmlDocument origDocument;
TiXmlElement * root2 = new TiXmlElement("root");
origDocument.LinkEndChild(root2);
TiXmlElement * object = new TiXmlElement("object");
TiXmlElement * position = new TiXmlElement("position");
TiXmlElement * sings = new TiXmlElement("sings");

object->SetAttribute("id","@1");
object->SetAttribute("type","@2");

position->SetAttribute("x","@3");
position->SetAttribute("y","@4");

/*sings->SetAttribute("id","@1");
sings->SetAttribute("song","Amazing");
*/
object->LinkEndChild(position);
root2->LinkEndChild(object);
// root2->LinkEndChild(sings);

origDocument.Print();

char * xsbQueryTest = "object(CC,BB), position(CC,G,H).";
if (!xsb_query_string(xsbQueryTest)) {
int i = 1;
xsb2xml(root2,root,i);

}
xsb_close_query();

clearVariableStore();
}
-------------------------
Nu vet jag inte om de objekten som du sänder över pekarna till hanterar radering av dem men om de inte gör det så läcker det minne ordentligt där. ser att det är en debugfunktion men viktigt och göra rätt i alla.

Nu är jag kanske inte rätt person att läxa upp dig och jag har inte sett koden men:

Skall det inte vara prgbFilenameGoal? Eftersom att char egentligen är en array(rg) som innehåller bytes(b). sz är ju "zero-terminated string".

Varför inte m_arstrVariableStore? Eftersom array=ar och string=str?

Om det nu är Hungarian Notation man använder sig av.
http://en.wikipedia.org/wiki/Hungarian_notation

Det finns många som kodar som en potta skit. Läs exempelvis matematiker som visar hur man löser matematiska problem programmeringsmässig. De brukar lyckas med och skriva 10 helt oläsliga rader kod som dessutom är korta.

sunkBurk Exakt hur man väljer och benämna variabler är lite upp till programmeraren, det viktiga är att man är konsekvent.

Men en superviktig sak och tänka på:
- Det är lättare och komma ihåg en regel jämfört med tio regler

Varför inte m_arstrVariableStore? Eftersom array=ar och string=str?

"ar" är två bokstäver, varför måste man ha två, går det och förkorta eftersom en bokstav är lättare och komma ihåg jämfört med två
"str" är tre bokstäver. Om du har en annan strängklass som heter CString eller varför inte wstring (unicode versionen). hur skall man veta vad "str" är för typ av string objekt.
Dessutom är string objekten objekt som alla andra objekt. varför förkorta detta objektet och kanske inte andra eller skall alla objekt förkortas?

Då är det enligt mig bättre och skapa få regler som är lätta och komma ihåg och beskriver mycket.
skriv exempelvis ut hela objektnamnet i små bokstäver och sedan kommer variabelbenämningen. detta är en enda regel som löser alla objekt

Om den funktion som returnerar pekaren gjort så att mottagaren måste radera den så är det extremt dåligt kodat. Förmodligen är det någon java-nisse eller C# kodare som skrivit funktionen i C++, de skickar objekt lite hur som helst för de behöver inte bry sig om hur objekten raderas. Det inbjuder till slarvig programmering.

Normalt sett så försöker du alltid para ett "new" med ett "delete". ser du inget "new" så behöver du heller inte köra något "delete".

Har du grävt en grop med "new" så måste du täppa igen den med "delete" men gräver du ingen grop så behöver du heller inte täppa igen den

prövat att använda valgrind ??

hmmm, kanske inte smartaste sättet.. använder man sig av olika bibliotek och de har lite egenheter för sig så skall man vara väldigt noga med om det faktiskt är värt. ok det fungerar säkert och använda för en labb men skall man göra en applikation som senare används av andra så måste man vara mycket noga med att kvaliteten är bra. minsta lilla samtidigt som man har dåliga möjligheter och själv rätta så strunta i det och koda själv även om det kan innebära lite extra tid

Detta rekommenderar jag också. Valgrind är duktig på att hitta minnesläckor. Kompilera in debuginfo (-g) i ditt program och kör valgrind --leak-check=yes dittprogram

Haha, du är inte på riktigt? Det finns programmerare som är skickliga nog att anpassa sig efter språken.

Nej jag är inte på riktigt

Självklart finns det javakodare som kan koda bra men deras språk har inbyggd hantering för pekare så programmeraren behöver aldrig tänka på det. I C++ är det i praktiken omöjligt och slarva med pekare eftersom det inte blir så många rader innan man inte har kontroll på koden.

C++ tvingar programmeraren till och skärpa sig, medan andra språk är mer förlåtande.

Anjovi: Jag kollade de där funktionerna som du nämnde och returnerade bool, vad jag såg så returnerade de en int. Och det är faktiskt bra för då kan man returnera mer information om vad som är felet. Returneras 0 så går allt perfekt. Returneras ett possitivt nummer så har det gått bra men man bör vara vaksam. Returneras ett negativ nummer så har det ballat ur och man kan ibland se vad som gått fel genom att tolka vilket nummer som returnerades. Ofta brukar de iofs ha makron för att kolla om funktionen gick bra eller ej och då blir det mer lättläst med.

Angående lib till C++:
C++ är inte gjort för att man skall använda sig av andra lib i första hand, det är gjort för att göra egna program och då det mesta av jobbet själv.
Det är få som gör lib i java eller C# dels på grund av att de själva har ett mastodontlib som följer med och de språken är inte gjorda för att man skall koda lika mycket själv som exempelvis C++.

C++ försöker göra det möjligt för kodaren och göra snabbast möjliga kod med maximal frihet.
En lat programmerare kommer och hata C++.
Men att vara lat är jobbigt, vet inte om du spelat squash någon gång men om du gjort det och försöker vila lite så märker du snabbt att du får springa mycket mer eftersom den andre då kan spela ut dig. Samma sak med programmering, att vara lat programmerare straffar sig väldigt snabbt.

Vad du tjänar på java och C# är att du kommer igång snabbare och har något och visa upp. Möjligen behöver du inte skriva lika mycket kod (vilket man oftast behöver efter ett tag).
C++ har en helt annan utvecklingscykel. ofta märks inget i början, folk kanske undrar varför inget händer som inte är med och progammerar. Detta beror på att C++ programmerarna då bygger upp sina egna lib/klasser och annat som designen är beroende av. I C++ måste man i princip alltid börja med att skapa funktionalitet för datat, inte designen på applikation medan man ibland gör tvärtom i andra språk. När det gått ett tag i projektet så börjar C++ programmet ta fart, det går ofta snabbare och snabbare för en utomstådende med de som kört motsatt teknik (börjat med design) tappar fart efter ett tag.

Det som är jobbigt med programmering är inte att att skriva kod, det jobbiga är att få bra struktur (eller rättare sagt så om man inte fått till strukturen så är det väldigt jobbigt) så man kan lägga till funktionalitet eller snabbt förändra. Även att programmera buggfritt.
För en van C++'are är detta inga större problem men för en ovan så kan det vara väldiga problem

Japp helt klart är "if (!xsb_next)" dåligt skriven kod men det är ändå bra att man ser det och faktiskt förstår att det är illa skrivet. I Windows så använder man ofta något som kallas för HRESULT vilket igentligen är en "long" och då finns två makron FAILED och SUCCEEDED

Du kan exempelvis skriva if( SUCCEEDED( xsb_next() ) ) { ... } vilket är mycket tydligare.

Skall man göra labbar eller små testprogram så är C++ ingen hitt. Men när man gör program för att större användande så krävs det en hel del jobb. Skulle exempelvis de som gör Photoshop, AutoCAD, Visual Studio, Word eller något annat program förlita sig på lib som olika gjort då hade de garanterat fått problem. Dessa företag har med all sannolikhet byggt upp deras egen generella kodbas som just passar deras program.

Skriv ett eget macro
#define SUCCEEDED(returnvalue) ((returnvalue) >= 0)