C ++ standart kütüphanesinden alıntı : bir eğitim ve el kitabı :

Şu anda şablonları kullanmanın tek taşınabilir yolu, bunları satır içi işlevler kullanarak başlık dosyalarına uygulamaktır.

Bu neden?

(Açıklama: başlık dosyaları tek taşınabilir çözüm değildir. Ancak en uygun taşınabilir çözümdür.)

Uyarı: Öyle değil , başlık dosyasına uygulanmasını koymak bu cevabın sonunda alternatif bir çözüm görmek için gerekli.

Her neyse, kodunuzun başarısız olmasının nedeni, bir şablonu başlatırken derleyicinin verilen şablon bağımsız değişkeniyle yeni bir sınıf oluşturmasıdır. Örneğin:

template<typename T>
struct Foo
{
    T bar;
    void doSomething(T param) {/* do stuff using T */}
};

// somewhere in a .cpp
Foo<int> f; 

Bu satırı okurken, derleyici FooIntaşağıdakilere eşdeğer olan yeni bir sınıf yaratacaktır (diyelim ki ):

struct FooInt
{
    int bar;
    void doSomething(int param) {/* do stuff using int */}
}

Sonuç olarak, derleyicinin, şablon argümanı ile (bu örnekte int) somutlaştırılması için yöntemlerin uygulanmasına erişimi olmalıdır . Bu uygulamalar başlıkta olmasaydı erişilemezlerdi ve bu nedenle derleyici şablonu başlatamazdı.

Bunun yaygın bir çözümü, şablon bildirimini bir başlık dosyasına yazmak, ardından sınıfı bir uygulama dosyasına (örneğin .tpp) uygulamak ve bu uygulama dosyasını başlığın sonuna dahil etmektir.

Foo.h

template <typename T>
struct Foo
{
    void doSomething(T param);
};

#include "Foo.tpp"

Foo.tpp

template <typename T>
void Foo<T>::doSomething(T param)
{
    //implementation
}

Bu şekilde, uygulama yine deklarasyondan ayrılır, ancak derleyici tarafından erişilebilir.

Alternatif çözüm

Başka bir çözüm, uygulamayı ayrı tutmak ve ihtiyacınız olan tüm şablon örneklerini açıkça somutlaştırmaktır:

Foo.h

// no implementation
template <typename T> struct Foo { ... };

foo.cpp

// implementation of Foo's methods

// explicit instantiations
template class Foo<int>;
template class Foo<float>;
// You will only be able to use Foo with int or float

Açıklamam yeterince açık değilse, bu konudaki C ++ Süper SSS'ye göz atabilirsiniz .

Burada çok doğru cevaplar, ama bunu eklemek istedim (bütünlük için):

Uygulama cpp dosyasının altında, şablonun kullanılacağı tüm türlerin açık bir örneğini yaparsanız, bağlayıcı bunları her zamanki gibi bulabilir.

Düzenleme: Açık şablon örneği örneği ekleme. Şablon tanımlandıktan ve tüm üye işlevler tanımlandıktan sonra kullanılır.

template class vector<int>;

Bu, sınıfı ve tüm üye işlevlerini (yalnızca) başlatır (ve böylece bağlayıcıya sunar). Benzer sözdizimi şablon işlevleri için de çalışır, bu nedenle üye olmayan operatör aşırı yüklemeleriniz varsa, bunlar için de aynı işlemi yapmanız gerekebilir.

Yukarıdaki örnek oldukça işe yaramaz çünkü vektör, üstbilgilerde tam olarak tanımlandığı için, ortak bir içerme dosyası (önceden derlenmiş üstbilgi?) Vektörü kullanan diğerextern template class vector<int> tüm (1000?) Dosyalarda örneklemesini engellemek için kullanırsa.

Bunun nedeni ayrı derleme gereksinimi ve şablonların örnekleme tarzı çok biçimlilik olmasıdır.

Bir açıklama için betona biraz daha yaklaşalım. Aşağıdaki dosyaları aldığımı söyle:

• foo.h
  • arayüzünü class MyClass<T>
• foo.cpp
  • uygulanmasını tanımlar class MyClass<T>
• bar.cpp
  • kullanımları MyClass<int>

