Geçenlerde benzer bir soru bana C dilinde programlamaya başlayan bir meslektaşım tarafından soruldu. Ve anlayışımı paylaşmak için iyi bir fırsat olduğunu düşündüm. bu konu. Çünkü deneyimli programcılar bile bu konuda her zaman benzer bakış açılarına sahip değiller.

Bu kısmen bir zevk meselesi, bu yüzden bunu nasıl yaptığımla ilgilenen varsa, kedinin altına hoş geldiniz.

h-dosyaları hakkındaki "gerçeğin tamamı" gcc önişlemcisinin açıklamasının ilgili bölümünde yer almasına rağmen, kendime bazı açıklamalar ve çizimler yapacağım.

Yani, kelimenin tam anlamıyla, bir başlık dosyası (h-dosyası), birden çok kaynak dosyada (c-dosyaları) kullanılması amaçlanan C bildirimlerini ve makro tanımlarını içeren bir dosyadır. Bunu açıklayalım.

Her iki dosyada da fonksiyon 1 ve 2'nin yanı sıra makro 2'den bahsedildiğini görmek kolaydır. Başlık dosyalarını dahil etmek, içeriği her bir C dosyasına kopyalamakla aynı sonuçları verdiğinden, aşağıdakileri yapabiliriz:

Böylece, iki dosyadan ortak kısmı seçip başlık dosyasına yerleştirdik.
Ancak bu durumda başlık dosyası bir arayüz mü?

• İşlev 1 ve 2'nin başka bir yerde uyguladığı işlevselliği kullanmamız gerekirse, o zaman Evet
• Makro 2'nin yalnızca Unit1.c ve Unit2.c dosyalarında kullanılması amaçlanıyorsa, arabirim dosyasında yeri yoktur.

Ayrıca, başlık dosyasında tanımlanan arabirimi uygulamak için gerçekten iki C dosyasına ihtiyacımız var mı? Yoksa bir tane yeterli mi?
Bu sorunun cevabı, arayüz fonksiyonlarının uygulama detaylarına ve nerede uygulandıklarına bağlıdır. Örneğin, diyagramları daha ayrıntılı hale getirirseniz, arayüz işlevlerinin farklı dosyalarda uygulandığı durumu hayal edebilirsiniz:


Bu uygulama seçeneği, yüksek kod uyumuna, düşük test edilebilirliğe ve bu tür modüllerin yeniden kullanılmasında zorluğa yol açar.
Bu tür zorluklar yaşamamak için, C-dosyası ve başlık dosyasını her zaman tek bir modül olarak ele alıyorum. hangisinde,

• başlık dosyası yalnızca bu modülün arayüzünün parçası olan işlev, tür ve makro bildirimlerini içerir.
• Buna karşılık C-dosyası, h-dosyasında açıklanan tüm işlevlerin yanı sıra özel türler, makrolar ve arabirimi uygulamak için gereken işlevleri içermelidir.

Böylece, yukarıdaki şemaya karşılık gelen kodu uygularsam, aşağıdakileri elde etmeye çalışırdım (dosya adlarındaki _c ve _h sonları, kullandığım araçta nokta kullanamadığım için eklenmiştir. diyagramlar oluşturun):


Diyagramdan, aslında her biri bir başlık dosyası biçiminde kendi arayüzüne sahip iki bağımsız modülle uğraştığımız görülebilir. Bu, yalnızca bu özel durumda gerçekten ihtiyaç duyulan arayüzün kullanılmasını mümkün kılar.Ayrıca, bu modüller birbirinden bağımsız olarak test edilebilir.
Okuyucu, başlık dosyasındaki makro 2'nin her iki C dosyasında da kopya olarak geri döndüğünü fark etmiş olabilir. Tabii ki, bunun bakımı çok uygun değil. Ancak bu makroyu arayüzün bir parçası yapmak doğru değil.
Bu gibi durumlarda, birkaç C dosyasının ihtiyaç duyduğu türleri ve makroları içeren ayrı bir başlık dosyası oluşturmayı tercih ederim.

Umarım başlık dosyalarına yerleştirilmesi gereken varlıkları tanımlayabilmişimdir. Ayrıca, arayüzler ile çeşitli C dosyalarının ihtiyaç duyduğu bildirimleri ve makroları içeren dosyalar arasındaki farkı göstermek için.

Malzemeye gösterdiğiniz ilgi için teşekkür ederiz.

Yapı ortamınıza bağlı olarak (belirtmiyorsunuz), tam olarak istediğiniz gibi çalıştığını görebilirsiniz.

