[C++] Release vs Debug mode

[Verwijderd]

Ik heb een dll voor mIRC, werkt perfect in debug mode (geen enkele fout).
Dan naar release mode & het werkt ineens niet meer...

Dan heb ik even gaan nalezen hoe ik moet debuggen in release mode...

Wat ik dus gedaan heb:
(Visual C++ btw)
- C/C++: General: Debug info: Program Database for Edit and Continue
- C/C++: Optimisations: Default
- C/C++: Inline: Disable
- Link: General: Generate Debug Info
- Link: General: Link incrementally

... Tot mijn grote verbazing werkt dit ook!

Maar nog steeds als ik de gekopieerde Release-mode (de "echte" release dus) probeer crasht mijn mIRC...

Let wel, dit is geen probleem betreffende mIRC, maar ergens een probleem in mijn code (die ik niet kan vinden omdat elke keer ik het wil debuggen, alles perfect verloopt).

[SWfreak]

Gooi wat output in je code (makkelijkst is om naar een file te schrijven) en probeer aan de hand daarvan het punt te vinden waar je DLL de mist in gaat?

[Martin Sturm]

Heb je wel alle settings voor debug- en releasemode hetzelfde?

[PommeFritz]

Wat vaak gebeurt is dat in debug mode het geheugen met 0x00000000 gevult wordt en bepaalde ongeinitialisseerde pointers zich "goed" gedragen.
In release mode is geheugen meestal met een random waarde gevuld, en zullen ongeinitialiseerde pointers dus "zomaar in het wild" wijzen. En dan kan de boel wel eens crashen ja.

Maar geef eens precies aan hoe hij crasht?

[hobbit_be]

je hebt een dll: wdz dat je je een externe .dll gebruikt ofdat je die zelf heb gemaakt?
define 'crash'.

meestal is het zo (in mijn ervaring) dat in debug mode alle pointerkes allemaal mooi op 'null' staan terwijl dat bij release niet zo is... Ik gebruik ook al geen jaren 'debug' meer (ik gebruik loggers voor me checking (die ik dan af/aan zet)...

edit: same time post als Patat-frites

[ Voor 12% gewijzigd door hobbit_be op 24-04-2003 20:00 ]

[Verwijderd]

martin: alle settings buiten degeen die ik opgenoemd hebben heb ik veranderd van release->release_debug mode

pommefritz: hij crasht eigenlijk niet... Ik zie op de achtergrond: first-chanc(e exception) & mijn cpu gaat naar 100%

swfreak: ik ben nu eventjes aan het schrijven naar file om te debuggen... Wel vrij omslachtige manier...

hobbit: ik init alle pointers mooi op null nu, had ik veranderd sinds vorige post, maar de 'crash' blijft er nog

[Verwijderd]

C++:

KString CanonURL(KString Invoer = "", bool NeedPostThisInfo = true) {
  char *result = new char [Invoer.Size() * 3 + 1]; // here it will surely fit in ;)
  char curChar(0);
  char *resptr = result;
  char tmp[4];

  for (int i = 0; i < Invoer.Size(); i++)
  {
    curChar = Invoer[i];

    if ( ( curChar >= 'a' && curChar <= 'z' ) ||
         ( curChar >= 'A' && curChar <= 'Z' ) ||
         ( curChar >= '0' && curChar <= '9' ) )
    {
      *(resptr++) = curChar;
    }
    else if ( curChar == ' ' && NeedPostThisInfo )
    {
      *(resptr++) = '+';
    }
    else
    {
      *(resptr++) = '%';
      sprintf(tmp, "%X", curChar);
      *(resptr++) = tmp[0];
      *(resptr++) = tmp[1];
    }
  }
  *resptr = 0;

  KString retval(result);
  delete result;

  return retval;
}

OK, hier gaat het dus totaal de mist in (in release dan)...

[Verwijderd]

wat wil je met regel 3 bereiken? Het bovenste gedeelte lijkt alleen declaraties te bevatten, maar volgend mij kan

code:

3  char curChar(0);

niet werken. Het is geen prototype, geen array declaratie en geen char declaratie. Wat moet het wel doen??

[Verwijderd]

char = int in C++

dus ik zet die char gewoon gelijk aan het allereerste karakter (ook wel de stringterminator genoemd)...

[Verwijderd]

Ow I got it!!!!! het was niet in dat stukje code, maar in een groot blok asm code dat ik geschreven had dat ik iets vies deed

Nu kan ik al mijn programma's gaan recompilen Want ik gebruik dat vrijwel overal!!

[PommeFritz]

Tip; herschrijf dat ASM stuk dan in C++?

En waarom ging het nou mis in release mode en niet in debug mode?

Tevens vind ik dat stukkie code met het commentaar

here it will surely fit in ; )

wel griezelig.... ik ruik een buffer overrun bug in de verte...

[ Voor 75% gewijzigd door PommeFritz op 24-04-2003 21:21 ]

[Verwijderd]

Verwijderd schreef op 24 April 2003 @ 20:31:

C++:

 ...
  char *result = new char [Invoer.Size() * 3 + 1]; // here it will surely fit in ;)
 ...
  delete result;