Ayrı derleme , bar.cpp'den bağımsız olarak foo.cpp dosyasını derleyebilmem gerektiği anlamına gelir . Derleyici, her derleme birimindeki tüm analiz, optimizasyon ve kod oluşturma çalışmalarını tamamen bağımsız olarak yapar; tam program analizi yapmamız gerekmez. Tüm programı bir kerede işlemesi gereken sadece bağlayıcıdır ve bağlayıcının işi oldukça kolaydır.

bar.cpp bile derleme yaparken mevcut gerekmez foo.cpp , ama yine de bağlamak mümkün olmalıdır foo.o Zaten birlikte vardı bar.o yeniden derleme gerek kalmadan, az önce üretilen ettik foo .cpp . foo.cpp , dinamik bir kütüphaneye bile derlenebilir, foo.cpp olmadan başka bir yere dağıtılabilir ve foo.cpp yazdıktan yıllar sonra yazdıkları kodlarla bağlantılı olabilir .

"Örnekleme tarzı polimorfizm", şablonun MyClass<T>herhangi bir değeri için çalışabilecek kod için derlenebilecek genel bir sınıf olmadığı anlamına gelir T. Yani vb allocators ve kurucular, C ++ şablonları niyeti yazmak zorunda kalmamak için işlev işaretçileri geçmesi gerek, boks gibi havai böyle eklersiniz neredeyse özdeş class MyClass_int, class MyClass_floatvb ama hala derlenmiş kod ile bitirmek muktedir çoğunlukla sanki biz vardı ayrı ayrı versiyonunu yazılı. Yani bir şablon tam anlamıyla bir şablondur; sınıf şablonu bir sınıf değildir , Tkarşılaştığımız her biri için yeni bir sınıf oluşturmak için bir reçetedir . Bir şablon kodda derlenemez, sadece şablonun başlatılmasının sonucu derlenebilir.

Yani foo.cpp derlendiğinde, derleyici bunun gerekli olduğunu bilmek için bar.cpp dosyasını göremezMyClass<int> . Şablonu görebilir MyClass<T>, ancak bunun için kod yayınlayamaz (bir şablon değil, bir sınıftır). Ve bar.cpp derlendiğinde, derleyici bir oluşturması gerektiğini görebilir MyClass<int>, ancak şablonu göremez MyClass<T>(yalnızca foo.h içindeki arayüzü ).

Eğer foo.cpp kendisi kullanıyorsa MyClass<int>, o zaman kod foo.cpp derlenirken üretilecektir , bu yüzden bar.o foo.o ile bağlantı kurduğunda bağlanabilir ve çalışacaktır. Bu gerçeği, tek bir şablon yazarak .cpp dosyasında sonlu bir şablon örneği kümesinin uygulanmasına izin vermek için kullanabiliriz. Ancak bar.cpp'in şablonu şablon olarak kullanmasının ve sevdiği türlere örnek oluşturmasının bir yolu yoktur ; yalnızca foo.cpp yazarının sağlamayı düşündüğü şablonlu sınıfın önceden var olan sürümlerini kullanabilir .

Bir şablonu derlerken derleyicinin "tüm sürümleri oluşturması" gerektiğini ve bağlantıda hiç kullanılmamış olanların filtrelenmesi gerektiğini düşünebilirsiniz. İşaretçi ve diziler gibi "tip değiştirici" özellikleri sadece yerleşik tiplerin bile sonsuz sayıda türe yol açmasına izin verdiğinden, bu tür bir yaklaşımın karşı karşıya olduğu devasa zorluklar ve aşırı zorlukların yanı sıra, şimdi programımı genişlettiğimde ne olacak toplayarak:

• baz.cpp
  • beyan ve uygular class BazPrivateve kullanırMyClass<BazPrivate>

Ya biz

1. Yeni bir roman örneği eklenmesi durumunda , programdaki başka bir dosyayı her değiştirdiğimizde foo.cpp'yi yeniden derlemeliyizMyClass<T>
2. Gerektir baz.cpp (başlık, muhtemelen ile) içeren tam bir şablonu MyClass<T>derleyici üretebilir, böylece, MyClass<BazPrivate>derlenmesi esnasında baz.cpp .

