[C++|OSX Framework] Memory problemen - Softwareontwikkeling

woensdag 2 juli 2008 09:39

Acties:

Topicstarter

Hoi,

Ik ben bezig een OS X framework te ontwikkelen, in C++, maar nu loop ik tegen toch iets heel vaags aan. Het gaat om de volgende situatie:

We hebben een framework, Core.framework. Daarin zitten een stel classes waaronder een singleton class met cached data. Eventjes wat versimpelt:

StaticCache.h

C++:

namespace Core
{
    class StaticCache
    {
    public:
        static StaticCache *GetInstance();
        
        std::vector<int> GetInts() const;
    };
}

StaticCache.cpp

C++:

#include "StaticCache.h"

Core::StaticCache *Core::StaticCache::GetInstance()
{
    static Core::StaticCache sInstance;
    return &sInstance;
}

std::vector<int> Core::StaticCache::GetInts() const
{
    std::vector<int> ints;
    ints.push_back( 1000);
    return ints;
}

Naast dit framework heb ik een test client gemaakt die het framework gebruikt. Maar nu is het afhankelijk wat ik doen voor dat ik GetInts aanroep dat de boel gewoon crashed.

Volgens mij kan ik in dit stukje gewoon echt geen memory overschrijven, want er komen verder eigenlijk geen pointers aan te pas, alleen dingen die op de stack worden gealloceerd (kan je weinig aan fout doen denk ik). Klopt mijn idee over frameworks überhaupt wel?? Is het wel mogelijk om een singleton class te hebben in een framework en dat in een programma te gebruiken?

Nu bedacht een collega van me dat dit zeer inefficiënt kan worden (er worden immers wat kopieën gemaakt), dus hij zei gebruik dan een reference. Maar dan krijg ik weer link errors op die functie (unknown symbol), misschien weer een ander verhaal, maar misschien ook wel gerelateerd.

Overigens lijkt het framework wel verder goed te werken, want ik heb meerdere dingen kunnen testen voordat ik op het GetInts principe kwam...

[ Voor 4% gewijzigd door ^Mo^ op 02-07-2008 09:46 ]

"There are 10 kinds of people in the world, those who understand binary and those who don't" | Werkbak specs

woensdag 2 juli 2008 10:04

Acties:

Icelus

Variabele op regel 11 is lokaal; zodra de functie wordt verlaten wordt deze vernietigd.
Te snel gelezen.

[ Voor 12% gewijzigd door Icelus op 02-07-2008 10:11 ]

Developer Accused Of Unreadable Code Refuses To Comment

woensdag 2 juli 2008 10:40

Acties:

.oisyn

Moderator Devschuur®

Demotivational Speaker

Gebruik je toevallig ook meerdere threads? De initialisatie van statics in functies is niet altijd thread-safe.

Nu bedacht een collega van me dat dit zeer inefficiënt kan worden (er worden immers wat kopieën gemaakt)

Een fatsoenlijke compiler kan alle kopieën wegoptimizen, tenzij je het resultaat van de functie natuurlijk aan een al bestaande vector assignt (maar dan kun je de swap() truc gebruiken).

dus hij zei gebruik dan een reference. Maar dan krijg ik weer link errors op die functie (unknown symbol), misschien weer een ander verhaal, maar misschien ook wel gerelateerd.

Unknown symbol

Wat was je code dan precies?

[ Voor 3% gewijzigd door .oisyn op 02-07-2008 10:42 ]

Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.

woensdag 2 juli 2008 11:06

Acties:

Zoijar

Because he doesn't row...

Je mag toch helemaal geen externe referentie geven aan een static functie var? (Regel 6 in .cpp) (ik weet het niet zeker, misschien vergis ik me...) Ik vergis me...

[ Voor 28% gewijzigd door Zoijar op 02-07-2008 11:14 ]

woensdag 2 juli 2008 11:15

Acties:

.oisyn

Moderator Devschuur®

Demotivational Speaker

Ja, je vergist je. Je mag geen referentie van een lokale ("auto") variabele teruggeven, of althans, dat is undefined behaviour. Maar wat de TS hier doet is in feite de standaard singleton manier in C++ (voor zover thread-safety geen issue is).

Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.

woensdag 2 juli 2008 11:42

Acties:

Zoijar

Because he doesn't row...

Een thread safe singleton is sowieso hell...

woensdag 2 juli 2008 11:48

Acties:

^Mo^

Topicstarter

.oisyn schreef op woensdag 02 juli 2008 @ 10:40:
Gebruik je toevallig ook meerdere threads? De initialisatie van statics in functies is niet altijd thread-safe.

[...]

Een fatsoenlijke compiler kan alle kopieën wegoptimizen, tenzij je het resultaat van de functie natuurlijk aan een al bestaande vector assignt (maar dan kun je de swap() truc gebruiken).

[...]
Unknown symbol Wat was je code dan precies?

Alles is (vooralsnog) single threaded. En als het goed is staan alle optimizations uit (hoewel ik dat met XCode ook nooit 100% zeker weet).

Wat die unknown symbol betreft, ging het om deze code (in de singleton):

C++:

