С/C + +

"Ох хвиля моя, хвиля, ти як С + + потужна"

Майже Пушкін

Відносно потужності C/С + +. Так, дійсно це дуже потужні мови, але їх потужність полягає в їх засобах низького рівня, а вони при розробці прикладних програм часто непридатні.

Потужність - це, звичайно, добре, але часто небезпечно.

Приклад: # define int long синтаксично вірно, але може призвести до катастрафіческім наслідків (хоча, наприклад, при перенесенні програм з однієї платформи на іншу це може знадобитися). Або оператор goto. Те, що він не включений в Java, багато хто вважає дуже великим благом. Goto - це потужна можливість, але, як показав ще у сімдесятих роках Дейкстра, м'яко кажучи, "не рекомендована" до використання. Проте це можливість, і вона може бути не зайвою. Я вважаю, що подібні низькорівневі конструкції повинні бути присутнім, але ними не слід зловживати. У тих рідкісних випадках, коли особисто я його використовував, це була спроба розвитку плохоспроектірованной програми.

"Щоб зробити кар'єру програміста за кордоном потрібно знати дві мови: англійська і C + + "

Російський аспірант, який побував у Відні.

"З точки зору теоретичного програмування мова Сі - це Фортран 80 - их. (Проти такого принизливій визначення не заперечував і автор мови Сі - Д. Рітчі). Ця мова, що поєднує в собі багато переваг мови високого рівня і асемблера, дав програмістам, за образним висловом деяких, педаль газу, але заблокував педаль гальма. На Сі комп'ютер може "мчати" швидко, але ризиковано. Тобто Сі, насаджуючи посилальної -- асемблерні програмування, як би має вектор в сторону, протилежну тій, яка визначається теорією і методологією мов програмування.