Kimse (1) 'i sevmez, çünkü tüm program analizi derleme sistemleri derlenmeyi sonsuza dek alır ve derlenmiş kitaplıkların kaynak kodu olmadan dağıtılmasını imkansız hale getirir. Onun yerine (2) var.

Şablonların gerçekte nesne koduna derlenmeden önce derleyici tarafından başlatılması gerekir . Bu örnekleme ancak şablon argümanları biliniyorsa elde edilebilir. Şimdi bir şablon işlevinin bildirildiği a.h, tanımlandığı a.cppve kullanıldığı bir senaryo düşünün b.cpp. Ne zaman a.cppderlenmiş, mutlaka yaklaşan derleme olduğu bilinmemektedir b.cpp, şablonun bir örneğini gerektirdiğini olacağını belirli örneği şöyle dursun edecektir. Daha fazla başlık ve kaynak dosyası için durum hızla daha karmaşık hale gelebilir.

Bir derleyici şablonun tüm kullanımları için "ileriye bakmak" için daha akıllı yapılabilir iddia edilebilir, ancak eminim özyinelemeli veya başka türlü karmaşık senaryolar oluşturmak zor olmayacaktır. AFAIK, derleyiciler böyle görünmüyor. Anton'un işaret ettiği gibi, bazı derleyiciler şablon örneklemelerinin açık ihracat bildirimlerini destekler, ancak tüm derleyiciler bunu desteklemez (henüz?).

Aslında C ++ 11 öncesinde standart tanımlı exportanahtar kelimeyi olur mümkün bir başlık dosyasına şablonları ilan etmek yapmak ve başka bir yerde bunları uygulamak.

Popüler derleyicilerden hiçbiri bu anahtar kelimeyi uygulamadı. Bildiğim tek kişi, Comeau C ++ derleyicisi tarafından kullanılan Edison Tasarım Grubu tarafından yazılmış ön uç. Tüm diğerleri, başlık dosyalarına şablon yazmanızı istedi, çünkü derleyicinin uygun örnekleme için şablon tanımına ihtiyacı var (diğerleri zaten belirtildiği gibi).

Sonuç olarak, ISO C ++ standart komitesi exportC ++ 11 ile şablonların özelliğini kaldırmaya karar verdi .

Standart C ++ 'ın böyle bir gereksinimi olmamasına rağmen, bazı derleyiciler tüm işlev ve sınıf şablonlarının kullanıldıkları her çeviri biriminde kullanılabilir olmasını gerektirir. Aslında, bu derleyiciler için şablon işlevlerinin gövdeleri bir başlık dosyasında kullanılabilir olmalıdır. Tekrarlamak gerekirse: bu derleyicilerin .cpp dosyaları gibi başlık dışı dosyalarda tanımlanmasına izin vermeyeceği anlamına gelir

Bu sorunu hafifletmesi beklenen bir dışa aktarma anahtar sözcüğü var, ancak taşınabilir olmaya yakın bir yerde değil.

Şablonlar başlıklarda kullanılmalıdır, çünkü derleyici şablon parametreleri için verilen / çıkarılan parametrelere bağlı olarak kodun farklı sürümlerini somutlaştırmalıdır. Bir şablonun kodu doğrudan temsil etmediğini, ancak bu kodun çeşitli sürümleri için bir şablon olduğunu unutmayın. .cppDosyada şablon olmayan bir işlev derlediğinizde, somut bir işlev / sınıf derlersiniz . Farklı türlerle somutlaştırılabilecek şablonlar için durum böyle değildir, yani şablon parametreleri somut türlerle değiştirilirken somut kod çıkarılmalıdır.

exportAnahtar kelimede ayrı derleme için kullanılması gereken bir özellik vardı . Bu exportözellik kullanımdan kaldırılmıştır C++11ve AFAIK, yalnızca bir derleyici uygulamıştır. Kullanmamalısınız export. Ayrı derleme mümkün değildir C++ya C++11ama belki de C++17kavramlar bunu yaparsanız, bu ayrı derleme bir yol olabilir.

Ayrı bir derlemenin gerçekleştirilmesi için ayrı şablon gövdesi kontrolü mümkün olmalıdır. Kavramlarla bir çözüm mümkün görünüyor. Son zamanlarda standart komite toplantısında sunulan bu makaleye bir göz atın . Hala kullanıcı kodu şablon kodu için kod somutlaştırmak gerekir, çünkü bu tek gereklilik olduğunu düşünüyorum.

