Original URL: https://www.stroustrup.com/bs_faq.html
Translated by: Qalina Najafova
23 iyul 2021-ci ildə dəyişdirilib.
Bunlar insanların mənə tez-tez verdiyi suallardır. Cavablarla bağlı daha yaxşı suallarınız və ya şərhləriniz varsa, mənə e-poçt göndərməkdən çekinmeyin. Xahiş edirəm unutmayın ki, mən bütün vaxtımı əsas səhifələrimi təkmilləşdirməyə sərf edə bilmərəm.
Bu səhifə fəlsəfə ilə bağlı şəxsi fikirlərə və ümumi suallara diqqət yetirir. C++ dili xüsusiyyətlərinə və C++ istifadəsinə daha çox aid olan suallar üçün C++ Fondunun Tez-tez verilən suallara və ya mənim C++ üslubu və texnikası ilə bağlı Tez-tez verilən suallara baxın . C++ terminologiyası və anlayışları üçün mənim C++ lüğətimə baxın . C++ məlumatının faydalı mənbələrinə keçidlər üçün mənim C++ səhifəmə və C++11 tez-tez verilən suallara baxın . Kitablarım haqqında məlumat (nəzərlər və dəstək məlumatı daxil olmaqla) üçün kitab siyahıma baxın . Kitablarımın tərcümələri üçün sənədlər və ISBN-lər üçün nəşrlər siyahısıma baxın .
Skandinaviyalı olmayanlar üçün çətin ola bilər. Hələ eşitdiyim ən yaxşı təklif "Norveçcə bir neçə dəfə söyləyərək başlayın, sonra boğazınıza bir kartof doldurun və yenidən edin :-)" Budur wav faylı .
Səsi qəbul edə bilməyən insanlar üçün belə bir təklif var: Mənim hər iki adım iki heca ilə tələffüz olunur: Bjar-ne Strou-strup. Mənim adımda nə B, nə də J vurğulanmır və NE kifayət qədər zəifdir, buna görə də Be-ar-neh və ya By-ar-ne bir fikir verə bilər. Mənim ikinci adımdakı ilk U hərfi həqiqətən V hərfi olmalı idi ki, birinci hecanın sonunu boğazdan aşağı salırdı: Strov-strup. İkinci U bir az OOP-dakı OO-ya bənzəyir, lakin yenə də qısadır; bəlkə Strov-stroop bir fikir verər.
Bəli, bu, yəqin ki, ən çox verilən sualdır :-)
PS Mənim ilk adım Bjarnedir - Bjorn deyil (ad deyil), Bjørn (əlaqəli, lakin fərqli ad), nə də Barney (əlaqəsi olmayan ad). İkinci adım Stroustrupdur - Stroustroup, Stroustrop, Strustrup, Strustrop, Strustroup, Straustrup, nə də Straustroup (bu səhvlərin hər birini istifadə edən sənədləri google-dan istifadə etməklə tapmaq olar).
Əlbəttə. E-poçtuma cavab verməyə çalışıram. Bununla belə, xahiş edirəm ana səhifələrimdə cavablandırılan sualı verməməyə çalışın. Həmçinin, xahiş edirəm, təcili cavaba etibar etməyin. Mən çoxlu e-poçt alıram.
Budur linklər
Edirəm, amma çoxlu e-poçt alıram. Hesab edirəm ki, qəbul etdiyim (spam olmayan) mesajların 95%-dən çoxuna cavab verirəm. Bununla belə, hərdən məni sıxır. Bəzi mesajlar poçt qutumda itdi, bəziləri vaxt tapana qədər gecikir, bəziləri əlaqəli mesajlar toplusuna cavab verənə qədər gecikir (bu, tez-tez kitablarımdakı potensial səhvlər haqqında şərhlərdə olur). Təəssüf ki, daha uzun və daha düşüncəli mesajların gecikmə ehtimalı sadə cavabları olan sadə mesajlara nisbətən daha çoxdur.
Həmçinin, mənə e-poçt göndərsəniz, sizə cavab verə biləcəyimə əmin olmağa çalışın. Qayıdış ünvanının etibarsız və ya əlçatmaz olduğunu tapmaq üçün yazıb cavab göndərməyimə çox nifrət edirəm.
İki növ mesajın itmə ehtimalı nisbətən yüksəkdir: ev tapşırığı sualları və "mən bu mülkiyyət kitabxanasından necə istifadə edirəm?". Sonuncu suallara cavab vermədiyimə görə bir qədər kədərlənirəm, çünki soruşan şəxs tez-tez DOS, Windows və ya C++-dan gələn hər hansı interfeysin C++ standartının bir hissəsi olmadığını başa düşmür (və mən çoxlu sayda suala cavab verə bilmirəm) C++ kitabxanaları ). Cavab ala bilmirsinizsə, sualınızın bu növlərdən biri olub-olmadığını düşünün.
Həmçinin, adınızı deməsəniz, oxunmamış mesajı siləcəm. Bu yeni siyasətdir. Mən heç vaxt təxəllüsün böyük pərəstişkarı olmamışam, amma görürəm ki, suuupergeeek və ya coolGuy3 kimi bir adın arxasında gizlənməyi gözəl hesab edən şəxslə nəzakətli texniki söhbət etmək şansım mənim üçün cəhd etməkdən narahat olmaq üçün çox azalır.
Mən veb-sayt dizayneri deyil, “məzmun təminatçısı”yam. Mən vaxtımı məzmunu və ya görünüşü yaxşılaşdırmaq üçün istifadə edə bilərəm, lakin hər ikisini deyil.
Kiməsə "sərin və müasir" görünən şeylər tez-tez başqası tərəfindən pis dad hesab olunur və moda sürətlə dəyişir. Həmçinin, çox sadə html hər şeydən daha sürətli yüklənir və göstərilir və bir çox insanlar hələ də yavaş veb bağlantılarından əziyyət çəkirlər.
Yəqin ki, yox. Məndən gəldiyini iddia edən xəbər qruplarının yazılarının, müsahibələrinin və s. çoxu məndən gəlir. Aşkar istisna hal- hazırda 20+ yaşı olan məşhur IEEE “müsahibəsi” dir və mənə olduqca gülməli gəlir. Əgər şübhəniz varsa, şübhəli mesajın üslubunu və məzmununu nəzərdən keçirin, forumda digər yazıları yoxlayın və ya soruşun.
Dərslər kodunuzu təşkil etməyə və proqramlarınız haqqında düşünməyə kömək etmək üçün var. Təxminən bərabər şəkildə deyə bilərsiniz ki, dərslər səhv etməməyiniz üçün və səhv etdikdən sonra səhvləri tapmağınıza kömək etmək üçün var. Bu şəkildə, siniflər baxım üçün əhəmiyyətli dərəcədə kömək edir.
Sinif kodda ideyanın, konsepsiyanın təmsilidir. Sinfin obyekti koddakı ideyanın xüsusi nümunəsini təmsil edir. Dərslər olmadan kodun oxucusu məlumat elementləri və funksiyalar arasındakı əlaqələri təxmin etməli olacaq - siniflər bu cür əlaqələri aydın edir və tərtibçilər tərəfindən "anlaşılır". Dərslərlə, proqramınızın yüksək səviyyəli strukturunun daha çoxu yalnız şərhlərdə deyil, kodda əks olunur.
Yaxşı dizayn edilmiş sinif öz istifadəçilərinə təmiz və sadə interfeys təqdim edir, təmsilçiliyini gizlədir və istifadəçilərini bu təqdimat haqqında məlumatlı olmaqdan xilas edir. Əgər təqdimat gizlədilməməlidirsə - deyək ki, istifadəçilər hər hansı məlumat üzvünü istədikləri şəkildə dəyişdirə bilməlidirlər - siz bu sinfi "sadəcə köhnə məlumat strukturu" kimi düşünə bilərsiniz; misal üçün:
struct Pair {
string name, value;
};
Qeyd edək ki, hətta verilənlər strukturları da konstruktorlar kimi köməkçi funksiyalardan faydalana bilər.
Bir sinfi dizayn edərkən, sinfin hər bir obyekti üçün və hər zaman nəyin doğru olduğunu nəzərə almaq çox vaxt faydalıdır. Belə bir xüsusiyyət invariant adlanır. Məsələn, vektorun invariantı o ola bilər ki, onun təmsili bir sıra elementlərin göstəricisindən ibarətdir və elementlərin sayı tam ədəddə saxlanılır. Sinfin invariantını qurmaq hər bir konstruktorun işidir ki, hər bir üzv funksiyası ona etibar edə bilsin. Hər bir üzv funksiya çıxdıqda invariantı etibarlı tərk etməlidir. Bu cür düşüncə, kilidlər, yuvalar və fayllar kimi resursu idarə edən siniflər üçün xüsusilə faydalıdır. Məsələn, fayl idarəsi sinfi açıq fayla göstərici saxlayan invariana malik olacaq. Fayl idarəsi konstruktoru faylı açır. Destruktorlar konstruktorlar tərəfindən əldə edilən resursları azad edir. Məsələn, fayl sapı üçün dağıdıcı konstruktor tərəfindən açılmış faylı bağlayır:
class File_handle {
public:
File_handle(const char* n, const char* rw)
{ f = fopen(n,rw); if (f==0) throw Open_failure(n); }
~File_handle() { fclose(f); } // destructor
// ...
private:
FILE* f;
};
Dərslərlə proqramlaşdırmamısınızsa, bu izahatın hissələrini qaranlıq tapacaqsınız və dərslərin faydalılığını az qiymətləndirəcəksiniz. Nümunələr axtarın. Bütün yaxşı dərsliklər kimi, TC++PL-də də çoxlu nümunələr var. Daha az təfərrüatlı və yanaşması asan kitab üçün C++ turuna baxın . Müasir C++ kitabxanalarının əksəriyyəti (digər şeylərlə yanaşı) siniflərdən ibarətdir və kitabxana dərsliyi faydalı dərs nümunələri axtarmaq üçün ən yaxşı yerlərdən biridir.
“Obyekt yönümlü”, “obyekt yönümlü proqramlaşdırma” və “obyekt yönümlü proqramlaşdırma dilləri”nin çoxlu tərifləri var. "Obyekt yönümlü" kimi düşündüyüm şeyin uzun izahı üçün oxuyun Niyə C++ sadəcə obyekt yönümlü proqramlaşdırma dili deyil . Bununla belə, obyekt yönümlü proqramlaşdırma Simula ilə (40 ildən çox əvvəl!) inkapsulyasiya, irsiyyət və polimorfizmə əsaslanan proqramlaşdırma tərzidir. C++ kontekstində (və kökləri Simula-da olan bir çox başqa dillər) bu, yaxşı müəyyən edilmiş interfeyslər vasitəsilə müxtəlif növ obyektlərin manipulyasiyasına imkan vermək və proqramın tədricən genişləndirilməsinə imkan vermək üçün sinif iyerarxiyalarından və virtual funksiyalardan istifadə edərək proqramlaşdırma deməkdir. törəmə yolu ilə.
Baxın. Dərslərdə nə gözəldir? "düz siniflər" haqqında nə gözəl bir fikir üçün. Siniflərin sinif iyerarxiyasına uyğunlaşdırılmasının məqsədi siniflər arasında iyerarxik əlaqələri ifadə etmək və kodu sadələşdirmək üçün bu əlaqələrdən istifadə etməkdir.
OOP-u həqiqətən başa düşmək üçün bəzi nümunələrə baxın. Məsələn, ümumi interfeysə malik iki (və ya daha çox) cihaz drayveriniz ola bilər:
class Driver { // common driver interface
public:
virtual int read(char* p, int n) = 0; // read max n characters from device to p
// return the number of characters read
virtual bool reset() = 0; // reset device
virtual Status check() = 0; // read status
};
Bu Sürücü sadəcə bir interfeysdir. O, heç bir məlumat üzvləri və təmiz virtual funksiyalar dəsti ilə müəyyən edilir. Sürücü bu interfeys vasitəsilə istifadə edilə bilər və bir çox müxtəlif növ sürücülər bu interfeysi həyata keçirə bilər:
class Driver1 : public Driver { // a driver
public:
Driver1(Register); // constructor
int read(char*, int n);
bool reset();
Status check();
private:
// implementation details, incl. representation
};
class Driver2 : public Driver { // another driver
public:
Driver2(Register);
int read(char*, int n);
bool reset();
Status check();
private:
// implementation details, incl., representation
};
Qeyd edək ki, bu drayverlər verilənləri (statusunu) saxlayır və onların obyektləri yaradıla bilər. Onlar Driver-da müəyyən edilmiş funksiyaları həyata keçirirlər. Sürücünün belə istifadə edildiyini təsəvvür edə bilərik:
void f(Driver& d) // use driver
{
Status old_status = d.check();
// ...
d.reset();
char buf[512];
int x = d.read(buf,512);
// ...
}
Burada əsas məqam odur ki, f() hansı növ sürücüdən istifadə etdiyini bilməlidir; onun bilməsi lazım olan tək şey Sürücüdən keçdiyidir; yəni bir çox müxtəlif növ sürücülər üçün interfeys. Biz f() funksiyasını belə çağıra bilərik:
void g()
{
Driver1 d1(Register(0xf00)); // create a Driver1 for device
// with device register at address 0xf00
Driver2 d2(Register(0xa00)); // create a Driver2 for device
// with device register at address 0xa00
// ...
int dev;
cin >> dev;
if (dev==1)
f(d1); // use d1
else
f(d2); // use d2
// ...
}
Qeyd edək ki, f() bir Sürücüdən istifadə etdikdə düzgün növ əməliyyatlar icra zamanı birbaşa seçilir. Məsələn, f() d1 ötürüldükdə d.read() Driver1::read() funksiyasından istifadə edir, f() isə d2 ötürüldükdə d.read() Driver2::read() funksiyasından istifadə edir. Buna bəzən iş vaxtı göndərilməsi və ya dinamik göndərmə deyilir. Bu halda f() funksiyasının hansı cihazla çağırıldığını bilməsinin heç bir yolu yoxdur, çünki biz onu giriş əsasında seçirik.
Nəzərə alın ki, obyekt yönümlü proqramlaşdırma panacea deyil. "OOP" sadəcə olaraq "yaxşı" demək deyil - probleminizdə əsas anlayışlar arasında heç bir xas iyerarxik əlaqələr yoxdursa, heç bir iyerarxiya və virtual funksiyalar kodunuzu təkmilləşdirməyəcək. OOP-un gücü ondan ibarətdir ki, sinif iyerarxiyalarından istifadə etməklə faydalı şəkildə ifadə oluna bilən bir çox problem var - OOP-un əsas zəif tərəfi ondan ibarətdir ki, həddən artıq çox insan həddən artıq çox problemi iyerarxik formada məcbur etməyə çalışır. Hər proqram obyekt yönümlü olmamalıdır. Alternativ olaraq, sadə sinifləri , ümumi proqramlaşdırmanı və müstəqil funksiyaları (riyaziyyat, C və Fortran kimi) nəzərdən keçirin.
Ümumi proqramlaşdırma parametrləşdirməyə əsaslanan proqramlaşdırmadır: Siz növü başqası ilə (məsələn, element növləri ilə vektor) və alqoritmi digəri ilə (məsələn, müqayisə funksiyası olan çeşidləmə funksiyası kimi) parametrləşdirə bilərsiniz. Ümumi proqramlaşdırmanın məqsədi faydalı alqoritmi və ya verilənlər strukturunu onun ən ümumi və faydalı formasına ümumiləşdirməkdir. Məsələn, tam ədədlərin vektoru gözəldir və tam ədədlərin vektorunda ən böyük dəyəri tapan funksiya da belədir. Bununla belə, istifadəçinin istifadə etdiyi istənilən növ vektoru və istənilən vektorda ən böyük dəyəri tapan funksiyanı təmin edən ümumi həll hələ daha yaxşıdır:
vector<string>::iterator p = find(vs.begin(), vs.end(), "Grail");
vector<int>::iterator q = find(vi.begin(), vi.end(), 42);
Bu nümunələr STL-dəndir (ISO C++ standart kitabxanasının konteynerlər və alqoritmlər hissəsi); qısa giriş üçün TC++PL -dən C++ Turuna baxın .
C++ 20-də biz bu nümunəni sadələşdirə bilərik
auto p = find(vs, "Grail");
auto q = find(vi, 42);
Ümumi proqramlaşdırma müəyyən mənada obyekt yönümlü proqramlaşdırmadan daha çevikdir. Xüsusilə, iyerarxiyalardan asılı deyil. Məsələn, int və sətir arasında iyerarxik əlaqə yoxdur. Ümumi proqramlaşdırma ümumiyyətlə OOP-dən daha strukturlaşdırılmışdır; əslində, ümumi proqramlaşdırmanı təsvir etmək üçün istifadə olunan ümumi termin "parametrik polimorfizm"dir və "ad hoc polimorfizm" obyekt yönümlü proqramlaşdırma üçün müvafiq termindir. C++ kontekstində ümumi proqramlaşdırma kompilyasiya zamanı bütün adları həll edir; dinamik (işləmə vaxtı) göndərilməsini əhatə etmir. Bu, ümumi proqramlaşdırmanın iş vaxtı performansının vacib olduğu sahələrdə üstünlük təşkil etməsinə səbəb oldu.
Nəzərə alın ki, ümumi proqramlaşdırma panacea deyil. Proqramın parametrləşdirməyə ehtiyacı olmayan bir çox hissəsi və iş vaxtı göndərilməsinin (OOP) lazım olduğu bir çox nümunə var.
Yəni niyə C++ statik (kompilyasiya vaxtı) tipli təhlükəsizlik qaydalarını pozmaq üçün istifadə edilə bilən əməliyyatları dəstəkləyir?
Bununla belə, bu üç xüsusiyyətdən birinə ehtiyacınız olmadıqda vəba kimi təhlükəli kodlardan qaçınmaq yaxşı bir fikirdir:
Demək olar ki, bütün C++ kodu bu sadə qaydalara əməl edə bilər. C++ dilində C kodu və ya C tipli kod yazsanız, bu qaydalara əməl edə bilməyəcəyinizlə çaşqınlıq etməyin.
C++-nın səmərəliliyinə və çevikliyinə xələl gətirmədən istifadəsini asanlaşdırmaq və daha təhlükəsiz etmək üçün iddialı layihə üçün Əsas C++ Təlimatlarına baxın .
Hər insan üçün ən yaxşı kitab yoxdur. Biri ola bilməzdi. İnsanlar öyrənmə üsulu, artıq bildikləri, ehtiyac duyduqları, istədikləri və nə cür səy göstərməyə hazır olduqları baxımından çox fərqlidirlər. C++ üzrə kifayət qədər mükəmməl kitablar var.
Əvvəllər proqramlaşdırmayan və ya başqa dildən gələn və müasir C++ dili ilə nisbətən yumşaq bir şəkildə tanış olmaq istəyən insanlar üçün Proqramlaşdırma: C++ istifadə edərək Prinsiplər və Təcrübəni nəzərdən keçirin . Bu, birinci kurs tələbəsi (1-ci kurs universitet tələbələri) proqramlaşdırma sinfi üçün yazdığım kitabdır və üç illik sinif istifadəsindən faydalanmışdır.
Proqramçı olan və klassik dərslikdən yeni anlayışlar və texnikalar öyrənmək istəyən insanlar üçün mən The C++ Proqramlaşdırma Dilini (4-cü nəşr) tövsiyə edirəm . Kitab müəyyən təcrübəyə malik olan və C++ dilini mənimsəmək arzusunda olan proqramçılar üçün nəzərdə tutulub. Bu, ilk proqramlaşdırma dilini öyrənməyə çalışan proqramçı olmayanlara və ya C++ dilini səthi şəkildə mümkün qədər tez başa düşməyə çalışan təsadüfi proqramçılara yönəldilməyib. Nəticə etibarilə, bu kitab anlayışlara və texnikalara diqqət yetirir və tam və dəqiq olmaq üçün bəzi ağrılara gedir. O, “saf C++” dilini, yəni hər hansı xüsusi proqram təminatı inkişaf mühitindən və ya təməl kitabxanadan (əlbəttə ki, standart kitabxanadan başqa) müstəqil dili təsvir edir. Standart kitabxananın hərtərəfli əhatəsini ehtiva edir.
Əgər siz artıq təcrübəli proqramçısınızsa və C++-nın təklif etdiyi şeylərə qısaca nəzər salmaq istəyirsinizsə, C++ turunu nəzərdən keçirin (ikinci versiya) . O, C++ dilinin əsas xüsusiyyətlərini və onun standart kitabxanasını 200 səhifədə təqdim edir.
Əgər C++-nın niyə belə olduğunu bilmək istəyirsinizsə, C++ dilinin dizaynı və təkamülünə (D&E) nəzər salın. Dizayn meyarlarını və məhdudiyyətlərini başa düşmək daha yaxşı proqramlar yazmağa kömək edir. İzdihamlı və Dəyişən Dünyada İnkişaf: C++ 2006-2020 D&E-nin ən müasir davamı kimi görünə bilər.
Bu, “öyrənmək” dedikdə nəyi nəzərdə tutmağınızdan asılıdır. Əgər siz C proqramçısısınızsa, bir gündə sizi C tipli proqramlaşdırmada daha effektiv etmək üçün kifayət qədər C++ öyrənə bilərsiniz.
TAMU -da biz birinci kurs tələbələrini (1-ci kurs tələbələri) bir semestrdə C++ dilinin əsaslarını və onun dəstəklədiyi proqramlaşdırma üsullarını (xüsusilə obyekt yönümlü proqramlaşdırma və ümumi proqramlaşdırma ) öyrənmək üçün C++ istifadə edərək Proqramlaşdırma: Prinsiplər və Təcrübədən istifadə edirik.
Digər tərəfdən, bütün əsas C++ dili konstruksiyaları ilə, məlumatların abstraksiyası, Obyekt yönümlü proqramlaşdırma, ümumi proqramlaşdırma, Obyekt yönümlü dizayn və s. ilə tam rahat olmaq istəyirsinizsə, asanlıqla bir və ya iki il sərf edə bilərsiniz - əgər siz artıq bu üsullarla (məsələn, Java və ya C#-dan) tanış deyilsiniz.
C++ öyrənmək üçün bu qədər vaxt lazımdır? Ola bilsin, amma yenə də bu, daha yaxşı dizaynerlər və proqramçılar olmaq üçün nəzərə almalı olduğumuz müddətdir. Əgər iş tərzimizdə və sistemlərin qurulması haqqında düşüncələrimizdə kəskin dəyişiklik etmək bizim məqsədimiz deyilsə, onda niyə yeni dil öyrənməyə can atırıq? Pianoda yaxşı ifa etməyi öyrənmək və ya xarici (təbii) dildə sərbəst danışmaq üçün tələb olunan vaxtla müqayisədə yeni və fərqli proqramlaşdırma dilini və proqramlaşdırma üslubunu öyrənmək asandır.
C++ öyrənməklə bağlı əlavə müşahidələr üçün D&E və ya bir müddət əvvəl yazdığım comp.lang.c++ qeydinə baxın .
Səhv. C və C++ dillərinin ümumi alt çoxluğunu öyrənmək C ilə müqayisədə daha asandır. Əl ilə tutmaq üçün daha az tip səhvləri olacaq (C++ tipli sistem daha sərt və daha ifadəlidir), öyrənmək üçün daha az fəndlər (C++ daha çox şeyi dövriyyəsiz ifadə etməyə imkan verir) , və daha yaxşı kitabxanalar mövcuddur. Öyrənmək üçün ən yaxşı C++ ilkin alt dəsti "bütün C" deyil.
Erkən öyrənmə üçün C++ konstruksiyalarının, texnikalarının və kitabxanalarının seçimi ilə bağlı müzakirə üçün C++ dilinin yeni dil kimi öyrənilməsinə baxın . Bu yanaşmanı sistematik şəkildə qəbul edən kitabların nümunəsi üçün bax: Stroustrup: Proqramlaşdırma: C++ ilə Prinsiplər və Təcrübə və Koenig&Moo: Addison Wesley-nin C++ In Depth seriyasından “Accelerated C++” .
Xeyr. Yeni bir şey öyrənmək demək olar ki, həmişə yaxşı fikirdir. Bununla belə, hər bir dil fərqlidir və öz üslubları və qəribəlikləri var. Bəzi başqa dildə modelləşdirilmiş bəzi guya "təmiz" OO üslubunda yazılmış kodlar (qeyri-müəyyənliklər və hamısı) C++ dilinə hərfi mənada transkripsiya edildikdə, çox vaxt optimal deyil və əsəbi olur. Həmçinin, " sadəcə təmiz Obyekt yönümlü kod yazmaq " mənim ideallarımdan biri deyil; OOPSLA əsas məruzəmə baxın Nə üçün C++ sadəcə Obyekt yönümlü Proqramlaşdırma Dili deyil . Yaxşı bir C++ proqramçısı olmaq istəyirsinizsə və bir neçə ay vaxtınız yoxdursa, C++ və onun özündə cəmləşdirdiyi anlayışlara diqqət yetirin.
Təbii ki, bu, artıq bildiklərinizdən və C++ dilini öyrənmək üçün səbəblərdən çox asılıdır. Əgər proqramlaşdırmada təcrübəsizsinizsə, sizə kömək etmək üçün təcrübəli bir proqramçı tapmağınızı şiddətlə tövsiyə edirəm. Əks halda, dil anlayışları ilə bağlı qaçılmaz səhvlər və istifadə etdiyiniz tətbiqetmə ilə bağlı praktik problemlər ciddi məyusluqlara çevrilə bilər.
C++ dilini öyrənmək üçün sizə dərslik lazımdır. Tətbiqiniz kifayət qədər onlayn sənədlərlə təmin edildikdə belə belə olur. Səbəb odur ki, dil və kitabxana sənədləri nümunə kodla birlikdə yaxşı anlayış müəllimləri deyil. Tipik olaraq, bu cür mənbələr hər şeyin niyə belə olduğu və bir texnikadan hansı faydaları gözləyə biləcəyiniz (və hansını gözləməməli olduğunuz) barədə susur. Dil-texniki detallara deyil, anlayışlara və texnikalara diqqət yetirin.
Kitab seçərkən, Standart C++ dilini təqdim edən birini axtarın və əvvəldən standart kitabxana imkanlarından inteqrasiya olunmuş şəkildə istifadə edin. Məsələn, girişdən sətir oxumaq kimi bir şey görünməlidir
string s; // Standard C++ style
cin >> s;
və bu kimi deyil
char s[MAX]; /* Standard C style */
scanf("%s",s);
Möhkəm C++ təcrübəsi olan proqramçılardan kitab tövsiyələri axtarın.
Mən C++ istifadə edərək Proqramlaşdırma: Prinsiplər və Təcrübəni tövsiyə edirəm , lakin unutmayın ki, heç bir kitab hamı üçün ən yaxşısı deyil . ACCU (C və C++ İstifadəçiləri Assosiasiyası) saytındakı kitab rəylərinə nəzər salın .
İdiomatik C++ yazmağı hədəfləyin: C++ sintaksisindən istifadə edərək əvvəlki dilinizin üslubunda sadəcə kod yazmaqdan çəkinin; sadəcə sintaksisi dəyişməkdən çox az şey əldə etmək olar.
Üzr istəmə. Mən (başqalarının) ev tapşırıqlarını etmirəm. Ev tapşırığı ilə bağlı kömək və vaxt tapa bilmək üçün tələbə proqramlarında səhvləri tapmaqda kömək üçün çoxlu sorğular alıram. Hər halda, uzaq bir mütəxəssisin proqramlarınızı düzəltməsi öyrənmək üçün ən yaxşı yol deyil. Rəhbərlik istəyə biləcəyiniz C++ təcrübəsi olan yerli insan tapmağa çalışın. Yaxşı mentor bir tələbənin edə biləcəyi ən yaxşı köməkdir; bəlkə də buna görə onları tapmaq asan deyil.
Həm də, yox, “tələbənin üzərində işləməsi üçün yaxşı layihə” təklif etməyəcəyəm. Təcrübəm ondan ibarətdir ki, hansı çətinlik səviyyəsinin tələb olunduğunu və hansı layihənin maraq doğurduğunu bilmək üçün tələbə və onun kursu haqqında kifayət qədər öyrənmək vaxt tələb edir. Yaxşı bir layihə haqqında düşünmək o zaman qeyri-ciddidir və layihənin nə olduğunu və ona necə yanaşmaq lazım olduğunu dəqiq izah etmək bir neçə mesaj və bir neçə saat çəkə bilər. Sadəcə mənim belə vaxtım yoxdur. Unutmayın ki, bu sorğular ən azı həftədə bir gəlir. Nəhayət, bəzi tələbələrdə belə bir fikir var ki, əgər mən bir layihə təklif etsəm, onun başa çatmasında kifayət qədər ətraflı köməklik göstərməyə mənəvi cəhətdən borcluyam.
İdeyalar: TC++PL və ya digər yaxşı dərsliklərdəki məşqlərə baxın . Bu məşqlərin bir çoxu tələbəni bir neçə gün məşğul saxlamaq üçün nəzərdə tutulub və bu məşqləri oxumaq təşəbbüskar tələbəni buna bənzər bir şeyə ruhlandıra bilər. Və ya dünyanızın kompüter elmləri ilə əlaqəli olmayan hissəsinə baxın: Ola bilsin, biologiya layihəsi yeni ölçmə cihazı üçün dəstəkdən istifadə edə bilər və ya tarixi öyrənən dost təkmilləşdirilmiş verilənlər bazası interfeysindən istifadə edə bilər. Ən yaxşı layihələrin bir çoxu və kompüterlərin ən yaxşı istifadəsi ənənəvi kompüter elmləri xaricindədir.
Həmçinin mənim C++ üslubu və texnikaları ilə bağlı tez-tez verilən suallara baxın . İlk dəfə "məlumat oxuyun, ona bir şey edin və bəzi nəticələr çıxarın" məşqi ilə qarşılaşan real naşılar çox sadə proqram və ya girişdən sətir oxuyan proqramla maraqlana bilər .
Bir çox yerdən; mənim C++ tərtibçiləri siyahısına baxın .
Xeyr. Mən Danimarkalıyam. Bioqrafiyama nəzər salın .
deyə bilmədim. Bu, necə istifadə etdiyinizdən asılıdır. Əksər insanlar abstrakt sinifləri və şablonları düzgün qiymətləndirmirlər. Əksinə, insanların çoxu cast və makrolardan ciddi şəkildə istifadə edir. İdeyalar üçün sənədlərimdən və ya kitablarımdan birinə baxın . Mücərrəd siniflər və şablonlar haqqında düşünmə üsullarından biri funksiyalar və ya tək köklü sinif iyerarxiyaları vasitəsilə təmin etmək asan olandan daha təmiz və məntiqli xidmətlərin təqdimatına imkan verən interfeyslərdir. Bəzi xüsusi nümunələr və ideyalar üçün Stil və texnikalar üzrə Tez-tez verilən suallara baxın .
Bəli, amma möcüzə gözləməyin. Bəzi insanlar proqramlaşdırma dilinin sistem quruculuğu ilə bağlı problemlərinin çoxunu həll edə biləcəyinə və ya heç olmasa həll etməli olduğuna inanırlar. Onlar mükəmməl proqramlaşdırma dilini əbədi olaraq axtarmağa məhkumdurlar və dəfələrlə məyus olurlar. Digərləri proqramlaşdırma dillərini əhəmiyyətsiz "tətbiq detalları" kimi rədd edir və pullarını inkişaf proseslərinə və dizayn metodlarına qoyurlar. Onlar əbədi olaraq COBOL, C və mülkiyyət dizayn dillərində proqramlaşdırmaya məhkumdurlar. Yaxşı bir dil - məsələn, C++ - bir dizayner və proqramçı üçün çox şey edə bilər, yalnız onun güclü tərəfləri və məhdudiyyətləri aydın şəkildə başa düşülür və hörmət edilir.
Xeyr. Onlar yaxşı iş gördük. Siz təfərrüatlarla mübahisə edə bilərsiniz (mən də bəzən yüksək səslə edirəm), lakin mən dildən və yeni standart kitabxanadan razıyam. ISO C++ əvvəlki C++ versiyalarından daha yaxşı və daha ardıcıl bir dildir. Siz bu gün standartlar prosesi başlayanda mümkün olduğundan daha zərif və davamlı C++ proqramları yaza bilərsiniz. Yeni standart kitabxana da əsl nemətdir. Bu cür fundamental növlər üçün sətirlərin, siyahıların, vektorların, xəritələrin və əsas alqoritmlərin təmin edilməsi C++ dilinə yanaşma tərzində böyük fərq yaradır. Kitabxananın C++ Proqramlaşdırma Dili və ya C++ Turu və ya son məqalələrimdən birinə baxın .
1998-ci ildən bizdə var. İkinci standart 2011-ci ildə gəldi.
Mövcud standart, C++14 , 2014-cü ildə təsdiq edilib və yaxşı tətbiqetmə artıq göndərilir . C++11/C++14 kitablarımın cari nəşrlərində təsvir edilmişdir .
C++ standartı (ISO/IEC 14882) ANSI Elektron Mağazasında yükləmək üçün mövcuddur . "INCITS/ISO/IEC 14882-2003 Proqramlaşdırma Dilləri - C++" tapmaq üçün "14882" axtarın. Qiymət (mən bunu yazdığım kimi) kredit kartı ilə onlayn ödənilməli olan 30,00 ABŞ dollarıdır. Yüklənmiş sənəd PDF formasındadır, ümumi ölçüsü təxminən 3 Mb.
Standart, standartlaşdırma səyi və gecikmiş iş sənədi (pulsuz olaraq mövcuddur) haqqında məlumat üçün ISOcpp/standartlaşdırmaya baxın . Mövcud standart C++17-dir, lakin C++20 təsdiqlənib və 2020-ci ilin sonunda rəsmi olacaq.
Xəbərdar olun ki, standart dərslik deyil; hətta mütəxəssis proqramçılar da dərslikdən C++ və yeni C++ xüsusiyyətləri haqqında daha yaxşı öyrənəcəklər.
Həqiqətən yox. Bu cür sualı verən insanlar adətən çoxlu varislik, istisnalar, şablonlar və ya iş vaxtı növünün identifikasiyası kimi əsas xüsusiyyətlərdən birini düşünürlər. Bunlar olmadan C++ natamam olardı. Mən illər ərzində onların dizaynını nəzərdən keçirdim və standartlar komitəsi ilə birlikdə onların bəzi detallarını təkmilləşdirdim, lakin heç biri zərər vermədən silinə bilmədi.
Dil dizaynı baxımından bəyənmədiyim funksiyaların əksəriyyəti (məsələn, deklarator sintaksisi və massivlərin çürüməsi) C++ dilinin C alt çoxluğunun bir hissəsidir və real dünya şəraitində işləyən proqramçılara zərər vermədən silinə bilməz. C++-ın C uyğunluğu marketinq hiyləsi deyil, əsas dil dizayn qərarı idi. Uyğunluğa nail olmaq və saxlamaq çətin olub, lakin real proqramçılar üçün real faydalar nəticələnib və bu gün də nəticə verir. İndiyə qədər C++ proqramçıya ən çətin C funksiyalarından istifadə etməkdən çəkinməyə imkan verən xüsusiyyətlərə malikdir. Məsələn, vektor, siyahı, xəritə və sətir kimi standart kitabxana konteynerlərindən ən çətin aşağı səviyyəli göstərici manipulyasiyasının qarşısını almaq üçün istifadə edilə bilər.
Və C++17 və C++20. Bu, asanlıqla ümumiləşdiriləcək bir şey deyil. Əksər praktik məqsədlər üçün C++ 20 C++ 11 ilə geriyə uyğundur, yəni C++ 98 ilə demək olar ki, tamamilə geriyə uyğundur. Standartın arxasında uyğunluq məsələlərini təfərrüatlandıran uyğunluq bölməsi var.
Bu C++17 olacaq. C++ 17-nin nə təklif edəcəyini dəqiq söyləmək üçün bir az tezdir, lakin bu, böyük bir təkmilləşdirmə üçün nəzərdə tutulub və mən bəzi fikirlərimi 2015-ci ildə standartların iclasında təqdim etdim . Nəzərə alın ki, arzuladığım hər şeyi əldə edə bilməyəcəyəm. Təkliflərin tam siyahısı üçün WG21 saytına baxın .
Çapdadır: C++ Proqramlaşdırma Dili (4-cü Nəşr) . Addison-Wesley. ISBN 978-0321563842. May 2013.
İndi amazondan, naşirdən və başqa yerlərdən göndərilir .
5-ci nəşr üçün cari plan yoxdur.
C++ Proqramlaşdırma Dili ilk növbədə C++ dilini öyrənmək istəyən təcrübəli proqramçılar üçün yazılmışdır. Onun üslubu peşəkar kitabdır. Proqramlaşdırma - C++ istifadə edərək Prinsiplər və Təcrübə ilk növbədə C++ istifadə edərək proqramlaşdırma öyrənmək istəyən insanlar üçün yazılmışdır. O, proqramlaşdırma təcrübəsi olmayan və ya zəif olan insanlar, həmçinin C++ tərəfindən dəstəklənən obyekt yönümlü proqramlaşdırma və ümumi proqramlaşdırma kimi müasir proqramlaşdırma üsullarını öyrənmək istəyən insanlar tərəfindən istifadə/oxuya bilər. Onun üslubu dərslikdir.
Xülasə:
Mən cinayət hekayələri və SF üçün elektron kitabları sevirəm. Onların ciddi texniki məlumatlara hazır olduğunu düşünmürəm. Bunun üçün kağıza üstünlük verirəm - hətta bir neçə gün gözləməli olsam da, əlavə çəki götürsəm də. Stolun üstündə açılmış yaxşı dərslik iki səhifə göstərəcək - elektron kitab oxuyucudan təxminən üç dəfə çox sahə. Böyük, keyfiyyətli ekranda oxumaq yaxşıdır, sadəcə olaraq yaxşıdır.
Kitablarımın qanuni pulsuz maşın oxuna bilən nüsxələri yoxdur. Əgər siz nüsxəni sərbəst əldə edirsinizsə, bu, müəllif hüquqlarının pozulması olmalıdır (yəni oğurlanıb).
Addison-Wesley Safari onlayn kitablar xidməti və başqa yerlərdə elektron versiyaları təklif edir .
Mən tövsiyə etmirəm. Bu ədalətli olmazdı. Bununla belə, son buraxılış əldə edin. Təbii ki, yeni tərtibçilər ISO standartını bir neçə il əvvəlki kompilyatorlarla müqayisədə daha yaxından təxmin edirlər.
C++ tətbiqlərinin natamam siyahısı üçün mənim C++ tərtibçiləri siyahısıma baxın .
Həmçinin, mümkün olduqda, standart kitabxanaya qeyri-standart "təməl kitabxanalara" üstünlük verin və xüsusi genişlənmələrdən istifadəni minimuma endirməyə çalışın.
İnternetin bəzi guşələrinə görə, vektorların həmişə əlaqəli siyahılardan daha yaxşı olduğu və ağaclar (məsələn, std::set ) və hash cədvəlləri (məsələn, std) kimi digər məlumat strukturları haqqında məlumatım olmadığı təəssüratındayam. ::ordered_map ). Açığı, bu, absurddur.
Problem Con Bentlinin vaxtilə mənə təklif etdiyi maraqlı kiçik məşq kimi görünür: Təsadüfi tam ədədlər ardıcıllığını çeşidlənmiş ardıcıllığa daxil edin, sonra təsadüfi mövqelər ardıcıllığı ilə müəyyən edildiyi kimi həmin elementləri bir-bir çıxarın: Bir vektordan istifadə edirsinizmi ( elementlərin bitişik olaraq ayrılmış ardıcıllığı) yoxsa əlaqəli siyahı? Məsələn, İnfrastruktur üçün Proqram təminatına baxın . Mən bu nümunədən bəzi məqamları göstərmək üçün istifadə edirəm, alqoritmlər, məlumat strukturları və maşın arxitekturası haqqında düşünməyə təşviq edirəm, nəticədə:
Nəticədə ''siyahı'' və ''vektor''un olmamasına diqqət yetirin. Zəhmət olmasa, nümunə ilə misal göstərmək üçün nəzərdə tutulan şeyi qarışdırmayın.
Mən bu nümunədən bir neçə söhbətdə istifadə etdim, xüsusən:
Bu video məşhur olub: O, 250K dəfədən çox yüklənib (əlavə olaraq digər saytlarda daha 50K+ dəfə). Mənim təəssüratım belədir ki, bir çox izləyicilər bu nümunənin məqsədinin bəzi ümumi prinsipləri göstərmək və insanları düşündürmək olduğunu başa düşə bilmədilər. Başlanğıcda insanların çoxu ``Siyahı əlbəttə ki!'' deyir (mən bu sualı dəfələrlə verməyə çalışmışam) ``ortada` çoxlu əlavə və silinmələrə görə (siyahılar bunda yaxşıdır). Bu cavab tamamilə və kəskin şəkildə səhvdir, buna görə də səbəbini bilmək yaxşıdır.
Mən illərdir nümunədən istifadə edirəm və aspirantlara bu məşqin onlarla variantını və müxtəlif məşqləri həyata keçirib ölçməyi tapşırmışam. Başqalarının nümunələri və ölçmələri İnternetdə tapıla bilər. Əlbəttə,
Mənim fikrim o qədər də siyahılarla bağlı deyil . Onların istifadəsi var, lakin bu nümunə onlardan biri deyil. Zəhmət olmasa, nümunə ilə misalın təsvir etmək üçün istifadə edildiyini qarışdırmayın. Bu nümunə yaddaşdan istifadə haqqındadır: Biz çox vaxt verilənlər strukturu yaradırıq, onun üzərində giriş tələb edən bəzi hesablamalar edirik (tez-tez, keçid) və sonra onu silin. Sifarişli ardıcıllıq bu cür istifadənin sadəcə bir nümunəsidir və nümunə insanları belə hallarda nəyin vacib olduğu barədə düşünməyə vadar etmək üçün təqdim olunur. Mənim təklifim:
Cache effektlərinin əhəmiyyətini vurğulayıram. Təcrübəmə görə, həqiqi ekspertlər istisna olmaqla, alqoritmlər müzakirə olunanda bunları unudurlar.
Bəli, mənim tövsiyəm standart olaraq std::vector istifadə etməkdir. Daha ümumi olaraq, etməmək üçün yaxşı bir səbəb olmadığı təqdirdə bitişik təmsildən istifadə edin. C kimi, C++ da standart olaraq bunu etmək üçün nəzərdə tutulmuşdur.
Həmçinin, lütfən, ölçmələr olmadan performans haqqında açıqlama verməyin. Mən elə bir hal görmüşəm ki, sıfırdan iki elementli siyahını sıfırdan iki elementli vektora dəyişmək alqoritmdə iki faktorlu fərq yaradır. Mən bunu gözləmirdim. Digər ekspertlər də koda baxmadılar.
Xeyr. Java hətta yaxın deyil. İnsanlar C++ və Java-nı müqayisə etməkdə israr edərlərsə - göründüyü kimi - mən onlara C++ dilinin niyə belə olduğunu öyrənmək üçün The Design and Evolution of C++ (D&E) oxumağı və hər iki dili I dizayn meyarları işığında nəzərdən keçirməyi təklif edirəm. C++ üçün təyin edilir. Bu kriteriyalar Sun's Java komandasının meyarlarından açıq şəkildə fərqlənəcək. Sintaktik oxşarlıqlara baxmayaraq, C++ və Java çox fərqli dillərdir. Bir çox cəhətdən Java, C++ ilə müqayisədə Smalltalk-a daha yaxın görünür.
Java dilinin nisbi sadəliyinin çoxu - əksər yeni dillərdə olduğu kimi - qismən illüziya və qismən də onun natamamlığının funksiyasıdır. Zaman keçdikcə Java ölçüsü və mürəkkəbliyi baxımından əhəmiyyətli dərəcədə artacaq. Ölçüsü ikiqat və ya üçqat artacaq və tətbiqdən asılı genişlənmələr və ya kitabxanalar böyüyəcəkdir. Kommersiya baxımından uğurlu olan hər bir dil belə inkişaf etmişdir. Böyük miqyasda uğurlu hesab etdiyiniz istənilən dilə baxın. Mən heç bir istisna bilmirəm və bu fenomen üçün yaxşı səbəblər var. [Mən bunu 2000-ci ildən əvvəl yazmışdım; indi (2012), Java 7 spesifikasiyasının dil hissəsi səhifələrin sayı baxımından ISO C++11 dil spesifikasiyasından bir qədər uzundur.]
Mən Java şırıngası haqqında (mənfi) şərh etdim və Java-nın uğurlarının çoxunu marketinqlə əlaqələndirdim. Məsələn, mənim HOPL-3 sənədimə baxın . Bu gün (2010), Java haqqında edilən iddialar daha çox reallığa əsaslanır və alternativlər haqqında daha az təmənnasız olaraq alçaldıcıdır. Bu həmişə belə deyildi. Məsələn, 1995-ci ilin orijinal Java ağ kağızını internetdə tapdığınız versiyalarla (bəzən "orijinal Java ağ kağızı" etiketli) müqayisə edin; səhifə 69 başlamaq üçün yaxşı yer olardı.
Java platformadan müstəqil deyil; platformadır. Windows kimi, bu da xüsusi bir kommersiya platformasıdır. Yəni, siz Windows/Intel və ya Java/JVM üçün proqramlar yaza bilərsiniz və hər bir halda siz tək bir korporasiyaya məxsus olan və həmin korporasiyanın kommersiya xeyrinə düzəldilmiş platforma üçün kod yazırsınız. Qeyd edilmişdir ki, JVM və əlaqəli əməliyyat sistemləri üçün istənilən dildə proqramlar yaza bilərsiniz. Bununla belə, JVM və s. Java-nın lehinə çox qərəzlidir. Bu, ümumi ağlabatan dil baxımından neytral VM/OS olmağa yaxın deyil.
Şəxsən mən ən çox düşündüyüm iş növləri üçün ağlabatan portativ C++-a sadiq qalacağam və qalanları üçün müxtəlif dillərdən istifadə edəcəyəm.
Bir dil olaraq C# haqqında heç bir şərhim yoxdur. Məni inandırmaq üçün çox şey lazım olacaq ki, dünyanın başqa bir xüsusi dilə ehtiyacı var. Xüsusi mülkiyyət əməliyyat sistemi ilə sıx inteqrasiya olunmuş bir dilə ehtiyacı olduğuna məni inandırmaq xüsusilə çətin olacaq.
Yalnız .Net platforması üçün yazmaq istəyirsinizsə, C# ən pis alternativ deyil, lakin unutmayın ki, C++ bu platformada güclü şəkildə dəstəklənən – daha az qızışdırılan alternativdir.
C++/CLI, C++ dilinin Microsoft-un CLI (Ümumi Dil İnfrastrukturu) ilə son dərəcə tam “bağlanmasını” təmin edən ISO C++ genişləndirmələri dəstidir. ECMA (ECMA-372) tərəfindən standartlaşdırılıb. Mən xoşbəxtəm ki, bu, CLI-nin hər bir xüsusiyyətini C++ dilindən asanlıqla əldə etmək imkanı verir və xoşbəxtəm ki, C++/CLI sələfi “Managed C++” ilə müqayisədə daha yaxşı dildir. Bununla belə, C++/CLI-nin CLI-nin hər bir xüsusiyyəti (interfeyslər, xassələr, generiklər, göstəricilər, miras, sadalamalar və daha çox) üçün ayrıca dil xüsusiyyəti ilə C++-ı mahiyyətcə artırmaqla öz məqsədlərinə çatmasına az sevinirəm. Bu, əsas çaşqınlıq mənbəyi olacaq (kim nə edirsə və ya deyir). ISO Standard C++ ilə müqayisədə C++/CLI-də yeni dil imkanlarının zənginliyi proqramçıları (çox vaxt görünməz şəkildə) Microsoft Windows ilə sıx bağlı olan qeyri-portativ kod yazmağa sövq edir.
CLI ənənəvi interfeyslərdən əməliyyat sistemi vasitələrinə və tətbiqlərinə qədər çox fərqli interfeyslər toplusunu (sistem qurğularına) təmin edir. Xüsusilə, bu interfeyslər adi proqramlaşdırma dillərində tam və ya rahat şəkildə ifadə edilə bilməyən semantikaya malikdir. CLI-ni təsvir etməyin bir yolu (qismən) "platforma" və ya "virtual maşın" kimidir. O, çoxlu əsas kitabxanalar dəstini (BCL) dəstəkləyən çoxlu dil xüsusiyyətlərindən (miras, metodlar, döngə konstruksiyaları, geri çağırış mexanizmləri və s.) ibarətdir. CLI bəzən "dil neytral" kimi təsvir olunur. Bununla belə, bu vasitələrin böyük bir hissəsini qəbul etməyən dil hətta əsas .Net imkanlarından (və ya Microsoftun planlarının dəyişmədiyini fərz etsək, gələcək Microsoft Windows qurğularından) və bütün bu xüsusiyyətləri ifadə edə bilməyən dildən istifadə edə bilməz. digər dillər tərəfindən istifadə edilə bilən resursların həyata keçirilməsi üçün istifadə olunur. Beləliklə, CLI yalnız o mənada "dil neytraldır" ki, hər bir dil .Net-də "birinci dərəcəli" olmaq üçün bütün CLI xüsusiyyətlərini dəstəkləməlidir.
Mən bağlamanın hər hansı bir dildə sadə funksiya çağırışları və sadə verilənlər strukturları kimi ifadə oluna bilən, ola bilsin ki, dilə aid kitabxanalarda əhatə olunmuş bir neçə primitiv olmasına üstünlük verirəm. CLI üçün bu, ən yaxşı halda yalnız CLI qurğularının istehlakçıları üçün edilə bilər. CLI modullarını istehsal etmək üçün istifadə olunan dil metadata da daxil olmaqla bütün CLI vasitələrini ifadə edə bilməlidir. Yalnız bunu edə bilən dil .Net-də sistem proqramlaşdırma dili hesab edilə bilər. Beləliklə, Microsoft C++ komandası belə nəticəyə gəldi ki, yalnız daxili dil imkanları öz müştəriləri üçün məqbuldur. Onların dizaynı C++/CLI genişləndirmələri ilə CLI-nin hansı hissəsinin C++ dilində ifadə oluna biləcəyinə dair heç bir məhdudiyyəti qəbul etməyən bir mənzərəni əks etdirir, CLI imkanlarından istifadə edərkən digər dillərlə müqayisədə heç bir təfərrüat yoxdur və digər dillərlə müqayisədə heç bir əlavə xərc tələb olunmur. Onların məqsədi C++ dilini Windows üçün dominant sistem proqramlaşdırma dili kimi qoruyub saxlamaqdır.
Həmişə olduğu kimi, daşınma qabiliyyətinə böyük əhəmiyyət verirəm və insanlara proqramlar tərtib etməyi tövsiyə edirəm ki, sistemə xas qurğulara giriş ISO C++-da müəyyən edilmiş dəqiq müəyyən edilmiş interfeyslər vasitəsilə olsun (məsələn, C++/CLI-dən birbaşa istifadə etməmək). Windows-da bu, bəzən birbaşa C++/CLI qurğularından istifadə ilə müqayisədə əlverişsiz olacaq, lakin bu, daşınma qabiliyyəti və satıcıdan müəyyən dərəcədə müstəqillik əldə etməyin yeganə yoludur. Aydındır ki, əgər kod parçasının məqsədi digər kod tərəfindən istehlak ediləcək CLI interfeysini təmin etməkdirsə, CLI-yə bu silah uzunluğunda yanaşma təmin edilə bilməz. Nəzərə alın ki, mən sistemə xas genişlənmələrə ehtiyac olduğunu başa düşürəm və Microsoft bu cür genişləndirmələrə malik yeganə C++ təchizatçısı deyil, mən sadəcə ISO standartı C++-da göstərilən “nazik interfeys” vasitəsilə bu cür genişləndirmələrlə məşğul olmağa üstünlük verirəm.
Sistemə xas genişlənmələrlə necə məşğul olmaq mahiyyətcə çətin sualdır. Microsoft C++ komandası, xüsusilə Herb Sutter, ISO C++ standartları komitəsinin (digər) üzvləri ilə fəal dialoq apardı ki, ISO C++ və onun superset C++/CLI arasında əlaqə nəhayət işlənib hazırlansın. ISO C++ komitəsində uzunmüddətli konstruktiv birgə iş təcrübəmiz var. Həmçinin, ISO C++ və C++/CLI genişləndirmələri arasında çaşqınlığı minimuma endirmək üçün Microsoft indi C++/CLI-ni ISO C++-dan aydın şəkildə fərqləndirməyə çalışmaq üçün öz Visual C++ sənədlərini yenidən nəzərdən keçirir (sadəcə keyfiyyətsiz C++ ISO C++ deməkdir). Ümid edirəm ki, başqaları da bu yolu izləyəcəklər.
C++ üçün CLI bağlayıcısı/genişləndirmələrinin nə adlandırılacağı ilə bağlı çətin və mübahisəli suala görə mən “ISO C++-a CLI genişləndirmələri” üçün stenoqram kimi C++/CLI-yə üstünlük verirəm. C++ dilinin adın bir hissəsi kimi saxlanması insanlara əsas dilin nə olduğunu xatırladır və C++ dilini C++/CLI genişləndirmələri ilə C++ dilinin müvafiq alt çoxluğu saxlamağa kömək edəcək. C /C++ uyğunluğu problemləri həmin alt çoxluq xassəsini saxlamağın nə qədər vacib olduğunu nümayiş etdirir.
C++/CLI ilə əlaqəli bəzi sənədlər bunlardır:
Uğurlu proqram təminatı uzun ömürlüdür; onilliklərin ömrü qeyri-adi deyil. Yaxşı proqram/proqram tez-tez nəzərdə tutulduğu aparatdan, onun üçün yazılmış əməliyyat sistemindən, ilkin istifadə etdiyi verilənlər bazası sistemindən və s. ömrünü üstələyir. Çox vaxt yaxşı proqram təminatı qurmaq üçün istifadə olunan əsas texnologiyaları təmin edən şirkətləri ötür. o.
Çox vaxt uğurlu proqram/proqramın müxtəlif platformalara üstünlük verən müştəriləri/istifadəçiləri olur. İstifadəçi populyasiyası dəyişdikcə arzu olunan platformalar dəsti dəyişir. Tək platformaya və ya tək satıcıya bağlı olmaq proqramın/proqramın potensial istifadəsini məhdudlaşdırır.
Aydındır ki, platformanın tam müstəqilliyi platformanın bütün xüsusi imkanlarından istifadə etmək imkanı ilə uyğun gəlmir. Bununla belə, siz tez-tez proqramın öz mühitinə kitabxana kimi baxışını təmsil edən "nazik interfeys" vasitəsilə platforma qurğularına daxil olmaqla, proqram üçün platformanın müstəqilliyini təxmin edə bilərsiniz.
Xeyr. Bu söz-söhbəti kimin başlatdığını bilmirəm, amma bu, həddindən artıq həvəsli və ya pis niyyətli Ada fədaisi olmalıdır.
Xeyr, üzr istəmərəm. Səbəbini The Design and Evolution of C++ kitabının giriş qeydlərində tapa bilərsiniz :
"Bir neçə rəyçi məndən C++ dilini digər dillərlə müqayisə etməyi xahiş etdi. Mən bunu etməmək qərarına gəldim. Beləliklə, mən uzun müddətdir mövcud olan və qətiyyətlə qəbul edilən fikri bir daha təsdiqlədim: Dil müqayisələri nadir hallarda mənalı və hətta daha az ədalətli olur. Əsas proqramlaşdırmanın yaxşı müqayisəsi. dillər insanların çoxunun xərcləmək istədiyindən daha çox səy, geniş tətbiq sahələrində təcrübə, ayrı və qərəzsiz nöqteyi-nəzərdən ciddi şəkildə qorunma və ədalət hissi tələb edir.Vaxtım yoxdur və dizayner kimi C++ dili ilə bağlı mənim qərəzsizliyim heç vaxt tam etibarlı olmazdı.
Dil müqayisələrində dürüst cəhdlərdə dəfələrlə müşahidə etdiyim bir fenomen məni də narahat edir. Müəlliflər qərəzsiz olmağa çox çalışırlar, lakin proqramçılar arasında vahid proqrama, vahid proqramlaşdırma tərzinə və ya vahid mədəniyyətə diqqət yetirməklə ümidsizcə qərəzli olurlar. Daha da pisi, bir dil digərlərindən əhəmiyyətli dərəcədə yaxşı tanındıqda, perspektivdə incə dəyişiklik baş verir: Tanınmış dildəki qüsurlar kiçik hesab olunur və sadə həllər təqdim olunur, digər dillərdə oxşar qüsurlar isə əsas hesab olunur. Çox vaxt daha az tanınan dillərdə istifadə olunan həll yolları müqayisə aparan insanlar üçün sadəcə olaraq bilinmir və ya qeyri-qənaətbəxş hesab edilir, çünki onlar daha tanış dildə işlənməyəcəkdir.
Eynilə, tanınmış dil haqqında məlumat tamamilə yenilənməyə meyllidir, az tanınan dil üçün isə müəlliflər bir neçə illik məlumatlara əsaslanır. Müqayisə etməyə dəyər dillər üçün, son eksperimental tətbiqdə göründüyü kimi, üç il əvvəl müəyyən edilmiş X dili ilə Y dilinin müqayisəsi nə ədalətli, nə də informativdir. Beləliklə, mən C++ dillərindən başqa dillər haqqında şərhlərimi ümumi və çox konkret şərhlərlə məhdudlaşdırıram."
Bununla belə, mən C++ dilini müxtəlif insanlar və tətbiqlər üçün proqramlaşdırma dilində ən yaxşı seçim hesab edirəm.
Bu, səriştəsizcəsinə və ya kommersiya məqsədi ilə edildiyi zaman edir. Ən çox yayılmış müqayisələr Z-nin digər dillərdən daha yaxşı olduğunu sübut etmək üçün hansısa dilin tərəfdarları olan Z tərəfindən yazılmış müqayisələrdir. Geniş istifadəsini nəzərə alaraq, C++ tez-tez Z tərəfdarlarının aşağı olduğunu sübut etmək istədikləri dillər siyahısında birinci yerdədir. Çox vaxt bu cür sənədlər marketinq kampaniyasının bir hissəsi kimi Z-ni satan şirkət tərəfindən "nəşr olunur" və ya yayılır. Təəccüblüdür ki, bir çoxları Z satan bir şirkətdə çalışan insanlar tərəfindən yazılan, Z-nin ən yaxşı olduğunu "sübut edən" nəzərdən keçirilməmiş kağızı qəbul edir. Problemlərdən biri odur ki, bu cür müqayisələrdə həmişə həqiqət dənəsi var. Axı, heç bir dil bütün mümkün yollarla hamıdan yaxşı deyil. C++, əlbəttə ki, mükəmməl deyil, lakin seçmə həqiqət ən cazibədar və bəzən tamamilə yanıltıcı ola bilər.
Dil müqayisəsinə baxarkən onu kimin yazdığına fikir verin, təsvirlərin faktiki və ədalətli olub-olmadığını, həmçinin müqayisə meyarlarının nəzərdən keçirilən bütün dillər üçün ədalətli olub olmadığını diqqətlə nəzərdən keçirin. Bu asan deyil.
Mən diatribes yazmıram (bu, bəzi mətnin düşmən xarakteristikasıdır), amma mən bunu ağlabatan hesab edirəm - bəlkə də bir vəzifə - bir dili onun fəzilətlərini izah etmək və onu düşmən xarakteristikalardan müdafiə etmək üçün dizayn edən biri üçün. Mənim nəşrlərim siyahısına baxın . Xüsusilə, ACM Proqramlaşdırma Konfransı Tarixi üçün geniş və nəzərdən keçirilmiş sənədlərimə baxın:
Çox vaxt mən C++ dilinin məhdudiyyətlərini və C++ dizaynının əsas fərziyyələrini qeyd edirəm (məsələn, D&E-ə baxın ).
Mənim fikrimcə yox. Mən heç vaxt C-nin C++-dan daha yaxşı olduğu bir layihə görmədim, ancaq yaxşı bir C++ kompilyatorunun olmaması.
Ciddi riyazi mənada C C++ dilinin alt çoxluğu deyil. Etibarlı C olan, lakin etibarlı olmayan C++ proqramları və hətta C və C++ dillərində fərqli məna daşıyan kod yazmağın bir neçə yolu var. Bununla belə, C++ C tərəfindən dəstəklənən hər bir proqramlaşdırma texnikasını dəstəkləyir. Hər bir C proqramı eyni işləmə vaxtı və məkan səmərəliliyi ilə C++ dilində mahiyyətcə eyni şəkildə yazıla bilər. Bir neçə saat ərzində on minlərlə ANSI C sətirini C tipli C++ dilinə çevirmək qeyri-adi deyil. Beləliklə, C++ 1985-ci ildə mövcud olduğu kimi ANSI C K&R C və ISO C++ C++ dilinin üst dəsti olduğu kimi ANSI C-nin üst dəstidir.
Yaxşı yazılmış C də qanuni C++ olur. Məsələn, Kernighan & Ritchie-dəki hər bir nümunə: "The C Programming Language (2nd Edition)" həm də C++ proqramıdır.
C/C++ uyğunluğu problemlərinin nümunələri:
int main()
{
double sq2 = sqrt(2); /* Not C++: call undeclared function */
int s = sizeof('a'); /* silent difference: 1 in C++ sizeof(int) in C */
}
Elan edilməmiş funksiyanın çağırılması C-də pis üslubdur və C++-da qeyri-qanunidir. Arqument növlərini siyahıya almayan bəyannamədən istifadə edərək funksiyaya arqumentlərin ötürülməsi də belədir:
void f(); /* argument types not mentioned */
void g()
{
f(2); /* poor style C. Not C++ */
}
C-də boşluq* istənilən göstərici tipinə çevrilə bilər və pulsuz mağazanın ayrılması adətən "kifayət qədər" yaddaş tələb olunub-olunmadığını yoxlamaq imkanı olmayan malloc() istifadə edərək həyata keçirilir:
void* malloc(size_t);
void f(int n)
{
int* p = malloc(n*sizeof(char)); /* not C++. In C++, allocate using `new' */
char c;
void* pv = &c;
int* pi = pv; /* implicit conversion of void* to int*. Not in C++ */
}
Boşluğun* int*-ə gizli çevrilməsi nəticəsində yaranan potensial uyğunlaşdırma xətasına diqqət yetirin. void* və malloc() üçün C++ alternativinə baxın .
C-dən C++-a çevirərkən diqqətli olun ki, C++-da C-dən daha çox açar sözlər var:
int class = 2; /* ok in C. Syntax error in C++ */
int virtual = 3; /* ok in C. Syntax error in C++ */
Yuxarıda göstərilənlər (və C++ standartında və C++ Proqramlaşdırma Dilinin (3-cü Buraxılış) B Əlavəsində ətraflı sadalananlar ) kimi bir neçə nümunə istisna olmaqla, C++ C dilinin üst dəstidir. (Əlavə B yükləmək üçün mövcuddur) .
Nəzərə alın ki, yuxarıdakı paraqraflardakı "C" Klassik C və C89-a aiddir. C++ C99-un nəslindən deyil; C++ və C99 qardaşdır. C99 C/C++ uyğunsuzluqları üçün bir sıra yeni imkanlar təqdim edir .
C++, demək olar ki, bütün C-ni alt çoxluq kimi saxlayan C dilinin birbaşa törəməsidir. C++ C ilə müqayisədə daha güclü tip yoxlanışını təmin edir və birbaşa C ilə müqayisədə daha geniş proqramlaşdırma üslublarını dəstəkləyir. C++ daha yaxşı tip yoxlanışı və daha çox qeyd dəstəyi ilə (itkisiz) C istifadə edərək edilən proqramlaşdırma üslublarını dəstəkləməsi mənasında “daha yaxşı C”dir. səmərəlilik). Eyni mənada, ANSI C K&R C-dən daha yaxşı C dilidir. Bundan əlavə, C++ verilənlərin abstraksiyasını, obyekt yönümlü proqramlaşdırmanı və ümumi proqramlaşdırmanı dəstəkləyir ( kitablarıma baxın ).
Mən heç vaxt C-də C++-dan daha yaxşı ifadə oluna bilən proqram görməmişəm (və belə bir proqramın mövcud ola biləcəyini düşünmürəm - C-də hər konstruksiya açıq-aydın C++ ekvivalentinə malikdir). Bununla belə, hələ də C++ dəstəyinin o qədər zəif olduğu bir neçə mühit mövcuddur ki, bunun əvəzinə C-dən istifadə etmək üstünlükdür. Baxmayaraq ki, qalanların hamısı o qədər də çox deyil; mənim (natamam) tərtibçilər siyahısına baxın .
C++ dizaynının müzakirəsi, o cümlədən onun C ilə əlaqəsinin müzakirəsi üçün C++ dizaynı və təkamülünə baxın .
Nəzərə alın ki, yuxarıdakı paraqraflardakı "C" Klassik C və C89-a aiddir. C++ C99-un nəslindən deyil; C++ və C99 qardaşdır. C99 C/C++ uyğunsuzluqları üçün bir sıra yeni imkanlar təqdim edir . Burada C++98 və C99 arasındakı fərqlərin təsviri verilmişdir .
Düşünürəm ki, C/C++ icması üçün çox yaxşı olardı. Yəni C/C++ uyğunsuzluqları sistematik və tamamilə aradan qaldırılsa və gələcək təkamül yeni uyğunsuzluqların yaranmasının qarşısını almaq üçün təşkil edilsəydi. Bunun mümkün olub-olmaması başqa məsələdir.
Mənim əsas fikrim odur ki, mövcud C/C++ uyğunsuzluqları heç bir fundamental səbəbləri olmayan “tarixin qəzalarıdır” (baxmayaraq ki, bəzi səriştəli və yaxşı niyyətli insanlara hamısı “o vaxt yaxşı fikir kimi görünürdü”). C/C++ uyğunsuzluqları bütövlükdə cəmiyyətə heç bir fayda vermir, C/C++ icmasının böyük bir hissəsinə ciddi problemlər yaradır və böyük çətinliklə aradan qaldırıla bilər.
C/C++ uyğunluğu ilə bağlı fikirlərimin daha ətraflı təqdimatı üçün bu barədə yazdığım məqalələr seriyasına baxın:
Təsəvvür edirəm ki, əgər uyğunsuzluqlar aradan qaldırılsa (həm C, həm də C++ dillərində dəyişiklik etməklə), hələ də C və C++ adlanan obyektlər olacaq, lakin o zaman C həqiqətən C++ alt çoxluğu kimi müəyyən ediləcək .
Nəzərə alın ki, bu sənədlər 2001-ci ilin sonu və 2002-ci ilin əvvəllərində C və C++ standartları komitələri tərəfindən onilliyin sonuna qədər praktiki nəticələrə gətirib çıxaran əlaqələndirilmiş fəaliyyəti təsəvvür etmək hələ mümkün olduğu vaxtlarda yazılmışdır. Bu baş vermədi.
İstərdim ki, C++ hətta ən tələbkar sistem proqramlaşdırması üçün kifayət qədər performansa və çevikliyə malik tam dillə uyğun olsun. Qəsdən məhdudiyyətləri olan başqa bir gözəl dil yaratmaqdan mükəmməl qorxurdum. Tarixi təfərrüatlar üçün C++ dizaynının və təkamülünün 2.7-ci bölməsinə baxın və siz həqiqətən düşünürsünüz ... məqalələrindəki məqalələri oxuyun . C/C++ uyğunluğu məsələlərinin (retrospektiv) texniki müzakirəsi üçün.
O zaman mən C dilini mövcud olan ən yaxşı sistem proqramlaşdırma dili hesab edirdim. Bu, o vaxt (1979) sonradan göründüyü kimi aydın deyildi, amma dəhlizdə mənim Dennis Riçi , Stiv Conson, Sendi Freyzer , Qreq Çesson, Daq Makilroy və Brayan Kerniqan kimi ekspertlərim var idi ki, onlardan öyrənə və rəy ala bildim. Onların köməyi və məsləhəti olmasaydı və C olmasaydı, C++ ölü doğulmuş olardı.
Təkrarlanan şayiələrin əksinə olaraq, mənə heç vaxt C-dən istifadə etməli olduğumu söyləmədilər; nə də mənə heç vaxt C-dən istifadə etməməyim deyilməyib. Əslində, ilk C++ təlimatı Dennisin mənə verdiyi C təlimatının troff mənbəyindən yaranıb. Bell laboratoriyalarında bir çox yeni dillər hazırlanmışdır; “Araşdırma”da heç olmasa dil təəssübkeşliyini tətbiq edən qaydalar yox idi.
Xeyr, bu, tez-tez aldığım sual deyil. Bu mənada, bu tez-tez verilən suallarda yeganə "saxta tez-tez verilən suallar"dır. Bununla belə, bu, tez-tez verilən suallar olmalıdır, çünki insanlar “C/C++” dilini sanki konkret bir məna ifadə edirmiş kimi istifadə edirlər və sanki bunun nə demək olduğunu bilirlər, bu da çox qarışıqlıq və bədbəxtliyə səbəb olur. İnsanlar “C/C++ nədir?” sualını verməlidirlər. və sonra düşünərkən bu termindən istifadə etməyi dayandırın. Zərər verir.
“C/C++” deyilən dil yoxdur. Bu ifadə adətən proqramlaşdırma haqqında heç bir ipucu olmayan insanlar tərəfindən istifadə olunur (məsələn, HR işçiləri və zəif menecerlər). Alternativ olaraq, sadə C++ dilini bilməyən (və çox vaxt C dilini də bilməyən) insanlar tərəfindən istifadə olunur. Proqramçılar tərəfindən istifadə edildikdə, adətən "C++ bir neçə faydalı və bir çox faydasız mürəkkəb funksiyalar əlavə edilmiş C-dir" münasibətini göstərir. Çox vaxt bu, printf və memcpy xaricində standart kitabxana haqqında az biliyi ilə öz sətirlərini və hash cədvəllərini yazmağı sevən insanların nöqteyi-nəzəridir. Mükəmməl yaxşı səbəblərə görə məhdud C++ alt çoxluğuna sadiq qalan insanlar var, lakin onlar (diqqət etdiyim qədər) “C/C++” deyən insanlar deyil.
Mən C/C++ dilini yalnız “C/C++ uyğunluğu” və “C/C++ icması” kimi ifadələrdə istifadə edirəm.
Mən 1979-cu ildə C++ olan şey üzərində işə başladım. İlkin versiya “C with Classes” adlanırdı. C++ dilinin ilk versiyası 1983-cü ilin avqustunda AT&T-də daxili olaraq istifadə edildi. "C++" adı həmin ilin sonunda istifadə edildi. İlk kommersiya tətbiqi 1985-ci ilin oktyabrında The C++ Proqramlaşdırma Dilinin 1-ci nəşrinin nəşri ilə eyni vaxtda buraxıldı . Şablonlar və istisnaların idarə edilməsi daha sonra 1980-ci illərdə daxil edilmiş və The Annotated C++ Reference Manual və The C++ Programming Language (2-ci Nəşr) sənədlərində sənədləşdirilmişdir . İlk ISO C++ standartı The C++ Proqramlaşdırma Dilində (3-cü Nəşr) təsvir olunduğu kimi C++98 idi .
C++ dilinin cari tərifi The C++ Proqramlaşdırma Dilində (4-cü Buraxılış) təsvir edilən 2011 ISO C++ Standartı .
Siz C++ dilinin dizaynı və təkamülü və C++ tarixi: 1979-1991 və real dünyada dilin inkişafı: C++ 1991-2006-da daha dolğun vaxt qrafiki və daha ətraflı izahat tapa bilərsiniz .
Simula67 tərəfindən təşviq edilən üslublarda səmərəli sistem proqramları yazmaq istədim. Bunun üçün mən C-yə daha yaxşı tip yoxlanışı, verilənlərin abstraksı və obyekt yönümlü proqramlaşdırma üçün imkanlar əlavə etdim. Daha ümumi məqsəd həm səmərəli, həm də zərif proqramlar yaza biləcəyim bir dil dizayn etmək idi. Bir çox dillər sizi bu iki alternativ arasında seçim etməyə məcbur edir.
C++ dilini (əvvəlcə “Siniflərlə C” adlanırdı) layihələndirməyə və tətbiq etməyə başlamama səbəb olan xüsusi tapşırıqlar əməliyyat sistemi vasitələrinin şəbəkə üzrə paylanması ilə bağlı idi.
Daha ətraflı izahatları C++ dilinin dizaynı və təkamülündə tapa bilərsiniz . Həmçinin baxın A History of C++: 1979-1991 and Evolving a language in and for real world: C++ 1991-2006 .
Mən C++ dilini ilk dəfə inkişaf etdirdiyim zaman AT&T əksər təşkilatlardan daha mürəkkəb və etibarlılıq tələbləri olan sistemlər qurdu. Nəticə etibarilə, biz bazara təsir etməli və ehtiyaclarımıza cavab verən standartların müəyyən edilməsinə kömək etməli olduq, əks halda sistemlərimizi qurmaq üçün alətlərimiz olmayacaqdı. Özünə qalan "sənaye" "orta" problemlərin həlli üçün dillər və alətlər yaradacaq. Eynilə, müəllimlər tələbələrə və tədqiqatçılara yaxşı xidmət edən dillərə və alətlərə diqqət yetirməyə meyllidirlər - hətta ən tələbkar tapşırıqları yerinə yetirməsələr də.
Mən C++-nı inkişaf etdirdiyim dövrdə - və ondan əvvəl Ken Thompson və Dennis Ritchie Unix və C-ni inkişaf etdirəndə - AT&T, yəqin ki, proqram alətlərinin dünyanın ən böyük mülki istifadəçisi (və istehlakçı) idi. Sonra, yəqin ki, biz daha geniş sistemlərdən istifadə etdik - ən kiçik daxili prosessorlardan tutmuş ən böyük superkompüterlərə və məlumat emal sistemlərinə qədər. Bu, bir çox texniki mədəniyyətlərdə və bir çox platformada tətbiq oluna bilən sistemlərə üstünlük verdi. C və C++ belə tələblər nəzərə alınmaqla hazırlanmışdır.
Beləliklə, ümumilik vacibdir və mülkiyyət xüsusiyyətləri platformaların və satıcıların seçimini məhdudlaşdıran kimi görünür. Nəticədə AT&T formal standartların (məsələn, ISO C və ISO C++) əsas tərəfdarı olmuşdur və belədir.
Əslində, AT&T mənim orijinal C++ kompilyatorum olan Cfront-da C++ dilinin inkişafı üçün bir neçə dəfə ödəmək üçün kifayət qədər pul qazandı.
Xeyr. Əgər hər kəs "C++" sahibidirsə, bu ISO olmalıdır. AT&T ISO-ya yazdığım C++ təlimatının hüquqlarını verdi. ISO C++ standartının müəllif hüquqları ISO tərəfindən qorunur.
Kompilyator satıcıları mənə və ya C++ üçün AT&T-yə qonorar ödəmirlər və ISO standartları hər kəs tərəfindən qonorarsız istifadə üçün nəzərdə tutulmuş spesifikasiyalardır (standartın surəti üçün İSO və ya milli standart komitəsinə ödəniş etdikdən sonra). Fərdi tərtibçilər müvafiq təchizatçılara/təchizatçılara məxsusdur.
"Lakin ŞƏT-dən kimsə C++-a sahib olduqlarını iddia etdi"; belə deyilmi? Tam zibildir. Həmin müsahibəni görmüşəm. ŞƏT adamının C++ dilinin nə olduğu barədə heç bir fikri yox idi və onu “C++ dilləri” adlandırırdı. Ən çox, ŞƏT Cfront-un 15 illik və ciddi şəkildə köhnəlmiş versiyasına sahib ola bilər - mənim orijinal C++ kompilyatorum. C++ ilə heç bir əlaqəsi olmayan patent və ya ticarət nişanı almamağa diqqətli idim. Bu, "C++(tm)" deyil, sadə "C++" yazmağımızın bir səbəbidir. C++ standartında patentlər yoxdur - komitə bunu da diqqətlə yoxladı.
D&E -nin 3-cü fəsli : ``Mən C++ dilini seçdim, çünki o, qısa idi, gözəl şərhləri var idi və "sifət C" şəklində deyildi.' C dilində ++ kontekstdən asılı olaraq "növbəti" kimi oxuna bilər. Həmişə "plus plus" kimi tələffüz olunsa da, "varis" və ya "artım". C++ adı və onun ikincisi ++C zarafat və söz oyunu üçün münbit mənbələrdir -- demək olar ki, hamısı ad seçilməzdən əvvəl məlum idi və yüksək qiymətləndirilmişdi. C++ adını Rik Mascitti təklif etmişdir. İlk dəfə 1983-cü ilin dekabrında [Stroustrup, 1984] və [Stroustrup, 1984c] son nüsxələrində redaktə edildikdə istifadə edilmişdir.
TC++PL -nin 1-ci Fəsli : ``C++ adı ("bax plus plus" kimi oxunur) 1983-cü ilin yayında Rick Mascitti tərəfindən yaradılmışdır. Bu ad C-dən dəyişikliklərin təkamül xarakterini bildirir; "++" C artım operatorudur. Bir qədər qısa olan "C+" adı sintaksis xətasıdır; qohum olmayan bir dilin adı kimi də işlənmişdir. C semantikasının biliciləri C++ dilini ++C-dən aşağı hesab edirlər. Bu dil D adlandırılmır, çünki o, C-nin uzantısıdır və xüsusiyyətləri aradan qaldıraraq problemləri həll etməyə çalışmır. C++ adının başqa bir təfsiri üçün [Orwell, 1949] əlavəsinə baxın.''
C++ dilində ``C`` uzun tarixə malikdir. Təbii ki, bu, Dennis Ritchie-nin tərtib etdiyi dilin adıdır. C-nin bilavasitə əcdadı Ken Thompson tərəfindən hazırlanmış B adlı BCPL-nin təfsir edilmiş nəslindən idi. BCPL digər Kembricdə MİT-də olarkən Kembric Universitetindən Martin Riçards tərəfindən hazırlanmış və həyata keçirilmişdir. BCPL öz növbəsində Basic CPL idi, burada CPL Kembric və London universitetləri tərəfindən birgə hazırlanmış kifayət qədər böyük (öz vaxtı üçün) və zərif proqramlaşdırma dilinin adıdır. Londonlular layihəyə qoşulmazdan əvvəl “C” Kembric üçün dayanırdı. Daha sonra "C" rəsmi olaraq Combined üçün dayandı. Qeyri-rəsmi olaraq, "C" Kristoferi təmsil edirdi, çünki Kristofer Straçi CPL arxasında əsas güc idi.''
İlk C++ kompilyatoru (Cfront) C++ dilində yazılmışdır. Bunu qurmaq üçün mən ilk olaraq C-dən C-dən C-yə qədər olan `` Siniflərlə C'' preprosessorunu yazmaq üçün istifadə etdim. ``C with Classes'' C++ dilinin bilavasitə əcdadı olan C ləhcəsi idi. Bu preprosessor "C ilə Sinif" konstruksiyalarını (məsələn, siniflər və konstruktorlar) C dilinə tərcümə etdi. Bu, bütün dili başa düşməyən, C kompilyatorunun etməli olduğu növün əksəriyyətini yoxlayan və fərdi tərcümə edən ənənəvi preprosessor idi. tam biliyi olmadan qurur. Daha sonra Cfront-un ilk versiyasını "C with Classes"də yazdım.
Cfront, C++ mənbəyinin tam sintaksisi və semantik yoxlanışını həyata keçirən ənənəvi tərtibçi idi. Bunun üçün onun tam analizatoru var idi, simvol cədvəlləri qurdu və hər bir sinfin, funksiyanın və s. üçün tam daxili ağac təsvirini qurdu. O, həmçinin C-ni çıxarmazdan əvvəl C++ konstruksiyalarının daxili ağac təsvirində bəzi mənbə səviyyəsində optimallaşdırma etdi. yaradılan C, hər hansı bir növ yoxlama üçün C-yə etibar etmədi. O, sadəcə C-dən assembler kimi istifadə edirdi. Nəticədə kod güzəştsiz sürətli idi. Əlavə məlumat üçün D&E-ə baxın .
Bu çox məşhur görünür. Daha doğrusu, C++-ın uğurunun bir növ təsadüf olması barədə heç bir fikrim olmadığını iddia etmək məşhur görünür. Bəli, bu cür bəyanatlar məni qıcıqlandırır, çünki onilliklər ərzində mənim işimi və bir çox dostlarımın zəhmətini rədd edirlər.
Gəlin əvvəlcə tam aydın olaq: Xeyr, mən C++ dilinin uğurunu gözləmirdim və yox, C++ ilə istifadə olunan hər bir texnikanı və ya C++-ın hər bir tətbiqini qabaqcadan görmədim. Əlbəttə yox!
Ancaq bu kimi ifadələr çox yanıltıcıdır:
Bu tez-tez verilən suallar bu gün bunları və daha bir neçəsini görməkdən irəli gəlir.
Mən C++ dilinin dizaynı və tətbiqi üçün meyarları təsvir etdim. Mən açıq şəkildə ümumiliyi hədəflədim: "Məni yalnız təsəvvür edə bildiklərimi edə bilən bir dil maraqlandırmır" və səmərəlilik üçün "obyekt yalnız faydalı olmamalıdır, həm də əlverişli olmalıdır." Mən şübhə edənlərə C++-ın Dizaynı və Təkamülünü və mənim HOPL2 və HOPL3 sənədlərimi oxumağı təklif edirəm (bunlar resenziyalı məqalələrdir). Deterministik məhvə gəlincə, bu, ilk və ya iki həftədə (1979) "C sinifləri ilə" idi. Mən RAII (1988) kəşf edənə qədər C++ dilinə istisnaların tətbiqini yarım il saxladım. RAII C++ istisna mexanizminin ayrılmaz və zəruri hissəsidir.
Jeremy Siek , sonradan std::conditional olarsa , kompilyasiya vaxtını mənə ilk dəfə göstərəndə çox təəccübləndim , lakin mən ümumiliyi hədəfləmişdim (və Turing tamlıq modulu tərcümə limitlərini əldə etdim). Erwin Unruh ilk şablon metaproqramı ISO Standartları Komitəsinin təkamül üzrə işçi qrupuna təqdim edəndə dərhal C++-a məhdudiyyətlərin əleyhinə çıxdım. Şablon-metaproqramlaşdırmanı öldürmək üçün etməli olduğum tək şey heç nə deməmək idi. Əvəzində şərhim "Vay, bu səliqəlidir! Biz buna güzəştə getməməliyik. Bu faydalı ola bilər." Bütün güclü ideyalar kimi, şablon-metaproqramlaşdırma da sui-istifadə və həddən artıq istifadə edilə bilər, lakin bu, kompilyasiya vaxtının hesablanmasının əsas ideyasının pis olduğunu ifadə etmir. Və bütün güclü ideyalar kimi, təsirlər və üsullar da zamanla bir çox şəxslərin töhfələri ilə ortaya çıxdı.
Təqaüd üçün vikipediyaya baxmaqdan, sürətli Google axtarışından və bir neçə blog yazısından daha çox şey var. İxtira üçün sadə nəticələr siyahısını verməkdən daha çox şey var. Əsas prinsiplər və dizayn qaydaları vacibdir. C++ dizaynının mənim hissəsi çoxlarının töhfə verməsi üçün imkan yaratdı və yazılarıma və elanlarıma baxsanız, görərsiniz ki, mən çox çalışaraq kredit verməyə çalışıram (məsələn, C++11 FAQ- ın istinad bölmələrinə baxın ) və ya kitablarımın tarix bölmələri .
Xeyr, mən gəzən C++ lüğəti deyiləm. Mən hər zaman hər texniki detalı beynimdə saxlamıram. Bunu etsəydim, daha kasıb proqramçı olardım. Əsas məqamları çox vaxt başımda saxlayıram və ehtiyac duyduğum zaman təfərrüatları haradan tapacağımı bilirəm. Misal üçün:
Əgər siz zibilin avtomatik yığılmasını istəyirsinizsə, C++ üçün yaxşı kommersiya və ictimai zibil yığanlar var. Zibil toplanmasının uyğun olduğu proqramlar üçün C++ digər zibil toplanmış dillərlə yaxşı müqayisə edən performansa malik əla zibil toplanmış dildir. C++ dilində avtomatik zibil yığılması ilə bağlı müzakirə üçün C++ Proqramlaşdırma Dilinə baxın . Həmçinin bax, Hans-J. C və C++ zibillərinin toplanması üçün Boehm saytı .
Həmçinin, C++ yaddaşın idarə edilməsini zibil toplayıcı olmadan təhlükəsiz və gizli saxlamağa imkan verən proqramlaşdırma üsullarını dəstəkləyir . Mən zibil yığımını son seçim və resursların idarə edilməsi üçün qeyri-kamil üsul hesab edirəm. Bu, heç vaxt faydalı olmadığı anlamına gəlmir, bir çox hallarda daha yaxşı yanaşmalar var.
C++11 GC ABI təklif edir.
Mən zibil sevmirəm. Mən zibil atmağı sevmirəm. Mənim idealım heç bir zibil istehsal etməməklə zibil yığan ehtiyacı aradan qaldırmaqdır. Bu, indi mümkündür. İstehsal olunan nailiyyətlərə nail olan proqramlaşdırma texnikalarını dəstəkləyən və tətbiq edən alətlər. Ümumi baxış üçün növ və resurs təhlükəsizliyi üçün C++ modelinə qısa girişə baxın. .
C++ çoxlu kommersiya və açıq mənbəli GUI-lərə malikdir (məsələn, Gtkmm , SmartWin++ , V C++ GUI , FLTK və Qt ). Xüsusilə, hər bir platforma satıcısı GUI-yə daxil olmaq üçün C++ kitabxanası təqdim edir. Problem ondadır ki, onun standart GUI-si yoxdur və bu, həqiqətən də böyük problemdir.
Qeyd edək ki, GUI təmin etmək həm texniki, həm də siyasi problemdir. Çoxlu istifadəçisi olan bir çox GUI var və ümumiyyətlə onlar başqa bir GUI-nin standart elan edilməsini istəməzlər. Hər halda, standartlar komitəsinin yeni və daha yaxşı GUI qurmaq üçün resursları yoxdur.
C++ 11 mövzular təklif edir.
Xeyr, mən belə düşünmürəm. C++ istifadəsi bəzi sahələrdə azalır, digərlərində isə yüksəlişdə görünür. Əgər təxmin etməli olsaydım, 2002-2004-cü illərdə xalis azalma və 2005-2007-ci illərdə və yenidən 2010-2011-ci illərdə xalis artımdan şübhələnərdim, amma hər kəsin həqiqətən bildiyinə şübhə edirəm. Populyar tədbirlərin əksəriyyəti əsasən səs-küyü ölçür və onların tapıntılarını "populyarlıq" deyil, desibellə bildirməlidir. 2015-ci ildə peşəkar sorğu C++ proqramçılarının sayının 4,4 milyon olduğunu təxmin etdi. C++ dilinin əsas istifadələrinin bir çoxu proqramçıların konfranslara getmədiyi və ya kodunu ictimaiyyət qarşısında təsvir etmədiyi infrastrukturdadır (telekommunikasiya, bankçılıq, daxili sistemlər və s.). Ən maraqlı və vacib C++ proqramlarının bir çoxu diqqət çəkmir, onlar proqramlaşdırma məhsulları kimi ictimaiyyətə satılmır və onların icra dili heç vaxt qeyd olunmur. Nümunələr Google və "800" telefon nömrələridir. 1985-ci ildə "C++ daxilində" loqosu haqqında düşünsəydim, bu gün proqramlaşdırma dünyası fərqli ola bilərdi.
Dil istifadəsi/populyarlığı ilə bağlı bir çox müzakirələri qarışdıran sadə bir şey nisbi və mütləq ölçülər arasındakı fərqdir. Məsələn, mən (2011-ci ildə) istifadəçi əhalisinin 200.000 proqramçı ilə 3.1M-dən 3.3M-ə qədər artdığını görəndə deyirəm ki, C++ istifadəsi artır. Bununla belə, başqası iddia edə bilər ki, “C++ ölür” çünki onun “populyarlığı” proqramçıların ümumi sayının 16 faizindən 11 faizinə düşüb. Hər iki iddia eyni vaxtda doğru ola bilər, çünki proqramçıların sayı artmağa davam edir və xüsusən də proqramlaşdırma hesab edilənlər dəyişməyə davam edir. Düşünürəm ki, C++ öz ənənəvi əsas sahələrində, məsələn, infrastruktur, sistem proqramlaşdırması, quraşdırılmış sistemlər və ciddi vaxt və/yaxud məkan və/yaxud enerji istehlakı məhdudiyyətləri olan tətbiqlərdə özünü saxlamaqdan daha çox şeydir. Həmçinin mənim DevX müsahibəmə baxın .
Tətbiqçilər öz kompilyatorlarını , kitabxanalarını və alətlərini daim təkmilləşdirirlər . Son beş ildə keyfiyyətdə çox əhəmiyyətli irəliləyişlər müşahidə edilmişdir. İnsanlara ən birbaşa və dərhal kömək edən budur; ki, və C++ icması tərəfindən davamlı olaraq istehsal olunan xüsusi və açıq mənbəli kitabxanalar və alətlər. Nümunələr üçün C++ səhifəmə baxın .
İlk ISO C++ standartı 1998-ci ildə ratifikasiya edilib. Növbəti versiya C++11 tamamlanıb və göndərilir. Siz C++ 11-i təsvir edən sənədləri nəşrlərim səhifəsində və yeni standartla bağlı bütün sənədləri ISO C++ komitəsinin əsas səhifələrində tapa bilərsiniz . C++ təkamülünün son 15 ilində mənim HOPL-iii sənədim nəyin və niyə edildiyini ən yaxşı izah edə bilər. Son müsahibədə yeni dil xüsusiyyətləri və standart kitabxanaların siyahıları var.
C++ dilinin təkamülünü nəzərdən keçirərkən yadda saxlamaq lazımdır ki, məqsəd ən çox sayda yeni funksiya əlavə etmək deyil, C++ dilini köhnə kodu pozmadan onun əsas tətbiq sahələri, o cümlədən sistem proqramlaşdırması və kitabxana qurulması üçün təkmilləşdirməkdir (milyarlarla C++ sətirlərinin "orada").
Bu, mənim maşınımda deyil və sizin də olmamalıdır. Mən hətta "salam dünya" proqramının C++ versiyasını C versiyasından kiçik görmüşəm. 2004-cü ildə mən Unix-də gcc -O2 istifadə edərək sınaqdan keçirdim və iki versiya (iostreams və stdio) eyni ölçülər verdi. Bir versiyanın digərindən daha böyük olması üçün heç bir dil səbəbi yoxdur. Bütün bunlar icraçının standart kitabxanaları necə təşkil etməsi ilə bağlı məsələdir (məsələn, statik əlaqələndirmə və dinamik əlaqə, standart olaraq yerli dəstək və seçim vasitəsilə aktivləşdirilmiş yerli dəstək və s.). Bir versiya digərindən əhəmiyyətli dərəcədə böyükdürsə, problemi daha böyük olanın icraçısına bildirin.
Təbii ki, C++ dilini köhnə dil adlandırmaq qərəzliyi göstərir (bax: köhnə kod ). Bu bir yana, insanlar belə bir sual verəndə adətən Java və ya C# haqqında düşünürlər . Mən C++ dilini bu dillərlə müqayisə etməyəcəyəm , lakin qeyd edə bilərəm ki, “müasir” mütləq “daha yaxşı” demək deyil və həm Java, həm də C# 1980-ci illərin OOP üslubunda kök salmışdır, C++ ilə müqayisədə daha böyükdür.
1987-ci ildən bəri C++ dilinin və onunla əlaqəli proqramlaşdırma üslublarının inkişafının diqqət mərkəzində şablonların, statik polimorfizmin, ümumi proqramlaşdırmanın və çoxparadiqma proqramlaşdırmanın istifadəsi olmuşdur. Bu, çox məşhur olan mülkiyyət dillərinin əhatə dairəsindən kənardadır. Digər əsas fərq ondan ibarətdir ki, C++ istifadəçi tərəfindən müəyyən edilmiş tipləri daxili tiplərlə eyni dərəcədə dəstəkləyir. Bu, xüsusən şablonların, konstruktorların və dağıdıcıların istifadəsi ilə birlikdə - C++ proqramçısına C++ dilinin ən çox müqayisə edildiyi dillərdə dəstəklənənlərdən daha təkmil olan proqramlaşdırma və dizayn üsullarından istifadə etməyə imkan verir (IMO); məsələn, RAII-ə baxın .
Standart C++ və onun dəstəklədiyi dizayn və proqramlaşdırma üslubları funksional dillərə, xüsusən də ML-ə borcludur. ML tipli deduksiya mexanizmlərinin ilkin variantları (bir çox başqaları ilə birlikdə) şablonların ilhamının bir hissəsi idi. Daha effektiv funksional proqramlaşdırma üsullarından bəziləri STL-nin ilhamının və C++-da funksiya obyektlərinin istifadəsinin bir hissəsi idi. Digər tərəfdən, funksional icma obyekt yönümlü proqramlaşdırma ilə gəmini əldən verdi və bu icmadan bir neçə dil və alət genişmiqyaslı sənaye istifadəsinin yetkin təcrübəsindən faydalandı.
Aydındır ki, mən düşünmürəm ki, zibil yığımı proqramlaşdırma dilləri kontekstində "qabaqcıl" üçün yeganə müəyyənedici xüsusiyyətdir. Xüsusilə qeyd edək ki, C++ zibil kollektorundan istifadə etmədən resurs sızmalarını aradan qaldıra bilən effektiv və səmərəli yaddaş idarəetmə üsullarına dəstək verir. Razı deyilsinizsə, sadəcə C++ üçün zibil kollektorundan istifadə etməyə başlaya bilərsiniz; yaxşıları var.
Çoxparadiqma proqramlaşdırma ``hər biri ən yaxşı effekt verən birdən çox proqramlaşdırma üslubundan istifadə edərək proqramlaşdırma' deməyin gözəl bir yoludur. Məsələn, müxtəlif obyekt növləri arasında işləmə zamanı həlli tələb olunduqda obyekt yönümlü proqramlaşdırmadan və statik olduqda ümumi proqramlaşdırmadan istifadə etmək növün təhlükəsizliyi və iş vaxtı performansı yüksək səviyyədədir. Təbii ki, multiparadiqma proqramlaşdırmanın əsas gücü birdən çox paradiqmanın (proqramlaşdırma üslubunun) istifadə edildiyi proqramlardadır ki, fərqli paradiqmaları dəstəkləyən dillərdə yazılmış hissələrdən sistem tərtib etməklə eyni effekti əldə etmək çətin olacaq. Çoxparadiqma proqramlaşdırması üçün ən cəlbedici halların bir paradiqma daxilində mümkün olduğundan daha zərif və daha davamlı kod yazmaq üçün sıx əməkdaşlıqda müxtəlif paradiqmalardan olan üsulların istifadə edildiyi hallarda tapılır. Sadə bir nümunə, polimorf tipli obyektlərin statik tipli konteynerinin keçididir:
void draw_all(vector<Shape*>& vs) // standart vektorun hər bir elementini çəkin
{
for_each(vs.begin(),vs.end(),[](Shape* p){ p->draw(); });
}
Burada Shape həndəsi fiqurların iyerarxiyasına interfeysi müəyyən edən mücərrəd əsas sinif olacaq. Bu nümunə istənilən standart kitabxana konteynerinə asanlıqla ümumiləşdirilir:
template<class C>
void draw_all(C& cs) // draw each element of a standard container
{
for_each(cs.begin(),cs.end(),[](Shape* p){ p->draw(); });
}
Jim Coplienin "C++ üçün Multiparadiqma Dizaynı" (Addison Wesley, 1998) kitabı dizayn və dizayn metodları kontekstində çoxsaylı paradiqmaların istifadəsini araşdırır.
Bizə "çox paradiqma"nı əvəz etmək üçün daha yaxşı -- daha təsviredici -- termin lazımdır.
C++ bəzi insanların təsəvvür etdiyi qədər böyük deyil. Bu, tədris üçün minimal dil olmaq üçün nəzərdə tutulmuş kiçik bir dil deyil, lakin insanların onu ən çox müqayisə etdikləri C, Java, C# kimi dillər də deyil. Onlar da Dr. Wirth ilk müəyyən kimi Pascal demək ilə müqayisədə böyük - yaxşı səbəblərə görə, mən hesab edirəm ki,. Proqramlaşdırma dünyası bu gün 30 il əvvəl olduğundan daha mürəkkəbdir və müasir proqramlaşdırma dilləri bunu əks etdirir.
C++ standartı 1151 səhifədir; 430 səhifə dil tərifi və 770 səhifə standart kitabxana təsviri daxildir. Dil tərifinin ölçüsü Java və C# dil təsvirlərinin 5%-i daxilindədir (səhifə sayı ilə ölçülür). Eynilə, TC++PL 1360 səhifədir; onlardan 750-si dil vasitələrinə və proqramlaşdırma texnikasına həsr olunub; qalanları kitabxanaları müzakirə edir və s.
C++ bilavasitə bəzi digər dillərin kitabxanalar vasitəsilə dəstəklədiyini (yəni dildə) dəstəkləyir, ona görə də dil hissəsi nisbətən daha böyük olacaqdır. Digər tərəfdən, əgər siz “tipik müasir proqram” yazmaq istəyirsinizsə, əməliyyat sistemi interfeyslərini, GUI, verilənlər bazası, veb interfeysləri və s. cırtdan proqramlaşdırma dili ilə tanış olmaq. Burada C++ ölçüsü yaxşı kitabxanaları daha yaxşı dəstəklədiyi üçün üstünlük ola bilər.
Nəhayət, təcrübəsiz bir proqramçının bütün dilləri bildiyi günlər, ən azı sənayedə geniş yayılmış dillər üçün geridə qaldı. “Bütün C” və ya “Javanın hamısını” çox az adam bilir və bunların heç biri yeni başlayanlar deyil. Bundan belə nəticə çıxır ki, heç kim yeni başlayanların C++ dilini bilməməsi faktına görə üzr istəməməlidir. İstənilən dildə etməli olduğunuz şey alt çoxluq seçmək, işləyən yazı kodu əldə etmək və tədricən dil, onun kitabxanaları və alətləri haqqında daha çox öyrənməkdir. Başlayanların C++-a necə yanaşması ilə bağlı təklifim üçün Proqramlaşdırma: C++ ilə Prinsiplər və Təcrübəyə baxın .
EC++ “sənaye konsorsiumu” tərəfindən müəyyən edilən istisnalar, şablonlar, ad boşluqları, RTTI dəstəyi, çoxsaylı miras və s. olmayan (demək olar ki) C++ alt çoxluğudur. Mən dil alt dəstələrinin və ya dialektlərin tərəfdarı deyiləm. Mən xüsusilə standart kitabxananı dəstəkləyə bilməyən alt dəstləri sevmirəm ki, həmin alt dəstənin istifadəçiləri öz uyğun olmayan təməl kitabxanalarını icad etsinlər. Qorxuram ki, C++ dilinin müəyyən edilmiş alt çoxluğu istifadəçi icmasını parçalaya və qəzəb yarada bilər (31.03.1999: Mən indicə EC++-nın “yağ” (yəni yaddaş sahəsini) ləğv etməklə necə azaldığını göstərmək üçün canlı qrafikadan istifadə edən bir reklam gördüm. şeylər - ad boşluqları, şablonlar və C++ standart sətirləri. Mən açıq forumda (məsələn, İSO və ya milli standartlar təşkilatı kimi) “standartlar” üzərində işləməyə üstünlük verirəm.
Daxili sistemlər tətbiq edənlərin Standart C++ (dialektlərdən istifadə etməkdən daha yaxşı) istifadə edərək performans problemlərini necə həll edə biləcəyini müzakirə etmək üçün ISO C++ komitəsinin performansla bağlı hesabatına baxın . Mənim bildiyimə görə EC++ ölüb (2004), əgər belə deyilsə, olmalıdır.
ISO C++-nın ciddi daxili sistemlərin proqramlaşdırılması üçün necə istifadə oluna biləcəyinə nəzər salmaq üçün JSF hava nəqliyyatı vasitəsi C++ kodlaşdırma standartlarına baxın .
Xeyr. C++ siniflər, törəmə siniflər, virtual funksiyalar (başqa sözlə, inkapsulyasiya, irsiyyət və polimorfizm anlayışları) kimi əsas anlayışları Smalltalk kimi Simula-dan aldı. Ailə münasibətləri baxımından C++ və Smalltalk bacı-qardaşdır.
C++ Obyekt yönümlü və digər faydalı proqramlaşdırma üslublarını dəstəkləyən çoxparadiqmalı proqramlaşdırma dilidir . Axtardığınız şey sizi hər şeyi tam bir şəkildə etməyə məcbur edən bir şeydirsə, C++ elə deyil. Hər bir proqramı yazmağın heç bir düzgün yolu yoxdur - hətta olsaydı belə, proqramçıları ondan istifadə etməyə məcbur etməyin heç bir yolu olmazdı.
Bununla belə, C++ dilində C tipli proqramların yazılması əksər proqramlar üçün C++ dilinin optimal istifadəsi deyil. Həqiqətən təsirli bir C++ proqramçısı olmaq üçün abstraksiya mexanizmlərindən və tip sistemindən məqsədlərinə uyğun şəkildə istifadə etməlisiniz. C++ tipli sistemi görməməzlikdən gəlməyə və ya məğlub etməyə çalışmaq ən sinir bozucu təcrübədir.
C++ dilində Java tipli kodun yazılması C++ dilində C tipli kodun yazılması qədər sinir bozucu və sub-optimal ola bilər.
Daha ətraflı müzakirə üçün biblioqrafiyamdakı icmalıma və ya üslub sənədlərimə baxın . Xüsusilə, mənim OOPSLA məqaləmə baxın "Niyə C++ sadəcə obyekt yönümlü proqramlaşdırma dili deyil".
Sitatlara baxın .
C++ dilinin qəsdən proqramçıların maaşlarını artırmaq üçün əlçatmaz kod yazmaq üçün dəhşətli bir dil kimi yaradıldığını etiraf etdiniz?
Əlbəttə yox. Əsl IEEE müsahibəsini oxuyun .
"Kirsi kod" (1) natiq/yazıçının köhnəlmiş hesab etdiyi və/və ya (2) natiq/yazıçı tərəfindən satılan/təşviq edilən bir şeylə rəqabət aparan dil və ya üslubda yazılmış kodu xarakterizə etmək üçün tez-tez alçaldıcı şəkildə istifadə edilən termindir. "Köhnə kod" tez-tez təklif olunan alternativdən əslində işləməsi və miqyası ilə fərqlənir.
Xeyr. 1980-1991-ci illər ərzində istifadəçilərin sayı yeddi ay yarımdan bir iki dəfə artdı (bax: C++ dilinin dizaynı və təkamülü ). Bununla belə, bunu təmin etmək üçün kifayət qədər proqramçı yoxdur. Əldə edə biləcəyim bir neçə rəqəmdən (tərtibçi satışı, kitab satışı, təsadüfən tanıdığım məsləhətçilərin iş yükü, IDC və s.) artım tempinin bir neçə faiz olduğunu təxmin edirəm. Davamlı və mütləq müsbətdir . IDC 1996-cı ildə 1,2 milyon C++ Tətbiqinin satıldığını təxmin etdi. Onların 2001-ci ildə C++ proqramçılarının sayı ilə bağlı təxminləri "təxminən 3 milyon" idi; 2004-cü ildə onların sayı "3 milyondan çox" idi. 2015-ci ildə keçirilən peşəkar sorğu 4,4 milyon C++ proqramçısını tapıb. Bu, inandırıcı görünür və davamlı artımdan xəbər verir.
Bəli, çoxları bunu edir. Onları effektiv saymaq üçün çoxlu C++ istifadəçisi var, lakin onların sayı milyonlarladır. C++ bütün əsas təchizatçılar tərəfindən dəstəklənir . C++ istifadə nümunələri üçün mənim proqram seçicimə baxın .
Bu, on ildən çoxdur ki, belədir; C++ proqramlarımın siyahısına baxın . Ən son nümunə Cloudiusdur .
Əlbəttə yox. Ümumi təyinatlı proqramlaşdırma dilləri üçün müvəffəqiyyət nisbəti çox kiçikdir. Mən bunu bilirdim və bilirdim ki, uğur şansına məndə olmayan marketinq nüfuzu təsir edir.
C++ ilkin olaraq mənim və həmkarlarımın üzləşdiyi bəzi xüsusi problemləri həll edən ümumi qurğular toplusu kimi dizayn edilmiş və tətbiq edilmişdir. Təqdim olunan obyektlərin ümumiliyi - və səmərəliliyi - gözlədiyimdən daha geniş ehtiyaclara xidmət etdi. Xüsusi problemlərə xüsusi həll yollarının təqdim edilməsindən fərqli olaraq ümumi imkanlara diqqət C++-da qaldı və icmanın üzləşdiyi spesifik problemlər illər ərzində dəyişdiyi kimi onun icmasına xidmət etdi.
Mənim bildiyimə görə, C++ proqramçıları üçün yaxşı bir sertifikat proqramı yoxdur. Çox heyif. Yaxşı bir sertifikat proqramı ən faydalı olardı. Bununla belə, C++-da möhkəm sertifikatlaşdırma proqramı hazırlayacaq mərkəzi təşkilat yoxdur və səlahiyyəti olmayan və ya sintaksisə yönəlmiş sertifikatlaşdırma proqramı faydasızdan daha pis olardı.
Hiss etdim ki, sənayeyə qayıtmağın vaxtıdır. Uğur və uğursuzluq halında real nəticələri olan real dünyadakı, irimiqyaslı layihələrin çətinliklərini qaçırdım. Akademiya mənə bir qədər rahat və `` Fil sümüyü qalası '' hiss etməyə başladı ( akademiyanın gənc fakültə və adyunkt fakültəsi üçün belə deyil -- onlar aldıqlarından daha çox dəstəyə ehtiyac duyurlar və onlara layiqdirlər). Morgan Stanley-nin texnoloji bölməsində çoxlu kompüter elmi problemləri və çoxlu ağıllı, yaxşı təhsilli və təəccüblü (``Wall Street''də işləyən insanların məşhur reputasiyası nəzərə alınmaqla) gözəl insanlar var. Morgan Stanley çox ciddi C++ istifadəsinə malikdir. Bundan əlavə, mən C++ standartlaşdırmasına baxıram (C++17 yoldadır) və Kolumbiya Universitetində və Texas A&M Universitetində professor kimi bəzi araşdırmalar aparıram . Şimal-şərqə və oradakı ailəmə qayıtmağın vaxtı gəldi.
PS. Mən JP Morgan deyil, Morgan Stanley üçün işləyirəm. Morgan Stanley ümumi ``maliyyə institutu'' deyil, kifayət qədər ciddi şəkildə tənzimlənən bankdır və IMO ən etik cəhətdən idarə olunan maliyyə institutlarından biridir.
PPS. Müasir cəmiyyəti banklar olmadan idarə edə bilməzsiniz.
Buxar Bell Labs və onun varisləri olan AT&T Labs və Lucent Bell Labs-dan tükənmişdi. Sadəcə əvvəlki kimi deyildi. TAMU-da dostlarım var idi (və var) və akademik həyatın müxtəlif bacarıqlarını öyrənmək üçün yaxşı yer olduğunu düşündüm. Başlayanlar üçün akademik tədqiqat mənim öyrəşdiyim sənaye tədqiqatlarından xeyli fərqlənir. Eynilə, birinci kurs tələbələrinə və məzunlara dərs demək peşəkar müəllimlərdən çox fərqlidir. Mən həmçinin Kompüter Elmləri və Mühəndisliyi Departamentinin qurulmasına kömək etdim . Mən hələ də universitetin görkəmli professoru kimi TAMU ilə əlaqə saxlayıram.
PS. Texas A&M Universiteti != Texas Universiteti.
Çünki bacarardım. 1980-ci illərdə (və ondan əvvəlki və sonrakı illərdə) yer üzündə belə bir yer yox idi. Hələ də yoxdur. Bell Labs dünyanın ilk tətbiqi elm və mühəndislik tədqiqat mərkəzi idi. Bu, qeyri-adi həmkarları ilə işləmək üçün ən maraqlı və çətin yer idi. Mən Kompüter Elmləri Tədqiqat Mərkəzinin bir hissəsi idim . Mən AT&T Labs-ı (AT&T Bell Labs-ın iki varisindən biri) yaxşı şərtlərlə tərk etdim və daha on il ərzində AT&T Təqaüdçüsü kimi AT&T ilə əlaqə saxladım.
Daha yaxşı tez-tez verilən suallar :-)
Ciddi şəkildə, mən böyük real dünya sistemlərini qurmaq üçün istifadə etdiyimiz alətləri və texnikaları təkmilləşdirməyin əsas yollarını axtarıram. İşimin bir hissəsi C++11- dir .
C++, sistem proqramlaşdırmasına qarşı qərəzli ümumi təyinatlı proqramlaşdırma dilidir
O , ISO standartı ilə müəyyən edilib , onilliklər ərzində sabitlik təklif edir və böyük və canlı istifadəçi icmasına malikdir. Həmçinin baxın: C++ Proqramlaşdırma Dili və Dilin real dünyada və onun üçün inkişafı: C++ 1991-2006 .
C++ dizaynı haqqında? C++ tarixi haqqında?
HOPL-2 və HOPL-3 üçün sənədlərimə baxın ; HOPL, ACM tərəfindən maliyyələşdirilən bu mövzuda əsas konfrans olan "Proqramlaşdırma Dillərinin Tarixi" deməkdir. Bunlar ciddi şəkildə nəzərdən keçirilən məqalələrdir. Daha ətraflı məlumat üçün mənim “ C++-ın Dizaynı və Təkamülü” kitabıma və 2006-cı ilə qədər məlumatı özündə əks etdirən D&E-nin 2006-cı il Yapon tərcüməsinə ön sözə baxın. Həmçinin, müsahibələrimin bir çoxu C++ dilinin mənşəyi, dizaynı və tarixi məsələlərinə toxunur. .
Çoxlu suallar mənə təsdiq şəklində gəlir
Çox vaxt bu məqamlardan birini gündəmə gətirən şəxs ifadəni fakt hesab edir (lakin bu iddiaların heç biri doğru deyil); bəzən, nəzərdə tutulan sual işarəsi var. Belə ki,
Boost , ISO C++ standart kitabxanası ilə yaxşı işləmək üçün nəzərdə tutulmuş geniş və genişlənən kitabxanalar toplusudur . O, asio, fayl sistemi, regex və thread kimi bir çox son dərəcə faydalı və yaxşı işlənmiş kitabxanaları ehtiva edir (daha faydalı kitabxanaları müəyyən etməyə cəhd etmədiyimiz üçün üzr istəyirik; sadəcə çoxları var). Bir kitabxana, TR1, yeni C++11 standart kitabxana komponentlərinin yaxşı təxminini ehtiva edir.
Boost kitabxanalarında test paketləri var, sənədlər var, bir çox sistemlərdə sınaqdan keçirilib və nəzərdən keçirilir.
Boost ilə bağlı iki problemim var, ümid edirəm ki, nəticədə həll olunacaq:
Dedi ki, artıq təklifləri artıran təkəri yenidən ixtira etmək çox axmaq bir fikirdir.
Şablon metaproqramlaşdırması, ehtiyatla və zövqlə istifadə edildikdə, əsasən daha böyük sistemlərin arxitekturasına, onların daşınmasına və saxlanmasına aid olduqca çətin problemlərin həllinə kömək edə bilən güclü proqramlaşdırma üsulları toplusudur (bax: Abrahams və Gurtovoy: C++ Şablon Metaproqramlaşdırma və bəziləri). Boost kitabxanalarından .
Bütün güclü texnikalar kimi, onlar asanlıqla həddən artıq istifadə olunur. Şəxsən mən şablonlardan ilk növbədə ümumi proqramlaşdırma üçün (məsələn, konteynerlərin və konteynerlər üzərində alqoritmlərin müəyyən edilməsi) və şablon arqumentlərinə əsaslanan kifayət qədər açıq kod yaradan şablonlar üçün (məsələn, buferlərin yaradılması və qeydiyyatdan keçmə kodu) istifadə etməyə meylliyəm; buna bəzən generativ proqramlaşdırma da deyirlər. Yazdığınız və ya istifadə etdiyiniz şablonların mürəkkəbliyinə diqqət yetirin; həddən artıq həvəslənmək və saxlanıla bilən istehsal kodu kimi faydalı olmaq üçün çox ağıllı olan şablon kodunu yazmaq asandır.
Funksional proqramlaşdırma üslublarını sevmirsinizsə, şablon metaproqramları başa düşmək çətin ola bilər. Funksional proqramlaşdırmanı sevirsinizsə, şablon versiyasını bir qədər primitiv tapa bilərsiniz, lakin bu şablonların tərtib zamanı icra olunduğunu unutmayın.
C++-ın metaproqramlaşdırma üçün dəstəyi yaxşılaşır. Konsepsiyalar ümumi proqramlaşdırmanı kəskin şəkildə sadələşdirəcək və şablon metaproqramlaşdırması üçün iskelelərin çoxunu lazımsız edəcək. Bundan əlavə, yaratmaq istədiyiniz dəyər (deyək və tam dəyər) olarsa, constexpr funksiyalarından istifadə etmək daha asandır (və daha sürətli tərtib).