[Managed C++] Datastructuren zonder zooi?

[Oogst]

Een stagair is bij mijn bedrijf op het moment bezig met het implementeren van een plug-in voor een level editing tool. De eis van die tool is dat de plug-in is gemaakt in managed C++. Helaas weet ik zelf weinig van managed C++ (wel een boel van gewoon C++), maar we liepen er dus mee tegen een probleem aan, waarvan ik hoop dat jullie er wat toelichting op kunnen geven.

We hebben een array van arrays van Dingen nodig. In C++ zou ik dat zo doen:

code:

std::vector<std::vector<Ding*> > lijst;

Echter, nu lijkt het er op dat in managed C++ alleen dingen met pointers mogen. Dan zouden we hier op komen, en dat vind ik wel echt heel erg jammere code:

code:

std::vector<std::vector<Ding*>*>* lijst
       = new std::vector<std::vector<Ding*>*>();

Dus mijn vraag is: kan dit handiger en hoe?

Merk op dat ik echt weinig van managed C++ weet, dus misschien is std::vector sowieso niet de goede keuze.

[PiepPiep]

Mijn C++ is ook een beetje roestig dus ik weet niet meer precies de syntax, maar kan je niet een typedef maken voor een DingArray en die in een array zetten. Dan ben je iig al van die *>*>* af die ik zelf niet zo overzichtelijk vind.

[H!GHGuY]

Kun je niet de System.Array gebruiken, al dan niet transparant?