Тому і Сі + + - це досить дивне поєднання деяких рис ООП (тут і далі - об'єктно - орієнтоване програмування) та процедурного програмування "

к.т.н. Соловйов А.Є.

"C + + являє собою цікавий експеримент з адаптації можливостей об'єктної технології до традиційного мови програмування. ... оскільки Сі + + - мова, що вимагає досить інтенсивної критики. Він представляє собою не надто вдалу реалізацію об'єктно - орієнтованої технології, і тому його недоліки просто необхідно піддавати критичному аналізу ... Сі + + приносить всім колосальне розчарування - він увібрав в себе всі погані і старі кошти, а також привніс в об'єктну технологію абсолютно непотрібну складність. Навіщо потрібна мова, наскрізь просочений низькорівневими конструкціями? ".

Ян Джойнер

Далі по тексту "Найбільш вірний шлях до успіху - використання чистого об'єктно - орієнтованої мови, що володіє інтерфейсом з мовою програмування С або з іншими низькорівневими мовами. Це забезпечить хороші підтримку і супровід, переносимість та якість ", що в принципі можна спостерігати на прикладі будь-якого засобу 4GL (того ж Delphi) підтримує стандартні засоби взаємодії Windows такі як Dll, Dde, Ole. Найпростіший приклад - звернення з Delphi програми до Win API (адже Windows написаний на Сі (9X) і C + + (NT)).

Спочатку створений для розробки ОС Unix, мова C набув широкого поширення. Це наклало дуже сильний відбиток на мову.

Як виник мову С? Спочатку був CPL: він був створений в середині 60 - х років.

Мова не отримав широкого розповсюдження, але в процесі його створення з'явилася маса ідей. Мова був беcтіповий, як і належить асемблеру (ще PDP 7).

Нова спрощена версія мови називалася Basic CPL або BCPL. На ньому була реалізована MULTICS. Але в результаті її розмірів і роздутість їй потрібна була заміна.

Частина ідей з MULTICS була взята розробниками Unix. Приміром, ієрархічна файлова система. Зауважу, що в прямому попереднику DOS-CP/M її не було, як і в першій версії DOS.

допрацювали мову - Вийшов B.

Розробили ОС - Вийшла Unix

Сі розроблявся як кросплатформний асемблер PDP 11 (багато досвідчених програмісти знають його по вітчизняним аналогам), є деякою сумішшю асемблера з Паскалем, цим збіднюється багато його особливості.

Наприклад:

Відсутній можливість напряму працювати з даними, не підтримує процесори PDP (безлічі, рядки, etc).

Присутність явно PDP - орієнтованих конструкцій:

Функція poly, зводиться до аналогічної команді асемблера. Обчислення ж поліномів НЕ є завданням першорядної важливості мови.

Постінскремент і предінскремент. На x86, наприклад, це нічого не дає. І A = B + + і A: = B; inc (b); приведуть до команд асемблера MOV a, b; inc b (природно, безпосередньо в коді це будуть не імена змінних, а, наприклад, регістри).

".. що аномалії існуючих обчислювальних машин старанно відтворюються в мовах програмування, причому це відбувається на шкоду інтелектуальної керованості програм, виражаються такою мовою .. "Е. Дейкстра." Дисципліна програмування "

Вірт писав що : "... Мова повинна визначатися в термінах математичних, абстрактних концепцій І тільки, якщо мова відповідає цьому критерію, він може вважатися високорівневим. "

Змінюються від платформи до платформи розміри типів даних.

Рядки, закінчуються нулем, запозичені з асемблера (директива. asciz асемблера PDP)

Відсутність автоматичної або обов'язкової ініціалізації змінних. Плюс такого підходу - Велика оптимальність коду, мінус - необхідність проводити ініціалізацію вручну. Відсутність автоматичної ініціалізації є потенційною можливістю для розробки програмного забезпечення, яке містить нестійкі помилки (в ідеалі компілятор повинен відслідковувати не проводиться чи читання не ініціалізований змінної і у випадку, якщо проводиться, обнуляти її).

Наявність безлічі "підводних каменів"

scanf ( "% d% d", & n, & ar [n]);

Ви думаєте, що буде введено ціле n і n - ий елемент масиву ar?

Це дуже малоймовірно. Швидше за все, всі аргументи scanf будуть обчислені до того, як операція буде викликана на виконання. Подібних побічних ефектів у мові маса.

Інша "особливість"

char

str [50] = "qwertyuio";

int a = 3; str [+ + a] = str [+ + a] = '';

cout <

str [a + +] = str [a ++]=' ';

cout <

Результат:

qwe tyuio

qwert uio

За логікою речей повинні бути додані дві пробіл. Але у C своя логіка, так що це не помилка компілятора, а особливість мови.

int i = 0, ar [2] = (10,11);

i = ar [i ++];// А хто відразу скаже чому одно значення i

Хочете ще? Формат виведення залежить від типу:

short int x = 55;

printf ( "% dn", x);

Якщо замінити short int на longt int, то доведеться міняти і printf ( "% dn", x) на printf ( "% Dn", x)

Приклад: припустимо, що замість i <= 100 розробник написав i = 100 при синтаксисі C/C + +

for (i = 0; i = 100; i ++)

Цикл буде виконуватися вічно (замість 101 рази) тому

Відсутній логічний тип даних.

Вираз i = 100 одно 100 (тобто по не нуль - істина).

Оскільки C містить у собі елементи не тільки процедурного, але і функціонального програмування така конструкція цілком правильна і логічна.

У міру розвитку в C включалося все більше можливостей Спочатку мова не мала коштів навіть для опису констант. Коли Сі став застосовуватися для вирішення серйозних завдань, до нього додали так звані "директиви препроцесора", такі, як # define і # include.

За допомогою define стали визначати константи і inline підпрограми,

А за допомогою # include було реалізовано, хоч і примітивний, механізм модульності. Популярність функціонального програмування теж зіграла свою роль. У мові з'явилися конструкції з функціональних мов.

Звичайно, у цій особливості є й більш гідне застосування

if (СH = getchar ()! = ESC)

{..}

Узагальнюючи, що такі коштів хоч і зручні в використанні і дозволяють писати розробнику "красиві" програми, не сприяють безпеці цих програм і зовсім не вважаються простотою мови. Так що "Красиво" - не завжди добре.

З мінусів також варто відзначити не надто читабельний синтаксис. Подумайте, що більше говорить end loop в пеклі або ")" в C. Звичайно, стислість - це добре, але платити за неї таку ціну ....

Приклади:

Паскаль:

if Screen.Forms [I] is FormClass then begin

C + +:

if (dynamic_cast (Screen -- > Forms [I ])){

A = (! CL & &! RC)? 0 : (! LC? RC: LC)// "Дуже ясна вираз"

* + + * agrv //"Ще одне дуже зрозуміле вираз, при тому синтаксично правильне"

"Інтуїтивно зрозумілий "синтаксис чудово підкреслює наступний приклад:

int i = 5;

int *

const p3 = &i;// Покажчик константу

const int *

p3 = &i;// Покажчик на константу

i = 5;// Правильно

* p3 = 5; Невірно! покажчик на константу змінену в попередній рядку.

char (* (* x2 ())[]) ()// Терміново покличте криптоаналітика !!!

Або робота з перерахуваннями:

enum modes (LASTMODE, BW40, C40, BW80, C80, MONO

);

..

modes

e1 = C80, e2;

e1 = e2 * 3;

// Дуже осмислений оператор на "ЯПВУ".

// Адже для "ЯПВУ" немає різниці, що int, що enum, що

bool

А що може значить, на Вашу думку, команда a = 24 [ar];?

За умови, що int ar [50]; int a; вона повністю еквівалентна a: = ar [24];

Як цілком справедливо зауважують шанувальники C/C + + ці мови дозволяють писати надзвичайно короткі і виразні програми. На рахунок стислості - безумовно.

А ось до якої виразності може призвести стислість, я зараз покажу:

# include

# define Q r = R [* p + + - '0 ']; while (

# define B; break; case

char * s = "Qjou! s311 ^ - g311 ^ - n311 ^ - c:: ^ - Q - ma% mO1JBHm% BQ - aP1J [O1HB% [Q

o) * | gps) <<* txjudi) m * | aQdbtf !::::; sfuvso