Bununla birlikte, *.c'nin derlenmesini bekleyen çok sayıda ortam (hem IDE'ler hem de el yapımı Makefile'ler) vardır - bu gerçekleşirse, sembol çoğaltma nedeniyle bağlayıcı hatalarıyla karşılaşmanız olasıdır.

Genel bir kural olarak, bu uygulamadan kaçınılmalıdır.

Kaynağı kesinlikle eklemeniz # gerekiyorsa (ve genellikle kaçınılması gerekiyorsa), dosya için farklı bir dosya kullanın.

Bir C dosyasını başka bir dosyaya dahil etmek yasaldır, ancak tam olarak neden yaptığınızı ve neyi başarmaya çalıştığınızı bilmiyorsanız tavsiye edilmez.
Buraya sorunuzun topluluğa bildirilme nedenini yazarsanız, hedefinize ulaşmak için başka bir uygun yol bulacağınızdan eminim ("neredeyse"ye dikkat edin, çünkü bağlam göz önüne alındığında bunun bir çözüm olması mümkündür. ).

Bu arada sorunun ikinci kısmını atlamışım. C dosyası başka bir dosyada yer alıyorsa ve aynı anda projeye dahil edilmişse, muhtemelen sembolleri çoğaltma, neden nesne bağlama, yani aynı işlevin iki kez tanımlanacağı (statik olmadıkça) sorunuyla karşılaşırsınız.

C dili böyle bir #include türünü yasaklamaz, ancak ortaya çıkan çeviri birimi yine de geçerli bir C olmalıdır.

.prj dosyasıyla hangi programı kullandığınızı bilmiyorum. "Make" veya Visual Studio gibi bir şey kullanıyorsanız, bağımsız olarak derlenemeyenler olmadan derlenmesi gereken dosyaların bir listesine ayarladığınızdan emin olun.

İki dosyayı bir çıktıya bağlamak için linux'ta gcc derleyicisini kullanabilirsiniz. Diyelim ki iki c dosyanız var, biri "main.c" ve diğeri "support.c". Yani bu ikisini bağlama komutu

gcc main.c support.c -o main.out

Bu iki dosya bir main.out çıktısına bağlanacaktır. Çıktıyı çalıştırmak için komut şöyle olacaktır:

./main.out

Eğer support.c dosyasında tanımlanmış olan main.c fonksiyonunu kullanıyorsanız, bunu main'de extern depolama sınıfını da kullanarak bildirmelisiniz.

Doğru kullanıldığında, bu yararlı bir teknik olabilir.

Oldukça küçük bir genel arabirime ve çok sayıda uygulanmamış uygulama koduna sahip karmaşık, görev açısından kritik bir alt sisteminiz olduğunu varsayalım. Kod, birkaç bin satıra, yüzlerce özel işleve ve oldukça fazla özel veriye kadar çalışır. Önemsiz olmayan gömülü sistemlerle çalışıyorsanız, muhtemelen bu durumla oldukça sık karşılaşıyorsunuzdur.

Çözümünüz büyük olasılıkla katmanlı, modüler ve ayrıştırılmış olacaktır ve bu yönler, alt sistemin farklı bölümlerini farklı dosyalarda kodlayarak uygun bir şekilde temsil edilebilir ve geliştirilebilir.

C ile bunu yaparak çok şey kaybedebilirsiniz. Hemen hemen tüm araçlar, tek bir derleme birimi için makul optimizasyonlar sağlar, ancak extern olarak bildirilen herhangi bir şey hakkında çok karamsardır.

Her şeyi bir C kaynak modülüne koyarsanız, elde edersiniz -

Performans ve kod boyutu iyileştirmeleri - çoğu durumda işlev çağrıları satır içi olacaktır. Satır içi olmadan bile, derleyicinin daha verimli kod üretecek yeri vardır.

Kanal düzeyindeki veriler ve işlevler gizlenir.

Ad alanı kirliliğinden ve bunun sonucundan kaçınmak, daha az hantal adlar kullanabilmenizdir.

Daha hızlı derleme ve bağlama.

Ama aynı zamanda iş o dosyayı düzenlemeye geldiğinde korkunç bir karmaşa yaşarsınız ve amaçlanan modülerliği kaybedersiniz. Bölünerek bu aşılabilir kaynak birkaç dosyaya ve bunları tek bir derleme birimine dahil etmek.