Şablonlar için ayrı derleme sorunu Sanırım şu anda çalışmakta olan modüllere geçiş ile ilgili bir sorun.

Bu, şablon sınıflarının yöntem uygulamalarını tanımlamanın en taşınabilir yolunun bunları şablon sınıfı tanımının içinde tanımlamak olduğu anlamına gelir.

template < typename ... >
class MyClass
{

    int myMethod()
    {
       // Not just declaration. Add method implementation here
    }
};

Yukarıda birçok iyi açıklama olmasına rağmen, şablonları başlık ve gövdeye ayırmanın pratik bir yolunu kaçırıyorum.
Ana kaygım, tanımını değiştirdiğimde tüm şablon kullanıcılarının yeniden derlenmesinden kaçınmak.
Şablon gövdesindeki tüm şablon örneklerine sahip olmak benim için uygun bir çözüm değildir, çünkü şablon yazarı kullanımının ve şablon kullanıcısının bunu değiştirme hakkına sahip olup olmadığını bilmeyebilir.
Daha eski derleyiciler için de geçerli olan aşağıdaki yaklaşımı kullandım (gcc 4.3.4, aCC A.03.13).

Her şablon kullanımı için kendi başlık dosyasında (UML modelinden oluşturulan) bir typedef vardır. Gövdesi, (sonunda bağlanmış bir kütüphanede sonuçlanan) örneklemeyi içerir.
Şablonun her kullanıcısı bu başlık dosyasını içerir ve typedef kullanır.

Şematik bir örnek:

MyTemplate.h:

#ifndef MyTemplate_h
#define MyTemplate_h 1

template <class T>
class MyTemplate
{
public:
  MyTemplate(const T& rt);
  void dump();
  T t;
};

#endif

MyTemplate.cpp:

#include "MyTemplate.h"
#include <iostream>

template <class T>
MyTemplate<T>::MyTemplate(const T& rt)
: t(rt)
{
}

template <class T>
void MyTemplate<T>::dump()
{
  cerr << t << endl;
}

MyInstantiatedTemplate.h:

#ifndef MyInstantiatedTemplate_h
#define MyInstantiatedTemplate_h 1
#include "MyTemplate.h"

typedef MyTemplate< int > MyInstantiatedTemplate;

#endif

MyInstantiatedTemplate.cpp:

#include "MyTemplate.cpp"

template class MyTemplate< int >;

main.cpp:

#include "MyInstantiatedTemplate.h"

int main()
{
  MyInstantiatedTemplate m(100);
  m.dump();
  return 0;
}

Bu şekilde, tüm şablon kullanıcılarının (ve bağımlılıkların) değil, yalnızca şablon örneklerinin yeniden derlenmesi gerekir.

Burada kayda değer bir şey eklemek için. Bir şablon şablonu, işlev şablonları olmadığında uygulama dosyasında gayet iyi tanımlanabilir.

myQueue.hpp:

template <class T> 
class QueueA {
    int size;
    ...
public:
    template <class T> T dequeue() {
       // implementation here
    }

    bool isEmpty();

    ...
}    

myQueue.cpp:

// implementation of regular methods goes like this:
template <class T> bool QueueA<T>::isEmpty() {
    return this->size == 0;
}


main()
{
    QueueA<char> Q;

    ...
}

Endişe, .hpp modüllerinin bir parçası olarak .h derlenerek üretilen ekstra derleme süresi ve ikili boyut şişmesi ise, birçok durumda yapabileceğiniz şablon şablonu arabirimin türe bağlı olmayan bölümleri ve bu temel sınıfın .cpp dosyasında uygulanması olabilir.

Bu tamamen doğru çünkü derleyici tahsis için ne tür olduğunu bilmek zorunda. Bu nedenle, şablon dosyaları, işlevler, numaralandırmalar, vb., Genel olarak veya bir kütüphanenin bir parçası (statik veya dinamik) yapılacaksa başlık dosyasında da uygulanmalıdır, çünkü başlık dosyaları c / cpp dosyalarının aksine derlenmez. vardır. Derleyici türün ne olduğunu bilmiyorsa derleyemez. .Net'te bunu yapabilir, çünkü tüm nesneler Object sınıfından türemiştir. Bu .Net değil.

