38

Inżynieria

oprogramowania

www.sdjournal.org

 Software Developer’s Journal   05/2007

Mechanizm koncepcji w języku C++: 

nowe oblicze szablonów

O 

języku  C++  można  pisać  wiele.  Przez  jed-

nych  programistów  kochany,  przez  innych 

znienawidzony  –  jednakże,  co  tu  kryć  – 

trudno  potraktować  go  obojętnie.  C++  postrzegane 

nowocześnie to już nie tylko C rozszerzone o obiek-

towość.  To  potężne  narzędzie  do  budowania  gene-

rycznych bibliotek i wysokowydajnych rozwiązań ty-

pu  DSEL  (ang.  Domain  Specific  Embedded  Langu-
ages),  w  których,  dzięki  technikom  metaprogramo-

wania działającym na etapie kompilacji, można budo-

wać zaawansowane mechanizmy modelowania abs-

trakcji, nie płacąc wysokiej ceny w postaci opóźnień 

w  czasie  wykonania  programu.  Niestety  –  ceną  za 

tę potęgę jest złożoność. Wystarczy spojrzeć w kod 

źródłowy  dowolnej  biblioteki  korzystającej  ze  wspo-

mnianych  mechanizmów  (chociażby  Boost.MPL  lub 

Boost.Spirit).  Przeciętnemu  programiście  C++  trud-

no zrozumieć zawarty tam kod, a jeszcze trudniej – 

tworzyć własne rozwiązania tego rodzaju. Gdzie le-

ży  przyczyna?  Wydaje  się,  że  niektóre  z  właściwo-

ści języka przypadkowo okazały się bardziej potężne 

niż spodziewali się jego twórcy. Mowa tu oczywiście 

o  szablonach  (ang.  templates).  Niemalże  wszystkie 

nowoczesne  techniki  C++  bazują  na  skomplikowa-

nych sztuczkach syntaktycznych związanych z sza-

blonami,  odkrywanych  sukcesywnie  przez  ostatnie 

lata. W niniejszym artykule opisuję mechanizm kon-

cepcji w C++: rozszerzenie języka, które ma być re-

medium  na  wspomniane  wyżej  problemy.  Czytelni-

ków, którzy pragną poznać nowe oblicze szablonów 

w języku C++ zapraszam do dalszej lektury.

„Jest super, jest super,

więc o co Ci chodzi?”

W ciągu ostatnich lat C++ rozwinęło skrzydła, ewo-

luując w kierunku, którego nie przewidywali chyba 

nawet jego pierwotni twórcy. Można śmiało stwier-

dzić, że to właśnie dzięki C++ programowanie ge-

neryczne  trafiło  pod  strzechy.  Ta  ważna  technika 

stała się motorem do budowy wysoce efektywnych 

i  jednocześnie  świetnie  nadających  się  do  wielo-

krotnego użycia bibliotek. Prekursorem tego rodza-

ju rozwiązań jest oczywiście biblioteka STL, wcho-

dząca  zresztą  obecnie  w  skład  biblioteki  standar-

dowej języka C++. W zasadzie historia z programo-

waniem  generycznym  zaczęła  się  dla  C++  w  mo-

mencie wprowadzenia do tego języka nowego roz-

szerzenia  w  postaci  szablonów  (ang.  templates). 

Mechanizm  ten,  pozwalający  łatwo  tworzyć  rodzi-

ny klas i funkcji sparametryzowanych typami, oka-

zał się przysłowiowym strzałem w dziesiątkę. Z pa-

radygmatu  programowania  generycznego  wyewo-

luowały  inne  techniki:  programowanie  generatyw-

ne  (ang.  generative  programming)  oraz  metapro-

gramowanie  bazujące  na  szablonach  (ang.  tem-
plate  metaprogramming).  Programiści  zaczęli  two-

rzyć  na  bazie  szablonów  wysokowydajne  rozwią-

zania  klasy  DSEL  (ang,  Domain  Specific  Embed-

ded  Languages).  Wydawałoby  się,  że  lepiej  już 

być nie może. A jednak nie obyło się bez zgrzytów. 

Aż chciałoby się zacytować słowa piosenki zespo-

łu T.Love (patrz: tytuł niniejszego podpunktu). Nie-

stety, potęga i elastyczność, oferowane przez sza-

blony  języka  C++  okupione  zostały  wysoką  ceną 

w  postaci  złożoności.  W  rezultacie,  zarówno  pro-

jektowanie  jak  i  implementacja  bibliotek  bazują-

cych  na  wymienionych  wcześniej  paradygmatach, 

okazały się zadaniami bardzo trudnymi. Powodów 

takiego  stanu  rzeczy  wymieniać  można  by  wiele, 

jednakże  za  główną  przyczynę  całego  zamiesza-

nia  można  uznać  pewną  decyzję  projektową  pod-

Rafał Kocisz

Autor pracuje na stanowisku Starszego Specjalisty ds. 
Oprogramowania w firmie BLStream (http://www.blstre-
am.com)  oraz  odbywa  studia  doktoranckie  na  Wy-
dziale  Informatyki  Politechniki  Szczecińskiej  (http://
www.wi.ps.pl). Centrum zainteresowań zawodowych au-
tora stanowią technologie mobilne, przetwarzanie rów-
noległe oraz języki programowania w ujęciu ogólnym.
Kontakt z autorem: rafal.kocisz@gmail.com

STLFilt kontra 

komunikaty o błędach w C++

Nieczytelne  błędy  pojawiające  się  przy  kompilacji  biblio-
tek generycznych języka C++ mogą przyprawić o prawdzi-
wy ból głowy. Dla Leora Zolmana problem ten musiał być 
szczególnie  palący,  tak  że  w  końcu  napisał  on  w  języku 
Perl narzędzie o nazwie STLFilt. Rozwiązanie to działa bar-
dzo prosto: na swoim wejściu pobiera komunikat o błędzie 
wygenerowany przez kompilator, odsiewa śmieci i na wyj-
ściu podaje odchudzony komunikat o błędzie. Ze względu 
na bardzo niestabilne warunki wejściowe (kompilatory ewo-
luują cały czas) STLFilt jest nieustannie modyfikowany. Ak-
tualnie narzędzie oferuje wsparcie dla następujących kom-
pilatorów: Comeau C++, gcc 2.95.x/3.x, DJGPP, MSVC++ 
6/7.x/8.x, Metrowerks CodeWarrior Pro 7/8, Borland C++ / 
C++Builder, Intel C++ 7/8, EDG Front End (Generic) oraz 
Digital Mars C++. STLFilt można pobrać za darmo ze stro-
ny internetowej firmy DBSoftware (której założycielem jest 
właśnie Leor Zolman), pod adresem http://www.bdsoft.com/
tools/stlfilt.html.

Koncepcje w C++

39

www.sdjournal.org

Software Developer’s Journal   05/2007

jętą przy wstępnym określaniu specyfikacji szablonów. Otóż 

kłopot w tym, że wspomniana konstrukcja języka nie posia-

da formalnie zdefiniowanego mechanizmu nakładania ogra-

niczeń  na  własne  parametry  (typy).  Ograniczenia  takowe 

istnieją,  aczkolwiek  bazują  one  na  pewnych  konwencjach, 

które  można  zweryfikować  dopiero  w  późnej  fazie  kompi-

lacji, czyli – chciałoby się rzecz – po rybach. Dla porówna-

nia, w przypadku zwyczajnych klas, sytuacja taka jest abso-

lutnie niedopuszczalna. Przykładowo, nie możemy wywołać 

na obiekcie metody, która nie jest zdefiniowana w specyfi-

kacji klasy opisującej wspomniany obiekt. Kompilator powia-

domi nas o tym problemie w bardzo wczesnej fazie swojej 

pracy (Listing 1). W przypadku szablonów, sprawdzanie po-

prawności wykonywane jest dopiero w momencie tworzenia 

instancji metody szablonu klasy, bądź funkcji szablonowej.

