initialisering af members attributter i kontruktøren.

ingen

men den sidste syntax virker kun på simple data typer (inkl. pointere til objekter)

[det er iøvrigt en af grundene til at jeg så godt som aldrig bruger
members som er classes - kun pointere til classes]

const og reference members kan kun initialiseres og derfor skal første metode anvendes på den slags.
Initialiseringerne bør (skal) ske i samme rækkefølge som erklæringerne.

Den anden metode kan naturligvis anvendes på alle slags member objekter, blot objektet har defineret en gyldig assignment-operator.

jeg vil MEGET gerne se et eksempel på to klasser hvor den ene klasse har en
member (altså ikke en pointer) af den anden klasse hvor den anden klasse
ikke har en constuctor uden argumenter compile med den anden metode

Hej.

Jeg kan pure afvise at ..

"Initialiseringerne bør (skal) ske i samme rækkefølge som erklæringerne"

det er ikke rigtigt.


Nu mit "rigtige" svar:
Der er ingen forskel i nævnte eksempel. Her er dit eksempel som svar på din sidste kommentar:

class A {
public:
  A( int _1):member1(_1), member2(0) {}
private:
int member1;
int member2;
};

class B {
public:
  B() : member2(123) { member1 = 0; }
private:
int member1;
A member2;
};

class C {
public:
  C() : member1(0), member2(123) {}
private:
int member1;
A member2;
};


Hvor klassen 'B' gør præcis hvad du spørger om, og klassen 'C' er den mest korrekte måde.


Mvh.
Asger

det var min kommentar - ikke spørgers

og klasse B gør ikke det jeg spørger om (du initialiserer netop member2 udenfor
ikke indenfor)

min kommentar var ren drilleri - det kan nemlig ikke lade sig gøre i C++

Så forklar venligst dit spørgsmål igen ... du nævnte jo ikke noget omkring indenfor/udenfor.


mvh.

nej - jeg snakker om anden metode (anden metode har initialiseringen indenfor - første
metode har initialiseringen udenfor)

nåhh! nej det er rigtigt, det kan man ikke.

Men du kunne f.eks. skrive;


struct A
{

CValueInit<int, 123123> m_member1;
};

dette ville gi' dig en int med 123123 som start værdi. Med den rette teknik behøver det ikke at fylde mere eller være langsommere.

mvh.

amma>
Jeg kan pure afvise at ..
"Initialiseringerne bør (skal) ske i samme rækkefølge som erklæringerne"
det er ikke rigtigt.

Så prøv venligst følgende eksempel (kompileret med Visual C++ 7)


#include "stdio.h"

class Foo
{
public:
  Foo() : c(3), b(c-1), a(b-1) {};
  Foo(int x) : a(1), b(a+1), c(b+1) {};
  int a,b,c;
};

int main(int argc, char* argv[])
{
  Foo Bar1;
  printf("Bar1: a=%d, b=%d, c=%d\n",Bar1.a,Bar1.b,Bar1.c);

  Foo Bar2(1);
  printf("Bar2: a=%d, b=%d, c=%d\n",Bar2.a,Bar2.b,Bar2.c);

  return 0;
}


med output

  Bar1: a=-858993461, b=-858993461, c=3
  Bar2: a=1, b=2, c=3

Såehhh.. rækkefølgen er altså ikke ligegyldig.

Læs f.eks

  Scott Meyers
  "Effective C++, 50 Specific Ways to Improve Your Programs ans Designs"

Item 12 behandler dette emne.


Mvh

I min 2ed 1998 er det altså Item 13 - og lige netop i den slags tilfælde (dependency
mellem initialiseringer) vil jeg klart foretrække assignments inde i constructor
fordi der er det netop krystal klart hvad der sker i hvilken rækkefølge

Og de performance hensyn han mener taler for initialisering udenfor i Item 12 (i min
udgave) vil jeg til enhver tid totalt ignorere for at få mere letlæselig kode.

arne_v>

Kan du forklare

"men den sidste syntax virker kun på simple data typer (inkl. pointere til objekter)"

lidt nærmere ?


Mvh

Jeg har første udgave af Scott Meyers bog, 1992.
Jeg foretrækker iøvrigt også metode 2.


Mvh

eksempel som ikke compiler:

class A
{
  public:
      A(int v) { };
};

class B
{
  private:
      A m_a;
  public:
      B(A a) { m_a = a; };
};

Svar til:
Jeg kan pure afvise at ..
"Initialiseringerne bør (skal) ske i samme rækkefølge som erklæringerne"
det er ikke rigtigt.

Så prøv venligst følgende eksempel (kompileret med Visual C++ 7)

Det er ikke det, dit eksempel gør. Erklæringerne er denne del:
  int a,b,c;

initialiseringerne af disse kan ske i vilkårlig rækkefølge, som dit eksempel også viser. At resultatet så bliver forskelligt fra hvad man måske skulle tro modsiger ikke min påstand.

der er visse semantiske forskelle i "bør" og "kan" ...

Hvis dine members er af typen int (eller andre simple typer) er der ingen forskel.
Men hvis dine members var af typen X:

class X
{
public:
  X(int){ std::cout << "X::X(int)" << std::endl; }
  X(){ std::cout << "X::X()" << std::endl; }
  X & operator = (int) {std::cout << "X:: = " << std::endl; return *this; }
};

Kan du se at der for det første eksempel kun bliver kaldt int constructoren X::X(int)
I det andet tilfælde bliver default constructoren X::X() først kaldt, derpå bliver assignment operatoren kaldt (X::=(int)).
Det ses let at den første metode er mest effiktiv.

SPAM fjernet

SPAM fjernet