🚀 go-pugleaf

Koen Witters writes:

> Dit is niet echt een programmeer vraag, maar eerder een software
> engineering vraag. Ik kan al programmeren in C++, maar in Java kan
> ik degelijk software ontwikkelen (hoop ik tenminste ;-).

He :)
Ik heb ongeveer het omgekeerde voor.. :(

> Aangezien
> ik dat nu ook in C++ moet gaan doen mis ik enkele zaken die ik van
> Java ken. Heb al wat op internet gezocht, maar de meeste van mijn
> vragen blijven onbeantwoord. Ik werk in Visual C++ 6.0 (No comment
> on this plz., t is onvermijdelijk) op ons allergeliefde Windows
> platform, en 't is puur OOP.

/me heeft medelijden..

> 1. JAVADOC (API generatie): heb er een paar gevonden, maar de welke
>    is de
> numero uno? Of is het gewoon beter om de API info in de header files
> te schrijven als comments?

zoek eens naar doxygen..
Kweet wel niet of dat ook op windows draait...

> 2. PACKAGES. In Java worden classen opgedeeld in een package
>    structuur (die
> zich ook manifesteert in de directory structure van de sources). Hoe
> gebeurt dit in C++? Code reuse wordt hierdoor vrij
> simpel. 'namespace' ken ik, maar wordt dit echt genest gebruikt om
> classes in te plaatsten?

Ik weet niet hoe dit alles werkt onder windows, dus deze uitleg is
voor UNIX/Linux.  Ik vermoed dat het analoog zal zijn onder
windows... 

Je moet in c++ het onderscheid maken tussen twee dingen:
1 namespaces.  Dit heeft enkel relevantie voor je code, heeft niets te
maken met de plaats in het bestandssysteem waar de headers en
libraries staan ( zie 2 en 3 ).  Dit zorgt er gewoon voor dat
pakketten ( libraries in c++-speak ) niet te veel woorden in de
globale namespace innemen, maar slechts een ( de naam van de namespace
).  Als bijvoorbeeld twee libraries gebruikt, die allebei een klasse
Coordinate hebben, dan kan je ze toch tegelijk gebruiken als
Toolkit1::Coordinate en Toolkit2::Coordinate
2 headers.  Headers zijn stukjes C++-code die klassen en definieren.
Als je een library installeert, dan worden ze meegeinstalleerd, zodat
je de klassen kan gebruiken in je programma.  Als je bijvoorbeeld de
klasse QObject uit Qt wil gebruiken, moet je eerst de header
<qobject.h> includen.  Dit gebeurt met #include <qobject.h>.  Deze
headers staan meestal op standaard-plaatsen zoals /usr/include en
/usr/local/include e.d.  Als ze elders staan ( vb. /opt/qt/include,
dan moet je bij het compileren de plaats opgeven met de -I vlag ).
3 libraries.  Bij het linken moet je zien dat je alle libraries die je
gebruikt meelinkt.  Anders krijg je "undefined reference" fouten.
Deze staan ook meestal geinstalleerd in /usr/lib of /usr/local/lib.

> 3. JUNIT testing en regression testing (en alles wat met testing te
>    maken
> heeft). In java wordt de testclasse in dezelfde package structuur
> gezet als de geteste classe. Het wordt echter wel in een andere dir
> gezet. Op deze manier is het eenvoudig om de tests te compileren en
> uit te voeren (en om aan protected members te geraken), en bij een
> release compilatie de test classes achterwege te laten.

Hiervoor is niet direct een alternatief onder C++.  Meestal wordt
gewoon een test-programmatje geschreven dat de code test en enkel op
het juiste moment meegecompileerd wordt.  Er worden ook asserties in
de code geplaatst met assert( a != 0 ) bijvoorbeeld.

> 4. En voor de rest, wat is zowat een goeie coding convention voor OO
> programming? (wat ik veronderstel dat een class niet altijd met een
> C hoeft te beginnen, maar het handig kan zijn dat een pointer wel
> een p in de naam heeft).

dat kan je volledig kiezen.  Veel gebruikt zijn _naam of mnaam of
mxnaam ( waar x een letter is zoals p voor pointer, i voor int, b voor
bool etc. ) etc. voor member variabelen.  Maar daar is niet echt een
vaste conventie voor...

> 5. Alles wat ik nog zou moeten weten voor practische OO programming
>    in
> (Visual) C++. (no worries, ik verkies nog altijd de Standard Library
> boven platform afhankelijke libs :-P)

Houden zo, kan je ooit nog overstappen naar een echt platform ;) (
geen flames hierover graag, tis een grap )
sjuus
domi

-- 
Don't worry.  Life's too long.
		-- Vincent Sardi, Jr.