Opisana sytuacja zaprezentowana jest na Listingu 2. Na-

leży zauważyć, że gdyby usunąć ostatnią linię w ciele funk-

cji 

main

, to przedstawiony fragment kodu skompilowałby się 

bez żadnego problemu. W przedstawionym przykładzie bar-

dzo łatwo zlokalizować i usunąć błąd. Niestety, pisząc dużą 

bibliotekę sprawa zaczyna się komplikować, gdyż programi-

sta fizycznie może nie być w stanie wymusić tworzenia in-

stancji w celu zweryfikowania poprawności. Kolejny poważ-

ny problem, to opis błędów generowanych przez kompilator: 

zmora programistów pracujących z nowoczesnymi bibliote-

kami C++. Kłopot jest naprawdę ważki – moim zdaniem to 

właśnie on powoduje, iż wielu początkujących informatyków 

zraża  się  do  języka  C++.  Wyobraźmy  sobie  bowiem  mło-

dego  adepta  trudnej  sztuki  programowania,  który  próbuje 

skompilować fragment kodu pokazany na Listingu 3. Listing 

4 przedstawia wynikowy komunikat o błędzie wyprodukowa-

ny przez kompilator C++ Visual Studio .NET 7, zaś Listing 5 

pokazuje komunikat zwrócony przez g++.

Koszmar,  nieprawdaż?  Dla  wprawnych  oczu,  błąd  jest 

oczywisty  –  przekazujemy  do  funkcji 

std::sort

  parę  itera-

torów,  które  nie  spełniają  wymagań  narzuconych  przez  tę 

funkcję. Problem w tym, że 

sort

 pracuje jedynie z iteratora-

mi o dostępie bezpośrednim (ang. random access), zaś lista 

posiada  iteratory  oferujące  dostęp  sekwencyjny.  Niestety 

pojęcia w rodzaju iterator o dostępie bezpośrednim czy te-
rator o dostępie sekwencyjnym nie mogą być wyrażone bez-

pośrednio  w  kodzie  C++.  Są  to  jedynie  pewne  konwencje 

Rysunek 1. 

Rodowód języka C++

�����������

���

�

������

������

���

�����������������

����������������

�����

�����������������

�����

�����������������

������

��������

���

��

���

40

Inżynieria

oprogramowania

www.sdjournal.org

 Software Developer’s Journal   05/2007

opisane w standardzie języka bądź w specyfikacji danej bi-

blioteki. Zachęcam Czytelników, aby postarali wyobrazić so-

bie jak wyglądają komunikaty o błędach w bardziej skompli-

kowanych  bibliotekach  generycznych.  Kiedyś  próbowałem 

pożenić bibliotekę Boost.Lambda z biblioteką Boost.Smart_

ptr. W końcu mi się to udało, ale zrozumienie istoty popeł-

nianego błędu na podstawie komunikatów kompilatora zaję-

ło mi kilka godzin. Na końcu okazało się, że błąd był dość 

banalny.  Jeśli  do  tego  wszystkiego  weźmiemy  pod  uwagę 

zjawisko określane potocznie jako magia kompilatorów (ang. 
compiler magic) (tzn. identyczny kod kompiluje się świetnie 

przy  użyciu  narzędzia  X  i  generuje  3  ekrany  błędów  przy 

próbie  kompilacji  narzędziem  Y)  to  otrzymamy  pełny  ob-

raz  problemu.  Powstaje  pytanie  –  dlaczego  komunikaty  o 

błędach nie mogą być bardziej przyjazne dla programisty? 

Przyczyna  tkwi  we  wspomnianym  wcześniej  błędzie  pro-

jektowym. Zasada jest prosta: im wcześniej da się wyłapać 

błąd  kompilacji,  tym  bardziej  ogólny  i  kompaktowy  będzie 

komunikat  na  jego  temat.  W  przypadku  szablonów  błędy 

wyłapywane są bardzo późno i kompilator – chcąc być po-

mocny – wypisuje wszystko, co na temat danego problemu 

wie. Czytelników, którzy chcieliby dowiedzieć się jak (przy-

najmniej częściowo) poradzić sobie z problemem nieczytel-

nych komunikatów o błędach w języku C++ zapraszam do 

ramki STLFilt kontra komunikaty o błędach w C++. W kolej-

nym podpunkcie opowiem o grupie ludzi, którzy postanowi-

li zmienić istniejący – nieciekawy – stan rzeczy, naprawiając 

opisywany problem definitywnie – u samego źródła.

Komitet standaryzacyjny 

nadciąga z odsieczą! 

Problem  przedstawiony  w  poprzednim  podpunkcie  oka-

zał się na tyle poważny, że za jego rozwiązanie zabrali się 

członkowie  komitetu  standaryzacyjnego  języka  C++,  z  sa-

mym  Bjarne  Stroustrupem  na  czele.  Po  wstępnych  anali-

zach problem okazał się znacznie bardziej złożony i wielo-

wymiarowy, niż sądzono na początku. W rezultacie podjęto 

bardzo odważną decyzję: rozszerzenie składni języka. I tak, 

w nowej odsłonie C++ (roboczo oznaczanej jako C++0x lub 

C++09)  otrzymamy  nowy  mechanizm,  który  docelowo  ma 

stanowić  remedium  na  kłopoty  z  szablonami.  Mechanizm 

ten  nazwano  koncepcjami  (ang.  concepts).  Gdyby  chcieć 

jednym zdaniem scharakteryzować tę ideę, można by napi-

sać, że koncepcje to podzbiór składni języka służący do na-

kładania ograniczeń na typy w szablonach C++. W prakty-

ce oznacza to, że język będzie rozszerzony o elementy po-

zwalające określić zbiór wymagań odnośnie zadanego typu. 

Dzięki  temu  takie  abstrakcje  jak  iterator  o  dostępie  bezpo-
średnim będzie można wyrazić bezpośrednio w C++, a nie 

– jak dotąd, jedynie w postaci umownej specyfikacji. Z kolei 

kompilator mając z góry określony meta-model typu, będzie 

w  stanie  już  na  etapie  odwołania  się  do  szablonu  porów-

nać  go  z  przekazanym  argumentem.  Gwoli  ścisłości  nale-

ży przypomnieć, że podobne zagadnienie (nakładanie ogra-

niczeń na typy będące parametrami szablonów) było rozpa-

Listing 1. 

Wykrywanie błędów przy kompilacji klasy

class

 

foo

 

{

public

:

   

void

 

f1

()

 

const

;

}

;

class

 

bar

{

public

:

   

void

 

f2

(

 

const

 

foo

&

 

a_foo

 

)

   

{

      

a_foo

.

f1

();

 // W porządku.

      

a_foo

.

f2

();

 // Błąd we wczesnej fazie kompilacji!

   

}

}

;

Listing 2. 

Wykrywanie błędów przy kompilacji szablonu 

klasy

class

 

foo

 

{

public

:

   

void

 

f1

()

 

const

;

}

;

template

<

 

class

 

Foo

 

>

class

 

bar

{

public

:

   

void

 

f2

(

 

const

 

Foo

&

 

a_foo

 

)

   

{

      

a_foo

.

f1

();

 // W porządku.

      

a_foo

.

f2

();

 // W porządku! Nie wiemy na tym etapie

                 

 // jakie składowe ma typ Foo...

   

}

   

void

 

f3

()

   

{

   

}

}

;

int

 

main

()

{

   

bar

<

 

foo

 

>

 

b

;

 // W porządku.

   

foo

 

f

;

   

b

.

f3

();

 // W porządku.

   

b

.

f2

(

 

f

 

);

 // Dopiero tutaj mamy błąd!

}

Listing 3. 

Drobny błąd

#include 

<algorithm>

#include 

<list>

int

 

main

()

{

   

std

::

list

<

int

>

 

l

;

   

std

::

sort

(

l

.

begin

()

, 

l

.

end

());

  

 // ...

}

Koncepcje w C++

41

