Başlık cehennemini nasıl önleyebilirim?


44

Sıfırdan yeni bir projeye başlıyoruz. Her biri dört veya beş kaynak dosya içeren yaklaşık sekiz geliştirici, bir düzine kadar alt sistem.

“Cehennem başlığı”, AKA “spagetti başlıkları” nı önlemek için ne yapabiliriz?

  • Kaynak dosya başına bir başlık?
  • Artı alt sistem başına bir tane?
  • İşlev prototiplerinden ayrı typdefs, stucts & enums?
  • Alt sistem iç alt sistem dış öğesinden ayrı mı?
  • Her bir dosyanın başlığının veya kaynağının bağımsız bir şekilde derlenebilir olması gerekip gerekmediğini vurgulayın.

“En iyi” bir yol istemiyorum, sadece neye dikkat edilmesi gerektiğini ve neyin kedere neden olabileceğini göstererek, bundan kaçınmayı deneyebiliriz.

Bu bir C ++ projesi olacak, ancak C bilgisi gelecekteki okuyuculara yardımcı olacaktır.


16
Büyük Ölçekli C ++ Yazılım Tasarımı'nın bir kopyasını alın , yalnızca başlıklarla ilgili sorunlardan kaçınmayı değil, C ++ projesindeki kaynak ve nesneler arasındaki fiziksel bağımlılıklarla ilgili birçok sorunu da öğretecektir.
Doktor Brown

6
Buradaki cevapların hepsi harika. Nesneleri, yöntemleri, işlevleri kullanma belgelerinin başlık dosyalarında olması gerektiğini eklemek istedim. Kaynak dosyalarda hala doc görüyorum. Bana kaynağı okumamı sağlama. Başlık dosyasının amacı budur. Bir uygulayıcı olmadığım sürece kaynağı okumam gerekmemeli.
Bill Door

