Reference-count - Hjelp!

[søppel]

joda, men når du først har fått det for deg at det burde gå an, er det ikke da høyst nødvendig å forklare hvordan det skal gå an?

 

Nei, det er det som er poenget: brukeren skal få lov til dette syntax-messig. Det blir videre opp til brukeren hvordan han/hun skal greie å implementere dette.

[saboi]

jeg tenkte mer på hvordan en kompilator skulle implementere dette. siden det er den som ikke gir deg lov.

[søppel]

Slik den gjør her:

// Dette er operator=, bare i en annen form (som gjør dette mulig i C++).
template<typename T>
T& assign(T& a, RefCount<T>& b)
{
return(a = b.getIt()); // = skulle ledet tilbake til mindre og mindre generelle funksjoner - til man havnet "på bunn"
} // assign

 

Tenk deg at = og operator= ikke eksisterer, men er erstattet av en funksjon assign og at det er den jeg overloader.

[saboi]

men det er jo det som er problemet. kompilatoren vet ikke hvilken den skal velge. den ser bare a = b; så må den finne ut hvilken operator= den skal velge. jeg skjønner at det går med assign, fordi det er en vanlig funksjon og er unik. det jeg sier er hvordan skal man implementere det inn i kompilatoren?

[søppel]

Jeg er ikke sikker på hva du mener, men går ut i fra at du mener "hvordan skal den velge hvilken funksjon den skal bruke av de overloadede"?

 

#include <iostream>

using namespace std;


template<typename T>
class RefCount {
public:
T& getIt()
{
return(_o);
} // getIt

private:
T _o;
}; // RefCount


// Dette er operator= (og =), bare i en annen form (som gjør dette mulig i C++).
// "den mer generelle"
template<typename T>
T& assign(T& a, T& b)
{
return(a = b); // = skulle ledet tilbake til mindre og mindre generelle funksjoner - til man havnet "på bunn"
} // assign


// Dette er operator= (og =), bare i en annen form (som gjør dette mulig i C++).
// "den mer spesifike"
template<typename T>
T& assign(T& a, RefCount<T>& b)
{
return(a = b.getIt()); // = skulle ledet tilbake til mindre og mindre generelle funksjoner - til man havnet "på bunn"
} // assign


int main(int argc, char** argv)
{
RefCount<int> ri;
ri.getIt() = 123;

int i;
// "den mer spesifike"
assign(i, ri);
cout << i << endl;

int j;
// "den mer generelle"
assign(j, i);
cout << j << endl;

return(0);
} // main

 

Dette er en detalj som er uavhengig av syntaxen for meg -- man burde t.o.m. kunne skrive kode som spesifiserer hvordan kompileren gjør slike valg i forskjellige sammenhenger og tilfeller!

 

Edit:

template<typename T>
T& assign(T& a, T& b) {
if(T == SomeType) {
// stuff here
}

if(T == SomeOtherType) {
// other stuff here
}
}

 

Virker sprøtt?

 

Edit2: Oh, btw. .. jeg vet dette også er et dårlig eksempel - men selve eksempelet er ikke poenget.

Endret 2. januar 2005 av søppel

[saboi]

jada. jeg skjønner hva du mener med koden din, det er ikke kode jeg spør etter. jeg sier hvis du skulle lage en kompilator, og du så koden

 

struct X {

X& operator=(const X& rhs);

};

 

X& operator=(const X& lhs, const X& rhs);

 

X y, z;

y = z;

 

hvordan ville du da valgt hvilken som skulle bli kalt? hvordan hadde du implementert det i kompilatoren? og hva hadde du skrevet i c++-standarden sånn at alle kompilatorer gjorde det samme?

[søppel]

Vekk med denne muligheten:

struct X {
X& operator=(const X& rhs);
};

 

..og bare hatt denne:

X& operator=(const X& lhs, const X& rhs);

 

Da sitter du igjen med noe som tilsvarer assign-eksempelet ovenfor.

 

Edit:

Hvis jeg ikke misser noe - så er den første overflødig. private:-tingen er en liten detalj. (Lisp har valgt å fjerne private:-muligheten og heller legge den til på et lag uten på dette med klasser og sånn kallt packages).

