hvordan skriver i classes?

en klasse gemmes i 2 filer.

klasse.h fil med definitioner

#ifndef KLASSE_H
#define KLASSE_H
class klasse{
  private:
    int i;
  public:
    int getI();
};
#endif

og en klasse.cpp fil med functions implementationerne

#ifndef KLASSE_CPP
#define KLASSE_CPP
#include "klasse.h"
int klasse::getI(){
  return i;
}
#endif

der kan godt være flere scope blokke af samme scope i en klasse definition, dette er relevant hvis du f.eks. vil

class klasse{
  public:
    ...
  private:
    ...
  public:
    ...
};

Og efter min mening skal member variabler altid erklæres private, så du sikker på at andre eller dig selv ikke ødelægger dem totalt i forhold til hvad tanken er med dem.

et eksempel kunne være hvis du havde en klasse der havde en liste af elementer og som blottede størrelses variablen i denne liste:

class klasse{
  private:
    liste f;
  public:
    int counter;
    item getByIndex(int a){
      return f[a];
    }
    int getCount(){
      return counter;
    }
};

int main(){
  klasse k;
  k.counter=10;
  for(int i=0;i<k.getCount();i++){
    k.getItem(i);
  }
}

ovenstånde er pseudokode, men bør være klart at eftersom man ikke havde putte noget i listen, men sætter counteren til at man har, vil den gå galt når du prøver at indeksere i listen med getItem();

men forstår ikke meningen i at putte variabler i private, også lave acceseor metoder.

Der er ingen mening, det er rent spild af tid. Det er en meget gammel mani blandt nogle OO-nørder, som har misforstået OO. Du vinder intet.

Til Jess; naturligvis er det en god ide at sætte sig ind i grundprincipperne i OO. Men at lave trivielle "accessor metoder" har intet med god OO programmering at gøre og man vinder reelt intet ved at lave "accessor metoder".

Det er jeg ikke enig med dig i. Du har ikke mulighed for at styre adgangen til variablerne hvis de er offentlige på klassen.

Forestil dig at du har en klasse som nedenstående. Det er dog kun et lille tænkt eksempel og ikke alle aspekter omkring sikkerhed er dækket i det.

class CPrincipal {
public:
  char* pszUsername;
  char* pszPassword;
}

Ovenstående vil gøre det muligt for alle umiddelbart at læse og skrive både brugernavn og adgangskode. Vælger du i stedet at bruge accessor metoder, så kan du pludselig begynde at styre adgangen og samtidig adgang til variablerne.

class CPrincipal {
public:
  const char* getUserName();
  void setUserName(const char* name);
  void setPassword(const char* newpass);
  void setPassword(const char* oldpass, const char* newpass);
private:
  char* pszUsername;
  char* pszPassword;
}

void CPrincipal::setUserName(const char* name)
{
  if (!isMemberOf("admin")) // pseudo funktion
    return;

  // ToDo change name
}

void CPrincipal::setPassword(const char* newpass)
{
  if (!isMemberOf("admin")) // pseudo funktion
    return;

  // ToDo change password
}
void CPrincipal::setPassword(const char* oldpass, 
                             const char* newpass)
{
  if (strcmp(pszPassword, oldpass))
    return;

  // ToDo change password
}

Herved tvinger du brugeren af klassen til at bruge den logik du har lagt og du beskytter tilgangen til dataene. Er alle medlemsvariable offentlige, så er der ingen grund til at bruge accessor metoderne. Man kan jo rette i dem direkte, så derfor laver man metoderne private.

Ved brug af flere DLL'er er det endvidere MEGET fornuftigt at bruge accessor metoder, da du så kan indkapsle dine allokeringer/deallokeringer i en DLL. Er alle variable public, så kan de blive allokeret fra en vilkårlig DLL, hvilket giver et meget dårligt og igennemskueligt design.

ok, det er også sådan codeblocks gør det. Hvad gør

#ifndef KLASSE_CPP
#define KLASSE_CPP
og
#endif
??

http://en.wikipedia.org/wiki/Include_guard

Husk at beskytte dine data på klassen, så har du nemmere med at styre ting som fx samtidighed. Det er generelt også en god regel at tilgå medlemsvariabler med accessor metoder i stedet for at gøre dem offentlig tilgængelige ved at placere dem under public sektionen. Herudover er det en god ide at have constructor og destructor med på sin klasse.

// HEJ.H fil
#ifndef HEJ_H
#define HEJ_H

class Hej
{
private:
int variabel1; // Medlemsvariabel
int variabel2; // Medlemsvariabel
public:
Hej(); // Constructor
~Hej(); // Destructor

void funktion();

int getVariabel1(); // Accessor metode
int getVariabel2(); // Accessor metode
void setVariabel1(int i); // Accessor metode
void setVariabel2(int i); // Accessor metode
}

#endif

// HEJ.CPP fil
// Indeholder implementationen af dine metoder
// To af metoderne er vist som eksempel her nedenfor

int Hej::getVariabel1()
{
return variabel1;
}

void Hej::funktion()
{

}

// MAIN.CPP fil
#include "HEJ.H"

int main()
{
Hej * pKlasse = new Hej();
pKlasse->funktion();
delete pKlasse;
}


Hth

Tak for alle svarene, det hjalp rigtig meget.

har fordelt pointne

sådan endelig fik jeg det til at virke....

havde sat nogel flueben nogle steder i code::blocks hvor de ikke skulle være... tror faktisk jeg har arbejdet på det siden jeg skrev forige post lol

Det er imho godt at starte class'en med public members, da det er dem der er vigtigst (for flest), så det gør det lettest at overskue og bruge class'en

Ideen med "accessor metoder" er en af dem mest overvurderede manier i C++ (og andre OO-sprog).

Det er imho godt at starte class'en med public members, da det er dem der er vigtigst (for flest), så det gør det lettest at overskue og bruge class'en

Ideen med "accessor metoder" er en af dem mest overvurderede manier i C++ (og andre OO-sprog).

Men det er stadig en god ide at lære grundprincipperne for OO-programmering fra starten (herunder indkapsling af data, lav kobling og høj samhørighed m.m.). Når man senere sidder med applikationer med 100.000+ liniers kode, så er man glad for at disse principper er på plads og anvendt.

men forstår ikke meningen i at putte variabler i private, også lave acceseor metoder.

Syntes de virker dumt, at vis jeg vil putte input fra en bruger ind i en variable fra en class, bliver jeg nødt til først at putte den ind i en alm. variable først...

det virker ivhært fald ikke særlig smart i de små programmer jeg laver.