1
Seninle daha önce çalıştığımdan eminim. Genellikle :-(
Mawg

5
Tanımladığınız şey büyük bir proje değil. İyi tasarım her zaman bekler, ancak "Büyük Ölçekli Sistemler" sorunlarıyla asla karşılaşmayabilirsiniz.
Sam

2
Boost aslında her şeyi içeren bir yaklaşıma sahip. Her indviidual özellik kendi başlık dosyasına sahiptir, ancak daha büyük olan her modül aynı zamanda her şeyi içeren bir başlık içerir. Bu, sizi her seferinde birkaç yüz dosya # içermek zorunda bırakmadan, cehennemi en aza indirmek için gerçekten güçlü olduğu ortaya çıkıyor.
Cort Ammon

Yanıtlar:


39

Basit yöntem: Kaynak dosya başına bir başlık. Kullanıcıların kaynak dosyalar hakkında bilmesi beklenmeyen bir alt sisteminiz varsa, tüm gerekli üstbilgi dosyalarını içeren alt sistem için bir başlık kullanın.

Herhangi bir başlık dosyası kendi başına derlenebilir olmalıdır (veya tek bir başlık içeren bir kaynak dosyanın derlemesi gerekir). Hangi başlık dosyasının istediğimi içerdiğini tespit edersem acı olur ve ardından diğer başlık dosyalarını avlamak zorunda kalırım. Bunu zorlamanın basit bir yolu, her kaynak dosyanın ilk önce başlık dosyasını içermesidir (teşekkürler doug65536, sanırım çoğu zaman farkına bile varmadan yapıyorum).

Derleme zamanlarını düşük tutmak için kullanılabilir araçlar kullandığınızdan emin olun - her başlık yalnızca bir kez eklenmeli, derleme zamanlarını düşük tutmak için önceden derlenmiş başlıklar kullanın, mümkünse derleme zamanlarını daha düşük tutmak için önceden derlenmiş modüller kullanın.


Zorlaştığında, diğer alt sistemde bildirilen tür parametreleriyle çapraz alt sistem fonksiyon çağrıları yapılır.
Mawg

6
Zor veya değil, "#include <subsystem1.h>" derlenmelidir. Bunu nasıl başarabiliyorsun, sana bağlı. @ FrankPuffer: Neden?
gnasher729

13
@Mawg Bu, farklı alt sistemlerin ortak noktalarını içeren ayrı, paylaşılan bir alt sisteme ihtiyacınız olduğunu veya her alt sistem için basitleştirilmiş "arabirim" başlıklarına ihtiyacınız olduğunu gösterir (daha sonra hem iç hem de çapraz sistem uygulama başlıkları tarafından kullanılır) . Arabirim başlıklarını çapraz içermeyen bir şekilde yazamıyorsanız, alt sistem tasarımınız berbat olur ve alt sistemlerin daha bağımsız olması için şeyleri yeniden tasarlamanız gerekir. (Bu, üçüncü bir modül olarak ortak bir alt sistemin çıkartılmasını içerebilir.)
RM

8
Bir başlığın bağımsız olmasını sağlamak için iyi bir teknik, kaynak dosyanın her zaman önce kendi başlığını içereceği kuralına sahip olmaktır . Bu, bağımlılığı taşımanız gereken durumlarda, uygulama dosyasındaki dosyaları başlık dosyasına dahil eder.
doug65536

4
@FrankPuffer: Lütfen yorumlarınızı silmeyin, özellikle de cevaplar bağlamsız olduğunda, başkaları onlara yanıt verirse. İfadenizi her zaman yeni bir yorumda düzeltebilirsiniz. Teşekkürler! Aslında ne dediğini bilmek istiyorum, ama şimdi bitti :(
MPW

18

Şimdiye kadar en önemli gereksinim, kaynak dosyalarınız arasındaki bağımlılıkları azaltmaktır. C ++ 'da, sınıf başına bir kaynak dosya ve bir başlık kullanmak yaygındır. Bu nedenle, iyi bir sınıf tasarımınız varsa, cehenneme bile yaklaşamayacaksınız.

Bunu diğer yönden de görebilirsiniz: Projenizde zaten cehennem cehennemi varsa, yazılım tasarımının geliştirilmesi gerektiğinden emin olabilirsiniz.

Özel sorularınızı cevaplamak için:

  • Kaynak dosya başına bir başlık? → Evet, çoğu durumda bu işe yarar ve bir şeyler bulmayı kolaylaştırır. Ama onu bir din yapmayın.
  • Artı alt sistem başına bir tane? → Hayır, neden bunu yapmak istiyorsun?
  • İşlev prototiplerinden ayrı typdefs, stucts & enums? → Hayır, fonksiyonlar ve ilgili tipler birbirine aittir.
  • Alt sistem iç alt sistem dış öğesinden ayrı? → Evet, elbette. Bu bağımlılıkları azaltacaktır.
  • Standalones tarafından başlığın veya kaynağın uyumlu olup olmadığına bakılmaksızın her bir dosyanın ısrar etmesini ısrarla? → Evet, asla herhangi bir başlığın başka bir başlığın önüne dahil edilmesini gerektirmez.

12

Diğer tavsiyelere ek olarak, azalan bağımlılık sınırları boyunca (esas olarak C ++ 'a uygulanabilir):

  1. Yalnızca gerçekten ihtiyacınız olanı, ihtiyaç duyduğunuz yere ekleyin (mümkün olan en düşük seviye). Örneğin. Yalnızca kaynaktaki aramalara ihtiyacınız varsa başlığa dahil etmeyin.
  2. Mümkün olan yerlerde başlıklarda ileriye dönük bildirimler kullanın (başlık yalnızca işaretçiler veya diğer sınıflara referanslar içerir).
  3. Her yeniden gözden geçirme işleminden sonra içerilen öğeleri temizleyin (yorum yapın, derlemenin nerede başarısız olduğunu görün, onları oraya taşıyın, hareketsiz yorum yapılan satırları kaldırın).
  4. Aynı dosyaya çok fazla ortak özellik eklemeyin; Onları işlevselliğe göre ayırın (örn. Logger bir sınıf, bu nedenle bir başlık ve bir kaynak dosya; SystemHelper dito, vb.).
  5. Elde ettiğiniz tek şey, yalnızca statik yöntemlerden (bağımsız işlevler yerine) oluşan bir sınıf olsa bile, OO ilkelerine bağlı kalın ya da bunun yerine bir ad alanı kullanın .
  6. Belirli ortak tesisler için, singleton modeli oldukça yararlıdır, çünkü örneği başka, ilgisiz bir nesneden talep etmeniz gerekmez.

5
# 3'te, aracı kullanma-kullanma-kullanma , tahmin et ve kontrol et manuel yeniden derleme yaklaşımını engelleyerek yardımcı olabilir.
RM

1
Bu bağlamda singleton'ların yararının ne olduğunu açıklayabilir misiniz? Gerçekten anlamıyorum.
Frank Puffer,

@FrankPuffer Mantığım şudur: Singleton olmadan bir sınıfın bir örneği genellikle bir Logger gibi bir yardımcı sınıfın örneğine sahiptir. Üçüncü bir sınıf kullanmak istiyorsa, sahibinden yardımcı sınıf referansı istemesi gerekir, yani iki sınıf kullanırsınız ve elbette ki başlıkları da içerir - kullanıcı başka türlü sahibi ile iş yapmasa bile. Bir singleton ile sadece yardımcı sınıfın başlığını eklemeniz gerekir ve örneği doğrudan ondan talep edebilirsiniz. Bu mantıkta bir kusur görüyor musunuz?
Murphy

1
# 2 (ileriye dönük beyanlar) derleme süresi ve bağımlılık kontrolünde büyük fark yaratabilir. Bu cevabın ( stackoverflow.com/a/9999752/509928 ) gösterdiği gibi, hem C ++ hem de C
Dave Compton için

3
İşlev satır içi tanımlanmadığı sürece değere göre iletilirken ileriye dönük bildirimleri de kullanabilirsiniz. İşlev bildirimi, tam tür tanımının gerekli olduğu bir içerik değildir (işlev tanımı veya işlev çağrısı böyle bir içeriktir).
StoryTeller - Unslander Monica,

6

Kaynak dosya başına neyin uygulanacağını / ihracatını tanımlayan kaynak dosya başına bir başlık.

Her bir kaynak dosyaya (kendi başlığından başlayarak) dahil olmak üzere, gerektiği kadar başlık dosyası ekleyin.

Başlık dosyalarının diğer başlık dosyalarına dahil edilmesinden kaçının (dairesel bağımlılıkları önlemek için). Ayrıntılar için bu cevaba bakınız: "İki sınıf C ++ kullanarak birbirlerini görebilir mi?"

Bu konuda bir kitap var, Lakos'un Büyük Ölçekli C ++ Yazılım Tasarımı . Yazılımın "katmanları" na sahip olduğunu açıklar: yüksek seviye katmanlar, tersi bağımlılıklardan kaçınan tersi olmayan düşük seviye katmanlar kullanır.


4

İki tür başlık cehennemi bulunduğundan, sorunuzun temel olarak cevapsız olduğunu iddia ediyorum:

  • Milyonlarca farklı başlık eklemeniz gereken tür ve cehennemde kim hepsini bile hatırlayabilir? Ve bu başlık listelerini koru? Ugh.
  • Bir şeyi dahil ettiğiniz ve tüm Babil Kulesi'ni dahil ettiğinize karar verdiğiniz tür (ya da Boost Kulesi mi demeliyim? ...)

Mesele şu ki, eskiden kaçınmaya çalışırsanız, bir dereceye kadar, ikincisiyle ve bunun tersi olur.

Ayrıca dairesel bağımlılıklar olan üçüncü tür bir cehennem var. Dikkatli olmazsanız bunlar ortaya çıkabilir ... kaçınmak çok karmaşık değildir, ancak nasıl yapılacağını düşünmek için zaman ayırmanız gerekir. John Lakos'un CppCon 2016'daki (ya da sadece slaytlardaki ) Seviyelendirme konusundaki konuşmasını görün .


1
Dairesel bağımlılıklardan daima kaçınamazsınız. Bir örnek, varlıkların birbirlerine atıfta bulundukları bir modeldir. En azından alt sistemdeki döngüselliği sınırlamayı deneyebilirsiniz, bu, alt sistem üstbilgisini eklerseniz, döngüselliği soyutladığınız anlamına gelir.
00

2
@nalply: Kodun yerine başlıkların dairesel bağımlılığından kaçınmak istedim ... dairesel başlık bağımlılığından kaçınmazsanız, muhtemelen oluşturamazsınız. Fakat evet, puan alındı, +1.
einpoklum - Monica,

1

Ayrışma

Sonuçta, günün sonunda, derleyicilerimizin ve bağlayıcılarımızın özelliklerinden mahrum olmayan en temel tasarım düzeyinde beni ayrıştırmakla ilgili. Her bir başlığın sadece bir sınıfı tanımlamasını, pezevenk kullanmasını, sadece bildirilmesi gereken türlere ileriye yönelik bildirimleri yapmasını, tanımlanmamasını, <iosfwd>kaynak dosyası başına bir başlık bile içerdiğini söyleyebilirim. sistemi bildirilmiş / tanımlanmış olan şey türüne göre tutarlı bir şekilde organize etmek.

Derleme Zamanı Bağımlılıklarını Azaltma Teknikleri

Ve tekniklerden bazıları biraz yardımcı olabilir, ancak kendinizi bu uygulamaları yorucu bulabilir ve hala sisteminizde ortalama kaynak dosyanızı bulabilirsiniz, iki sayfalık bir başlangıç ​​sayfası gerekir. #includeArayüz tasarımlarınızdaki mantıksal bağımlılıkları azaltmadan, derleme zamanı bağımlılıklarını başlık düzeyinde azaltmaya çok fazla odaklanırsanız, fırlatma zamanları ile biraz anlamlı bir şey yapma yönergeleri ve kesinlikle "spagetti başlıkları" olarak kabul edilemeyebilir. Hala benzer zararlı meselelere pratikte üretkenliğe dönüştüğünü söyleyebilirim. Günün sonunda, derleme üniteleriniz hala bir şeyler yapmak için bir tekne yükü bilgisine ihtiyaç duyuyorsa, o zaman artan inşa sürelerine çevrilecek ve potansiyel olarak geri dönmeniz ve geliştiricileri yaparken bir şeyleri değiştirmek zorunda kalacağınız nedenleri çoğaltacak. Günlük kodlama işlemlerinin bitmesini sağlamak için sisteme kafa tutuyormuş gibi hissediyorum. O'

Örneğin, her alt sistemin çok soyut bir başlık dosyası ve arabirim sağlamasını sağlayabilirsiniz. Ancak eğer alt sistemler birbirinden ayrılmazsa, çalışmak için karışıklık gibi görünen bir bağımlılık grafiğine sahip diğer alt sistem arayüzlerine bağlı olarak, alt sistem arayüzleriyle tekrar spagetti benzeri bir şey alırsınız.

Dış Tiplere Yönelik Beyanlar

Geliştiriciler bazen iki saat süren eski bir kod temeli elde etmeye çalışmak için harcadığım süre içerisinde geliştiriciler bazen 2 gün boyunca, yapı sunucularımızdaki CI'ye dönüşlerini bekledi (bu makinelerin neredeyse hiç bitmemiş bir yük canavarı olarak hayal edebiliyorsunuz. geliştiriciler değişikliklerini zorlarken devam etmemek ve başarısız olmak için), bana en tartışmalı olanı diğer başlıklarda tanımlanan türleri bildirmek oldu. Ve bu kod üssünü küçük adımlarla yaptığım yaşlardan sonra "tepe spagetti" yi düşürmeye çalışırken, başlarda en tartışmalı uygulama olan "başlıklı spagetti" yi azaltmaya çalışırken (asıl doğanın bakış açısını kaybetmeme neden oldu.) Tünel, başlık bağımlılıklarına bakıldığında tasarım) diğer başlıklarda tanımlanmış türleri bildirir.

Foo.hppGibi bir şey içeren bir başlık düşünün :

#include "Bar.hpp"

Ve yalnızca Barbaşlıkta tanımını değil, bildirim gerektiren bir şekilde kullanır . o zaman başlıkta görünür class Bar;tanımını yapmaktan kaçınmak için ilan etmek hiç akıllıca Bargörünmeyebilir. Uygulamada sık sık, ya da yine de, kendilerini en fazla dahil etme zorunluluğuyla tanımlanmaya Foo.hppihtiyaç duyan derleme birimlerinin çoğunu bulursunuz ya da gerçekten yardım eden başka bir senaryoya girersiniz. senin o derleme birimlerinin% içermeden çalışabilir o zaman daha temel tasarım sorusunu gündeme dışında (ya da en azından bence olması gerektiği günümüzde) bile bildirimi bkz gerek neden ve niçinBarBar.hppFoo.hppBar.hppBarFoo çoğu kullanım durumuyla ilgisiz ise bile bunu bilmek bile rahatsız edilmek zorundadır (neden bir tasarımın daha önce hiç kullanılmadığı başka birine bağlı bir tasarım yükü olsun?).

Kavramsal Çünkü biz gerçekten ayrılmış değil Foogelen Bar. Biz sadece bunu yaptık, böylece başlığın başlığı Foohakkında fazla bilgiye ihtiyaç duymaz Barve bu ikisi birbirinden tamamen bağımsız kılan bir tasarım kadar önemli değil.

Gömülü Komut Dosyası

Bu gerçekten daha büyük ölçekli kod tabanları içindir, ancak son derece yararlı bulduğum bir başka teknik de sisteminizin en üst düzeyindeki bölümleri için gömülü bir betik dili kullanmaktır. Lua'yı bir günde gömebildiğimi ve sistemimizdeki tüm komutları eşit bir şekilde arayabildiğimi buldum (komutlar soyut, neyse ki). Ne yazık ki, geliştiricilerin başka bir dilin tanıtımını ve belki de en tuhaf bir şekilde en büyük şüpheleri olan performanslarını güvensizleştirdiği bir barikatla karşılaştım. Yine de diğer kaygıları anlayabilsem de, kullanıcılar sadece kendi başlarına ciddi bir döngüye neden olmayan düğmeleri tıklattıklarında komutları çağırmak için komut dosyasını kullanmak için kullanıyorsak, performans sorun olmamalı (ne yapmaya çalışıyoruz, düğme tıklaması için yanıt sürelerinde nanosaniye farklılıklarından endişe?).

Örnek

Bu arada, büyük kod tabanlarındaki derleme zamanlarını azaltmak için yorucu tekniklerden sonra şimdiye kadar tanık olduğum en etkili yol , sistemdeki herhangi bir şeyin çalışması için gereken bilgi miktarını gerçekten azaltan, yalnızca bir başlığın derleyiciden ayrılmasını değil perspektif ancak bu arayüzlerin kullanıcılarının bildiklerinde (hem insan hem de derleyici bakış açısından, derleyici bağımlılıklarının ötesine geçen gerçek bir ayrılma) bilmesi gereken her şeyi yapmalarını zorunlu kılan asgari değer.

ECS sadece bir örnektir (ve bir tane kullanmanızı önermiyorum), ama bununla karşılaştığımda, şablonlar ve diğer birçok kaliteyi mutlu bir şekilde kullanırken ECS’nin, doğası, sistemlerin sadece ECS veritabanı hakkında bilmesi gereken ve tipik olarak bir avuç bileşen türünü (bazen sadece bir tane) yapması gereken çok ayrık bir yapı yaratır:

görüntü tanımını buraya girin

Tasarım, Tasarım, Tasarım

İnsan, kavramsal düzeyde bu tür ayrıştırılmış mimari tasarımlar, kod tabanınız büyüdükçe ve büyüyüp büyüdükçe derleme sürelerini en aza indirgeme açısından daha etkilidir, çünkü bu büyüme sizin ortalamanıza çevrilmez, çünkü derleme için gerekli olan miktar bilgisini ve çalışmak için bağlantı zamanlarını çarpma derleme birimi (ortalama geliştiricinizin bir şeyler yapmak için bir yük dolusu malzeme içermesini gerektiren herhangi bir sistem de onları gerektirir ve sadece derleyicinin bir şey yapmak için büyük miktarda bilgi bilmesini gerektirir. ). Ayrıca, geliştirme sürelerinin kısalmasından ve dolaşmayan başlıklardan daha fazla avantaja sahiptir, çünkü geliştiricilerin sistemle ilgili bir şeyler yapmak için hemen gerekli olanın ötesinde bir şey bilmesi gerekmediği anlamına gelir.

Örneğin, AAA oyununuz için milyonlarca LOC'yi kapsayan bir fizik motoru geliştirmek üzere uzman bir fizik geliştiricisi kiralayabilir ve mevcut türler ve ara yüzler gibi en az minimum bilgiyi öğrenirken çok hızlı bir şekilde başlayabilir. Sistem konseptlerinizin yanı sıra, o zaman doğal olarak hem onun hem de derleyicinin fizik motorunu inşa etmesini gerektiren daha az miktarda bilgiye çevrilecek ve aynı zamanda genellikle spagetti'ye benzeyen bir şey olmadığını ima ederek inşa sürelerinde büyük bir azalmaya çevrilecektir. sistemin herhangi bir yerinde. İşte tüm bu diğer tekniklere öncelik vermeyi öneriyorum: sistemlerinizi nasıl tasarladığınız. Aksi takdirde, diğer teknikleri tüketmek en üstte buzlanma yapacaktır.


1
Mükemmel bir cevap! Althoguh ben keşfetmek için biraz kazmak zorunda pimpls :-) olduğunu
Mawg

0

Bu bir görüş meselesidir. Bkz bu cevabı ve o biri. Ayrıca, proje büyüklüğüne de çok bağlıdır (projenizde milyonlarca kaynak hattının olacağına inanıyorsanız, birkaç düzine binine sahip olmakla aynı değildir).

Diğer cevapların aksine, alt sistem başına bir (oldukça büyük) genel başlık (tavsiye edilen "özel" başlıkları içerebilir, belki de birçok satır içi fonksiyonun uygulaması için ayrı dosyalar vardır) öneririm. Yalnızca birkaç #include yönergeye sahip bir başlığı bile düşünebilirsiniz .

Birçok başlık dosyasının önerildiğini sanmıyorum. Özellikle, sınıf başına bir başlık dosyası veya her biri birkaç düzine satırdan oluşan birçok küçük başlık dosyası önermiyorum.

(Çok sayıda küçük dosyanız varsa, bunların hepsini her bir küçük çeviri birimine dahil etmeniz gerekir; bu nedenle genel oluşturma süresi zarar görebilir)

Gerçekten istediğiniz şey, her alt sistem ve dosya için, bundan sorumlu ana geliştirici tanımlamaktır.

Sonunda, küçük bir proje için (örneğin, yüz bin satırdan daha az kaynak kodu), bu çok önemli değildir. Proje sırasında kodu kolayca yeniden değerlendirebilir ve farklı dosyalarda yeniden düzenleyebilirsiniz. Kod parçalarını kopyalayıp yeni (başlık) dosyalara yapıştıracaksınız, büyük bir iş değil (dosyalarınızı nasıl yeniden düzenleyeceğinizin akıllıca tasarlanması daha zor olan şeydir ve projeye özgüdür).

(kişisel tercihim çok büyük ve çok küçük dosyalardan kaçınmak; çoğunlukla her biri birkaç bin satırlık kaynak dosyalarım var; ve yüzlerce satırın hatta birkaç satırının satır içi işlev tanımlarını içeren bir başlık dosyasından korkmuyorum. onlardan binlerce)

Önceden derlenmiş başlıkları GCC ile kullanmak istiyorsanız ( derleme zamanını düşürmek için bazen mantıklı bir yaklaşımdır) tek bir başlık dosyasına (diğerlerinin tümü ve sistem başlıkları da dahil) ihtiyacınız olduğuna dikkat edin .

C ++ 'da standart başlık dosyalarının çok fazla kod çektiğine dikkat edin . Örneğin #include <vector>, Linux üzerindeki GCC 6'mda on binden fazla hat çekiyor (18100 hat). Ve #include <map> neredeyse 40KLOC'ye genişler. Bu nedenle, standart başlıklar da dahil olmak üzere birçok küçük başlık dosyanız varsa, derleme sırasında binlerce satırı yeniden ayrıştırırsınız ve derleme süreniz daha az olur. Bu yüzden birçok küçük C ++ kaynak satırına (en fazla birkaç yüz satırlık) sahip olmaktan hoşlanmıyorum, ancak daha az ancak daha büyük C ++ dosyalarına (birkaç bin satırlık) sahip olmayı tercih ediyorum.

( her zaman - dolaylı olarak - birkaç standart başlık dosyası içeren yüzlerce küçük C ++ dosyasına sahip olmak, geliştiricilere rahatsız eden büyük derleme süresi sağlar)

C kodunda, genellikle başlık dosyaları daha küçük bir şeye genişler, bu nedenle takas farklıdır.

Ayrıca, mevcut ücretsiz yazılım projelerinde (örneğin github'da ) ilham almak için önceki uygulamalara bakın .

Bağımlılıkların iyi bir yapım otomasyon sistemi ile ele alınabileceğine dikkat edin . GNU markasının belgelerini inceleyin . GCC'ye giden çeşitli -Mönişlemci bayraklarının farkında olun (otomatik bağımlılıklar oluşturmakta kullanışlıdır).

Başka bir deyişle, projeniz (yüzden az dosya ve bir düzine geliştiriciden daha azıyla) muhtemelen "başlık cehennemi" ile gerçekten ilgilenecek kadar büyük değil, bu yüzden endişeniz haklı değil . Yalnızca bir düzine başlık dosyasına sahip olabilirsiniz (veya daha da az), çeviri birimi başına bir başlık dosyasına sahip olmayı seçebilir, tek bir başlık dosyasına sahip olmayı bile seçebilirsiniz ve ne yapmayı seçerseniz seçin "header cehennem" (ve dosyalarınızı yeniden düzenlemek ve yeniden düzenlemek oldukça kolay olacaktır, bu nedenle ilk tercih gerçekten önemli değildir ).

(Çabalarınızı “başlık cehennemi” üzerine odaklamayın - ki bu sizin için sorun değil - ama onları iyi bir mimari tasarlamaya odaklayın)


Bahsettiğiniz teknikler doğru olabilir. Ancak, anladığım kadarıyla OP zaman derleme değil, kodun korunabilirliğini ve organizasyonunu nasıl geliştireceğiyle ilgili ipuçlarını soruyordu. Ve bu iki hedef arasında doğrudan bir çatışma görüyorum.
Murphy,

Ancak bu hala bir fikir meselesidir. Ve OP görünüşe göre çok büyük bir proje başlatmıyor.
Basile Starynkevitch,
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.