Derleme adımı sırasında bir şablon kullandığınızda, derleyici her şablon örneği için kod oluşturur. Derleme ve bağlama işleminde .cpp dosyaları, main.cpp'nizde bulunan .h dosyalarının uygulama YET'i olmadığından, içinde referanslar veya tanımlanmamış semboller içeren saf nesneye veya makine koduna dönüştürülür. Bunlar, şablonunuz için bir uygulama tanımlayan başka bir nesne dosyasıyla bağlanmaya hazırdır ve bu nedenle tam bir a.out yürütülebilir dosyasına sahip olursunuz.

Ancak, tanımladığınız her şablon örneği için kod oluşturmak amacıyla şablonların derleme adımında işlenmesi gerektiğinden, üstbilgi dosyasından ayrı bir şablon derlemek işe yaramaz, çünkü bu nedenle her zaman el ele gider. her şablon örneğinin, kelimenin tam anlamıyla yepyeni bir sınıf olduğunu. Normal bir sınıfta .h ve .cpp'yi ayırabilirsiniz, çünkü .h bu sınıfın bir taslağıdır ve .cpp ham uygulamadır, böylece tüm uygulama dosyaları düzenli olarak derlenebilir ve bağlanabilir, ancak şablonlar kullanmak .h, sınıf, nesnenin bir şablonun nasıl görünmesi gerektiği biçimine bakmamalıdır .cpp dosyası bir sınıfın ham normal uygulaması değil, sadece bir sınıf için bir taslaktır, bu nedenle .h şablon dosyasının herhangi bir uygulaması '

Bu nedenle şablonlar hiçbir zaman ayrı ayrı derlenmez ve yalnızca başka bir kaynak dosyada somut bir somut örneğinizin olduğu her yerde derlenir. Ancak, somut somutlaştırmanın şablon dosyasının uygulanmasını bilmesi gerekir, çünkütypename T.hpp dosyasında somut bir tür kullanmak işi yapmayacaktır çünkü bağlantı için .cpp orada ne var, daha sonra bulamıyorum çünkü şablonları soyut ve derlenemez hatırlıyorum, bu yüzden zorla ne derlemek ve bağlantı bilmek biliyorum şimdi ve şimdi vermek için, ve şimdi uygulama kaynak dosyası içine bağlı alır. Temel olarak, bir şablon oluşturduğum anda tamamen yeni bir sınıf oluşturmam gerekiyor ve derleyiciye haber vermedikçe, sağladığım türü kullanırken bu sınıfın nasıl görünmesi gerektiğini bilmiyorsam bunu yapamam şablon uygulaması, böylece derleyici Tbenim türüm ile değiştirebilir ve derlenip bağlanmaya hazır somut bir sınıf oluşturabilir.

Özetle, şablonlar sınıfların nasıl görünmesi gerektiğine dair taslaklardır, sınıflar bir nesnenin nasıl görünmesi gerektiğine dair taslaklardır. Derleyicileri yalnızca somut türleri derlediğinden, başka bir deyişle, en azından C ++ 'daki şablonlar saf dil soyutlaması olduğundan, somut örneklemelerinden ayrı şablonları derleyemiyorum. Şablonları konuşmak için soyutlamalıyız ve bunları ele almaları için somut bir tür vererek şablon soyutlamasının normal bir sınıf dosyasına dönüşebilmesini ve normal olarak derlenebilmesini sağlarız. Şablon .h dosyasını ve şablon .cpp dosyasını ayırmak anlamsızdır. Bu .cpp ve .h'nin ayrılması yalnızca .cpp'in ayrı ayrı derlenebildiği ve şablonlarla ayrı ayrı bağlanabildiği bir yerdir, çünkü bunları ayrı olarak derleyemediğimiz için şablonlar bir soyutlamadır,

Anlam typename Tget derleme adımı sırasında bağlantı adım değil değiştirilir, bu yüzden bir şablonu Tderleyici için tamamen anlamsız somut bir değer türü olarak değiştirmeden derlemeye çalışırsam ve sonuç olarak nesne kodu oluşturulamaz çünkü ne Tolduğunu bilmek .