ndbtf! aP2Q; m> aP2Q aP4HC% T

Qsq,, ^> m, 2 aP4HC% SD12N1nJNQm> s.. q ^ aHC% NHb% GN1! D32P3% RN1UP1D12JPQUaP1H

R% PN4nQ aP2Q, 2 aP4Hb% OD12D12N2! N3nJVP3Q,, n

(aP3Q (^ * m> g (aP3Q (^

aP1Q * aHb% FN1nQm >:::: aHC% VP3Q> bupj) hfut) c ** aHb% JD12JON1! Qjg) a% LN1UP1D12JIQUa

P1HL% IQ * m> aN2! N2nP2Q P2Q> aN2nP2Hbdd! b/d "; int k; char R [4] [99]

; main (c, v) char ** v; (char * p, * r, * q; for (q = s; * q; q + +) * q> ' '&&(* q) - -; (FILE * i = fopen (v

[1], "r"), * o = fopen (q -- 3, "w"); for (p = s;; p + +) switch (* p + +) (B'M ': Q (k = fgetc (i))! = EOF

& & k! =* p) * r + + = k; if (k == EOF) (fputs ( ")) n", o); fclose (o); return system (q - 6);) * r = 0

B'P ': while (* p !='`') fputc (* p + +, o) B'O': Q * r) fputc (* r + +, o); p - - B'C ': k = 0; Q k <* p - '0'

) (* r + + = fgetc (i), k ++);* r = 0 B'I ': k = * p; if (** R == k) goto G B'G ': k = * p; G: p = s; while (

* p !='$'|| p [1]! = k) p + +; p + + B'N ': R [* p - '0'] [0 ]++;}}}

Ця програма всього в 17 рядках текстового режиму VGA (25X80) являє собою повнофункціональний інтерпретатор мови Basic, який підтримує:

Змінні (імена від A до Z), які не започатковано нульовими значеннями при запуску.

Цикл FOR var = exp TO exp .. NEXT var

Підпрограми GOSUB exp і RETURN

Природно, оператор GOTO (який же Basic без GOTO)

Умови IF exp THEN exp

Коментар REM any text

Оператор кінець програми END

Присвоєння var = exp

Введення INPUT variable

І висновок PRINT string PRINT exp

Чи є читачі, які по - як і раніше, вважають, що стислість - це завжди дуже добре. А читабельність конструкцій мови факт другорядний?

У частині ясності синтаксису антиподом C/С + + є мова АДА. Замість нескінченних ")" пишеться END LOOP, END IF, END CASE або END ІМЯ_ПОДПРОГРАММИ/ПАКЕТА. Я вже не кажу, наскільки "Змінна ТИПУ цілий" читабельною ніж "цел Змінна ". Логічно припустити, що платою за стислість є читабельність програм, або платою за читабельність програм є відсутність стислості.

Хоча, що стислість в синтаксисі є сестрою таланту є вкрай сумнівним. Відсутність надмірності на рівні синтаксису доводиться компенсувати рясними коментарями (якщо, звичайно, розробник хоче мати можливість розібратися в цьому коді через пару місяців).

Відзначу, що подібний синтаксис Microsoft поклала в основу мови Visual Basic.

