Uttrykke bruk av C ++ argumenter gjennom metode grensesnitt

stemmer
5

Er det en vanlig måte å uttrykke bruken av argumentene i C ++? Jeg ønsker å implisitt fortelle forbrukerne av min klasse hvordan de argumentene de passerer vil bli brukt av klassen.

eksempler:

  1. Jeg eier ditt argument (vil rydde opp)
  2. Jeg vil holde en referanse til ditt argument løpet av min levetid (så du bør ikke slette den mens jeg er stile i live)
  3. Jeg vil bruke ditt argument bare under bygging og vil ikke holde en referanse

Er det en vanlig måte å uttrykke disse tingene ganske enkelt ved hjelp av metoden erklæring? Jeg tror i det første tilfellet en std :: auto_ptr ville være fornuftig. I det andre tilfellet jeg vanligvis tar en peker for å unngå noen passerer en verdi fra stabelen som ville oppheve min henvisning raskt, eller alternativt en shared_ptr. I det tredje tilfellet ta I en referanse for å gi verdier fra stabelen.

Hvordan takler du dette? Også er det nødvendig å stole på smarte tips her, eller kan man uttrykke slike ting bare ved hjelp av nakne referanser og pekere eller annen måte?

Publisert på 25/01/2009 klokken 23:05
kilden bruker
På andre språk...                            


7 svar

stemmer
1

Hvis du leter etter klarhet, er dokumentasjon en god måte å håndtere dette. Selvfølgelig, forutsetter at at folk legger merke til dokumentene dine.

Bortsett fra å bruke eksisterende klasser med kjente bruksmønstre, kan du lage din egen klasse. Med en klasse som kompilatoren kan automatisk generere fra en vanlig parameter (med operatører du ville skrive, selvfølgelig), kan du mer nøyaktig oppgi kontrakts uten å gjøre det vanskeligere å passere parametrene. Det er ulemper med denne (ekstra klasser, flere lag for brukeren å se og forstå, navngi ansvar), men det er et alternativ å vurdere.

Hvis du er i et miljø der IntelliSense er tilgjengelig, sørg for at nødvendig informasjon er til stede i parameterbeskrivelsen. Det kan spare deg fra noen av disse andre trinnene.

Svarte 25/01/2009 kl. 23:15
kilden bruker

stemmer
2

Kanskje jeg mangler poenget med du spørsmålet, men hvis din metode prototyper i din header-filen er opp riktig så vil det gjøre det.
"Implisitt" brukeren vil vite at gitt metode aksepterer kun en referanse til parameteren, eller at en gitt parameter er skrivebeskyttet (konst) .. etc ....

Svarte 25/01/2009 kl. 23:17
kilden bruker

stemmer
3

Jeg vet ikke om det er et felles formspråk, men jeg vet at en sikker-brann måte at jeg gi denne informasjonen er kommentarer i grensesnittet spissen. Brukerne av klassen vil ikke alltid lese dem, ikke vil alltid huske dem, og de vil skru dem opp raskere enn du kan blunke, men informasjonen vil være der.

Nå, når det er sagt, har jeg også tatt for å være mot å holde referanser til noe som noen annen del av systemet eier. Det er ikke alltid praktisk (eller fornuftig) å restrukturere slik at klassen eier alt (eller ikke holder referanser etter et metodekall avkastning), men det er den sikreste måten å gjøre ting, og enten man er lettere for den som ringer å forstå.

Det store problemet med å beholde referanser er at innringere aldri vil huske at de ikke får lov til å ødelegge disse tingene, og du vil til slutt ende opp med 'bruk av slettede objekt' type feil.

Svarte 25/01/2009 kl. 23:20
kilden bruker

stemmer
2

Mens dokumentasjon er det eneste svaret, er det dessverre ikke en nyttig en. Forskningen som jeg har gjort viser at mange kunder ikke leser dokumentasjon av metoder som de bruker.

Jeg vil anbefale å sette den inn i nomenklaturen av metodenavn eller argumentnavn, siden minst som er synlig i autofullfør-vinduet. Det er stygt, men det får melding via :)

I mitt eget verktøy (for Java / Eclipse) Jeg har en kode for at det tillater meg å kunngjøre for brukeren når han trenger å vite noe viktig om parameteren.

Svarte 25/01/2009 kl. 23:27
kilden bruker

stemmer
6

Vårt team har lignende koding konvensjoner til de du foreslår:

1 - auto_ptr argument betyr at klassen vil ta kontroll over minnehåndtering for objektet. (Vi bruker ikke så mye.)

2 - shared_ptr betyr at klassen vil sannsynligvis bruke argument for en lengre periode, og spesielt kan lagre av sin egen shared_ptr til objektet.

3 - Vanlig henvisning betyr at argumentet blir bare brukt for varigheten av anropet.