Euh, dit is eigenlijk ook verkeerd Ok, je hebt hier natuurlijk geluk dat het werkt. Je doet een 'array new'. Dan moet je ook een 'array delete' doen natuurlijk.
Dus

C++:

delete [] result;

In jouw geval maakt het toevallig niets uit omdat de destructor van char toch niets doet, maar ik zou hier toch maar een goede gewoonte van maken. Anders zou je wel eens heel rare dingen kunnen krijgen als je met niet ingebouwde types gaat spelen

[.oisyn]

Verwijderd schreef op 24 April 2003 @ 20:45:
wat wil je met regel 3 bereiken? Het bovenste gedeelte lijkt alleen declaraties te bevatten, maar volgend mij kan

code:

3  char curChar(0);

niet werken. Het is geen prototype, geen array declaratie en geen char declaratie. Wat moet het wel doen??

euh?
het is gewoon een definitie van curChar van het type char, die op 0 geinitializeerd wordt... niets mis met die statement

(het is hetzelfde als: char curChar = 0;)

Verwijderd schreef op 24 April 2003 @ 20:48:
char = int in C++

neuh, een char is gewoon een char. Je kunt 'm idd initializeren met een int literal ja, mits dat past natuurlijk

[.oisyn]

Verder: waarom niet std::string gebruiken? (is al eens eerder gemeld dacht ik )

Is wat veiliger dan je nogal vieze char allocatie, en sprintf () een stukje verderop

[Verwijderd]

oisyn: ik gebruik geen string-class omdat die te weinig kan
_piranha_: dit is NIET verkeerd
als ELK elementje van de invoerstring moet geconvert worden zit je met len(invoer) * 3 tekens... Doe daar 1 bij & je hebt de maximale lengte van de uitvoerstring... simpel hé

Of hoe zou jij het anders voorstellen? Ik heb de afweging geheugenruimte <-> snelheid gemaakt en dit is volgens mij het beste. Ik alloceer 1x geheugen, anders moet ik na elk char geheugen alloceren... Nu niet

en is een new char[xxx] een tabel? Ik dacht altijd dat dit gewoon was? Een gewone delete?

[PommeFritz]

Verwijderd schreef op 25 April 2003 @ 09:21:en is een new char[xxx] een tabel? Ik dacht altijd dat dit gewoon was? Een gewone delete?

new char[100] alloceert een array van 100 chars. Dus je moet delete[] gebruiken, omdat je een array moet dealloceren en niet een enkel object.

[Verwijderd]

/me Kan het niet laten maareh...

Verwijderd schreef op 25 April 2003 @ 09:21:
oisyn: ik gebruik geen string-class omdat die te weinig kan

Een string-class kan toch echt VEEL meer dan een op stack ge-alloceerde char-array die jij gebruikt... sprintf hoort eigenlijk niet thuis in C++ code (vind ik...)

[hobbit_be]

in Visual Studio C++ is delete == delete[] //niet mooi van MS maar tja

maar ik wil ook wel weten waarom je asm (ie geen verschil debug/release) net 'hapert' (of is het inline ASM?)

[Soultaker]

hobbit_be schreef op 25 april 2003 @ 17:15:
in Visual Studio C++ is delete == delete[] //niet mooi van MS maar tja

Dat lijkt me niet; hoe wordt het aanroepen van destructors op de objecten in een array dan afgehandeld?

[madwizard]

hobbit_be schreef op 25 April 2003 @ 17:15:
in Visual Studio C++ is delete == delete[] //niet mooi van MS maar tja

Alleen voor simpele types zonder destructors, dus niet altijd. En dat is wel mooi want het kan gewoon, er is simpelweg geen verschil tussen het deleten van 1 gealloceerde int of 100 (in VC dan), het wordt pas lelijk als je er misbruik van gaat maken.
Zie ook [rml]madwizard in "[ C / C++] De grootte van een array"[/rml].
Bottom line: gewoon delete of delete[] gebruiken zoals het hoort.

[hobbit_be]

lelijk idd ben ook VOOR het gebruik van delete[] hoor - wel wist ik niet dat het alleen voor simpel types was...

[MSalters]

hobbit_be schreef op 25 april 2003 @ 17:47:
lelijk idd ben ook VOOR het gebruik van delete[] hoor - wel wist ik niet dat het alleen voor simpel types was...

Dat is ook fout, het is voor alle types, inclusief simpele types.

De opmerkingen gingen erover dat bij MSVC++ (6) je voor simpele types delete kon schrijven ipv delete[]. Dat gaat alleen goed door een toevalligheidje in de geheugen boekhouding.

[MSalters]

Verwijderd schreef op 25 April 2003 @ 09:21:
oisyn: ik gebruik geen string-class omdat die te weinig kan

Dat is ook niet de taak van std::string. std::string is een STL class, dus je kunt ook de STL algoritmes gebruiken. Kijk maar in <algorithm>, dat werkt allemaal.

Als je al die functies members van std::string had gemaakt, dan had je ze opnieuw voor std::vector, std::deque en je eigen containers moeten maken, vandaar dat het losse (template) functies zijn.