www.sdjournal.org

Software Developer’s Journal   05/2007

Listing 4. 

VC++: komunikat o błędzie

C

:

\

Program

 

Files

\

Microsoft

 

Visual

 

Studio

 .

NET

 2003\

Vc7

\

include

\

list

(

898

)

 

:

 

while

 

compiling

 

class

-

template

 

member

 

function

 '

std

:

:

list

<

_Ty

>::

_Nodeptr

 

std

::

list

<

_Ty

>::

_Buynode

(

void

)

'

  

with

  

[

      

_Ty

=

int

  

]

  

Test

.

cpp

(

6

)

 

:

 

see

 

reference

 

to

 

class

 

template

 

instantiation

 '

std

::

list

<

_Ty

>

' 

being

 

compiled

  

with

  

[

      

_Ty

=

int

  

]

C

:

\

Program

 

Files

\

Microsoft

 

Visual

 

Studio

 .

NET

 2003\

Vc7

\

include

\

xstring

(

1453

)

 

:

 

warning

 

C4530

:

 

C

++

 

exception

 

handler

 

used

, 

but

 

unwind

 

semantics

 

are

 

not

 

enabled

. 

Specify

 /

EHsc

  

C

:

\

Program

 

Files

\

Microsoft

 

Visual

 

Studio

 .

NET

 2003\

Vc7

\

include

\

xstring

(

1444

)

 

:

 

while

 

compiling

 

class

-

template

 

member

 

function

 '

void

 

std

::

basic_string

<

_

Elem

,

_Traits

,

_Ax

>::

_Copy

(

std

::

basic_string

<

_Elem

,

_Traits

,

_Ax

>::

size_type

,

std

::

basic_string

<

_Elem

,

_

Traits

,

_Ax

>::

size_type

)

'

  

with

  

[

      

_Elem

=

char

,

      

_Traits

=

std

::

char_traits

<

char

>

,

      

_Ax

=

std

::

allocator

<

char

>

  

]

  

C

:

\

Program

 

Files

\

Microsoft

 

Visual

 

Studio

 .

NET

 2003\

Vc7

\

include

\

stdexcept

(

39

)

 

:

 

see

 

reference

 

to

 

class

 

template

 

instantiation

 '

std

:

:

basic_string

<

_Elem

,

_Traits

,

_Ax

>

' 

being

 

compiled

  

with

  

[

      

_Elem

=

char

,

      

_Traits

=

std

::

char_traits

<

char

>

,

      

_Ax

=

std

::

allocator

<

char

>

  

]

C

:

\

Program

 

Files

\

Microsoft

 

Visual

 

Studio

 .

NET

 2003\

Vc7

\

include

\

algorithm

(

1795

)

 

:

 

error

 

C2784

:

 '

reverse_iterator

<

_RanIt

>::

difference_type

 

std

::

operator

 

-(

const

 

std

::

reverse_iterator

<

_RanIt

>

 

&

,

const

 

std

::

reverse_iterator

<

_RanIt

>

 

&)

' 

:

 

could

 

not

 

deduce

 

template

 

argument

 

for

 '

const

 

std

::

reverse_iterator

<

_

RanIt

>

 

&

' 

from

 '

std

::

list

<

_Ty

>::

iterator

'

  

with

  

[

      

_Ty

=

int

  

]

  

C

:

\

Program

 

Files

\

Microsoft

 

Visual

 

Studio

 .

NET

 2003\

Vc7

\

include

\

xutility

(

634

)

 

:

 

see

 

declaration

 

of

 '

std

::

operator

`

-

''

  

Test

.

cpp

(

7

)

 

:

 

see

 

reference

 

to

 

function

 

template

 

instantiation

 '

void

 

std

::

sort

<

std

::

list

<

_Ty

>::

iterator

>(

_RanIt

,

_RanIt

)

' 

being

 

compiled

  

with

  

[

      

_Ty

=

int

,

      

_RanIt

=

std

::

list

<

int

>::

iterator

  

]

C

:

\

Program

 

Files

\

Microsoft

 

Visual

 

Studio

 .

NET

 2003\

Vc7

\

include

\

algorithm

(

1795

)

 

:

 

error

 

C2784

:

 '

reverse_iterator

<

_RanIt

>::

difference_type

 

std

::

operator

 

-(

const

 

std

::

reverse_iterator

<

_RanIt

>

 

&

,

const

 

std

::

reverse_iterator

<

_RanIt

>

 

&)

' 

:

 

could

 

not

 

deduce

 

template

 

argument

 

for

 '

const

 

std

::

reverse_iterator

<

_

RanIt

>

 

&

' 

from

 '

std

::

list

<

_Ty

>::

iterator

'

  

with

  

[

      

_Ty

=

int

  

]

  

C

:

\

Program

 

Files

\

Microsoft

 

Visual

 

Studio

 .

NET

 2003\

Vc7

\

include

\

xutility

(

634

)

 

:

 

see

 

declaration

 

of

 '

std

::

operator

`

-

''

C

:

\

Program

 

Files

\

Microsoft

 

Visual

 

Studio

 .

NET

 2003\

Vc7

\

include

\

algorithm

(

1795

)

 

:

 

error

 

C2784

:

 '

reverse_iterator

<

_RanIt

>::

difference_type

 

std

::

operator

 

-(

const

 

std

::

reverse_iterator

<

_RanIt

>

 

&

,

const

 

std

::

reverse_iterator

<

_RanIt

>

 

&)

' 

:

 

could

 

not

 

deduce

 

template

 

argument

 

for

 '

const

 

std

::

reverse_iterator

<

_

RanIt

>

 

&

' 

from

 '

std

::

list

<

_Ty

>::

iterator

'

  

with

  

[

      

_Ty

=

int

  

]

  

C

:

\

Program

 

Files

\

Microsoft

 

Visual

 

Studio

 .

NET

 2003\

Vc7

\

include

\

xutility

(

634

)

 

:

 

see

 

declaration

 

of

 '

std

::

operator

`

-

''

C

:

\

Program

 

Files

\

Microsoft

 

Visual

 

Studio

 .

NET

 2003\

Vc7

\

include

\

algorithm

(

1795

)

 

:

 

error

 

C2784

:

 '

reverse_iterator

<

_RanIt

>::

difference_type

 

std

::

operator

 

-(

const

 

std

::

reverse_iterator

<

_RanIt

>

 

&

,

const

 

std

::

reverse_iterator

<

_RanIt

>

 

&)

' 

:

 

could

 

not

 

deduce

 

template

 

argument

 

for

 '

const

 

std

::

reverse_iterator

<

_

42

Inżynieria

oprogramowania

www.sdjournal.org

 Software Developer’s Journal   05/2007

Listing 5. 

g++: komunikat o błędzie

Test

.

cpp

:

8

:

2

:

 

warning

:

 

no

 

newline

 

at

 

end

 

of

 

file

/

usr

/

lib

/

gcc

/

i686

-

pc

-

cygwin

/3.4.4/

include

/

c

++

/

bits

/

stl_algo

.

h

:

 

In

 

function

 `

void

 

std

::

sort

(

_RandomAccessIterator

, 

_

RandomAccessIterator

)

 

[

with

 

_RandomAccessIterator

 

=

 

std

::

_List_iterator

<

int

>]

'

:

Test

.

cpp

:

7

:

   

instantiated

 

from

 

here

/

usr

/

lib

/

gcc

/

i686

-

pc

-

cygwin

/3.4.4/

include

/

c

++

/

bits

/

stl_algo

.

h

:

2553

:

 

error

:

 

no

 

match

 

for

 '

operator

-

' 

in

 '

__last

 

-

 

__first

'

/

usr

/

lib

/

gcc

/

i686

-

pc

-

cygwin

/3.4.4/

include

/

c

++

/

bits

/

stl_algo

.

h

:

 

In

 