Vi behandler dette som en koding standard. Det er ikke noe vi dokumentere for hver samtale.

Svarte 25/01/2009 kl. 23:50
kilden bruker

stemmer
2

Jeg jobber ikke med kode som bruker boost eller STL, som jeg ikke jobber med systemer som støtter dem spesielt godt, men jeg har funnet følgende standarder nyttig ...

Jeg bruker const referanser og parameterverdi hverandre. (Jeg bruker referanser hvis verdiene er større enn et register - dette er rett og slett en optimalisering.) Den callee vil ta en kopi av verdi hvis det er behov for det, så det argumentet kan bli ødelagt med en gang. (Sak 3.)

Jeg bruker const pekere for å indikere at inngangen er for-referanse, og at callee vil ta en kopi som referanse. Levetiden for argumentet må overstige den for anropt. (Sak 2.)

Jeg bruker ikke-const pekere for å indikere at inngangen er ved-referanse, og at den anropte vil modifisere pointee om nødvendig. Levetiden for argumentet er bevisst udefinert i det generelle tilfellet. (Dvs. tilfelle 2 eller 3.)

Jeg bruker ikke ikke-const referanser meg selv, rent fordi det er ikke åpenbart syntaktisk på melder hva som skjer, men dette er bare min personlige helling. Jeg har mine grunner, men det betyr ikke at noen andre har til å være enig! Så kan man med fordel bruke referanse / pekeren skille å indikere levetid, som jeg har beskrevet i det const tilfelle. I dette tilfelle kanskje Peker = tilfelle 2, og referanse = tilfelle tre.

Jeg indikerer fall en (callee tar eierskap) med en kommentar; dette er sjelden nok i min kode som jeg ikke bry deg om det for mye.

Svarte 26/01/2009 kl. 02:07
kilden bruker

stemmer
2

Jeg bruker følgende metode prefiksene å betegne objekt eierskap. Eierskap innebærer ansvar for sletting.

Y.take_ZZZ(x)

Innringeren gir eierskap av X til Y og innringer må ikke videre tilgang x. (Fordi Y kan til og med umiddelbart slette x).

Y.own_ZZZ(x)

Ligner å ta; innringeren gir eierskap av X til Y, men innringeren kan fortsette å referere x og forventer Y vil ikke umiddelbart slette x (minst så lenge en Y finnes, og det antas at Y skal finnes minst gjennom sammenheng med den som ringer vite av Y). Vanligvis Y vil ikke slette x før Y er ødelagt (selv om Y kan overføre eierskapet).

Y.know_ZZZ(x)

Den som ringer er å tilveiebringe en peker / referanse til x (anroperen kan eller kan ikke i seg selv egen x), men Y er ikke bli eier av x. Y vil forvente at x vil eksistere så lenge det gjør.

x = Y.provide_ZZZ()

x er et formål at Y eier. Y returnerer en referanse (&) til objektet slik at den som ringer kan 'vite' det. Gjenstanden det kan være utgangspunktet en nullpeker inntil det er påkrevet, kan Y ikke skape objektet før det er nødvendig. Enten x dynamisk allokert eller ikke er skjult fra den som ringer, betyr Y det som er nødvendig for å returnere referansen til en forekomster av objektet som skal leveres. x vil da forbli instansiert så lenge Y eksisterer. Noen ganger vil jeg gitt en tilsvarende fremgangsmåte Y.done_with_ZZZ (x), slik at den som ringer kan fortelle Y dette er gjort kan slette x.

x = Y.give_ZZZ()

Y avkall x til anroperen og vil uten videre referere til den. Den som ringer vil da eier x og være ansvarlig for å slette den eller gi den til en annen gjenstand.

x = Y.lend_ZZZ()

Y gir en referanse / peker til x til den som ringer (motsatt av know_ZZZ) Y beholder eierskap. (Tilsvarende for å tilveiebringe, men Y ikke instantiate X, slik at det enten må x og returnere referansen (pekeren) eller det vil ikke gå tilbake og null.

x = Y.check_out_ZZZ() and Y.check_in_ZZZ(x)

Med kassa, gir Y innringeren eksklusiv tilgang til x til innringeren sjekker den inn.

x = Y.create_ZZZ()

Y vil skape x og umiddelbart gi slipp den til den som ringer (fabrikk funksjon).

Eierskapet kan styrkes ytterligere ved hjelp av smarte tips, men generelt jeg bruke disse navnekonvensjoner uten smarte tips med mindre det kommer til å bli en mer komplisert sekvens av eiertransaksjoner, er omfanget av eierskap ikke veldig lokalisert, eller objektene skal henvises (kjent) med flere objekter.

Svarte 26/01/2009 kl. 21:07
kilden bruker

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more