Ancak, bununla başa çıkmak için bazı sözleşmeler uygulamanız gerekir. Bir dereceye kadar bu, alet zincirinize bağlı olacaktır, ancak bazı genel işaretçiler

Genel arayüzü ayrı bir başlık dosyasına koyun - yine de yapmalısınız.

Tüm alt .c dosyalarını içeren bir ana .c dosyasına sahip olun. Ayrıca ortak arayüz için kod içerebilir.

Özel başlıkların ve kaynak modüllerin dahil edilmesini önlemek için derleyici korumalarını kullanın harici modüller derleme.

Tüm özel veriler ve işlevler statik olarak bildirilmelidir.

.c ve .h dosyaları arasında kavramsal bir ayrım yapın. Mevcut sözleşmeleri kullanır. Aradaki fark, başlıklarınızda çok sayıda statik reklam olacak olmasıdır.

Araç zinciriniz bir anlam ifade etmiyorsa, .c ve .h gibi özel uygulama dosyaları belirtmemelisiniz. Dahil edilen korumaları kullanırsanız, kod üretmeyecekler ve herhangi bir yeni ad getirmeyecekler (sonuç olarak bazı boş bölümlerle karşılaşabilirsiniz). Büyük avantaj, diğer araçların (örn. IDE) bu dosyaları buna göre işlemesidir.

Dosya uzantısı çoğu C derleyicisi için önemli değildir, dolayısıyla çalışacaktır.

Ancak, dosyanıza veya proje ayarlarınıza bağlı olarak, dahil edilen c dosyası ayrı bir nesne dosyası oluşturabilir. Bağlanırken, bu çift belirli karakterlerle sonuçlanabilir.

böyle bir başlık eklemelisiniz

#katmak

not: her iki dosya da aynı yere yerleştirilmelidir

.C veya .CPP dosyalarını diğer kaynak dosyalara uygun şekilde dahil edebilirsiniz. IDE'nize bağlı olarak, genellikle eklemek istediğiniz kaynak dosyaların özelliklerine bakarak çift bağlantıyı önleyebilirsiniz. sağ tık fareyi üzerlerine getirin ve özelliklere tıklayın ve derleme/bağlantı/montajdan hariç tutma veya her neyse işaretini kaldırın/işaretleyin. Belki. Veya dosyayı projenin kendisine dahil edemezsiniz, bu nedenle IDE onun var olduğunu bile bilmez ve onu derlemeye çalışmaz. Ve makefiles ile, derlemek ve bağlantı kurmak için içine bir dosya koymazsınız.