function

 `

void

 

std

::

__final_insertion_sort

(

_

RandomAccessIterator

, 

_RandomAccessIterator

)

 

[

with

 

_RandomAccessIterator

 

=

 

std

::

_List_iter

ator

<

int

>]

'

:

/

usr

/

lib

/

gcc

/

i686

-

pc

-

cygwin

/3.4.4/

include

/

c

++

/

bits

/

stl_algo

.

h

:

2554

:

   

instantiated

 

from

 `

void

 

std

::

sort

(

_RandomAccessIterator

, 

_RandomAccessIterator

)

 

[

with

 

_RandomAccessIterator

 

=

 

std

::

_List_iterator

<

int

>]

'

Test

.

cpp

:

7

:

   

instantiated

 

from

 

here

/

usr

/

lib

/

gcc

/

i686

-

pc

-

cygwin

/3.4.4/

include

/

c

++

/

bits

/

stl_algo

.

h

:

2197

:

 

error

:

 

no

 

match

 

for

 '

operator

-

' 

in

 '

__last

 

-

 

__first

'

/

usr

/

lib

/

gcc

/

i686

-

pc

-

cygwin

/3.4.4/

include

/

c

++

/

bits

/

stl_algo

.

h

:

2199

:

 

error

:

 

no

 

match

 

for

 '

operator

+

' 

in

 '

__first

 

+

  

_S_threshold

'

/

usr

/

lib

/

gcc

/

i686

-

pc

-

cygwin

/3.4.4/

include

/

c

++

/

bits

/

stl_algo

.

h

:

2200

:

 

error

:

 

no

 

match

 

for

 '

operator

+

' 

in

 '

__first

 

+

  

_S_threshold

'

/

usr

/

lib

/

gcc

/

i686

-

pc

-

cygwin

/3.4.4/

include

/

c

++

/

bits

/

stl_algo

.

h

:

 

In

 

function

 `

void

 

std

::

__insertion_sort

(

_RandomAccessIterator

, 

_RandomAccessIterator

)

 

[

with

 

_RandomAccessIterator

 

=

 

std

::

_List_iterator

<

i

nt

>]

'

:

/

usr

/

lib

/

gcc

/

i686

-

pc

-

cygwin

/3.4.4/

include

/

c

++

/

bits

/

stl_algo

.

h

:

2203

:

   

instantiated

 

from

 `

void

 

std

::

__final_insertion_sort

(

_

RandomAccessIterator

, 

_RandomAccessIterator

)

 

[

with

 

_RandomAccessIterator

 

=

 

st

d

::

_List_iterator

<

int

>]

'

/

usr

/

lib

/

gcc

/

i686

-

pc

-

cygwin

/3.4.4/

include

/

c

++

/

bits

/

stl_algo

.

h

:

2554

:

   

instantiated

 

from

 `

void

 

std

::

sort

(

_RandomAccessIterator

, 

_RandomAccessIterator

)

 

[

with

 

_RandomAccessIterator

 

=

 

std

::

_List_iterator

<

int

>]

'

Test

.

cpp

:

7

:

   

instantiated

 

from

 

here

/

usr

/

lib

/

gcc

/

i686

-

pc

-

cygwin

/3.4.4/

include

/

c

++

/

bits

/

stl_algo

.

h

:

2113

:

 

error

:

 

no

 

match

 

for

 '

operator

+

' 

in

 '

__first

 

+

 1'

/

usr

/

lib

/

gcc

/

i686

-

pc

-

cygwin

/3.4.4/

include

/

c

++

/

bits

/

stl_algo

.

h

:

2203

:

   

instantiated

 

from

 `

void

 

std

::

__final_insertion_sort

(

_

RandomAccessIterator

, 

_RandomAccessIterator

)

 

[

with

 

_RandomAccessIterator

 

=

 

st

d

::

_List_iterator

<

int

>]

'

/

usr

/

lib

/

gcc

/

i686

-

pc

-

cygwin

/3.4.4/

include

/

c

++

/

bits

/

stl_algo

.

h

:

2554

:

   

instantiated

 

from

 `

void

 

std

::

sort

(

_RandomAccessIterator

, 

_RandomAccessIterator

)

 

[

with

 

_RandomAccessIterator

 

=

 

std

::

_List_iterator

<

int

>]

'

Test

.

cpp

:

7

:

   

instantiated

 

from

 

here

/

usr

/

lib

/

gcc

/

i686

-

pc

-

cygwin

/3.4.4/

include

/

c

++

/

bits

/

stl_algo

.

h

:

2119

:

 

error

:

 

no

 

match

 

for

 '

operator

+

' 

in

 '

__i

 

+

 1'

Listing 4 cd. 

VC++: komunikat o błędzie

RanIt

>

 

&

' 

from

 '

std

::

list

<

_Ty

>::

iterator

'

  

with

  

[

      

_Ty

=

int

  

]

  

C

:

\

Program

 

Files

\

Microsoft

 

Visual

 

Studio

 .

NET

 2003\

Vc7

\

include

\

xutility

(

634

)

 

:

 

see

 

declaration

 

of

 '

std

::

operator

`

-

''

C

:

\

Program

 

Files

\

Microsoft

 

Visual

 

Studio

 .

NET

 2003\

Vc7

\

include

\

algorithm

(

1795

)

 

:

 

error

 

C2676

:

 

binary

 '-' 

:

 '

std

::

list

<

_Ty

>:

:

iterator

' 

does

 

not

 

define

 

this

 

operator

 

or

 

a

 

conversion

 

to

 

a

 

type

 

acceptable

 

to

 

the

 

predefined

 

operator

  

with

  

[

      

_Ty

=

int

  

]

C

:

\

Program

 

Files

\

Microsoft

 

Visual

 

Studio

 .

NET

 2003\

Vc7

\

include

\

algorithm

(

1795

)

 

:

 

error

 

C2780

:

 '

void

 

std

::

_Sort

(

_RanIt

,

_

RanIt

,

_Diff

,

_Pr

)

' 

:

 

expects

 4 

arguments

 

-

 3 

provided

  

C

:

\

Program

 

Files

\

Microsoft

 

Visual

 

Studio

 .

NET

 2003\

Vc7

\

include

\

algorithm

(

1913

)

 

:

 

see

 

declaration

 

of

 '

std

::

_Sort

'

trywane już znacznie wcześniej – przy pracach nad pierw-

szą  odsłoną  standardu  C++.  Wtedy  jednak,  po  burzliwych 

dyskusjach, nie zdecydowano się na obranie tej drogi. Czy-

telników zainteresowanych aspektami historycznymi mecha-

nizmu koncepcji odsyłam do książki Projektowanie i rozwój 
języka C++ autorstwa Bjarne Stroustrupa. W kontekście sy-

tuacji  przedstawionej  na  Listingu  2,  korzystając  z  koncep-

cji, kompilator potrafiłby już na etapie odwołania się do sza-

43

Koncepcje w C++

www.sdjournal.org

Software Developer’s Journal   05/2007

blonu (w instrukcji 

bar< foo > b;

) stwierdzić, że coś jest nie 

tak.  Po  prostu  mógłby  porównać  model  typu  zdefiniowa-

ny w ramach zadanej koncepcji, co pozwoliłoby mu wykryć, 

że  zastosowany  typ  do  wspomnianej  koncepcji  nie  pasuje 

(w tym konkretnym przypadku brakuje składowej funkcji 

f2()

). 

W dalszej części artykułu pokażę, jak można tego rodzaju 

koncepcję zdefiniować. W tym miejscu warto jeszcze przy-

toczyć cele, jakie postawili sobie członkowie komitetu, pra-

cujący nad propozycją wspomnianego rozszerzenia języka: 

•   Koncepcje  powinny  przede  wszystkim  służyć  jako  me-

chanizm  ułatwiający  pisanie  generycznego  kodu;  cel 

ten  ma  być  uzyskany  poprzez  uproszczenie  szablonów 

i  uczynienie  ich  bezpieczniejszymi  (w  sensie  bezpie-
czeństwa typów). W rezultacie użytkownik nie musiałby 

