Navngivning metoder, const og ikke.

[Gjest Slettet-Pqy3rC]

Noen som har konstuktive forslag til en slags navne"standard" i de tilfellene hvor en metode finnes i både const og ikke-const utgave i en klasse ?

 

F.eks;

class someClass {
    returnValue & Get() {...};
    const returnValue & ???() {...};
};

Her gjør "???" metoden det samme som Get() bortsett fra at returverdien har fått const angitt. Jeg er altså ute etter hva en skal kalle ??? metoden.

 

Grunnen til spørsmålet er at jeg aldri har klart å legge meg til noen egen "god" standard i disse tilfellene, hvilket i grunn er rimelig frustrerende siden en da ofte må slå opp/lete i klasser en selv har lagd tidligere... Så jeg lurte litt på hva andre bruker å gjøre.

[GeirGrusom]

Forslag:

 

returnValue & Fetch();
const returnValue & Get();

Men fetch er et teit ord. Tanken var ihvertfall at Get kanskje passer bedre til å returnere en const.

[Lycantrophe]

const type read() const;

 

Forøvrig er problemstillingen moot siden du -egentlig- ikke bør gjøre #1 uansett.

Endret 10. september 2013 av Lycantrophe

[Gjest Slettet-Pqy3rC]

Forøvrig er problemstillingen moot siden du -egentlig- ikke bør gjøre #1 uansett.

He, he ... joda, men noen ganger blir det rett og slett for mye data (tar for mye tid) om en skal

void Set(const type &x) {...}

kopiere x i metoden (operator =), f.eks om type er et in-memory xml 'ish objekt. Da er greit å kunne manipulere fra utsiden. (Den største "feilen" er imidlertid om en utelater const varianten eller ikke benytter denne der det er mulig.)

 

Et eksempel på noe jeg har brukt en del (men desverre ikke konsekvent);

type & ParamsSet() const {...}
const type & Params() const {...}

Hvor "Set" endelsen i metodenavnet illustrerer at returverdien er manipulerbar. Hmm...

[Lycantrophe]

Nja. Objektet ditt bør heller eksponere faktisk modifikasjonsfunksjonaliet i stedet for å bare returnere en referanse til den underliggende biten. Det gjør at du faktisk kan bytte den ut senere og, eller gjøre brekkende forandringer.

type& ParamSet() const {}

ser for meg krise ut. Er det i det hele tatt lovlig? Det er uansett svært, svært dårlig stil, med mindre det kun er til svært intern bruk og aldri blir eksponert ut av modulen din

 

Unntak: containers.

Endret 10. september 2013 av Lycantrophe

[GeirGrusom]

Nja. Objektet ditt bør heller eksponere faktisk modifikasjonsfunksjonaliet i stedet for å bare returnere en referanse til den underliggende biten. Det gjør at du faktisk kan bytte den ut senere og, eller gjøre brekkende forandringer.

type& ParamSet() const {}

ser for meg krise ut. Er det i det hele tatt lovlig? Det er uansett svært, svært dårlig stil, med mindre det kun er til svært intern bruk og aldri blir eksponert ut av modulen din

 

 

template<typename T> T& std::vector::at(size_type n) const;

Så vil påstå det kommer an på applikasjonens krav.

[Lycantrophe]

Yeah, kom på den som eksempel etterpå. Men vector er en container, og har ikke parametere på samme måten. :--)

 

La til en edit.

Endret 10. september 2013 av Lycantrophe

[OldMan]

Hvorfor ikke bruke Get også for const variant ?

[Gjest Slettet-Pqy3rC]

vel, det kompilerer ikke når du trenger begge utgavene i samme klasse, kompilatoren vet ikke hvem av metodene som skal kalles.

 

Forøvrig er jeg enig at "ikke const" variantene bør unngås, men noen ganger må man bare (som oftest grunnet objektets størrelse og kompleksistet).

[Lycantrophe]

Isåfall er objektet for stort og komplekst :-------)

[Glutar]

De kan ha samme navn hvis const utgaven også er en const medlemsfunksjon.

type & get();
type const & get() const;

Endret 18. september 2013 av Glutar

[Gjest Slettet-Pqy3rC]

De kan ha samme navn hvis const utgaven også er en const medlemsfunksjon.

 

Da må det gjennomføres at alle metoder som returnerer non-const må være non-const selv. Det må jeg i tilfelle teste litt på.

 

Men f.eks;

type x = static_cast<const class &>(object).get();

...blir rimelig vanskelig å huske på å bruke når du gjør kallet fra et objekt som selv er non-const (men du allikevel har mulighet til å kalle const utgaven). Jeg synes kanskje der er hakket bedre å få kompileringsfeil på kall til feil funksjon når du er i et const objekt.

 

Men forslaget er uten tvil den beste løsningen for metodenavnet, isolert sett.

Endret 19. september 2013 av Slettet-Pqy3rC

[Glutar]

Hvis medlemsfunksjonen ikke har const signatur er det jo ikke noe poeng i at den returnerer const &.

 

For eksempel:

struct A
{
    std::sting & get();
};

A a;

// Const utgave av referansen.
auto const & s = a.get();

// Non-const utgave.
auto & s = a.get(); 

// I dette tilfellet er det ikke nødvendig med en const utgave av get().

Const utgaven er først nødvendig hvis du bare har tilgjengelig en const utgave av A:

struct A
{
    std::string & get();
    std::string const & get() const;
};

void foo(A const & a)
{
    // Det er først her du har trenger const utgaven av A::get();
    auto const & s = a.get();
}

Jeg ser ikke helt nytten av "std::string const & read()" som dette (hvis "get" og "read" returnerer refersanse til det samme):

struct A
{
   std::string const & read();
   std::string & get();
};

Endret 19. september 2013 av Glutar