Ну і, звичайно, відсутність суворого контролю типів (хоча в цьому є й зворотний бік - в Pascal'е Вам доведеться для того, щоб мати можливість "прострілити собі ногу ", явно вказати на своє бажання компілятору.

поширеності C послужила:

Поширеність Unix.

Гарне якість що генерується коду. Особливо на PDP.

Достатня "потужність" мови.

Порівняльна простота реалізації компіляторів.

Стислість синтаксису та його "краса" улюблена багатьма С/C + + - програмістами, багато хто вважає їх мало не основними перевагами мови (тобто можливість написати ar [c + +] замість ar [c]; inc (c) мала великий вплив на популярність мови).

Широкі можливості розробки системного ПЗ (наприклад, адресна арифметика, бітові поля). У цієї низькорівневими для багатьох розробників навіть прикладного ПЗ є якась принадність, що привертає до мови.

Справедливості ради скажу, що саме такі низькорівневі кошти часто роблять C/C + + більш привабливим для задач системного програмування в порівнянні з Паскалем (Щоправда, вже в Modula 2 з'явилася адресна арифметика).

Пізніше сам Керніган радив розробникам не використовувати бітові поля, так як вони "занадто платформозавісіми".

Підсумок - C гарна мова системного програмування, кроссассемблер, що дозволяє дуже ефективно використовувати PDP, не дуже добре підходить для розробки прикладного ПЗ. Зауважу також, що деякі розробники "забави ради "занижують рівень обраного для розробки мови (дивіться розділ про людський фактор).

Перед C розробниками стояло завдання створити мову, що володіє перевагами і асемблера і ЯПВУ. Із завданням вони, в принципі, впоралися добре: правда, з плюсами оних були додані і їх мінуси.

C та й C + + не були і не будуть безпечними мовами, оскільки один з пріоритетів цих мов - Ефективність. Тому Страуструп не включив в C + + динамічну перевірку типів. Як свідчить базовий принцип ЯП, ефективність і безпека несумісні. Та й втрати в ефективності не настільки значні для більшості завдань.

Та й втрата не така велика. Я провів невеличкий експеримент з наступною програмою та її аналогом на Pacal.

# include

# include

# include

void

main ()

(unsigned long int i;

int

ar [10000];

time_t t, t2;

t = time (NULL);

randomize ();

// Багаторазове привласнення випадкового елементу випадкового значення

for (i = 1; i <429496; i + +)

ar [random (1000)] = random (32767);

// Багаторазове заповнення

масиву числом 2

for (i = 1; i <429496; i + +)

ar [i% (1000)] = 2;

t2 = time (NULL);

printf ( "Час виконання =% d ", t2 - t);

)

Як видно, програма дуже інтенсивно працює з масивом і контроль за вихід кордонів масиву повинен, імовірно, сповільнити роботу. Адже на кожне присвоєння доводиться перевірка індексу масиву.

Висновки можуть виявитися для кого - то несподіваними:

Версія на C не показала більш високої швидкодії в порівнянні з Pascal версією.

швидкодії Pascal версії при відключенні всіх перевірок збільшувалася на 7 - 8%.

Що цілком логічно, тому що перевірка у процесорів 80x86 реалізуються на апаратному рівні. А приріст у 7 - 8% може дати використання компілятора з гарною оптимізацією.

За даними Дмитра Беленко, заснованим на проведеному їм експерименті, різниця між Delphi і C + + Builder навіть обчислювальних завданнях становить 4 - 5%.

Зауважу що існує і з спеціальний проект Cyclone. Його розробники - Корнельський університет і AT & T. Мова фактично являє Сі з перевіркою потенційно небезпечних ситуацій, таких як переповнення буферу. У дистрибутив входить програма перетворення програм з Сі в Cyclone яка може відшукати і знайти потенційно небезпечні місця програми. Основна мета розробників -- створити мову придатний для програмування безпечних додатків.

Після появи і розповсюдження ООП левова частка З програмістів перейшли на С + +. У цьому (і великому обсязі ПЗ вже написаному на С) я бачу одну з основних причин його поширеності.

Відзначу що і C + + вплинув на C. Приміром enum З отримав від С + +, і при програмуванні на С він практично не використовується, однак було відзначено, що С містить таку конструкцію, оскільки вона є в нині чинному стандарті мови.

У мові з'явилися:

класи (classes);

шаблони (templates);

простору імен (namespaces);

перевантаження (overload);

потоки (streams);

виключення (exception)

ООП і сучасні компілятори частково згладили недоліки С. З'явилися класи для роботи з такими типами даних, як рядки і безлічі. У сумнівних (дивіться приклад вище) ситуаціях компілятор (далеко не будь-який) може видати підказку. Для кращої читабельності IDE автоматично вирівняє вихідний текст (Спочатку цим займалася команда indent, яка існує і зараз у багатьох клонах UNIX (в т.ч. Linux)). Спеціальні средства, наприклад, NuMega BoundsChecker дозволяють відстежувати найбільш ймовірні помилки, такі, як вихід за межі масиву або витік пам'яті. Програма lint (входить в Unix'и) займається виключно ревізією вихідного тексту програми з приводу контролю типів.

Низька швидкість компіляції в результаті відсутність повноцінного механізму модульності часто компенсується механізмом попередньої компіляції заголовків файлів.

"Software engineering - мистецтво програмування без уміння це робити "

Едсгар Дейкстра (Edsger Dijkstra)

"Використання C + + для розробки прикладного ПЗ та допоміжних засобів для нейтралізації недоліків мови подібно до використання решета для перенесення води і спеціальних засобів для замикання дір у решеті. "

Автор

Хоча С + + частково згладив недоліки (просто прикривши їх своїми засобами, самі недоліки нікуди не поділися) до нього він додав і свої:

Головний -- надмірне складність і розмір мови (це ріднить його з Адою, хоча складність Ади викликана різноманітністю засобів, а не їх дублюванням). Навіть реалізація ООП інтенсивної піддається критиці. Я для прикладу розгляну множинне спадкування. Саме питання про необхідність включення множинного спадкоємства в мову є досить спірним. Зокрема стоїть проблема наявності однойменних методів у батьків класу. Виникає питання: що викликати? Перший-ліпший? Чи все по черзі? На практиці це вирішується написанням в нового класу методу, який безпосередньо реалізує потрібну логіку, щоправда тоді виникає питання про адекватності самого множинного спадкоємства. Адже його зміст у автоматичному виклику методів (та доступ до полів) класів предків. Якщо ж розробнику доводиться вказувати конкретний клас - предок, то множина спадкоємство в значній мірі втрачає сенс. Залишаються лише такі зокрема як можливість звернення до protected елементів класів предків, але відповідна модифікація програми це не проблема. Реалізацію множинного спадкоємства теж не можна назвати тривіальним справою, вона значно складніше реалізації "одиничного успадкування".

Велика надмірність засобів - тобто для вирішення однієї задачі я можу використовувати велику кількість ідентичних коштів.

До речі, багато засоби мови, які, на думку його прихильників, з'явилися в C + +, були запозичені з інших мов. Наприклад, аналог шаблонів - пакети - були в пеклі до створення C + +. Обробка виняткових ситуацій присутній у пекло і навіть у PL/1.Перезагрузка операцій також була присутня в пеклі.

Величезна різноманітність засобів, які дублюють один одного, подобається багатьом шанувальникам C + +. Вони вважають, що це робить мову більш зручним для використання. Вважати так-це їхнє право. Ймовірно, для кого-то це дійсно так.

Наведу авторитетна думка Кена Томпсона (одного з розробників C і Unix):

"При роботі з мовами C + + і Java в мене виникало певне занепокоєння, коли я просив зробити що - небудь, а у відповідь отримував: "Добре, ви робите це так - то чи можете зробити так - то ". Цілком очевидно, якщо ви в змозі зробити що - то настільки різноманітними способами і всі ці способи не менш еквівалентні, значить в системі закладено занадто багато можливостей. "

C теж надмірний. Приклад циклу без тіла: for (a = 1, b = 70; a <50; ar [a + +] = a + b, b -). По суті тут for виконує роль while.

Як зазначив У. Вульф, "Факт наявності тих чи інших можливостей у деякому ЯП не може служити критерієм для оцінки цієї мови. Великий набір хороших самих по собі можливостей, зібраних воєдино без загальної ідеї, без певного однаковості і без елегантності, не призводить до появи хорошого ЯП. "

Засоби підтримки сумісності з С.С одного боку це великий плюс (дуже багато ПЗ написано на C), з іншого, для об'єктно - орієнтованого програмування вони не потрібні.

Приклад: введення класів (при їх використанні) робить непотрібним записи (struct) і варіантні записи (union), проте з міркувань сумісності вони присутні.

С + + є надмножеством C, тобто якась Високорівнева оболонка до мови системного програмування. Але база для цієї оболонки все та ж - C.

Приміром, додані класи для роботи з рядками, але самі рядки реалізовані через покажчики. Звичайно, тут є і плюс-широта засобів мови. Але вона не компенсує що вийшла громіздкість.

Макросредства асемблером теж є високорівневої оболонкою і дозволяють використовувати конструкції, характерні для ЯПВУ (типу циклів) у програмах на асемблері. Зауважу, що і на макросредствах асемблера без використання безпосередньо команд процесора можна створювати досить складні системи. Але це не робить Асемблер мовою високого рівня.

"Писати погані програми на С + + значно легше, ніж хороші. "

Загальновизнаний факт.

Громіздкість С + + Б'ярне Страуструп пояснює наступним чином:

"Отже, універсальна мова програмування повинна підтримувати різні способи мислення та стилі програмування. Ця різноманітність є наслідком, як різнорідності розв'язуваних задач, так і різноманіття шляхів їх вирішення. C + + підтримує широкий спектр стилів програмування і тому більш заслуговує назва мультипарадигмова, ніж об'єктно - орієнтованого мови ...

Мені видається, що мови, що спираються на яку - або одну парадигму, обмежують свободу програміста. Платою за простоту виявляється гамівна сорочка, що сковує інтелект розробника .. "

Тобто виходить, якщо різні розробники використовують різні стилі програмування, то повну підтримку всіх стилів потрібно включати в мову.

Продовжуючи ідею, зауважу - для вирішення різних завдань необхідні різні алгоритми. Тому в STL необхідно включити алгоритми рішення задач з усіх областей людської діяльності, де використовується мова C + +!

А в різних ОС інтерфейси розробника істотно відрізняються (порівняйте Win32 API і POSIX). Це теж необхідно відобразити в мові.!!!

Страуструп нещодавно в інтерв'ю висловився за включення в мову засобів розробки баз даних і інтерфейсу користувача (як в Java). Звичайно, включити все, що буває в ЯП в одну мову - ідея гарна, але Вам вона нічого не нагадує? Згадайте долю "грандіозного проекту всіх часів і народів - мови АДА". Питання про кордоні, де закінчуються засоби мови і починаються інші засоби, порушено у розділі "Про маленьких і великих мовах".

І останнє -- що б не писав Страуструп, факт залишається фактом. C + + повністю практично ніколи і ніким не застосовується. Використовуються лише обмежені підмножини мови, що підтримують певний стиль розробки. Як він сам зауважив, "Для того, щоб писати гарні програми на C + +, необов'язково знати його повністю "

У принципі, люди від природних мов беруть лише дуже невелику частину. Але в програмуванні такий підхід може мати великі негативні наслідки. Наприклад, може з'явитися необхідність модифікації програмного коду написаного одним розробником, що використовує 20 % Мови іншим, що використовують інші 20% мови (іншу частину).

С + + увібрав у себе кошти для підтримки дуже широкого спектру технологій розробки і стилів програмування. На ньому можна розробляти з майже однаковою [не] успішністю, використовуючи і лінійне, і об'єктно - орієнтоване програмування.

Лінійне програмування - архаїчний спосіб розробки програм без використання таких структур мови, як цикли. Зате інтенсивно використовується оператор GO TO. Був витіснений структурним програмуванням.

Власною ідеології мова не має. Підтримується безліч парадигм. Розробник повинен вибрати те, що необхідно особисто йому, а про решту він може спокійно забути.

Навіть рівень мови однозначно визначити неможливо. Він підтримує як низькорівневі структури даних (бітові поля) і методи програмування (адресна арифметика), так і високорівневі структури даних (

Все це робить мова вкрай універсальним (і навіть унікальним), придатним для вирішення дуже широкого кола завдань. Інше питання, що така універсальність для левової частки практичних завдань не потрібна. Та й винести низькорівневий код, в окремий модуль написаний, припустимо, на асемблері не становить проблем.

Процитую один абзац з першої частини.

"У такому випадку я можу запропонувати відмінити всі різновиди і моделі літаків. І залишити одну. Найбільшу "круту". Наприклад, стратегічний бомбардувальник - невидимку B - 2.Правда, людей доведеться перевозити в бомболюк, хоча багато народу не поміститься. Та й вартість квитків з огляду на те, що виготовлення одного літака коштує більше двох мільярдів доларів буде немаленька. Занадто немаленька, щоб практично використовувати цей вид транспорту. "

А як зручно керувати таким літаком! Адже кошти управління він повинен включити в себе від всіх типів літаків. От і доведеться пілоту постійно перемикатися з панелі управління озброєнням на панель регулювання температури і вологості в салоні літака.

Важливо відзначити, що в цьому полягає одна з ключових відмінностей з Віртовской лінією Pascal/Modula/Oberon. На Pascal'е можна дуже добре використовувати процедурну декомпозицію, але використовувати лінійне програмування незручно.

На Оберон аналоги (а тим більше на Java) дуже важко писати, не використовуючи ООП. Чи не ГО, мають ГО аналоги засоби, вилучені з мови.

Наприклад, без варіантної записи, використовуючи можливість спадкування розгортаються записів, тобто класів, можна спокійно обходитися.

Тим не менше, Оберон залишається універсальною мовою. Звісно, не таким універсальним, як C + + (в сенсі не мультипарадигмова). Але природа програм, так і програмістів така, що універсальних програм, так і програмістів не існує. Уявіть собі гру, яка займається не тільки підрахунком грошей зароблених гравцями, але і читанням/записом збережених ігор посредствам роботи з портами введення - виведення (тобто те, чим займається низькорівневий драйвер на асемблері).

Або розробника, який по черзі розробляє то цей драйвер, то бухгалтерський АРМ. Звичайно, обидві програми можна за бажання написати на C + +, але які використовуються при розробці кошти будуть різні. Та й програми будуть поступатися аналогічним, написаним на асемблері (працювати буде швидше) і, наприклад, Delphi (розробка займе менше часу).

З іншого боку, саме всеосяжність засобів C + + і відсутність чіткої ідеології мови послужили його поширенню. Кожен може вибирати стиль програмування по душі. C + + це скриню в якому кожен знаходить те сто потрібно йому. У цьому полягає одне з ключових відмінностей від таких мов, як Pascal та Java, які в значною мірою диктують стиль програмування розробнику.

З одного боку, подібне нав'язування стилю - це погано, тому що обмежує свободу розробника. Але якщо подивитися з іншої точки зору: навряд чи рядовий розробник придумає що - небудь краще, ніж пропонують розробники мови (середовища, CASE засоби і т.д.), а якщо і придумає, то краще втілити цю технологію у чому - то доступний іншим розробникам, наприклад, ЯП.

Якщо орієнтуватися не на розробників, а на завдання, то ми побачимо ще одне "НО". Різні технології різною мірою застосовні до різних завдань. Приміром, ООП не дає помітного виграшу в обчислювальних математичних завданнях. Але ж і помітного програшу теж немає?

До того ж кожна мова має свою сферу застосування. Ніхто не пропонує писати на Perl модулі ОС. Та й програмісти, які пишуть на Perl, і програмісти, які пишуть модулі ОС - звичайно різні люди.

У випадку мови АДА подібна всеосяжність мала практичну необхідність. Адже АДА була покликана замінити (і замінила) всі мови (а їх було кілька сотень, що використовуються в US DOD (міністерстві оборони США) і всіх організаціях, що працюють на нього. Відповідно, така ж універсальність потрібна C + + лише в тому випадку, якщо він покликаний витіснити НЕ менше мов. Правда, US DOD потрібен був єдиний стандартний мова, а кому потрібен C + +?

У Страуструп є така ідея: "Користувач не зобов'язаний знати нічого, крім того підмножини мови, яке він явно застосовує для написання програми "

Ідея хороша, але, на жаль, стовідсотково нереалізована. Елементарні операції з рядками вимагають знайомства з STL і шаблонами. Звичайно, можна писати в стилі C, але тоді зникають переваги C + + перед ним. Для використання масивів з перевіркою на вихід індексу з діапазону необхідно використовувати STL і перевантаження операцій шаблону.

В одному з інтерв'ю Страуструп наводить наступні потенційні напрямки розвитку C + +:

"Паралелізм: я прихильник бібліотечної реалізації потоків і паралельного виконання операцій без поділу пам'яті.

Відображення типів: непогано було б забезпечити бібліотечну організацію інтерфейсу з інформацією розширених типів.

Типізація: хотілося б, щоб в бібліотеку Standard Library були включені функції підтримки розширених типів, однак конкретних пропозицій у мене немає.

Хеш - таблиці: звичайно, необхідно інтегрувати деякі варіанти популярної схеми hash_map.

Обмеження для аргументів - шаблонів: все це просто, універсально і елегантно реалізується в рамках існуючого стандарту Сі + +.

Оператори контролю: багато хто з найбільш важливих операторів контролю - верифікація коду та обробка помилок - можна було б реалізувати у вигляді шаблонів. Деякі з них слід включити до бібліотеки Standard Library.

Зіставлення з регулярними виразами: хотілося б бачити в стандартному варіанті мови бібліотеку визначення відповідності шаблонах.

Прибирання сміття: в стандарті Сі + + потрібно явно визначити технологію, що дозволяє ігнорувати "приховані покажчики", а також конкретизувати порядок обробки деструкторів.

Графічний інтерфейс користувача: добре було б мати стандартні конструкції GUI, але не знаю, наскільки це реально в ситуації, що склалася.

Незалежність від платформи: хотілося б, щоб Standard Library підтримувала більш широкий набір інтерфейсів із загальними системними ресурсами, наприклад, з каталогами та сокетами. "

Ще один проблема заслуговує згадки - це шлях поширення C + +. Очевидно, що тут вплинули поширеність Сі, широта засобів мови та областей його застосування. Досить велике питання - наскільки на розповсюдження C + + вплинула рекламна підтримка?

Ось що говорить сам Страуструп з цього приводу:

"Сі + + придбав масу прихильників там, де це було найбільш потрібно: мільйони програмістів використовують його в якості свого основного інструменту.

Дивно, але цього вдалося домогтися, не маючи <адміністративного ресурсу "і по суті без фінансових витрат. Однак, з іншого боку, співтовариство прихильників Сі + + виявилося роз'єднаним і вкрай вразливим для випадів ворожої пропаганди. Мені здається, вся справа тут у тому, що хороший код часто залишається непоміченим -- навіть його користувачами. Подивіться на програми, написані на Сі + +, наприклад, на програми Netscape або на Internet Explorer. Компанії, що розробляють програми для вирішення реальних завдань - зокрема, для управління телекомунікаціями, контролю за різними механізмами та імітаційного моделювання, - вважають за краще не говорити, якою мовою написані їх додатки.

Про те, що додаток написано не на C + +, як правило, теж ніхто не говорить. Про кількість помилок у згаданих продуктів я не кажу.

На жаль, це розв'язує руки тим, хто пропагує альтернативні засоби, а також любителям теоретичних міркувань.

Мова Сі + + ніколи не підтримувався яким - то одним лідером галузі. Кожен великий виробник доповнює (і так було завжди) стандарт Сі + + своїми власними елементами. Сі + + ніколи не було предметом маркетингової стратегії. Якщо які - то маркетингові заходи і проводилися, то тільки організаціями, що продають що - то інше (наприклад, середовище для розробки програмного забезпечення), включающее в себе Сі + + як складові компоненти. Спільнота Сі + + швидше страждало від надмірної популярності цієї мови: він постійно ставав <об'єктом нападок ", адже в сучасному світі, що живе по законами комерції, чесна боротьба - велика рідкість.

У спільноти Сі + + ніколи не було координуючого центру, фінансові можливості якого дозволяли б йому займатися популяризацією мови. Хто і з яких міркувань готовий голосувати за Сі + +? І як довести цю інформацію до програмістів, викладачів, менеджерів? Буквально днями я слухав виступ професора перед студентами, в якому він категорично заперечував існування стандарту Сі + +! Шкода, що навіть через два роки після ратифікації цього стандарту часто - поруч виникають подібні непорозуміння. "

Наведу і іншу точку зору.

Багато прихильники C + + вважають його мовою для професіоналів. Це так.

Але вони переходять далі і виробляють помилковий наслідок, що єдина мова для професіоналів - це C + +.

Яблуко - це фрукт. Але це не означає, що будь-який фрукт є яблуко.

Шанувальники Сі навіть склали віршик

"У будь-якого ти спитай

Будь хоч тричі ламер

программіруешь на Сі

Ти - крутий програмер "

Я Вважаю що визначати крутість програміста з мови - принаймні некоректно. Можна писати гарні програми на Basic і жахливі на C + +. Крім того, аргумент проти C + + в релігійних війнах про його рекламної поширеності теж з'явився, ймовірно не з неба.

На закінчення зазначу що:

У той же час потрібно визнати, що C + + є найбільш потужним, ймовірно за винятком Ad'и мовою з широко використовуваних.

Він же є на момент написання огляду найбільш популярною мовою. Хоча це не безперечно. Чому див. сторінку XXX. Хоча останні роки його потіснила Java.Сейчас тіснить і C #.

Він же є найбільш критикованим мовою.

Він же містить величезне найбільшу кількість недоліків і підводних каменів нерідко роблять програми на ньому менш надійними.

P.S.

Хотілося б знати думки читачів з приводу:

частка того чи іншої мови у програмній індустрії (виміряна у вартості проектів, вартості продаються програмних продуктів, кількість програмістів, може ще в ніж ...)

вплив мови на вартість проекту, вартість супроводу, надійність.

принципи, за яким в індустрії вибираються мови

сфери, де існує конкуренція мов - і області, де "все поділено"

тенденції і прогнози (наприклад - "через N років ми всі будемо у сфері A - писати на B, в сфері C - на D, тощо "

Дуже вітаються аргументовані відповіді посилання на наукові дослідження, книги і статті.

Дуже цікаві результати розробок (і практичний досвід набутий при розробці них) однотипного (а краще однакового ПЗ) на різних ЯП та його вплив на їх вартість/час розробки/стійкість і швидкість роботи додатків/...

При цьому добре б розглядати ЯП не як річ в собі, а у зв'язку з іншим ПЗ (від відладчика рівня ядра до Case коштів).

Цікавий порівняльний аналіз ЯП і компіляторів і взагалі все що з цим пов'язано. У Зокрема зв'язок з психологією. Дуже цікаво відмінність "у нас" і "За бугром".

Цікавлять також координати людей і орган