stosować skomplikowanych sztuczek aby uzyskać pożą-

dane efekty.

•   Szablony  w  swojej  nowej  odsłonie  muszą  oferować  ten 

sam  poziom  wydajności  jak  szablony  klasyczne,  jako  że 

efektywność  jest  jedną  z  podstawowych  miar  sukcesu 

w przypadku generycznych bibliotek języka C++.

•   Mechanizm koncepcji powinien być przede wszystkim na-

stawiony na wsparcie paradygmatu programowania gene-

rycznego, dzięki czemu C++ będzie mógł nadal domino-

wać w tej dziedzinie.

•   Koncepcje  muszą  być  kompatybilne  wstecz,  tak  aby  ist-

niejące szablony mogłyby być bez problemu kompilowane 

przy pomocy nowych narzędzi.

W dalszej części artykułu pokażę, jak projektanci nowej odsło-

ny języka C++ zamierzają spełnić wszystkie te wymagania.

Koncepcje w praktyce: prosty przykład

Zanim  przejdę  do  omówienia  konkretnych  właściwości  języ-

ka  związanych  z  mechanizmem  koncepcji,  przedstawię  pro-

ste ich zastosowanie. Chciałbym w ten sposób uniknąć oma-

wiania  nowych  właściwości  języka  całkowicie  na  sucho. 

W  dalszej  części  artykułu  przedstawię  bardziej  zaawanso-

wane przykłady zastosowania koncepcji. Na razie zachęcam 

Czytelników do zapoznania się z Listingiem 6. Przedstawiłem 

tam prosty szablon funkcji.

Gdy przyjrzymy się implementacji wspomnianego szablo-

nu, to na pierwszy rzut oka widać, że możemy użyć go z każ-

dym typem, który ma zdefiniowany operator mniejszości 

(<)

 

zwracający wartość typu bool. Popatrzmy teraz na Listing 7. 

Umieściłem  tam  alternatywną  implementację  szablonu  min 

korzystającą z dobrodziejstw koncepcji.

W zasadzie szablon wygląda bardzo podobnie. Podstawo-

wa (i w zasadzie jedyna różnica) polega na tym, że zamiast 

słowa  kluczowego  typename  w  liście  parametrów  szablonu 

użyliśmy  identyfikatora 

LessThanComparable

.  Szybkie  spojrze-

nie na Listing 8 powinno rozwiać wszelkie wątpliwości co do 

tego identyfikatora.

W  ten  oto  sposób  zdefiniowaliśmy  naszą  pierwszą  kon-

cepcję. Przeanalizujmy kod przedstawiony na wspomnianym 

Listingu.  Definicja  koncepcji  przypomina  nieco  definicję  sza-

Listing 6. 

Szablon funkcji min

template

<

typename

 

T

>

const

 

T

&

 

min

(

const

 

T

&

 

x

, 

const

 

T

&

 

y

)

{

   

return

 

x

 

<

 

y

? 

x

 

:

 

y

;

}

Listing 7. 

Szablon funkcji min: wykorzystanie koncepcji 

LessThanComparable

template

<

 

LessThanComparable

 

T

 

>

const

 

T

&

 

min

(

 

const

 

T

&

 

x

, 

const

 

T

&

 

y

 

)

{

   

return

 

x

 

<

 

y

? 

x

 

:

 

y

;

}

Listing 8. 

Definicja koncepcji LessThanComparable.

concept

 

LessThanComparable

<

 

typename

 

T

 

>

{

   

bool

 

operator

<(

T

, 

T

);

}

;

Listing 9. 

Nowe podejście do starego problemu

concept

 

Fooable

 

{

   

void

 

f1

()

 

const

;

   

void

 

f2

()

 

const

;

 

}

;

class

 

foo

 

{

public

:

   

void

 

f1

()

 

const

;

}

;

template

<

 

Fooable

 

Foo

 

>

class

 

bar

{

public

:

   

void

 

f2

(

 

const

 

Foo

&

 

a_foo

 

)

   

{

      

a_foo

.

f1

();

 // W porządku.

      

a_foo

.

f2

();

 // Błąd będzie wyłapany właśnie 

                  // na tym etapie!

   

}

   

void

 

f3

()

   

{

   

}

}

;

int

 

main

()

{

   

bar

<

 

foo

 

>

 

b

;

 // Błąd: kompilator zauważy, że

          

 // klasa foo nie pasuje do koncepcji

          

 // Fooable.

}

44

Inżynieria

oprogramowania

www.sdjournal.org

 Software Developer’s Journal   05/2007

blonu klasy. W oczy rzuca się od razu lista parametrów i de-

klaracja  operatora.  Przedstawiona  koncepcja  reprezentuje 

dokładnie to, o co nam chodziło: dowolny typ, którego obiek-

ty  można  porównywać  przy  pomocy  operatora  mniejszości. 

Spójrzmy teraz na Listing 9. Pokazałem tam jak można przy 

pomocy koncepcji rozwiać problem przedstawiony wcześniej 

na Listingu 2.

Koncepcje, a nowe właściwości języka

Teraz,  gdy  znamy  już  ogólną  koncepcję  mechanizmu  kon-

cepcji,  możemy  bezpiecznie  przejść  do  pełniejszego  omó-

wienia  powiązanych  z  nim  właściwości  języka  C++.  A  jest 

o czym dyskutować. Aby zdać sobie sprawę ze złożoności 

idei koncepcji, warto zastanowić się nad pytaniem: co mo-

że  być  parametrem  szablonu.  Odpowiedź  jest  prosta  i  za-

wiera  się  w  dwóch  słowach:  każdy  typ  –  włącznie  z  typa-

mi definiowanymi przez użytkownika, czy nawet innymi sza-

blonami. Do przekazywania tych ostatnich dedykowana jest 

nawet specjalna składnia w postaci szablonowych parame-

trów  szablonu  (ang.  template  template  parameters).  Teraz 

wyobraźmy sobie jak złożony musi być mechanizm języka, 

którego zadaniem jest definiowanie ograniczeń na dowolne 

typy (np. gdyby ktoś chciał napisać szablon, który jako pa-

rametr przyjmuje inny szablon, zawierający składową klasę 

o określonych metodach). Odpowiedź nasuwa się automa-

tycznie – mechanizm taki będzie cechował się podobną zło-

żonością jak jego odpowiednik służący do definiowania ty-

pów.  I  tak  jest  w  istocie.  Składnia  koncepcji  w  języku  C++ 

opiera się na pięciu nowych słowach kluczowych: concept, 
concept_map,  where,  axiom,  oraz  late_check.  Pierwsze 

z  wymienionych  słów  kluczowych  poznaliśmy  już  w  po-

przednim  punkcie  niniejszego  artykułu.  Słowo  to  służy  do 

definicji  koncepcji:  definicji  ograniczenia  nakładanego  na 

typ  w  postaci  listy  deklaracji  wymaganych  składników.  Na 

Listingu 10 przedstawiona jest przykładowa, nieco bardziej 

rozbudowana koncepcja.

Koncepcja  ta  opisuje  rodzinę  typów  regularnych  –  czy-

li takich, które możemy konstruować bez parametrów, nisz-

czyć, kopiować i porównywać. Przedstawiona koncepcja po-

siada tylko jeden parametr. Nic nie stoi jednak na przeszko-

dzie, aby stworzyć koncepcję obsługującą klika parametrów 

jednocześnie, np.:

auto concept Convertible< typename T, typename U >
{
   operator U( const T& );
};

Koncepcja ta określa ograniczenie zakładające, że typ 

T

 mo-

że być automatycznie konwertowany do typu 

U

. Aby użyć tej 

koncepcji musimy skorzystać ze specjalnej formy nakładania 

ograniczenia na szablon w postaci klauzuli 

where

. Na Listingu 

11 przedstawiłem prosty szablon korzystający ze wspomnia-

nej koncepcji.

Koncepcje posiadające wielokrotne argumenty w połącze-

niu z klauzulą 

where

, która pozwala nakładać dodatkowe ogra-

niczenia na te argumenty, są potężnym narzędziem do nakła-

dania  ograniczeń  na  typy.  Wyobraźmy  sobie,  że  budujemy 

szablon  klasy,  który  jako  parametry  będzie  przyjmował  dwa 

Listing 11. 

Szablon wykorzystujący koncepcję

template

<

 

typename

 

U

, 

typename

 

T

 

>

where

 

Convertible

<

 

T

, 

U

 

>

U

 

convert

(

 

const

 

T

&

 

t

 

)

{

   

return

 

t

;

}

Listing 12. 

Zastosowanie klauzuli where

template

<

 

typename

 

T1

, 

typename

 

T2

 

>

where

 

Regular

<

 

T1

 

>

 

&&

    

Convertible

<

 

T1

, 

T2

 

>

 

&&

    

Convertible

<

 

T2

, 

T1

 

>

class

 

my_class

{

  

 // ...

}

;

Listing 13. 

Dziedziczenie i agregacja koncepcji

concept

 

InputIterator

<

 

typename

 

Iter

, 

typename

 

Value

 

>

{

   

typename

 

value_type

;

   

typename

 

reference

;

   

typename

 

pointer

;

   

typename

 

difference_type

;

   

where

 

Regular

<

Iter

>;

 // agregacja koncepcji

   

where

 

Convertible

<

reference

 

type

, 

value_type

>;

   

Value

 

operator

*(

const

 

Iter

&);

 // dereferencja

   

Iter

&

 

operator

++(

Iter

&);

    

 // pre-inkrementacja

   

Iter

 

operator

++(

Iter

&

, 

int

);

 // post-inkrementacja

}

;

concept

 

ForwardIterator

<

 

typename

 

Iter

, 

typename

 

Value

 

>

   

:

 

InputIterator

<

Iter

, 

Value

>

 // dziedziczenie koncepcji

{

  

 // Iterator sekwencyjny jest w sensie syntaktycznym

  

 // identyczny jak operator wejścia.

}

;

Listing 10. 

Nieco bardziej rozbudowana koncepcja

auto

 

concept

 

Regular

<

 

typename

 

T

 

>

{

   

T

::

T

();

 // domyślny konstruktor

   

T

::

T

(

 

const

 

T

&

 

);

 // konstruktor kopiujący

   

T

::

~

T

();

 // destruktor

   

T

&

 

operator

=(

 

T

&

, 

const

 

T

&

 

);

 // operator przypisania

   

bool

 

operator

==(

 

const

 

T

&

, 

const

 

T

&

 

);

 // operator 

równości

   

bool

 

operator

!=(

 

const

 

T

&

, 

const

 

T

&

 

);

 // operator 

nierówności

   

void

 

swap

(

 

T

&

, 

T

&

 

);

 // zamiana

}

;

45

Koncepcje w C++

www.sdjournal.org

Software Developer’s Journal   05/2007

typy, przy czym typu te muszą dać się w obie strony konwer-

tować, zaś pierwszy typ powinien być regularny. Ograniczenie 

tego rodzaju możemy zrealizować stosując kod przedstawio-

ny na Listingu 12.

Proste, nieprawdaż? We wspomnianym przykładzie warto 

zwrócić uwagę na sposób łączenia kilku ograniczeń w klauzuli 

where przy pomocy operatora iloczynu logicznego 

&&

. W cie-

le  klauzuli  możemy  stosować  również  operator  logicznej  su-

my (

||

) i negacji (

!

). Co ciekawe, ten sam rodzaj klauzuli można 

używać do nakładania ograniczeń na parametry innych kon-

cepcji. Patrząc na przedstawione powyżej przykłady jasno wi-

dać, że korzystanie z omawianego mechanizmu przypomina 

nieco modelowanie typów: z mniejszych koncepcji można bu-

dować większe i bardziej złożone. W tej sytuacji aż się prosi 

o odpowiednik mechanizmów agregacji i dziedziczenia typów. 

Projektanci koncepcji pomyśleli i o tym: koncepcje można za-

równo agregować jak i dziedziczyć. Proste przykład obydwu 

wspomnianych  technik,  wraz  z  odpowiednimi  komentarzami, 

przedstawiłem na Listingu 13.

Warto  zauważyć,  że  w  ciele  koncepcji  InputIterator 

umieszczone  są  dodatkowo  wymagania  odnośnie  powią-

zanych  typów,  które  powinny  być  zdefiniowane  w  szablonie 

spełniającym tą koncepcję.

Reasumując, koncepcje pozwalają w bezpośredni sposób 

określić  interfejs  typu,  który  ma  być  parametrem  szablonu. 

Jednakże nie zawsze ten rodzaj definicji da się zastosować. 

Spójrzmy na następujący fragment kodu:

char* p = new char[ 10 ];
// ... tu wypełniamy zawartość tablicy
char* found = std::find( p, p + 10, 'a' );
// ...

Traktujemy tutaj typ char* jako iterator przekazywany do stan-

dardowej funkcji 

std::find

. Zakładając, że wspomniana funkcja 

zaimplementowana jest w postaci szablonu ograniczonego za 

pomocą koncepcji, to na przekazywane do niej iteratory nało-

żone  są  odpowiednie  wymagania  (

InputIterator

).  Jeśli  spoj-

rzymy ponownie na Listing 13 to przekonamy się, iż koncep-

cja InputIterator żąda od docelowego typu posiadania typów 

zagnieżdżonych (np. 

value _ type

). No i w tym momencie po-

jawia się kłopot, gdyż typ char* takowych typów nie posiada. 

I  co  z  tym  fantem  zrobić?  W  C++98  problem  ten  można  by 

rozwiązać stosując tzw. cechy typów (ang. type traits); w świe-

cie koncepcji da się uzyskać bardziej eleganckie rozwiązanie. 

Pomogą nam w tym tzw. odwzorowania koncepcji (ang. con-
cept maps), które zaprojektowano właśnie po to, aby adapto-

wać  składnię  istniejących  typów  do  wymagań  określonych 

koncepcji, bez modyfikacji tych typów. Aby przekonać się jak 

to wygląda w praktyce, spójrzmy na Listing 14.

Pierwsze  z  dwóch  przedstawionych  tam  odwzorowań 

koncepcji  (definiowanych  przy  pomocy  słowa  kluczowego 

concept _ map

)  adaptuje  typ  char*  do  interfejsu  InputIterator. 

Listing 16. 

Przeciążone implementacje funkcji 

std::advance

template

<

 

InputIterator

 

Iter

 

>

void

 

advance

(

 

Iter

&

 

x

, 

Iter

::

difference

 

type

 

n

 

)

{

   

while

 

(

 

n

 

>

 0 

)

 

{

 

++

x

;

 

--

n

;

 

}

}

template

<

 

BidirectionalIterator

 

Iter

 

>

void

 

advance

(

 

Iter

&

 

x

, 

Iter

::

difference

 

type

 

n

 

)

{

   

if

 

(

n

 

>

 0

)

 

while

 

(

n

 

>

 0

)

 

{

 

++

x

;

 

--

n

;

 

}

   

else

 

while

 

(

n

 

<

 0

)

 

{

 

--

x

;

 

++

n

;

 

}

}

template

<

 

RandomAccessIterator

 

Iter

 

>

void

 

advance

(

 

Iter

&

 

x

, 

Iter

::

difference

 

type

 

n

 

)

{

   

x

 

+=

 

n

;

}

Listing 14. 

Proste odwzorowania koncepcji

concept_map

 

InputIterator

<

 

char

*

 

>

{

   

typedef

 

char

 

value

 

type

;

   

typedef

 

char

&

 

reference

;

   

typedef

 

char

*

 

pointer

;

   

typedef

 

std

::

ptrdiff_t

 

difference_type

;

}

;

concept_map

 

InputIterator

<

 

int

 

>