1	void GetInts2( std::vector<int> &outInts) const;

Met als implementatie:

C++:

void Core::StaticCache::GetInts2( std::vector<int> &outInts) const
{
    outInts.push_back( 1000);
}

Maar dat levert in het test programma een unknown symbol op. En als ik het framework helemaal niet mee zou linken krijg ik nog meer errors. Dus dat framework wordt toch echt wel meegelinkt.

Ik ben aan het pogen om de boel ook eens op Windows aan de praat te helpen (moest toch gebeuren vroeger of later), misschien dat ik daar wat meer kan zien

"There are 10 kinds of people in the world, those who understand binary and those who don't" | Werkbak specs

woensdag 2 juli 2008 11:58

Acties:

.oisyn

Moderator Devschuur®

Demotivational Speaker

Op welke regel zegt ie dan unknown symbol? En wat is de exacte en complete foutmelding van de compiler?

Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.

woensdag 2 juli 2008 12:08

Acties:

^Mo^

Topicstarter

Undefined symbols:
"Core::StaticCache::GetInts2(__gnu_debug_def::vector<int, std::allocator<int> >&) const", referenced from:
_main in main.o
ld: symbol(s) not found

Het compileerd allemaal wel omdat de header gewoon keurig wordt geinclude. Maar op een of andere manier kan 'ie zich dan niet bedenken dat de implementatie uit het framework moet komen (ik zal het wel fout doen..)

"There are 10 kinds of people in the world, those who understand binary and those who don't" | Werkbak specs

woensdag 2 juli 2008 12:14

Acties:

.oisyn

Moderator Devschuur®

Demotivational Speaker

Ik krijg het idee dat je linkt met een oude versie van je library, wat tevens ook de reden is van je crashes. Omdat de gecompileerde library niet meer klopt met je headers, maar de symbols verder wel bestaan, loopt alles in de soep omdat de code niet doet wat de headers zeggen dat het zou moeten doen. En ja, zodra je dan een nieuwe functie wilt implementeren hou je idd unresolved external symbols over.

[ Voor 15% gewijzigd door .oisyn op 02-07-2008 12:15 ]

Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.

woensdag 2 juli 2008 12:23

Acties:

^Mo^

Topicstarter

Net een complete rebuild gedaan van zowel de test client als het framework, maar ik krijg nog steeds dezelfde problemen.

En als ik het framework niet heb wil m'n client ook niet bouwen (dus een clean doen van het framework, en dan de client proberen te bouwen)

Nog even een testje gedaan (om het nog vreemder te maken allemaal)
Ik heb nog een functie gemaakt in de singleton:
void GetString( std::string &outStr) const
En dat werkt wel!!

[ Voor 26% gewijzigd door ^Mo^ op 02-07-2008 12:34 . Reden: Iets nieuws geprobeerd ]

"There are 10 kinds of people in the world, those who understand binary and those who don't" | Werkbak specs

woensdag 2 juli 2008 13:57

Acties:

farlane

Kan het misschien zijn dat je ergens een evil macro hebt staan die zonder dat je het in de gaten hebt iets verandert aan je namespace/functienamen?

Mbt tot je static probleem: Kan het zijn dat je twee static objecten hebt die met elkaar lopen te pielen?

Somniferous whisperings of scarlet fields. Sleep calling me and in my dreams i wander. My reality is abandoned (I traverse afar). Not a care if I never everwake.

woensdag 2 juli 2008 15:56

Acties:

PrisonerOfPain

farlane schreef op woensdag 02 juli 2008 @ 13:57:
Kan het misschien zijn dat je ergens een evil macro hebt staan die zonder dat je het in de gaten hebt iets verandert aan je namespace/functienamen?

In debug mode worden door xcode zelf sowieso _GLIBCXX_DEBUG en _GLIBCXX_DEBUG_PEDANTIC gedefinieerd die er voor zorgen dat je tegen de debug versie van de STL compileert (de __gnu_debug_def namespace). Waarschijnlijk kan die niet gevonden worden.

woensdag 2 juli 2008 16:41

Acties:

^Mo^

Topicstarter

PrisonerOfPain schreef op woensdag 02 juli 2008 @ 15:56:
[...]

In debug mode worden door xcode zelf sowieso _GLIBCXX_DEBUG en _GLIBCXX_DEBUG_PEDANTIC gedefinieerd die er voor zorgen dat je tegen de debug versie van de STL compileert (de __gnu_debug_def namespace). Waarschijnlijk kan die niet gevonden worden.

Dat zullen de enige zijn dan. Want verder zijn er geen (bekende) macros in gebruik.

Ik denk dat ik me heel erg moet gaan schamen

Het waren inderdaad de door XCode gegenereerde macros. Die stonden voor het framework dus niet aan, en voor de test client wel. Het lijkt er op dat hiermee beide problemen zijn opgelost, de linker error in ieder geval en het lijkt er op dat de crash ook is opgelost.

Allemaal bedankt! $_/-\o_$

[ Voor 27% gewijzigd door ^Mo^ op 02-07-2008 17:01 ]

"There are 10 kinds of people in the world, those who understand binary and those who don't" | Werkbak specs