DÜZENLEME: Üzgünüm, diğer cevapları cevaplamak yerine cevap verdim :(

çevrimiçi oy verin (8)

Bir C dosyasını başka bir dosyaya dahil etmek yasaldır, ancak tam olarak neden yaptığınızı ve neyi başarmaya çalıştığınızı bilmiyorsanız tavsiye edilmez.
Buraya sorunuzun topluluğa bildirilme nedenini yazarsanız, hedefinize ulaşmak için başka bir uygun yol bulacağınızdan eminim ("neredeyse"ye dikkat edin, çünkü bağlam göz önüne alındığında bunun bir çözüm olması mümkündür. ).

Bu arada sorunun ikinci kısmını atlamışım. C dosyası başka bir dosyada yer alıyorsa ve aynı anda projeye dahil edilmişse, muhtemelen sembolleri çoğaltma, neden nesne bağlama, yani aynı işlevin iki kez tanımlanacağı (statik olmadıkça) sorunuyla karşılaşırsınız.

Dosya uzantısı çoğu C derleyicisi için önemli değildir, dolayısıyla çalışacaktır.

Ancak, dosyanıza veya proje ayarlarınıza bağlı olarak, dahil edilen c dosyası ayrı bir nesne dosyası oluşturabilir. Bağlanırken, bu çift belirli karakterlerle sonuçlanabilir.

Yapı ortamınıza bağlı olarak (belirtmiyorsunuz), tam olarak istediğiniz gibi çalıştığını görebilirsiniz.

Bununla birlikte, *.c'nin derlenmesini bekleyen çok sayıda ortam (hem IDE'ler hem de el yapımı Makefile'ler) vardır - bu gerçekleşirse, sembol çoğaltma nedeniyle bağlayıcı hatalarıyla karşılaşmanız olasıdır.

Genel bir kural olarak, bu uygulamadan kaçınılmalıdır.

Kaynağı kesinlikle eklemeniz # gerekiyorsa (ve genellikle kaçınılması gerekiyorsa), dosya için farklı bir dosya kullanın.

İki dosyayı bir çıktıya bağlamak için linux'ta gcc derleyicisini kullanabilirsiniz. Diyelim ki iki c dosyanız var, biri "main.c" ve diğeri "support.c". Yani bu ikisini bağlama komutu

gcc main.c support.c -o main.out

Bu iki dosya bir main.out çıktısına bağlanacaktır. Çıktıyı çalıştırmak için komut şöyle olacaktır:

./main.out

Eğer support.c dosyasında tanımlanmış olan main.c fonksiyonunu kullanıyorsanız, bunu main'de extern depolama sınıfını da kullanarak bildirmelisiniz.

Ekibimin .c dosyalarını eklemeye karar verdiği bir durumu paylaşayım dedim. Mimarımız esas olarak bir mesaj sistemi aracılığıyla ayrıştırılmış modüllerden oluşmaktadır. Bu ileti işleyicileri geneldir ve işlerini yapmak için birçok yerel statik çalışan işlevi çağırır. Sorun, tekli test durumlarımız için kapsam almaya çalışırken ortaya çıktı. tek yol bu özel uygulama kodunu uygulamak, dolaylı olarak genel mesaj arabirimi aracılığıyla yapıldı. Yığının kucağındaki bazı işçi özellikleriyle, bunun uygun kapsama alanı sağlamak için bir kabus olduğu kanıtlandı.

.c dosyalarının dahil edilmesi bize makinedeki dişliye ulaşma fırsatı verdi, test etmekle ilgileniyorduk.

C dili böyle bir #include türünü yasaklamaz, ancak ortaya çıkan çeviri birimi yine de geçerli bir C olmalıdır.

.prj dosyasıyla hangi programı kullandığınızı bilmiyorum. "Make" veya Visual Studio gibi bir şey kullanıyorsanız, bağımsız olarak derlenemeyenler olmadan derlenmesi gereken dosyaların bir listesine ayarladığınızdan emin olun.

Doğru kullanıldığında, bu yararlı bir teknik olabilir.

Oldukça küçük bir genel arabirime ve çok sayıda uygulanmamış uygulama koduna sahip karmaşık, görev açısından kritik bir alt sisteminiz olduğunu varsayalım. Kod, birkaç bin satıra, yüzlerce özel işleve ve oldukça fazla özel veriye kadar çalışır. Önemsiz olmayan gömülü sistemlerle çalışıyorsanız, muhtemelen bu durumla oldukça sık karşılaşıyorsunuzdur.

Çözümünüz büyük olasılıkla katmanlı, modüler ve ayrıştırılmış olacaktır ve bu yönler, alt sistemin farklı bölümlerini farklı dosyalarda kodlayarak uygun bir şekilde temsil edilebilir ve geliştirilebilir.

C ile bunu yaparak çok şey kaybedebilirsiniz. Hemen hemen tüm araçlar, tek bir derleme birimi için makul optimizasyonlar sağlar, ancak extern olarak bildirilen herhangi bir şey hakkında çok karamsardır.

Her şeyi bir C kaynak modülüne koyarsanız, elde edersiniz -

Performans ve kod boyutu iyileştirmeleri - çoğu durumda işlev çağrıları satır içi olacaktır. Satır içi olmadan bile, derleyicinin daha verimli kod üretecek yeri vardır.

Kanal düzeyindeki veriler ve işlevler gizlenir.

Ad alanı kirliliğinden ve bunun sonucundan kaçınmak, daha az hantal adlar kullanabilmenizdir.

Daha hızlı derleme ve bağlama.

Ama aynı zamanda iş o dosyayı düzenlemeye geldiğinde korkunç bir karmaşa yaşarsınız ve amaçlanan modülerliği kaybedersiniz. Bu, kaynak kodu birden fazla dosyaya bölerek ve bunları tek bir derleme birimine dahil ederek aşılabilir.

Ancak, bununla başa çıkmak için bazı sözleşmeler uygulamanız gerekir. Bir dereceye kadar bu, alet zincirinize bağlı olacaktır, ancak bazı genel işaretçiler

Genel arayüzü ayrı bir başlık dosyasına koyun - yine de yapmalısınız.

Tüm alt .c dosyalarını içeren bir ana .c dosyasına sahip olun. Ayrıca ortak arayüz için kod içerebilir.

Özel başlıkların ve kaynak modüllerin harici derleme modülleri tarafından dahil edilmesini önlemek için derleyici koruyucuları kullanın.

Tüm özel veriler ve işlevler statik olarak bildirilmelidir.

.c ve .h dosyaları arasında kavramsal bir ayrım yapın. Mevcut sözleşmeleri kullanır. Aradaki fark, başlıklarınızda çok sayıda statik reklam olacak olmasıdır.

Araç zinciriniz bir anlam ifade etmiyorsa, .c ve .h gibi özel uygulama dosyaları belirtmemelisiniz. Dahil edilen korumaları kullanırsanız, kod üretmeyecekler ve herhangi bir yeni ad getirmeyecekler (sonuç olarak bazı boş bölümlerle karşılaşabilirsiniz). Büyük avantaj, diğer araçların (örn. IDE) bu dosyaları buna göre işlemesidir.

Bu iyi? evet derlenecek

tavsiye edilir mi? no - .c dosyaları, derlemeden sonra (bağlayıcı tarafından) bir yürütülebilir dosyaya (veya kitaplığa) bağlanan .obj dosyalarında derlenir, bu nedenle bir .c dosyasını diğerine dahil etmeye gerek yoktur. Bunun yerine, büyük olasılıkla başka bir .c dosyasında bulunan işlevleri/değişkenleri listeleyen ve .h dosyasını içeren bir .h dosyası yapmak istersiniz.

Programlama Kozlova Irina Sergeevna

27. C++ kaynak dosyaları

27. C++ kaynak dosyaları

Bir C++ programı genellikle her biri türlerin, işlevlerin, değişkenlerin ve sabitlerin açıklamalarını içeren çok sayıda kaynak dosya içerir. Bir ismin farklı kaynak dosyalarda belirli bir nesneye atıfta bulunabilmesi için harici olarak bildirilmesi gerekir. Örneğin:

harici çift sqrt(double); harici giriş cin;

Kaynak dosyaları tutarlı tutmanın en kolay yolu, aynı açıklamaları bireysel dosyalar, başlık (veya başlık) dosyaları olarak adlandırılır ve daha sonra bu başlık dosyalarını, bu açıklamaların gerekli olduğu tüm dosyalara dahil edin, yani kopyalayın. Örneğin, sqrt'nin tanımı math.h standart matematiksel fonksiyonlarının başlık dosyasında bulunuyorsa ve 4'ün karekökünü çıkarmanız gerekiyorsa, programı kullanmalısınız:

Normal başlık dosyaları çok sayıda kaynak dosya içerdiğinden, tekrar edilmemesi gereken açıklamalar içermezler.

Bir içerme komutunda, örneğin köşeli ayraçlar içindeki dosya adı, standart dizindeki (genellikle /usr/include/CC) o addaki dosyaya atıfta bulunur; diğer konumlarda depolanan dosyalara çift tırnak içine alınmış adlar kullanılarak başvurulur. Örneğin:

#include "math1.h" #include "/usr/bs/math2.h"

geçerli kullanıcı dizininden math1.h'yi ve /usr/bs dizininden math2.h'yi içerecektir.

Ostream çıktı akışı türünü nasıl belirleyebileceğimizi gösterelim. Görevi basitleştirmek için arabelleğe alma için streambuf türünün tanımlandığını varsayalım. Streambuf türü, ostream'in gerçek tanımıyla aynı yerde tanımlanır. Kullanıcı tanımlı bir türün değeri, o türdeki bir nesneyi temsil etmek için gereken verileri ve bu nesneler üzerinde çalışacak çok sayıda işlemi belirtir. Tanım iki bölümden oluşur: yalnızca geliştiricisi tarafından kullanılan bilgileri içeren özel (özel) bölüm ve kullanıcı ile türün arayüzü olan genel (genel) bölüm.

Programlar kitabından ve Windows dosyaları yazar Klimov A

.dbx dosyaları .dbx dosyaları Outlook Express için kayıtları depolar. İleti Bankası adı verilen bu dosyalar mektupları, haber grubu iletilerini vb. içerir. İstenirse, verileri başka bir bilgisayara aktarmak için bu dosyaları bir depolama ortamına kopyalayabilirsiniz.

Programlama kitabından yazar Kozlova Irina Sergeevna

INF dosyaları Bu yazıda, bir INF dosyasının ne olduğuna, diğer dosyalarla ve kayıt defteriyle çalışmak, kısayollar oluşturmak, programları çalıştırmak vb. için nasıl kullanılacağına bakacağız. Bildiğiniz gibi, az ya da çok ciddi yazılım ürünü genellikle özel gerektirir

Win2K SSS kitabından (v. 6.0) yazar Shashkov Alexey

12. Yorumlar. Kaynak Dosyalar Yorum, derleyici tarafından yok sayılan bir dizi karakterdir. Ancak bu karakter grubu belirli kısıtlamalara tabidir. Bir yorumu temsil eden bir karakter kümesi içinde, özel karakterler, Hangi

Microsoft Visual C++ ve MFC kitabından. Windows 95 ve Windows NT için Programlama yazar Frolov Alexander Vyacheslavovich

27. C++ kaynak dosyaları Bir C++ programı genellikle her biri türlerin, işlevlerin, değişkenlerin ve sabitlerin açıklamalarını içeren çok sayıda kaynak dosyası içerir. Bir ismin farklı kaynak dosyalarda belirli bir nesneyi ifade edecek şekilde kullanılması için,

UNIX: Süreç Etkileşimi kitabından yazar Stephen William Richard

Dosyalar Yoğun talep üzerine, ile bölümü açın. faydalı dosyalar w2k için. Bölüm iki bölümden oluşur, ilki Microsoft'un resmi yamalarıdır (hepsi değil, yalnızca bize en önemli görünenler) ve ikinci bölüm, SSS'de belirtilen tüm dosyaları, yalnızca yardımcı programları içerecektir.

C Programlama Dili kitabından kişisel bilgisayar yazar Bochkov S. O.

Öğrenciler ve okul çocukları için KOMPAS-3D kitabından. Çizim, bilgisayar bilimi, geometri yazar Bolşakov Vladimir

Belgelenmemiş ve Az Bilinen kitabından pencere özellikleri XP yazar Klimenko Roman Aleksandroviç

Kaynak dosyalar Bir C programının metni birkaç kaynak dosyaya bölünebilir. kaynak dosya Metin dosyası, programın tamamını veya bir kısmını içerir. Bir kaynak programı derlerken, onu oluşturan kaynak dosyaların her biri

Linux için Programlama kitabından. Profesyonel yaklaşım yazar Mitchell Mark

Ek 2 Katı modelleme için girdi verileri

UNIX Kitabından: Geliştirme ağ uygulamaları yazar Stephen William Richard

Ek 3 Modelleme aileleri için ilk veriler

Wiki-Goverment'tan [Teknoloji Gücü Nasıl Daha İyi, Demokrasiyi Daha Güçlü ve Vatandaşları Nasıl Daha Güçlü Hale Getirebilir] yazar Novek Bahis

CPL Dosyaları Önceki birkaç paragraftan, rundll32.exe programıyla çalışmak için gerekli olan neredeyse tüm teorik hesaplamaları öğrendiniz. Şimdi olasılıkları listeleyeceğiz bu program kullanıcı sağlayabilir. Bir açıklama ile başlayalım

UNIX - Evrensel Programlama Ortamı kitabından yazar Pike Rob

1.5.4. Linux kaynağı açık kaynaklı bir sistem değil mi? Bir sistemin nasıl çalıştığına dair nihai yargıç, sistemin kendisinin kaynak kodudur. Neyse ki bizim için ücretsiz olarak mevcut. Mevcut Linux dağıtımı tüm sistemin kaynak kodunu içerebilir ve tüm

yazarın kitabından

A.3.5. Hesap makinesi programının kaynak metinleri Liste A.3, sonek ifadelerinin değerlerini hesaplayan programın metnini gösterir Liste A.3. (calculator.c) Hesap makinesinin ana bölümü/* Tekli formatta hesaplamalar. *//* Tek satır

yazarın kitabından

Ek D Çeşitli kaynak kodları D.1. unp.h Başlık Dosyası Bu kitaptaki hemen hemen her program Liste D.1'de gösterilen unp.h başlık dosyasıyla başlar. Bu dosya, çalıştırmak için gereken tüm standart sistem başlık dosyalarını içerir.

yazarın kitabından

yazarın kitabından

Ek 3 Hoc Hesap Makinesi Kaynakları Bu dosyalar, Brian Kernighan ve Rob Pike'ın yazdığı "The Unix Programming Environment" (Prentice Hall, 1984, ISBN 0-13-937681-X)'deki tüm kodları içerir. Ayrı bir hoc6 dağıtımı, ona uyguladığımız tüm düzeltmeleri içerir; bu dosyadaki sürüm kitaptan alınmıştır.Telif hakkı © Lucent Technologies, 1997. Tüm Hakları SaklıdırBu yazılımı ve belgelerini şu kişiler için kullanma, kopyalama, değiştirme ve dağıtma izni: