[C++] Borland 5.5 vergeet in class mijn variabelen

[tafkaw]

hallo allemaal,

ik heb een klein probleempje

code:

database.h

C++:

class _abc 
{
 char eenvariabele[256];
public:
 void initiate(void);
 void geefterug(char *test);
}

database.cpp

C++:

void _abc::initiate(void)
{
strcpy(eenvariabele, "test");
}

void _abc::geefterug(char *test)
{
strcpy(test, eenvariabele);
}

main.cpp

C++:

int main(void)  // weet ook wel dat dit nie zo is, maar is ff zo voor de uitleg
{
_abc testerdetest;
char testje[256];
testerdetest.initiate();
testerdetest.geefterug(testje);
application.msgbox(testje, "test", MB_OK);
}

owkeew, het gaat nu om het volgende probleem:
tijdens het initialiseren (testerdetest.initiate()) gaat alles goed, in die functie wordt de variabele eenvariabele gevuld, wat ie ook echt doet
nou is mijn probleem dat in de functie testerdetest.geefterug daarin de variabele eenvariabele weer compleet leeg is, alsof ie niet gevuld is in de vorige functie
wat het nog vreemder maakt is dat als ik 'eenvariabele' dan public maak, dan kan ik hem in de functie testerdetest.geefterug nog steeds niet uitlezen, maar in de mainfunctie heeft ie dan wel de goede waarde, namelijk 'test'

ik snap hier echt geen donder van

zou iemand please zo vriendelijk willen zijn mij hiermee te helpen

[ Voor 9% gewijzigd door curry684 op 22-03-2004 22:18 . Reden: dan doe ik het maar... ]

[Verwijderd]

Allereerst zou ik je willen adviseren om je code leesbaarder te maken, dit kun je met code tags doen.
Zelf heb ik even snel je voorbeeld omgebouwd en deze werkt:

C++:

#include <iostream>

class CTest
{
private:
  char m_chararray[256];
public:
  CTest(const char* initial)
  {
    std::strcpy( m_chararray, initial );
  }

  void getit(char* right)
  {
    std::strcpy(right, m_chararray);
  }
};

int main(int argc, char* argv[])
{
  CTest test("blaat");
  char chars[256];
  test.getit(chars);
  std::cout << chars;
  std::cin.get();
}

[MSalters]

Verwijderd schreef op 22 maart 2004 @ 14:50:
Allereerst zou ik je willen adviseren om je code leesbaarder te maken, dit kun je met code tags doen.
Zelf heb ik even snel je voorbeeld omgebouwd en deze werkt:

C++:

#include <iostream>
#include <string>

class CTest
{
private:
  char m_chararray[256];
public:
  CTest(const char* initial)
  {
    std::strcpy( m_chararray, initial );
  }

  void getit(char* right)
  {
    std::strcpy(right, m_chararray);
  }
};

int main(int argc, char* argv[])
{
  CTest test("blaat");
  char chars[256];
  test.getit(chars);
  std::cout << chars;
  std::cin.get();
}

Waarom niet meteen goed en

C++:

#include <iostream>

class CTest
{
private:
  std::string m_string;
public:
  CTest(std::string const& initial) 
  : m_string (initial)
  {  }

  void getit(std::string & right)
  {
    right =  string;
  }
};

int main(int argc, char* argv[])
{
  CTest test("blaat");
  std::string chars;
  test.getit(chars);
  std::cout << chars;
  std::cin.get();
}

[ Voor 5% gewijzigd door MSalters op 22-03-2004 19:20 ]

[.oisyn]

Je vergeet de m_ nog in CTest::getit ()

Gr0wLiThE: Maar over je probleem, dat werkt hier gewoon, dus ik snap het eigenlijk niet. Hoe kom je eigenlijk tot de conclusie dat er niets in staat? Heb je al eens met een debugger gekeken?

[tafkaw]

ja, want ik gebruik eigenlijk c in c++, dus zonder al die andere libaries.
als ik 'gewone' c-vars gebruik, dan blijft de variabele leeg als ik um in een functie in de class zelf uitlees. ik wil de code graag op de manier die ik getikt heb, omdat ik zelf nog niet zoveel ervaring heb met als die extra libaries enz van c++, en liever gewoon c gebruik

code:

void _abc::initiate(void) 
{ 
strcpy(eenvariabele, "test");  //hier vul ik die var dus
} 

void _abc::geefterug(char *test) 
{ 
strcpy(test, eenvariabele); //en als ik um hier probeer uit te lezen (ook met debugger echt getest blijft ie leeg
}

[Verwijderd]

Je mixt c code met c++ code en daar kan C++Builder behoorlijk van in de war raken.
De Functie strcpy is c code, maar C++Builder denkt dat je in C++ aan het klussen bent en probeert daarom strcpy volgens de C++ manier te compileren (lees std::strcpy). Dit gaat natuurlijk niet en daarom kan het fout gaan. Jawel KAN fout gaan (levert in iedergeval buggy code op). Wat ietwat slordig is, is dat de compiler geen error of warning hiervoor geeft. Mijn advies, gebruikt std:strcpy (samen met #include <cstring>). Of nog beter, stap volledig over op C++. C++ is een heel andere progtaal dan C, die toevallig downwards compatible is met C. Koop een goed boek, zoals "The C++ Standard Library" van Nicolai M. Josuttis. Als je dit eenmaal gelezen hebt, wil je nooit meer terug naar C. (Let wel, geen reclame, slechts mijn enorme ethausiamse over de standaard C++ library)

[farlane]

Je zegt blijft ie leeg, bedoel je dat het test leegblijft of dat eenvariabele leeg is ?

[tafkaw]

eenvariabele & test blijven allebei leeg (in de 2e functie, dus in de functie geefterug)

[curry684]

Verwijderd schreef op 23 maart 2004 @ 10:11:
Je mixt c code met c++ code en daar kan C++Builder behoorlijk van in de war raken.
De Functie strcpy is c code, maar C++Builder denkt dat je in C++ aan het klussen bent en probeert daarom strcpy volgens de C++ manier te compileren (lees std::strcpy). Dit gaat natuurlijk niet en daarom kan het fout gaan. Jawel KAN fout gaan (levert in iedergeval buggy code op). Wat ietwat slordig is, is dat de compiler geen error of warning hiervoor geeft.

Uhm, kweet niet waar je bovenstaand verhaal vandaan hebt maar het slaat nergens op

strcpy werkt perfect in C++Builder, ik heb het in enkele triljarden aanroepen nog nooit fout zien gaan. En dat is dezelfde compiler als Borland 5.5 dus.

std::strcpy is sowieso in de praktijk niets anders dan:

C++:

namespace std {
  inline char* strcpy(char* dst, const char* src) { return ::strcpy(dst, src); }
}

Tis niet alsof er andere code achter zit....

[ Voor 17% gewijzigd door curry684 op 23-03-2004 10:52 ]

[farlane]

Kan het zijn dat je optimalisaties nog aan hebt staan, zodat je geen correcte debug informatie hebt ?

[tafkaw]

ik heb geen optimalisaties aanstaan, alleen alle debuginforamtie aanstaan, om tenminste alle warnings en errors te krijgen
bij mijn weten werkt trouwens c-functies wel altijd onder c++
ik heb nl al redelijk wat win32 progsels geschreven met heel vaak c dingen erin als fopen, strcpy enz, en het werkte altijd perfect (en meestal sneller dan de c++ functies)

[farlane]

Dan snap ik er ook niets van, de code is gewoon goed. Het enige dat ik zou kunnen bedenken, maar dat is erg ver gezocht, dat die underscore iets betekent voor de compiler.

[.oisyn]

Gr0wLiThE schreef op 23 maart 2004 @ 11:22:
ik heb nl al redelijk wat win32 progsels geschreven met heel vaak c dingen erin als fopen, strcpy enz, en het werkte altijd perfect (en meestal sneller dan de c++ functies)

Let ook maar niet op dat verhaal van Magic Mark, dat slaat nergens op
Wat krijg je als output als je dit programmaatje compilet en runt:

C++:

#include <iostream>
#include <cstring>

int main ()
{
    char str[256] = "";
    std::cout << "De string bevat nu: \"" << str << '"' << std::endl;

    std::strcpy (str, "Teststring");
    std::cout << "De string bevat nu: \"" << str << '"' << std::endl;

    std::strcpy (str, "bliep");
    std::cout << "De string bevat nu: \"" << str << '"' << std::endl;
}

[ Voor 41% gewijzigd door .oisyn op 23-03-2004 13:40 ]

[MSalters]

curry684 schreef op 23 maart 2004 @ 10:47:
[...]

std::strcpy is sowieso in de praktijk niets anders dan:

C++:

namespace std {
  inline char* strcpy(char* dst, const char* src) { return ::strcpy(dst, src); }
}

Tis niet alsof er andere code achter zit....

Nee, 't is andersom:

C++:

// <cstdio>
namespace std {
   inline char* strcpy(char* dst, const char* src)
   {
      while( *dst++ = *src++ ) ; // of slimmer
   }
}
// <stdio.h>
#include <cstdio>
using namespace std;

De reden: assert( &std::strcpy == &::strcpy );

[curry684]

MSalters schreef op 23 maart 2004 @ 15:18:
[...]

Nee, 't is andersom:

Mierenneuker Ging om het gedeelte dat de code hoe dan ook identiek is

[.oisyn]

Ja maar dat kan andersom net zo goed

C++:

// string.h
extern "C" char * strcpy (char *, const char *);

// cstring
#include <string.h>
namespace std
{
    using ::strcpy;
}

[ Voor 6% gewijzigd door .oisyn op 23-03-2004 15:36 ]

[Verwijderd]

curry684 schreef op 23 maart 2004 @ 10:47:
[...]

Uhm, kweet niet waar je bovenstaand verhaal vandaan hebt maar het slaat nergens op

strcpy werkt perfect in C++Builder, ik heb het in enkele triljarden aanroepen nog nooit fout zien gaan. En dat is dezelfde compiler als Borland 5.5 dus.

std::strcpy is sowieso in de praktijk niets anders dan:

C++:

namespace std {
  inline char* strcpy(char* dst, const char* src) { return ::strcpy(dst, src); }
}

Tis niet alsof er andere code achter zit....

Tsja, dan ben je blijkbaar er nog niet van op de hoogte dat strcpy en std::strcpy uit twee totaal verschillende libs komen. std::strcpy is een rewrite van strcpy en gebruikt c++ methodes (new / delete) voor geheugenmanagement in tegenstelling tot strcpy die gebruik maakt van malloc en consorten. Deze twee manieren van geheugenbeheer zijn dus absoluut niet compatible en kunnen daarom dus problemen opleveren zoals de poster ondervind. Zie ook "The C++ Programming Language" by Bjarne Stroustrup

No personal offence, maar om dan meteen uit te kramen dat dit nergens op slaat vind ik wel een beetje ver gaan. Bovendien zul jij wel triljarden keren een zeer gelukkig man zijn geweest, of stiekum toch de juiste libs gebruikt hebben.

[.oisyn]

Wat een onzin, strcpy doet geen enkel geheugenbeheer whatsoever, die kopieert alleen de ene null-terminated char-buffer naar de ander. new/delete of malloc/free is echt totaal niet relevant. Wellicht ben je in de war met een functie als strdup () oid?

[curry684]

Verwijderd schreef op 23 maart 2004 @ 22:03:
[...]
Tsja, dan ben je blijkbaar er nog niet van op de hoogte dat strcpy en std::strcpy uit twee totaal verschillende libs komen. std::strcpy is een rewrite van strcpy en gebruikt c++ methodes (new / delete) voor geheugenmanagement in tegenstelling tot strcpy die gebruik maakt van malloc en consorten.

Wtf slaat dat op? Waarom zou strcpy moeten alloceren?

Deze twee manieren van geheugenbeheer zijn dus absoluut niet compatible en kunnen daarom dus problemen opleveren zoals de poster ondervind. Zie ook "The C++ Programming Language" by Bjarne Stroustrup

Ligt hier naast me, geef ff het paginanummer door dan zal ik het even opzoeken.

No personal offence, maar om dan meteen uit te kramen dat dit nergens op slaat vind ik wel een beetje ver gaan. Bovendien zul jij wel triljarden keren een zeer gelukkig man zijn geweest, of stiekum toch de juiste libs gebruikt hebben.

Mjah, ik zie dat dit je eerste 2 posts zijn, en om dan meteen te gaan zeggen dat ik, oisyn en MSalters uit onze nek zwetsen is ook niet helemaal de beste entree op C++ gebied hier. Feel free om te onderbouwen echter

[Korben]

In reply tot TS... Whoa... ik vraag me af wat je verder in je code doet, maar als zelfs dat kleine voorbeeld het niet doet... dat is gewoon zo keihard onmogelijk eigenlijk, dat het haast een fout in je compiler moet zijn... Ik neem aan dat curry, MSalters & oisyn evenals ikzelf allemaal VC7.1 gebruiken dus...

[MSalters]

Verwijderd schreef op 23 maart 2004 @ 22:03:
[...]
Tsja, dan ben je blijkbaar er nog niet van op de hoogte dat strcpy en std::strcpy uit twee totaal verschillende libs komen. std::strcpy is een rewrite van strcpy en gebruikt c++ methodes (new / delete) voor geheugenmanagement in tegenstelling tot strcpy die gebruik maakt van malloc en consorten. Deze twee manieren van geheugenbeheer zijn dus absoluut niet compatible en kunnen daarom dus problemen opleveren zoals de poster ondervind. Zie ook "The C++ Programming Language" by Bjarne Stroustrup

Nou moet ik direct toegeven dat ik dat niet wist. Sterker nog, de rest van de ISO C++ commissie weet dat ook niet, en Bjarne dus ook niet. Misschien kun je even aangeven waar dat in de standaard staat, dan zorg ik hoogstpersoonlijk dat dit kleine foutje wordt gefixt.

Dat staat los van het feit dat std::strcpy inderdaad helemaal geen memory management doet.

[tafkaw]

okeew, allemaal heel leuk...
dit zou dus betekenen dat als Magic Mark gelijk heeft, dat ik std::strcpy moet gebruiken inpl v de strcpy van C.
ik hoop dat dat het is, maar ik kan het nu even niet testen want we zitten midden in een verhuizing, en me pc is net naar het nieuwe huis verplaatst
alleen vraag k me nou ff af, of iemand mijn probleem ook kan reproduceren
ik hoop in ieder geval van wel, want anders kan ik me pc alweer gan formatteren en opnieuw installeren dat zou ik toch niet zo heel fijn vinden eigenlijk, omdat ik dat een week geleden nog gedaan heb

ik hoop dat iemand mijn probleem wel kan reproduceren, want dan zal k is een nieuwe compiler gaan zoeken voor mijn programmaatje... (alhoewel me dat ook weer redelijk veel tijd en/of geld gaat kosten )

[farlane]

Ik denk eerlijk gezegd dat er toch iets fout zit in je code, ik kan me moeilijk voorstellen dat zo iets simpels niet correct wordt gecompileerd.

Het probleem kan overigens wel ergens anders zitten, niet perse in dit stukje.

[MSalters]

Gr0wLiThE schreef op 25 maart 2004 @ 08:57:
okeew, allemaal heel leuk...
dit zou dus betekenen dat als Magic Mark gelijk heeft, dat ik std::strcpy moet gebruiken inpl v de strcpy van C.
ik hoop dat dat het is, maar ik kan het nu even niet testen want we zitten midden in een verhuizing, en me pc is net naar het nieuwe huis verplaatst
alleen vraag k me nou ff af, of iemand mijn probleem ook kan reproduceren
ik hoop in ieder geval van wel, want anders kan ik me pc alweer gan formatteren en opnieuw installeren dat zou ik toch niet zo heel fijn vinden eigenlijk, omdat ik dat een week geleden nog gedaan heb

ik hoop dat iemand mijn probleem wel kan reproduceren, want dan zal k is een nieuwe compiler gaan zoeken voor mijn programmaatje... (alhoewel me dat ook weer redelijk veel tijd en/of geld gaat kosten )

Misschien kun je nog even de reacties lezen. Er zitten hier genoeg professionals die wel weten hoe std::strcpy werkt. In een commerciele omgeving red je het niet als je aanneemt dat strcpy memory management doet, dan krijg je op z'n best een transfer naar de VB club.

Heb je al met de debugger gekeken wat er precies gebeurt? Wat zie je gebeuren als je line voor line door je code loopt?

[tafkaw]

ik heb met die debugger alle code regel voor regel nagelopen, en daarmee gebeurde het precies zoals ik omschreven heb...
ik heb de andere reacties ook gelezen, maar er wordt op die manier geen oplossing gevonden, en ik probeer alleen maar dingen uit te sluiten... het kan dus best dat Magic Mark niet gelijk heeft, maar dat wil ik dus graag testen voordat ik hem ongelijk geef... mensen die net beginnen hoeven niet standaard ongelijk te hebben... (owkee, ik vind het zelf ook zeer onwaarschijnlijk, maar ik wil gewoon alle dingen uitproberen, omdat ik het opgelost wil hebben)

en wat die code betreft, zal ik (als ik in het nieuwe huis woon ) wel ff die code hier posten, maar (bij mijn weten:9) zit er geen verschil tussen mijn voorbeeld en de code...

[.oisyn]

Al zou Magic Mark inhoudelijk gelijk hebben dan was het hier alsnog niet relevant, omdat je helemaal geen C en C++ library calls mixt

Had je dit stukje code ook al eens geprobeerd? [rml].oisyn in "[ C++] Borland 5.5 vergeet in class mijn ..."[/rml]

[tafkaw]

okeew, ik ben ondertussen verhuisd, heb mn computer weer werkend, en ben nu achter mijn 'fout'

ik had dus de volgende code:

database.h

code:

 class _abc  
{ 
 char eenvariabele[256]; 
public: 
 void initiate(void); 
 void geefterug(char *test); 
}

database.cpp

code:

void _abc::initiate(void) 
{ 
strcpy(eenvariabele, "test"); 
} 

void _abc::geefterug(char *test) 
{ 
strcpy(test, eenvariabele); 
}

main.cpp

code:

 int main(void)  // weet ook wel dat dit nie zo is, maar is ff zo voor de uitleg 
{ 
_abc testerdetest; 
char testje[256]; 
testerdetest.initiate(); 
testerdetest.geefterug(testje); 
application.msgbox(testje, "test", MB_OK); 
}

in mijn eigen code had ik nu '_abc testerdetest' in database.h staan, en in main.h dan database.h geinclude. als ik dan probeerde de variabele testerdetest in main.cpp te gebruiken, dan behandelde hij dat als een andere variabele dan die in database.cpp zelf
stomme fout dus