{

   

typedef

 

int

 

value

 

type

;

   

typedef

 

int

 

reference

;

   

typedef

 

int

*

 

pointer

;

   

typedef

 

int

 

difference

 

type

;

   

int

 

operator

*(

int

 

x

)

 

{

 

return

 

x

;

 

}

}

;

Listing 15. 

Koncepcja stosu i odwzorowanie adaptujące

concept

 

Stack

<

 

typename

 

X

 

>

{

   

typename

 

value

 

type

;

   

void

 

push

(

X

&

, 

const

 

value

 

type

&);

   

void

 

pop

(

X

&);

   

value

 

type

 

top

(

const

 

X

&);

   

bool

 

empty

(

const

 

X

&);

}

;

template

<

 

typename

 

T

 

>

concept

 

map

 

Stack

<

 

std

::

vector

<

 

T

 

>

 

>

{

   

typedef

 

T

 

value

 

type

;

   

void

 

push

(

 

std

::

vector

<

 

T

 

>&

 

v

, 

const

 

T

&

 

x

 

)

 

{

 

v

.

push_

back

(

x

);

 

}

   

void

 

pop

(

 

std

::

vector

<

 

T

 

>&

 

v

 

)

 

{

 

v

. 

pop_back

();

 

}

   

T

 

top

(

 

const

 

std

::

vector

<

 

T

 

>&

 

v

 

)

 

{

 

return

 

v

.

back

();

 

}

   

bool

 

empty

(

 

const

 

std

::

vector

<

 

T

 

>&

 

v

 

)

 

{

 

return

 

v

.

empty

();

 

}

}

;

46

Inżynieria

oprogramowania

www.sdjournal.org

 Software Developer’s Journal   05/2007

Listing 17. 

Koncepcje iteratorów z biblioteki standardowej języka C++

W tym przypadku w odwzorowaniu umieszczono jedynie od-

powiednie  definicje  typów;  reszta  wymaganych  operacji  jest 

dostępna  jako  część  syntaktyki  typów  wskaźnikowych  wbu-

dowanej w język C++. Ciekawostkę stanowi druga część Li-

stingu, gdzie do koncepcji InputIterator adaptowany jest nie-

wskaźnikowy typ int. Aby wymaganiom wspomnianej koncep-

cji  stało  się  zadość,  to  oprócz  zapewnienia  definicji  typów, 

trzeba jeszcze zdefiniować operator dereferencji. W rezultacie 

moglibyśmy napisać następujący kod:

std::copy( 1, 10, std::ostream_iterator< int >( std::cout, ” ” 

) );

przy czym na wyjściu otrzymalibyśmy sekwencję:
1 2 3 4 5 6 7 8 9 10

Odwzorowania koncepcji można zapisywać również w postaci 

szablonów. W rzeczywistości możliwość ta połączona ze sto-

sowaniem technik adaptacji składni, stanowi prawdziwą moc 

tej  konstrukcji.  Na  Listingu  15  przedstawiona  jest  koncepcja 

stosu  (struktury  danych)  oraz  odwzorowanie,  które  adaptu-

je do tej koncepcji kontener 

std::vector

. Prawda, że eleganc-

kie rozwiązanie? Rozważając temat koncepcji w odniesieniu do 

właściwości języka C++, należy zdać sobie sprawę, że szablo-

ny, które korzystają z omawianego mechanizmu, rządzą się tro-

chę innymi prawami niż szablony klasyczne. W rzeczywistości 

można wręcz mówić o nowym rodzaju szablonów (w terminolo-

gii anglojęzycznej określanych jako constrained templates). Sza-

blony te mogą zawierać odniesienia do koncepcji w ramach listy 

parametrów (Listing 7), bądź w ciele klauzuli where (Listing 11). 

Najważniejsza cecha nowych szablonów związana z faktem, iż 

sprawdzanie poprawności przekazanych do nich typów nastę-

puje bezpośrednio w momencie tworzenia instancji bazujących 

na nich obiektów. Regułę tę można obejść jedynie przy pomocy 

dedykowanego słowa kluczowego 

late _ check

. Koncepcje oka-

zują się również wielce przydatne w sytuacji przeciążania sza-

blonów funkcji, w odniesieniu do ich typów szablonowych oraz 

specjalizacji  szablonów  klas.  Na  Listingu  16  zaprezentowana 

jest  implementacja  standardowej  funkcji 

std::advance

  (przesu-

nięcie iteratora o n kroków do przodu), zrealizowana przy pomo-

cy przeciążenia bazującego na koncepcjach.

Jak widać, realizacja powyższego zadania w świecie kon-

cepcji staje się prosta niczym przeciążenie zwyczajnych funk-

cji na bazie ich parametrów. Aby uzyskać podobne rozwiąza-

nie w C++98 trzeba by zastosować mało eleganckie i niewy-

godne sztuczki programistyczne (np. idiom SFINAE lub wybór 

implementacji bazujący na tagach).

Koncepcje: konsekwencje

W poprzednim podpunkcie Czytelnicy mieli okazję zapoznać 

się  mechanizmem  koncepcji,  postrzeganym  przez  pryzmat 

nowych  właściwości  języka  C++.  W  przedstawionym  opisie 

starałem  się  wybrać  i  przedstawić  najbardziej  istotne  cechy 

rozwiązania i z tej racji pominąłem cały szereg specyficznych 

zagadnień  związanych  z  tematem  (chociażby  wyjaśnienie 

znaczenia  słowa  kluczowego  axiom).  Czytelników  zaintere-

sowanych poznaniem formalnej specyfikacji koncepcji zapra-

szam  do  ramki  W  Sieci,  gdzie  proponuję  cały  szereg  cieka-

wych  materiałów.  W  niniejszym  podpunkcie  chciałbym  prze-

analizować temat z innego punktu widzenia. Warto zastano-

wić się jakie konsekwencje pociągnie za sobą wprowadzenie 

mechanizmu koncepcji do języka C++.

Na  początek  rozważmy  w  jaki  sposób  koncepcje  wpłyną 

na kształt biblioteki standardowej. Przede wszystkim możemy 

spodziewać się nowego nagłówka: 

<concepts>

. Nagłówek ten 

Listing 18: 

ConceptGcc: komunikat o błędzie

sort_list

.

cpp

:

 

In

 

function

 ’

int

 

main

()

’

:

sort_list

.

cpp

:

8

:

 

error

:

 

no

 

matching

 

function

 

for

 

call

 

to

 ’

sort

(

std

::

_List_iterator

<

int

>

, 

std

::

_List_iterator

<

int

>)

’

.../

stl_algo

.

h

:

2835

:

 

note

:

 

candidates

 

are

:

 

void

 

std

::

sort

(

_Iter

, 

_Iter

)

 

[

with

 

_Iter

 

=

 

std

::

_List_iterator

<

int

>]

sort_list

.

cpp

:

8

:

 

note

:

 

no

 

concept

 

map

 

for

 

requirement

 ’

std

::

MutableRandomAccessIterator

<

std

::

_List_iterator

<

int

>

 

>

’

concept

 

InputIterator

<

typename

 

Iter

>

   

:

 

CopyConstructible

<

Iter

>

, 

EqualityComparable

<

Iter

>

, 

Assignable

<

Iter

>

{

   

typename

 

value

 

type

 

=

 

Iter

::

value

 

type

;

   

typename

 

reference

 

=

 

Iter

::

reference

;

   

typename

 

pointer

 

=

 

Iter

::

pointer

;

   

SignedIntegral

 

difference

 

type

 

=

 

Iter

::

difference

 

type

   

where

 

Arrowable

<

pointer

, 

value

 

type

>

 

&&

 

Convertible

<

reference

, 

value

 

type

>;

   

reference

 

operator

(

Iter

);

   

pointer

 

operator

!

 

(

Iter

);

   

Iter

&

 

operator

++(

Iter

&);

   

typename

 

postincrement

 

result

;

   

postincrement

 

result

 

operator

++(

Iter

&

, 

int

);

   

where

 

Dereferenceable

<

postincrement

 

result

, 

value

 

type

>;

}