Template.cpp dosyasını kaydedecek ve diğer kaynaklarda bulduğunda türleri kapatacak bir tür işlevsellik oluşturmak teknik olarak mümkündür, standardın exportşablonları ayrı bir yere koymanıza izin verecek bir anahtar kelimeye sahip olduğunu düşünüyorum cpp dosyası ama pek çok derleyici aslında bunu uygulamak değil.

Sadece bir yan not, bir şablon sınıfı için uzmanlık yaparken, üstbilgiyi uygulamadan ayırabilirsiniz, çünkü tanım gereği bir uzmanlaşma, ayrı ayrı derlenip bağlanabilen somut bir tür için uzmanlaştığım anlamına gelir.

Ayrı bir uygulamaya sahip olmanın bir yolu aşağıdaki gibidir.

//inner_foo.h

template <typename T>
struct Foo
{
    void doSomething(T param);
};


//foo.tpp
#include "inner_foo.h"
template <typename T>
void Foo<T>::doSomething(T param)
{
    //implementation
}


//foo.h
#include <foo.tpp>

//main.cpp
#include <foo.h>

inner_foo için ileri bildirimler var. foo.tpp uygulaması vardır ve inner_foo.h; ve foo.h, foo.tpp'yi dahil etmek için yalnızca bir satıra sahip olacaktır.

Derleme zamanında, foo.h içeriği foo.tpp dosyasına kopyalanır ve daha sonra tüm dosya foo.h dosyasına kopyalanır ve ardından derlenir. Bu şekilde, herhangi bir sınırlama yoktur ve adlandırma, fazladan bir dosya karşılığında tutarlıdır.

Bunu yapmak için çünkü * .tpp sınıf ileri bildirimlerini görmüyor kod için statik çözümleyicileri kırmak. Herhangi bir IDE'de kod yazarken veya YouCompleteMe veya diğerlerini kullanırken bu can sıkıcı bir durumdur.

Şablon örneklemeleri için "cfront" ve "borland" modeli arasındaki dengeleri tartışan bu gcc sayfasına bakmanızı öneririm.

https://gcc.gnu.org/onlinedocs/gcc-4.6.4/gcc/Template-Instantiation.html

"Borland" modeli, yazarın önerdiği şeye karşılık gelir, tam şablon tanımını sağlar ve birçok kez derlenmesini sağlar.

Manuel ve otomatik şablon örneklemenin kullanımına ilişkin açık öneriler içerir. Örneğin, "-repo" seçeneği, somutlaştırılması gereken şablonları toplamak için kullanılabilir. Veya başka bir seçenek, el ile şablon başlatmayı zorlamak için "-fno-implicit-templates" kullanarak otomatik şablon örneklerini devre dışı bırakmaktır.

Deneyimlerime göre, her derleme birimi (şablon kitaplığı kullanarak) için başlatılan C ++ Standart Kitaplığı ve Boost şablonlarına güveniyorum. Büyük şablon sınıflarım için, ihtiyaç duyduğum türler için bir kez manuel şablon örneklemesi yapıyorum.

Bu benim yaklaşımım çünkü diğer programlarda kullanmak için bir şablon kütüphanesi değil, çalışan bir program sağlıyorum. Kitabın yazarı Josuttis, şablon kütüphanelerinde çok çalışıyor.

Hız konusunda gerçekten endişeliysem, Önceden Derlenmiş Üstbilgileri kullanarak keşfe çıkacağımı sanırım https://gcc.gnu.org/onlinedocs/gcc/Precompiled-Headers.html

bu da birçok derleyicide destek kazanıyor. Ancak, önceden derlenmiş başlıkların şablon başlık dosyalarıyla zor olacağını düşünüyorum.

Üstbilgi dosyalarına hem bildirimleri hem de tanımları yazmanın iyi bir fikir olmasının başka bir nedeni de okunabilirliktir. Utility.h dosyasında böyle bir şablon işlevi olduğunu varsayalım:

template <class T>
T min(T const& one, T const& theOther);

Ve Utility.cpp dosyasında:

#include "Utility.h"
template <class T>
T min(T const& one, T const& other)
{
    return one < other ? one : other;
}

Bu, buradaki her T sınıfının operatörden daha azını (<) uygulamasını gerektirir. "<" Karakterini uygulamayan iki sınıf örneğini karşılaştırdığınızda derleyici hatası verir.