(in C# heb je Ding[] dingen wat automatisch van het type Array is)

eerste resultaat op google (managed c++ arrays)
http://www.functionx.com/vcnet/references/managedarrays.htm

[ Voor 29% gewijzigd door H!GHGuY op 01-04-2008 12:50 ]

[.oisyn]

Managed C++ (VS 2002/2003, .Net 1.0/1.1) of C++/CLI (vanaf VS 2005, .Net 2.0)? Die eerste zou ik echt afraden, tenzij je geen .Net 2.0 wilt gebruiken (of kun je in 2005 ook switchen tussen platform versies?)

Manager C++ is deprecated en C++/CLI zit echt veel cleaner in elkaar. Managed references declareer je met een ^ ipv een *, en bovendien heeft het een .Net versie van de STL (STL.Net). .Net arrays maak je mbv de array<> template. Een array van T is dus array<T^>, en een 2d array is array<T^, 2>.

C++:

array<Ding^, 2>^ myArray = gcnew array<Ding^, 2>(width, height);
myArray[x, y] = gcnew Ding("aap", "noot", 123.34f);

[.edit: oeps. STL.Net shipped pas met VS 2008. Het volgende werkt dus niet in 2005]
Als je het echt bij vector wilt houden:

C++:

#include <cli/vector>   // let op de cli/

int main()
{
    vector<vector<Ding^>^>^ lijst = gcnew vector<vector<Ding^>^>(width);
    for each (vector<Ding^>^% v in lijst)
    {
        v = gcnew vector<Ding^>(height);
        for each (Ding^% d in v)
            d = gcnew Ding();
    }
}

En idd, een fatsoenlijk C++ programmeur gebruikt gewoon typedefs voor al z'n container instanties

[ Voor 33% gewijzigd door .oisyn op 01-04-2008 13:29 ]

[Oogst]

Helaas schrijft onze stagair een plug-in die van alles moet doen met de tool en die tool is in Managed C++. We zitten dus echt aan Managed C++ vast en kunnen niet naar die nieuwe taal. Dus: hoe is dit het handigst te doen in Managed C++?

Ow, enneuh: is er voor alles een interface nodig als je van Managed C++ naar gewoon C++ wilt? Dat klinkt ook aantrekkelijk, maar als er dan interface wrappers rond alle Managed C++ klasses van de tool nodig zijn, dan is dat ook niet zaligmakend.

En typedefs, dat snap ik, maar ja, met pointers naar vectors wordt alle code vies. Pperator[] werkt bijvoorbeeld ook niet meer zo mooi, omdat je eerst moet dereferencen.

[ Voor 15% gewijzigd door Oogst op 01-04-2008 13:25 ]

[.oisyn]

Ik zie niet in waarom je in Managed C++ niet gewoon een std::vector<std::vector<Ding*> > mag maken. Als Ding een managed class is mag dat idd geen value zijn in de vector, maar de binnenste vector mag wel gewoon een value zijn in de buitenste vector - vector is immers geen managed class.

En vziw kun je native en managed C++ gewoon mixen.

[ Voor 15% gewijzigd door .oisyn op 01-04-2008 13:32 ]

[Niemand_Anders]

Waarom draai je het niet gewoon om. Schrijf gewoon full managed plugins en markeer ze als com en benader ze vanuit C++ via de com interface.

Maar waarom laat jij een stagier iets doen waar je geen verstand/kennis van hebt? Jij behoort de stagier te begeleiden en dat kun je nu niet. Want straks heb je de omgedraaide situatie dat de stagier jouw iets leert..

Waarom accepteren jullie (bedrijf) een opdracht als jullie daarvoor de kennis niet hebben?

[sjongenelen]

Niemand_Anders schreef op dinsdag 01 april 2008 @ 13:46:
Waarom draai je het niet gewoon om. Schrijf gewoon full managed plugins en markeer ze als com en benader ze vanuit C++ via de com interface.

Maar waarom laat jij een stagier iets doen waar je geen verstand/kennis van hebt? Jij behoort de stagier te begeleiden en dat kun je nu niet. Want straks heb je de omgedraaide situatie dat de stagier jouw iets leert..

Waarom accepteren jullie (bedrijf) een opdracht als jullie daarvoor de kennis niet hebben?

waarschijnlijk omdat ze dachten te maken te gaan hebben met 'gewoon' C++ - maar de student TI (neem ik aan) doet dat niet meer ! Valt nog mee dat hij C++ ként (ik kreeg nl. gewoon Java)

[.oisyn]

@Niemand_Anders: Wat een onzin. Je kunt een stagiair prima technologie laten onderzoeken waar het bedrijf niet bekend mee is. Dat moet dan uiteraard wel onderdeel zijn van de opdracht. Stagebegeleiding is niet uitleggen hoe een API werkt ofzo.

[ Voor 3% gewijzigd door .oisyn op 01-04-2008 13:51 ]

[pedorus]

Eerste hit op managed c++ collections:
http://www.codeguru.com/c...anaged/article.php/c4849/

Ik zou zeggen dat "een stagair" daar ook wel op had kunnen zoeken.

[Oogst]

.oisyn schreef op dinsdag 01 april 2008 @ 13:30:
Ik zie niet in waarom je in Managed C++ niet gewoon een std::vector<std::vector<Ding*> > mag maken. Als Ding een managed class is mag dat idd geen value zijn in de vector, maar de binnenste vector mag wel gewoon een value zijn in de buitenste vector - vector is immers geen managed class.

En vziw kun je native en managed C++ gewoon mixen.

Ah, kijk, als dat gewoon kan, dan is er inderdaad geen probleem. Het leverde een error en een crash op, maar dan zat dat misschien wel ergens anders.

.oisyn schreef op dinsdag 01 april 2008 @ 13:50:
@Niemand_Anders: Wat een onzin. Je kunt een stagiair prima technologie laten onderzoeken waar het bedrijf niet bekend mee is. Dat moet dan uiteraard wel onderdeel zijn van de opdracht. Stagebegeleiding is niet uitleggen hoe een API werkt ofzo.

Agree.

[Niemand_Anders]

Volgens mij wordt nu een stagier en een afstudeerder door elkaar gehaald. Een stagier moet juist meelopen met het bedrijf zodat deze praktijk ervaring opdoet. Een afstudeerder doet meestal een onderzoek naar een bepaalde technologie.

Wij zij door de HRO namelijk al enkele malen aangesproken op het feit dat wij stagieres minder onderzoek moeten laten doen en meer moeten laten meelopen.