;

concept

 

ForwardIterator

<

typename

 

Iter

>

co

:

 

InputIterator

<

Iter

>

, 

DefaultConstructible

<

Iter

>

{

   

where

 

Convertible

<

reference

, 

const

 

value

 

type

&>;

   

where

 

Convertible

<

pointer

, 

const

 

value

 

type

>;

}

;

concept

 

MutableForwardIterator

<

Iter

>

   

:

 

ForwardIterator

<

Iter

>

, 

OutputIterator

<

Iter

>

{

   

where

 

SameType

<

reference

, 

value

 

type

&>

 

&&

      

SameType

<

pointer

, 

value

 

type

>;

}

;

Koncepcje w C++

47

www.sdjournal.org

Software Developer’s Journal   05/2007

będzie zawierał definicje standardowych koncepcji, czyli zapi-

sane w języku C++ podstawowe wymagania odnośnie typów, 

zdefiniowane (zazwyczaj w postaci tabel) w standardzie języ-

ka. Można więc spodziewać się koncepcji takich jak: 

Assigna-

bl

e, 

DefaultConstructible

, 

LessThanComparable

, 

EqualityCom-

parable

  itd.  Niewątpliwym  wyzwaniem  dla  twórców  biblioteki 

standardowej będzie zaprojektowanie hierarchii koncepcji ite-

ratorów (na Listingu 17 przedstawiona jest jedna z możliwych 

prób implementacji części tej hierarchii). W tej sytuacji biblio-

teka STL będzie przepisana od nowa i istnieje duża szansa, 

że  doczekamy  się  bardziej  przyjaznych  komunikatów  o  błę-

dach. Mając w zanadrzu mechanizm koncepcji, będzie moż-

na  zaimplementować  też  algorytmy  działające  bezpośrednio 

na kolekcjach (a nie – tak jak dotychczas – jedynie ma parach 

iteratorów). Co ważne, standardowe koncepcje będą stanowi-

ły solidną bazę do tworzenia własnych bibliotek generycznych 

– prawdopodobnie zdecydowanie bardziej intuicyjnych i prze-

nośnych niż podobne rozwiązania tworzone w C++98.

Koncepcje niewątpliwie wpłyną też na pokrewne paradyg-

maty programistyczne. Przy projektowaniu klas na bazie stra-

tegii (ang. policy based class design), koncepcje będzie moż-

na  wykorzystać  do  definiowania  interfejsów.  Przy  tworzeniu 

rozwiązań  typu  DSEL,  techniki  metaprogramowania  oparte-

go na szablonach staną się znacznie prostsze i bardziej prze-

nośne – właśnie dzięki koncepcjom. Kto wie – może pojawią 

się nowe paradygmaty programowania bazujące na koncep-

cjach? Jedno już dziś pozostaje pewne: dysponując tym me-

chanizmem,  C++  będzie  w  stanie  jeszcze  bardziej  umocnić 

swoją  pozycję  głównego  języka  wspierającego  paradygmat 

programowania generycznego.

Na bezrybiu

Zdaję sobie sprawę, że wielu programistów C++ po przeczy-

taniu powyższych akapitów rozmarzy się: “ach, jak dobrze by-

łoby móc skorzystać z dobrodziejstw koncepcji już dziś.”. Tym-

czasem trzeba wracać do pracy z istniejącymi kompilatorami 

i bibliotekami, które, nawiasem mówiąc, zazwyczaj nie są na-

wet  w  pełni  kompatybilne  ze  specyfikacją  standardu  C++98. 

Dla  zmartwionych  takim  stanem  rzeczy  programistów  C++ 

mam dobrą wiadomość: koncepcje są dostępne już dziś. Oso-

bom zainteresowanym bezpośrednim zapoznaniem się z nową 

właściwością języka polecam otwarty kompilator ConceptGCC 

(patrz:  ramka  W  Sieci),  który  pozwala  eksperymentować 

z koncepcjami w ich pełnej postaci. Kompilator ten niestety nie 

do końca nadaje się do zastosowań komercyjnych (jego imple-

mentacja w momencie pisania niniejszego tekstu znajduje się 

ciągle w fazie Alpha). Fakt ten wynika w dużej mierze z nie-

stabilności specyfikacji koncepcji, nad którą ciągle prowadzo-

ne  są  intensywne  prace.  Do  celów  edukacyjnych  narzędzie 

to jest jednak całkowicie wystarczające. O jego jakości niech 

zaświadczy  komunikat  o  błędzie  wygenerowany  przy  próbie 

kompilacji  programu  pokazanego  na  Listingu  3.  Wspomnia-

ny komunikat można zobaczyć na Listingu 18. Proponuję aby 

Czytelnicy porównali sobie zawartość tego Listingu z komuni-

katami wygenerowanymi przez kompilatory VC++ czy g++.

Osoby, które chciałyby wdrożyć ideę koncepcji w produk-

cyjnych  rozwiązaniach  opartych  na  języku  C++98,  powin-

ny zapoznać się z biblioteką v  (BCCL). Biblioteka ta oferuje 

część  funkcjonalności  powiązanej  z  mechanizmem  koncep-

cji w postaci akceptowalnej przez istniejące kompilatory C++. 

Na Listingu 19 można zobaczyć, jak przy pomocy BCCL moż-

na wymusić proste ograniczenie dla typu przekazywanego ja-

ko parametr szablonu klasy. Oczywiście możliwości BCCL nie 

umywają  się  do  elastyczności  i  potęgi  koncepcji  dostępnych 

w postaci rozszerzenia języka, jednakże, jak mówi stare przy-

słowie: na bezrybiu i rak ryba.

Podsumowanie

W  powyższym  artykule  przedstawiłem  podstawowe  infor-

macje  na  temat  mechanizmu  koncepcji,  którego  dołączenie 

planuje się w nadchodzącej odsłonie standardu języka C++. 

Koncepcje, oferujące zbiór zaawansowanych konstrukcji po-

zwalających  modelować  ograniczenia  typów,  będących  pa-

rametrami  w  szablonach  klas  i  funkcji,  postrzegane  są  jako 

przyszłe remedium na bolączki związane ze złożonością no-

woczesnych bibliotek generycznych, pisanych w języku C++. 

Celem,  który  postawiłem  sobie  przy  pisaniu  niniejszego  ar-

tykułu  było  przedstawienie  mechanizmu  koncepcji  tak,  aby 

Czytelnik mógł łatwo zrozumieć ideę tego rozwiązania i jed-

nocześnie uświadomić sobie konsekwencje stosowania go w 

praktyce.  Kończąc,  chciałbym  podkreślić,  że  niniejszy  tekst 

oparty  jest  na  roboczej  specyfikacji  mechanizmu  koncepcji 

i z tej racji nie należy traktować go w kategoriach materiału 

referencyjnego. n

W Sieci

•   http://www.generic-programming.org/  –  dużo  ciekawych  infor-

macji na temat programowania generycznego i koncepcji,

•   http://www.generic-programming.org/software/ConceptGCC/ 

– strona domowa projektu ConceptGCC,

•   http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/

n2081.pdf – najświeższa specyfikacja mechanizmu koncepcji,

•   http://www.open-std.org/jtc1/sc22/wg21/ – strona domowa ko-

mitetu standaryzacyjnego języka C++,

•   http://www.boost.org/libs/concept_check/concept_check.htm 

– strona domowa biblioteki Boost Concept Check..

Listing 19. 

Proste zastosowanie biblioteki BCCL

template

 

<

class

 

T

>

struct

 

generic_library_class

{

   

BOOST_CLASS_REQUIRE

(

T

, 

boost

, 

EqualityComparableConcept

);

  

 // ...

}

;

class

 

foo

{

  

 //... 

}

;

int

 

main

()

{

   

generic_library_class

<

foo

>

 

glc

;

  

 // ...

   

return

 0

;

}