Bu nedenle, şablon bildirimini ve tanımını ayırırsanız, derleyici size bunu söyleyecek olsa da, bu API'yi kendi sınıflarınızda kullanmak için bu şablonun giriş ve çıkışlarını görmek için yalnızca başlık dosyasını okuyamazsınız. hangi operatörün geçersiz kılınması gerektiği konusunda.

Şablon sınıfınızı aslında bir .cpp dosyası yerine bir .template dosyası içinde tanımlayabilirsiniz. Bunu sadece bir başlık dosyasında tanımlayabileceğinizi söyleyen kişi yanlıştır. Bu, c ++ 98'e kadar çalışan bir şeydir.

Derleyicinizin .template dosyanıza zekayı korumak için c ++ dosyası gibi davranmasını unutmayın.

Dinamik dizi sınıfı için bunun bir örneği.

#ifndef dynarray_h
#define dynarray_h

#include <iostream>

template <class T>
class DynArray{
    int capacity_;
    int size_;
    T* data;
public:
    explicit DynArray(int size = 0, int capacity=2);
    DynArray(const DynArray& d1);
    ~DynArray();
    T& operator[]( const int index);
    void operator=(const DynArray<T>& d1);
    int size();

    int capacity();
    void clear();

    void push_back(int n);

    void pop_back();
    T& at(const int n);
    T& back();
    T& front();
};

#include "dynarray.template" // this is how you get the header file

#endif

Şimdi içinizde .template dosyası işlevlerinizi normalde nasıl yapacağınızı tanımlarsınız.

template <class T>
DynArray<T>::DynArray(int size, int capacity){
    if (capacity >= size){
        this->size_ = size;
        this->capacity_ = capacity;
        data = new T[capacity];
    }
    //    for (int i = 0; i < size; ++i) {
    //        data[i] = 0;
    //    }
}

template <class T>
DynArray<T>::DynArray(const DynArray& d1){
    //clear();
    //delete [] data;
    std::cout << "copy" << std::endl;
    this->size_ = d1.size_;
    this->capacity_ = d1.capacity_;
    data = new T[capacity()];
    for(int i = 0; i < size(); ++i){
        data[i] = d1.data[i];
    }
}

template <class T>
DynArray<T>::~DynArray(){
    delete [] data;
}

template <class T>
T& DynArray<T>::operator[]( const int index){
    return at(index);
}

template <class T>
void DynArray<T>::operator=(const DynArray<T>& d1){
    if (this->size() > 0) {
        clear();
    }
    std::cout << "assign" << std::endl;
    this->size_ = d1.size_;
    this->capacity_ = d1.capacity_;
    data = new T[capacity()];
    for(int i = 0; i < size(); ++i){
        data[i] = d1.data[i];
    }

    //delete [] d1.data;
}

template <class T>
int DynArray<T>::size(){
    return size_;
}

template <class T>
int DynArray<T>::capacity(){
    return capacity_;
}

template <class T>
void DynArray<T>::clear(){
    for( int i = 0; i < size(); ++i){
        data[i] = 0;
    }
    size_ = 0;
    capacity_ = 2;
}

template <class T>
void DynArray<T>::push_back(int n){
    if (size() >= capacity()) {
        std::cout << "grow" << std::endl;
        //redo the array
        T* copy = new T[capacity_ + 40];
        for (int i = 0; i < size(); ++i) {
            copy[i] = data[i];
        }

        delete [] data;
        data = new T[ capacity_ * 2];
        for (int i = 0; i < capacity() * 2; ++i) {
            data[i] = copy[i];
        }
        delete [] copy;
        capacity_ *= 2;
    }
    data[size()] = n;
    ++size_;
}

template <class T>
void DynArray<T>::pop_back(){
    data[size()-1] = 0;
    --size_;
}

template <class T>
T& DynArray<T>::at(const int n){
    if (n >= size()) {
        throw std::runtime_error("invalid index");
    }
    return data[n];
}

template <class T>
T& DynArray<T>::back(){
    if (size() == 0) {
        throw std::runtime_error("vector is empty");
    }
    return data[size()-1];
}

template <class T>
T& DynArray<T>::front(){
    if (size() == 0) {
        throw std::runtime_error("vector is empty");
    }
    return data[0];
    }