Endret 2. januar 2005 av søppel

[saboi]

haha, nå skal du plutselig velge vekk en?

da kan jo jeg si "det er teit at ikke c++ lar meg gjøre den første muligheten, fordi jeg vil få lov til å gjøre teite ting som er syntaktisk korrekt", som du nå har klaget over hele tida. og siden du nå allikevel er enig i at det bare skal være en operator= som jeg har sagt hele tida, så er det vel lurest å si at den skal være medlem av klassen, siden det gir mest mening. du slipper f.eks å skrive friend X& operator=(const X& lhs, const X& rhs) hver gang du trenger at operator= har tilgang til private medlemmer, som ikke er sjeldent. og hva skjer forresten når noen andre kommer og lager en ny operator= funksjon utenfor klassen, hvilken skal den velge da igjen? nei, jeg tror nok at den måten som er nå er den beste.

Endret 2. januar 2005 av saboi

[søppel]

Du skjønner hva jeg mener tror jeg.

[saboi]

nei jeg skjønner ikke hva du mener.

i det første innlegget skrev jeg hvorfor man måtte ha operator= som en funksjon av klassen og ikke alene. du skrev at det var teit og at du ville kunne gjøre som du ville.

nå så sier du "ok ta vekk operator= som en funksjon av klassen og heller ha den som en funksjon alene". da gjør du jo motsatt av det du har argumentert for hele tida, at du ikke kan gjøre som du vil. og jeg tror du er enig at det er mer hensiktsmessig å la operator= være en funksjon av klassen istedetfor alene når vi nå allikevel er enige om at begge to ikke går

[søppel]

Ok.

 

Dette er operator= (og =), bare i en annen form (som gjør dette mulig i C++).

Endret 2. januar 2005 av søppel

[Dead_Rabbit]

template<class T>
class X {
public:
  T& operator=(T& rhs);
private:
  T a;
};

template<class T>
T& operator=(T& lhs, T& rhs);

Edit: Gjorde om setningen litt.

Hvis kompilatoren sier at dette er en re-definition, så vil det ikke være noe problem i det heletatt.

 

Edit: Eller i dette tilfellet:

struct X {
X& operator=(const X& rhs);
};

X& operator=(const X& lhs, const X& rhs);

X y, z;
y = z;

Også redifinition.

Endret 2. januar 2005 av zirener

[saboi]

søppel, ja hva er poenget? det var ikke det vi diskuterte i det hele tatt. det vi diskuterte var at du syns c++ var så teit siden du ikke kunne ha begge to, og på slutten ville du plutselig ikke ha begge to, men den som er minst logisk av dem begge.

 

zirener, noe sånt kunne kanskje virket, problemet er hvor lett det er å skrive kompilatoren sånn at den skjønner det. det høres kanskje lett ut, men sånne ting kan fort bli vanskelige ettersom du må lage spesialtilfeller i kompilatoren osv. egc (tror jeg) brukte liksom like lang tid på å implementere et eneste keyword (export) i c++ som de brukte på å skrive java-greia dems fra scratch, som var 1.5 år.

 

uansett, det er en grunn til at man har gjort det sånn, og det er bare å akseptere. personlig ser jeg ikke hva man tjener på på å ikke ha den som en funksjon av klassen, det blir mye lettere hvis man har den som en funksjon av klassen, og det er derfor det er sånn.

[Dead_Rabbit]

zirener, noe sånt kunne kanskje virket, problemet er hvor lett det er å skrive kompilatoren sånn at den skjønner det. det høres kanskje lett ut, men sånne ting kan fort bli vanskelige ettersom du må lage spesialtilfeller i kompilatoren osv. egc (tror jeg) brukte liksom like lang tid på å implementere et eneste keyword (export) i c++ som de brukte på å skrive java-greia dems fra scratch, som var 1.5 år.

Bare si ifra, så kan jeg skrive en slik implementasjon!

 

Edit:

uansett, det er en grunn til at man har gjort det sånn, og det er bare å akseptere. personlig ser jeg ikke hva man tjener på på å ikke ha den som en funksjon av klassen, det blir mye lettere hvis man har den som en funksjon av klassen, og det er derfor det er sånn.

Tenk hvordan samfunnet vil bli hvis vi bare må akseptere alt. Da ville vi stått "på stedet vil", og det gjelder også innenfor programmering. Endret 2. januar 2005 av zirener

[søppel]

saboi:

Du misser totalt poenget - eller så vil du ikke se det fordi det kommer fra meg. Jeg kan ta et annet eksempel:

 

Si jeg skal reise hjemmefra (Norge) til USA. Jeg vet det er mulig, fordi jeg har sett andre gjøre det - men ikke i detalj hvordan jeg kommer meg dit.

 

Samme med programmeringsspråk - jeg vet det er mulig (andre språk), men ikke i detalj hvordan jeg kommer dit.

 

Jeg greier i hvertfall ikke beskrive det med mer detaljer enn det jeg har gjodt hittil for deg. Spesiellt siden det er detjaler man prøver å unngå når man generaliserer (template-kode).

 

På slutten her fokuserer du etterhvert på hva det på overflaten ser ut til at jeg gjør - når det som foregår i bakgrunnen (idéen bak kodeeksempler o.l., men det blir veldig spesifikt igjen) faller utenfor. Hvorfor du gjør dette forstår jeg ikke - for jeg tror du forstår hva som egentlig foregår her.

Endret 2. januar 2005 av søppel

[saboi]

ja! jeg har sett at i python trenger man ikke si hvilken type man bruker

c++ er no jævla drit siden dette ikke fungerer a = 5; fordi jeg har sett at det går an et annet sted.

alle språk har begrensninger, og hvis du syns et språk er teit fordi det har begrensninger som andre språk ikke har er du ganske borka. hele denne diskusjonen begynte med at du syns det var teit at det var en begrensning i språket, og jeg har prøvd så godt jeg kan å forklare hvorfor det ikke lar seg gjøre. noe som du tydeligvis skjønte på slutten når du valgte å ta vekk den ene operator=. det viser jo bare at du er enig, det er ikke lurt å ha både operator= og T::operator=. da startet imidlertid en helt ny diskusjon. nå mente du at c++-standarden hadde valgt feil operator= og du ville heller at den skulle være en funksjon alene. det syns jeg også er feil, og jeg mener at T::operator= er den som er riktig og mest logisk å ha. du får like det eller ikke, men det er nå hvertfall det du må finne deg i hvis du skal bruke c++. så får du heller skrive et brev til c++-komiteen hvor du forklarer at du vil at de skal bytte sånn at du kan bruke operator= og ikke T::operator=. selv om jeg ikke ser et eneste poeng å bruke den framfor T::operator=

[søppel]

Sjekk posten jeg refererte til i ang. kritikk av C/C++:

http://forum.hardware.no/index.php?showtop...dpost&p=3391621

 

Legg også merke til det zirener sier om forbedringer og endringer -- C++ er et språk i endring; det er en god ting - i flere sammenhenger. (se på Boost - og hvilke idéer de forsøker å implementere)

 

Jeg er glad vi ikke sitter med hullkort fortsatt for å si det slik.

 

Legg også merke til at jeg sa: "Jeg snakker ikke om C++ og standaren, men en idé."

 

Edit:

..og alle endringer og ting relatert til kodeeksemplene mine blir selfølgelig halvveis - da jeg ikke kan endre selve kompileren og standaren på strak arm.

 

Edit2:

Og kan vi ikke snu på det nå - du ler altid av løsningene og idéene mine, jeg er nysjerrig på hvilke du har;

 

Hvordan ville du implementert dette slik at koden til zirener fungerte:

template<class T>                      
T& operator=(T& lhs, const RefCount<T>& rhs)  
{
//lhs = rhs->p;
//return lhs;
}

(i sammenhenger der T kan være innebyggde typer, ja)

 

Ville du i det hele tatt implementert mulighet for dette?

* Hvis ikke - hvorfor ikke?

* Hvis - hvordan?

Endret 3. januar 2005 av søppel