Mogens Hansen wrote:
> "Esben Mose Hansen" <esben@SLETMIGoek.dk> wrote
>
>
>>Er der nogen der har kendskab til denne metode? Både for og imod er
>>meget velkomne.
>>
>
>
> Først vil jeg sige, at jeg ikke kender til C++ udvikling på Z/OS.
Det skal du ikke være ked af... trust me!
> Egentlig undrer det mig at symbollængden er noget som programmøren skal tage
> sig af - det burde vel egentlig håndteres af compiler/linker
> implementeringen, på lige fod med mange andre platform specifikke
> teknikaliteter (f.eks. alignment, sizeof(int)).
> Men sådan er der så meget.
Jep. Som det fremgår af det skrevne er det også en lille smule mere
kompliceret.... men lad nu det ligge
> Ulemper:
> Jeg har nemt ved at forestille mig at du hurtigt vil få _lange_ build-tider.
> Risikerer du ikke nemt at skulle recompilere _samtlige_ funktioner for hver
> gang ?
Det er sandt. Men vores applikation er ikke sååå stor (60.000--90.000
linier C-kode), så jeg regner ikke med det er et kæmpeproblem. Men det
er umiddelbart også min største bekymring. På den anden side er vores
linker herrelangsom, så det kan være det tabte til dels vindes igen :)
> Fordele:
> ???
> Naturligvis er det en fordel at programmet virker
>
> Er du _sikker_ på at du har konstateret at det er inkluderingen af såvel
> erklæringer som definitioner der gjorde forskellen ?
> En anden _mulighed_ er at du har et lidt fejlbehæftet program, hvor fejlen
> viser sig i een konfiguration og ikke i en anden.
Jeg kan nemt skrive programmet her, så kan du se hvad der kan være galt.
Faktisk vil jeg give to eksempler (skrevet af fra hukommelsen da jeg
ikke lige har programmerne ved hånden)
main:
#include "Object.h" //
int main(int argc, char* argv[])
{
Object* pObject = new Object();
}
Object.h: (eller i Z/OS termologi: DEV.WORK.C(OBJECT)
class Object
{
public:
Object::Object();
Object::Object() {}
}
Object.c:
#include <iostream>
Object::Object() { cout << "Hello" << endl; }
Dette program giver en protection exception... så vidt jeg kan se farer
den vild i stakken når den skal tilbage fra cout:
erator<<(...)
Et andet eksempel:
Object.h:
#include <iostream>
class Object
{
public:
static int myFunc();
static int myVar;
}
/* Uanset hvilken af nedenstående stumper flyttes til en .c-fil så sker
der noget lignende... en protection fault */
int Object::myVar = 5;
int Object::myFunc() { cout<<"hello"<endl; return 4;}
> Jeg kan ikke umiddelbart forstå hvilken indflydelse inkludering af funktions
> definitionerne får på symbollængden - men som sagt kender jeg ikke
> platformen.
Ah... efter kompilering bliver alle symboler kortet til 8 tegn. Dette
sker for at kunne ligge objektfilerne ned i det "directory" (kaldet
partitionerede datasæt) som de skal ligge i. Jeg ved det, det lyder
sindsygt, men det er ikke desto mindre sandt..
> Hvorfor påvirker symbollængden egentlig run-time miljøet ?
Det ved jeg heller ikke om det gør. Jeg hælder til at selve linkningen
fucker op.
> Det jeg er vandt til at se, er at symbolerne ikke står i det eksekverbare
> resultat (dynamisk linkede biblioteker er en undtagelse), men kun findes som
> debug information i en eller anden form. Eksekveringsmiljøet kalder ikke
> funktionerne ved hjælp af navnet, men via absolute adresser.
Jep... men linkeren linker via. de symbolske navne.
> Strengt taget taget er der ingen grund til at samle erklæring og definition.
> Du kan blot inkludere ".cpp" filerne i stedet for ".h" filerne -
> preprocessoren er ligeglad med hvad filerne hedder.
> Navnene er kun konvention.
Både ja og nej. Fordi compileren forventer at finde alle h-filer i en
samling af disse "directories"... og C-filerne ligger andetsteds. Men
det er nu ligemeget. Jeg var mere interesseret i om der var nogen
problemer med ideeen... bortset fra compiletiden
1000 tak for svar!
--
mvh. Esben
home.worldonline.dk/~mesben