Wykład 6 – part a
Zanim zaczniemy kodować
-
jakość oprogramowania
itm / MVLab (c) 2007-2011
Gdzie jesteśmy?
Analiza
Projekt
Implementacja
l
Klasy (
Atrybuty, Metody,
Mechanizmy dostępu)
l
Struktury (
Dziedziczenie,
Asocjacje, agregacje i
kompozycje)
l
Architektury (
Warstwy,
Moduły, Przetwarzanie
danych)
itm / MVLab (c) 2007-2011
Cele tego wykładu
l
co jest do zrobienia?
l
zadania w fazie implementacji
l
jak to zrobić?
l
systematyczne postępowanie podczas implementacji
programu obiektowego
l
jak to działa?
l
podstawowa umiejętność wdrażania elementarnych
zasad obiektowości w języku programowania C++
itm / MVLab (c) 2007-2011
4.1. Zanim rozpoczniemy
implementację...
itm / MVLab (c) 2007-2011
Cele implementacji
bez-
błędność stabilność
dokumen-
tacja
oszczędn
ość
czasu
oszczędno
ść
kosztów
zrozumia-
łość
przyjaznoś
ć
użytkowni-
kowi
rozsze-
rzalność
efektywno
ść
otwartość
Jakość
(za ISO 9126 dla oprogramowania):
funkcjonalność, niezawodność,
stosowalność, efektywność,
serwisowalność, przenośność
itm / MVLab (c) 2007-2011
„Diabelski kwadrat”
(Harry M. Sneed)
Jakość
Ilość
Czas
projektowania
Koszty
Powierzchnia kwadratu
•
miara produktywności
zespołu projektowego,
•relatywnie niezmienna
itm / MVLab (c) 2007-2011
Software -
jakość produktu
l
Funkcjonalność
l
celowość
l
pewność
l
dokładność
l
współdziałanie,
l
zgodność ze standardami
l
Niezawodność
l
dojrzałość
l
tolerancja błędów
l
łatwość modyfikacji
l
Efektywność
l
wymagania czasowe
l
„zasobożerność”
l
Serwisowalność
l
zrozumiałość
l
łatwość uczenia
l
łatwość obsługi
l
Przenośność
l
możliwość analizy systemu
l
możliwość modyfikacji
l
stabilność
l
łatwość analizy błędów
l
Stosowalność
l
dopasowanie do wymagań
l
łatwość instalacji
l
zgodność ze standardami
l
zamienność
itm / MVLab (c) 2007-2011
Konstruktywne wskaźniki
jakości software'u
chińskie piły
są super!
Zapewnienie jakości dzięki projektowaniu w
sposób systematyczny (jakość jest
„wbudowana”)
l
wskazówki
l
szablony
l
narzędzia
l
notacja
l
metodyka
l
wykształcenie
Większość wskaźników jakości software'u
została stworzona na podstawie
doświadczeń z systematycznym
podejściem.
itm / MVLab (c) 2007-2011
Zadania w fazie implementacji
l
Cel główny: kodowanie,
l
Zadania pomocnicze:
l
Wybór języka programowania
(np. C++)
l
Wybór środowiska programistycznego
(np. MS Visual Studio)
l
Wybór generatora kodu
(np. Rhapsody)
l
Wybór potrzebnych bibliotek
(np. .net-Framework)
l
Zasady programowania
(o tym później)
l
Design Pattern
(już nieco omówione)
l
Dokumentacja
(o tym później)
l
Algorytmika
(
o tym później)
l
Modularność
(o tym później)
l
Modyfikowalność
(o tym później)
l
Serwis
(o tym później)
itm / MVLab (c) 2007-2011
Generatory kodu
Znane, dostępne generatory kodu:
Matlab, Rhapsody, Rational Rose, Poseidon for UML,
Trice, Easy Code, ...
Otwarte problemy:
l
Zakres generacji (np. czy tylko statyczny
szkielet klas?)
l
Sposób sprzężenia (generacja w jednym
kierunku czy także z powrotem)
l
Funkcjonalność/stabilność
l
Gospodarka czasowa, efektywność (np.
także „zasobożerność”)
l
Czytelność, zrozumiałość kodu źródłowego
l
Aspekty pewności systemu
Projekt
#include <c>
//kod źródł.
int main()
{ //...
itm / MVLab (c) 2007-2011
Dygresja: Narzędzia CASE
l
Definicja:
l
Computer Aided Software Engineering
l
Komputerowo wspomagana inżynieria oprogramowania
l
Możliwości:
l
wspomaganie tworzenia diagramów UML
l
generacja kodu źródłowego na podstawie UML
l
tworzenie diagramów UML na podstawie kodu źródłowego
(Reverse Engineering)
l
Roundtrip-Engineering
l
wymiana danych pomiędzy narzędziami różnych firm dzięki
formatowi XMI (XML Metadata Interchange)
itm / MVLab (c) 2007-2011
Zasady programowania
l
Problem
l
składnia języków programowania pozwala na daleko idącą swobodę
l
„goły” kod oznacza kiepską jakość softwere'u
l
brak zasad: niespójności i kiepska jakość softwere'u
l
Rozwiązanie: konwencje
l
zasady formatowania kodu
l
komentarze
l
dobór identyfikatorów (nazw)
l
szczególne zasady i algorytmika
l
dokumentacja
...
Niestosowanie obowiązującej konwencji jest uważane za błąd!
itm / MVLab (c) 2007-2011
Zasady programowania
l
Formatowanie
l
Wcięcia, odstępy
l
Widoczne ustawienie klamry
l
Zasady dot. maksymalnych rozmiarów bloku programowego (np. metody,
znaków w linii, linii w bloku)
l
Komentarze
l
Co jest komentowane
l
pliki
l
klasy
l
metody
l
algorytmy
l
Jak
jest komentowane
l
wzorce standardowe
l
automatyczna dokumentacja XML
-
Pańskie przemówienie było wyborne,
kolego. -
Kto je panu napisał?
-
Dziękuję. Cieszę się że się podobało. -
Kto je panu wytłumaczył?
itm / MVLab (c) 2007-2011
Zasady programowania
Identyfikatory
l
Język (polski, angielski?)
l
Pliki (nazwa modułu, nazwa nagłówka?)
l
Klasy, typy danych (np. struktury)
l
Nazwy metod (otwarte, prywatne, wg zwracanej wartości?)
l
Zmienne -wg funkcji (zmienne -
składniki, zmienne lokalne, zmienne
globalne, ...)
l
Zmienne -wg typu
(standardowe,
tablice, obiekty,
wskaźniki, ...)
l
Stałe
(stałe literalne, makra, ...)
itm / MVLab (c) 2007-2011
Zasady programowania
Algorytmika i inne
l
Modularyzacja (modele komponentów, rozdział tekstu źródłowego na wiele plików, co
znajduje się w plikach nagłówkowych, co w implementacji)
l
Zalecenia do implementacji łącz
l
klasy abstrakcyjne (interfejsy)
l
preferencje (przekazywanie argumentów przez referencje/wartość)
l
zwracanie wartości przez funkcje (np. dla obsługi błędów)
l
wzorce (templates)
l
Zalecenia do wdrażania zależności klas (asocjacje, kompozycje, ...)
l
Zasady inicjalizacji
l
Zasady rozgałęziania (if...else, switch...case...default)
l
Obsługa błędów i wyjątków
l
unikanie dzielenia przez 0 (zero)
l
unikanie wykraczania poza dopuszczalne zakresy wartości
l
inne zasady obsługi błędów
itm / MVLab (c) 2007-2011
Zasady programowania
Dokumentacja
l
Podczas implementacji
l
projektant
l
wersja
l
zaplanowane testy
l
przeprowadzone testy
l
znalezione błędy
l
naprawione błędy
l
Po implementacji
l
wprowadzenie do instalacji
l
wymagania
l
wprowadzenie dla użytkownika
l
szczegóły dla programistów
l
rozszerzalność
l
serwis
itm / MVLab (c) 2007-2011
Zasady programowania -
standardy
l
Zasady MISRA
l
The Motor Industry Software Reliability Association
l
141 zasad kodowania dla C (wcześniej 127)
l
Zasady kodowania dla C++: Wysoko integralny C++
l
Opracowane przez THE PROGRAMMING RESEARCH GROUP
l
Ok. 200 zasad, opracowanych dla standardowych zadań
programistycznych z zakresu C++
l
Narzędzia do automatycznej kontroli
l
PC-lint, FlexeLint
l
QA C/C++
l
CodeSurfer
l
...
itm / MVLab (c) 2007-2011
Dalsza statystyczna analiza
kodu
Wiedza:
Całościowe badanie kodu źródłowego konkretnej implementacji bez
uruchamiania programu
Cele:
l
Rozpoznanie miejsc potencjalnie krytycznych w programie
l
możliwe dzielenie przez 0 (zero)
l
niezabezpieczone przekroczenie obszaru zapisu
l
...
l
Analiza metryk
l
wyjaśnianie przez modularność/złożoność
l
wyjaśnianie przez spójność
l
...
l
Rozpoznawanie klonów
l
...
itm / MVLab (c) 2007-2011
itm / MVLab (c) 2007-2011
Metryki oprogramowania
itm / MVLab (c) 2007-2011
Zarządzanie wersjami i błędami
l
Zarządzanie błędami
l
dokumentacja i reprodukowalność błędów
l
klasyfikacja błędów (np. pod względem ich krytyczności)
l
poszukiwanie błędów i uwzględnianie w planach kolejnych wersji
l
Zarządzanie wersjami
l
wersje oprogramowania definiują w sposób ciągły zmiany
nanoszone na oprogramowanie, dyskretne stany na które ma
zostać położony szczególny nacisk
l
wersja: zdefiniowana jednostka programistyczna powstała przez
integrację modułów
l
Narzędzia
l
Bugzilla, WinCVS, Subversion SVN (open source), ...
Wykład 6 – part b
Pierwsze kroki w C++
Klasy, metody, atrybuty, konstruktor,
operator, organizacja programu
itm / MVLab (c) 2007-2011
4.2. Pierwsze kroki w kierunku
programowania w C++
itm / MVLab (c) 2007-2011
Co już mamy do dyspozycji ?
l
Mamy
l
dokumentację projektu szczegółowego (diagramy
klas, działań i stanów)
l
język programowania C++
l
środowisko programistyczne .net
l
zasady programowania
l
Implementujemy...
l
krok 1: implementacja klas
l
krok 2: implementacja działań
Plan
(rozdz. 3)
Krok 1
narzędzia
(klasy)
Krok 2
działania
(obiekty)
itm / MVLab (c) 2007-2011
Klasy
Klasa
jest definicją właściwości, metod i semantyki dla pewnego zbioru
obiektów. Wszystkie obiekty danej klasy odpowiadają jej definicji.
Wyrażenia „klasa” i „typ” mogą być w pewnych warunkach traktowane
jako synonimy.
l
Implementacja klasy
l
Podejście statyczne
l
definicja struktury danych podobna do struktur lub rekordów
l
klasa jako szablon dla potencjalnych obiektów
l
Podejście dynamiczne
l
mechanizmy dostępu
l
implementacja metod podobna do funkcji i procedur
l
Ogólne
l
klasa może być potencjalnie wykorzystana poza konkretnym
programem, jako w pełni oprogramowany komponent
l
należy rozpatrzyć wszystkie potencjalne przypadki zastosowań
itm / MVLab (c) 2007-2011
Metoda
Metoda
to operacja jaka może być wykonana przez obiekt. Metodę
określa sygnatura (nazwa, lista parametrów, typ wartości zwracanej).
Wyrażenia: „operacja”, „usługa”, „procedura”, „routine” i „funkcja” mogą
być traktowane jako synonimy.
l
Implementacja metod
l
implementacja algorytmu
przekazane parametry
→ obróbka → wynik
l
łącze wejściowe:
przekazane parametry + właściwości (dostęp do odczytu)
l
łącze wyjściowe:
wartość zwracana + właściwości (dostęp do zapisu)
l
Następstwa
l
działanie metody nie zależy tylko do parametrów przekazanych, ale także
od wewnętrznego stanu obiektu (właściwości).
itm / MVLab (c) 2007-2011
Deklaracja klasy w C++
Ulamek
- Licznik
- Mianownik
+ Ulamek(int L, int M)
+ ~Ulamek()
+ Wypisz()
+ SprowDoMian(int M)
UML
C++
class CUlamek {
private:
int m_iLicznik;
int m_iMianownik;
public:
CUlamek(int iLicznik, int iMianownik);
~CUlamek()
void Wypisz() const;
void SprowDoMian(int iMianownik);
};
Dane reprezentujące
dowolny ułamek zwykły
Metody do przetwarzania
dowolnego ułamka zw.
Mechanizm dostępu
Zasada: information hiding
Deklaracja właściwości
Deklaracja metod
itm / MVLab (c) 2007-2011
Rozdział: deklaracja i
implementacja
Plik nagłówkowy: Ulamek.h
definicje struktur i powiązań:
•deklaracje klas
•
używane biblioteki
•
używane definicje typów
Plik implementacji: Ulamek.cpp
realizacja -implementacja metod:
•konstruktorów
•destruktorów
•operatorów
•akcesorów
•innych metod
l
Zasada „czarnej skrzynki”
l
Oddzielenie struktur i powiązań od implementacji
l
pomaga radzić sobie z dużą złożonością
l
umożliwia oddzielną kompilację elementów programu
l
gdy potrzebna jest klasa CUlamek, wystarczy dodać odpowiednie pliki
nagłówkowe
itm / MVLab (c) 2007-2011
Rozdział: deklaracja i
implementacja
// Ulamek.h
class CUlamek {
private:
int m_iLicznik;
int m_iMianownik;
public:
CUlamek(int iLicznik,
int iMianownik);
~CUlamek()
void Wypisz() const;
void SprowDoMian
(int iMianownik);
};
// Ulamek.cpp
#include "Ulamek.h"
CUlamek::CUlamek(int iLicznik, int
iMianownik) {
m_iLicznik=...
}
CUlamek::~CUlamek(){ ... }
void CUlamek::Wypisz() const
{
cout<<"Wynik: "<< ...
}
void CUlamek::SprowDoMian
(int iMianownik) {
m_iLicznik = ...
}
Powiązanie z plikiem
nagłówkowym
Implementacja metody
Wypisz()
:
•
należącej do klasy
CUlamek
,
•bezparametrowej,
•
niezmieniającej stanu obiektu,
•
zwracającej typ
void
.
itm / MVLab (c) 2007-2011
Implementacja metod
Specyfikacja metody Wypisz klasy CUlamek:
•
funkcja: wypisuje na monitorze wartość ułamka
w postaci dziesiętnej
•
parametry wejściowe: brak
•
zwracana wartość: brak
•warunki PRE i POST: brak
•
metoda nie może zmieniać stanu obiektu
void CUlamek::Wypisz() const
{
if(m_iMianownik)
cout << m_iLicznik / m_iMianownik;
else
cerr << " NaN"; //BLAD: dzielenie przez zero
}
void CUlamek::SprowDoMian(int iMianownik) {
double mnoznik = (m_iLicznik * iMianownik / m_iMianownik);
if(!m_iMianownik && !(mnoznik%1))
m_iLicznik *= mnoznik; m_iMianownik = iMianownik;
else
cerr << "Nie mozna sprowadzic do podanego mianownika.”;
}
na podst.
specyfikacji szczegółowej
cout -
obiekt związany
z monitorem (o tym później)
złącze „na zewnątrz”
-
zmiana właśc. obiektu
itm / MVLab (c) 2007-2011
Konstruktory
CUlamek::CUlamek(int iLicznik, int iMianownik)
{
if(!iMianownik) {
cerr << "Mianownik nie może być zero! Ustawiam na 1." << endl;
iMianownik = 1;
}
m_iLicznik = iLicznik;
m_iMianownik = iMianownik;
}
Konstruktor:
l
specjalna metoda,
l
gwarantuje prawidłową inicjalizację obiektu,
l
wywoływane automatycznie podczas tworzenia obiektów,
l
mogą posiadać parametry wejściowe (argumenty)
Nazwa taka
sama jak klasy
itm / MVLab (c) 2007-2011
Konstruktory standardowe
CUlamek::CUlamek()
{
m_iLicznik = 0;
m_iMianownik = 1;
}
//Alternatywa dla domyslnego konstruktora standardowego
CUlamek::CUlamek(int iLicznik = 0, int iMianownik = 1)
{
if(!iMianownik) { //Blad dzielenia przez 0
{
Konstruktor standardowy:
l
także konstruktor domyślny,
l
brak argumentów,
l
powinien być zawsze implementowany,
l
szczególnie potrzebny w przypadku agregacji (o tym później)
konstruktor
bezparametrowy
wartości domyślne w przypadku braku
argumentów w wywołaniu.
UWAGA! niebezpieczeństwo
dwuznaczności przy wywołaniu
bezparametrowym!
itm / MVLab (c) 2007-2011
Destruktory
Destruktor:
l
oznaczony przez znak tyldy (~) i nazwę klasy,
l
brak argumentów,
l
wywoływane automatycznie przez system
l
aby usunąć obiekt po zakończeniu działania bloku programu (np.
funkcji)
l
przez wywołanie delete w sposób jawny (o tym później)
CUlamek::~CUlamek()
{
//tu umieszcza sie operacje pozwalajace usunac obiektypowiazane
//z danym obiektem.
//Pamiec przydzielona samamu obiektowi na rzecz ktorego wywolany
//jest destruktor jest dealokowana autoamtycznie (pusty
//destruktor, lub jego brak)
}
brak parametrów
itm / MVLab (c) 2007-2011
Nasz pierwszy program w C++
CUlamek.h
CUlamek.cpp
TestUlamek.cpp
Krok 1
Krok 2
Definicja i
implementacja klasy
CUlamek
Użycie
zaimplementowanej
klasy w działającym
programie
„używa”
Deklaracja klasy
itm / MVLab (c) 2007-2011
Nasz pierwszy program w C++
// Ulamek.h
#include <iostream>
class CUlamek {
private:
int m_iLicznik;
int m_iMianownik;
public:
CUlamek(int iLicznik,
int iMianownik);
~CUlamek()
void Wypisz() const;
void SprowDoMian
(int iMianownik);
};
// Ulamek.cpp
#include "Ulamek.h"
using namespace std;
CUlamek::CUlamek(int iLicznik, int iMianownik)
{ /*implementacja podana wcześniej*/ }
CUlamek::~CUlamek()
{ }
void CUlamek::Wypisz() const
{ /*implementacja podana wcześniej*/ }
void CUlamek::SprowDoMian(int iMianownik)
{ /*implementacja podana wcześniej*/ }
// TestUlamek.cpp
#include "Ulamek.h"
void main() {
CUlamek mojUlamek(1,2);
mojUlamek.Wypisz();
mojUlamek.SprowDoMian(4);
mojUlamek.Wypisz();
}
łączenie z definicją klasy
Tworzenie instancji (obiektu) klasy
CUlamek -
niejawne wywołanie konstr.
operator odwołania (.)
itm / MVLab (c) 2007-2011
Przebieg kompilacji
Ulamek.h
Ulamek.cpp
TestUlamek.cpp
Kompilator
Kompilator
Ulamek
.obj
TestUlamek
.obj
Linker
TestUlamek.exe
itm / MVLab (c) 2007-2011
Przebieg kompilacji
Ulamek.h
Ulamek.cpp
TestUlamek.cpp
Kompilator
Kompilator
Ulamek
.obj
TestUlamek
.obj
Linker
TestUlamek.exe
Muszą znajdować się w
jednym katalogu.
wspierane przez wizardy
niepowiązane adresy wejściowe
itm / MVLab (c) 2007-2011
4.3 Nasze klasy „rosną”...
4.3.1 Przestrzenie nazw
4.3.2 Przeciążanie metod
4.3.3 Przeciążanie operatorów
4.3.4 Wzorce
4.3.5 Właściwości i dynamiczna
alokacja pamięci
4.3. Nasze klasy „rosną”...
itm / MVLab (c) 2007-2011
Przestrzenie nazw
Powód:
l
większa swoboda nazywania funkcji, zmiennych, ...
l
niebezpieczeństwo konfliktów nazw w przypadku dużych
projektów
// AAA.h
class CMojaKlasa
{
private:
int var_1;
//...
};
// BBB.h
class CMojaKlasa
{
private:
int var_1;
//...
};
// Test.cpp
#include AAA.h
#include BBB.h
Użycie obydwu headderów
na raz jest niemożliwe.
Błąd kompilacji.
itm / MVLab (c) 2007-2011
Zastosowanie przestrzeni nazw
l
deklaracje widoczne tylko w obrębie swojej przestrzeni
l
deklaracje bibliotek standard. znajdują się w przestrzeni nazw std
l
UWAGA! mechanizm nie jest wspierany przez wszystkie kompilatory.
// AAA.h
namespace A
{
class CMojaKlasa
{ /* ... */ };
};
// BBB.h
namespace B
{
class CMojaKlasa
{ /* ... */ };
};
// Test.cpp
#include AAA.h
#include BBB.h
using namespace A
B::CMojaKlasa test;
//...
using: wybiera
do użycia jedna
z istniejących
przestrzeni nazw
dostęp do innych
od obecnie używanej
przestrzeni nazw przez
operator dostępu (::)
itm / MVLab (c) 2007-2011
Przeciążanie metod
Powód:
l
W standardowym C mogła istnieć tylko jedna funkcja o danej
nazwie.
l
Funkcje (metody) robiące zasadniczo to samo, powinny
również tak samo się nazywać. Np:
class CUlamek {
// ...
public:
void WypiszNaEkranie() const
{
//...
};
void WypiszNaDrukarce() const
{
//...
};
//...
};
Czy
w każdym przypadku
potrzebna jest nowa
nazwa?
itm / MVLab (c) 2007-2011
Zły przykład: konstruktory
class CUlamek1
{
CUlamek1(int iL, int iM)
{
m_iLicznik=iL;
m_iMianownik=iM;
};
\\...
};
class CUlamek2
{
CUlamek2(int iL)
{
m_iLicznik=iL;
m_iMianownik=1;
};
\\...
};
class CUlamek3
{
CUlamek3()
{
m_iLicznik=0;
m_iMianownik=1;
};
\\...
};
#include "Ulamek1.h"
#include "Ulamek2.h"
#include "Ulamek3.h"
void main()
{
CUlamek1 ulamekA(1,2);
CUlamek2 ulamekB(3);
CUlamek3 ulamekC;
};
Nigdy
w ten
sposób
itm / MVLab (c) 2007-2011
Przeciążanie metod - przykład
class CUlamek
{
private:
int m_iLicznik;
int m_iMianownik;
public:
CUlamek();
CUlamek(int iLicznik);
CUlamek(int iLicznik,
int iMianownik);
};
#include "Ulamek.h"
#include <iostream>
CUlamek() {
m_iLicznik=0;
m_iMianownik=1;
};
CUlamek(int iLicznik) {
m_iLicznik=iLicznik;
m_iMianownik=1;
};
CUlamek(int iLicznik, int iMianownik) {
if(!iMianownik) {
std::cerr<<"Dzielenie przez 0!";
std::exit(1);
};
m_iLicznik=iLicznik;
m_iMianownik=iMianownik;
};
#include "Ulamek.h"
void main()
{
CUlamek ulamekA(1,2);
CUlamek ulamekB(3);
CUlamek ulamekC(ulamekB);
CUlamek ulamekD;
};
takie same nazwy,
ale inny zestaw parametrów
itm / MVLab (c) 2007-2011
Przeciążanie metod - przykład
#include "Ulamek.h"
void main()
{
CUlamek ulamekA(1,2);
CUlamek ulamekB(3);
CUlamek ulamekC(ulamekB); //Kopiowanie; kompilator dostarcza
//standardowego konstruktora kopiującego
};
#include "Ulamek.h"
void main()
{
CUlamek ulamekA(1,2);
CUlamek ulamekB(3);
CUlamek ulamekC; //konstruktor
ulamekC=ulamekB; //przypisanie
};
#include "Ulamek.h"
void main()
{
CUlamek ulamekA(1,2);
CUlamek ulamekB(3);
CUlamek ulamekC(3);
};
lu
b
lu
b
najlepsze
rozwiązanie
itm / MVLab (c) 2007-2011
Przeciążanie metod - przykład
#include "Ulamek.h"
void main()
{
CUlamek ulamekA(1,2);
CUlamek ulamekB(3);
CUlamek ulamekC(ulamekB); //Kopiowanie; kompilator dostarcza
//standardowego konstruktora kopiującego
};
#include "Ulamek.h"
#include <iostream>
CUlamek::CUlamek(int iLicznik) {
m_iLicznik = iLicznik;
m_iMianownik = 1;
};
CUlamek::CUlamek(const CUlamek& kUlamek) {
m_iLicznik = kUlamek.m_iLicznik;
m_iMianownik = kUlamek.m_iMianownik;
};
lub:
przeładować
samodzielnie
konstruktor i
kopiować elementy w
zdefiniowany przez
siebie sposób
itm / MVLab (c) 2007-2011
Konstruktory kopiujące i
konwertujące
#include "Ulamek.h"
void main()
{
CUlamek ulamekB = 3;
CUlamek ulamekC = ulamekB;
};
#include "Ulamek.h"
CUlamek::CUlamek
(const CUlamek& kUlamek)
{
m_iLicznik =
kUlamek.m_iLicznik;
m_iMianownik =
kUlamek.m_iMianownik;
};
class CUlamek
{
private:
int m_iLicznik;
int m_iMianownik;
public:
CUlamek(
const CUlamek& kUlamek
);
CUlamek(int iLicznik);
CUlamek(int iLicznik, int iMianownik);
};
argument
przekazany
przez referencję
konstruktory z
dokładnie jednym
argumentem
niejawne
wywołanie
konstruktora
itm / MVLab (c) 2007-2011
Konstruktory kopiujące i
konwertujące
#include "Ulamek.h"
void main()
{
CUlamek ulamekB = 3;
CUlamek ulamekC = ulamekB;
};
niejawne wywołanie
konstruktora
#include "Ulamek.h"
void main()
{
CUlamek ulamekB(3);
CUlamek ulamekC(ulamekB);
};
jawne wywołanie
konstruktora
Porównanie: jawne i niejawne wywołanie
konstruktorów.
Która metoda jest preferowana?